Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

From: Santosh Chokhani <[email-masked]>
Date: Mon, 20 Feb 2012 19:59:56 -0500

As mentioned before the author of the e-mail reads 5280 incorrectly and has exhibited a genuine lack of understanding or refusal to understand how IDP, CRL DP and partitioning work.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, February 20, 2012 10:38 AM
To: Tomas Gustavsson
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Tomas Gustavsson wrote:
> 
> Martin Rex wrote:
> > Tomas Gustavsson wrote:
> >>
> >> Just as a funny of-topic mention. A CRL with 10M revoked entries is 
> >> about 400-500MB large. Very useful :-)
> >
> > As I indicated here:
> >    https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html
> >
> > I strongly believe that a CA (i.e. that specific DName) should be 
> > retired when the expected growth of the CRL during the remaining 
> > lifetime of the all certs singed with that exact issuer DName 
> > exceeds a reasonable size.
> >
> > The US government is operating several CAs with CRLs carrying>1 
> > million CRLEntries (1080 Millon = 22 MBytes), which is IMO far 
> > beyond a resonably sized CRL.
> >
> > Instead of partitioning CRLs, the CA should simply get a new CA cert 
> > issued (simply bumping a Serialnumber AVA in the subject DName of 
> > the CAs certificate would be sufficient), at which point it will 
> > automatically start with a fresh, empty CRL, and this will work 
> > nicely with *ALL* RPs.
> 
> Since CRLs needs to be maintained as long as the end entity 
> certificates are active, all issued end entity certificates of a given 
> CA can potentially become revoked, hence the CRL may contain all these entries.

I had that case explicitly covered above.  Not a problem.  Just move to a different CA cert early enough.  This is not about worst case, but what should be reasonably expected, with some safety margin.

> 
> This means that any given CA is only allowed to issue as many 
> certificates as is reasonable to have on a CRL. If you think it is 
> 500.000, any given CA is only allowed to issue 500.000 CRLs, this 
> seems cumbersome way beyond usability.

Just the contrary.  Managing risk sensibly means that you want to limit the value of any single CA keypair, so that if anything very bad happens, you don't have to nuke the entirey PKI, but only that part of it that is actually affected.  Limiting the number of certs that are signed with a single CA keypair can significantly help here, and will work with every conforming RP, while only partitioning CRLs based on distribution point will not help at all, but may create interop problems with conforming RPs and makes things actually slower, because the CA MUST still provide the full CRL in addtion to the zoo of partitioned CRLs, and it is difficult to see how you can mix them in a fashion that they not intefere with each other, becaus the CRL distribution point extension of the certificate (rather than that of the CRL) does not support paritioning of CRLs based on distribution point names, only on reason codes.

> 
> In reality CAs can issue 10M certificates within days, I surely don't 
> want to renew these CAs as that pace.

That is not necessarily a problem, if you do not expect your CRLs to grow at the same rate (10M revocations within days).

The partitioning of CRLs by distribution point is ill-conceived, no matter how you look at it.  Whether a CA uses partitioning by CRL distribution point is *NOT* visible in the CRL distribution point extension of the Certificate at all!

Quoting from rfc5280 Section 6.3:
   http://tools.ietf.org/html/rfc5280#section-6.3

   This algorithm assumes that all of the needed CRLs are available in a
   local cache.  Further, if the next update time of a CRL has passed,
   the algorithm assumes a mechanism to fetch a current CRL and place it
   in the local CRL cache.

An RP with an efficient implementation of revocation checking will be using CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so that a revocation check will incur a single table lookup keying on issuer&serial, and zero PK-crypto operations and zero third party network communication in-band while authenticating peers.

-Martin
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Feb 2012 15:34:48 +0100 (MET)

Santosh Chokhani wrote:
> 
> As mentioned before the author of the e-mail reads 5280 incorrectly
> and has exhibited a genuine lack of understanding or refusal to
> understand how IDP, CRL DP and partitioning work.

I'm only reading the specification the way it is written.
And I'm apply formal logic to determine the "permissible interpretations"
for those many areas that are unclear and ambiguous.

Your interpretation of the spec, while not uncommon for people arguing
natural language, is outside of formally valid interpretation, I'm sorry.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 22 Feb 2012 05:21:13 -0500

Your formal logic in this case is in serious need of debugging.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2012 9:35 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Your interpretation of the spec, while not uncommon for people arguing natural language, is outside of formally valid interpretation, I'm sorry.

-Martin

> > >> Just as a funny of-topic mention. A CRL with 10M revoked entries 
> > >> is about 400-500MB large. Very useful :-)
> > >
> > > As I indicated here:
> > >    
> > > Instead of partitioning CRLs, the CA should simply get a new CA 
> > > cert issued (simply bumping a Serialnumber AVA in the subject 
> > > DName of the CAs certificate would be sufficient), at which point 
> > > it will automatically start with a fresh, empty CRL, and this will 
> > > work nicely with *ALL* RPs.
> > 
> > certificates are active, all issued end entity certificates of a 
> > given CA can potentially become revoked, hence the CRL may contain all these entries.
> 
> > In reality CAs can issue 10M certificates within days, I surely 
> > don't want to renew these CAs as that pace.
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 22 Feb 2012 12:11:39 -0800

I think it would be more useful if you explained what you think 5280 is supposed to be saying.

There seem to be a significant number of people who believe that neither CRLs, nor OCSP provide the revocation functionality which is actually needed.  There also seem to be people (like you?) who believe that, given some kind of meta-knowledge, the existing capabilities and specifications are just fine.  I can't help wondering if that isn't behind some of these more localized disagreements.

>> An RP with an efficient implementation of revocation checking will be using CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so that a revocation check will incur a single table…

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 22 Feb 2012 23:08:15 +0100 (MET)

> Your formal logic in this case is in serious need of debugging.

Debugging is a method to search for defects in trial-and-error
approaches to design and implementation.

If you apply formal correctness proofing to specifications, the
result is provable ambiguities and contradictions.

Maybe you're just not familiar with reviewing specification under
the aspect of formal correctness proofing in order to find out
whether some existing wording is a defect of the spec or some
interpretation that seems conceivable at the natural language
level is actually inconsistent with the specification.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 22 Feb 2012 17:28:14 -0500

5280 is saying that IDP must be critical,

Hence relying party must process the IDP in order to use the CRL.

5280 us saying that if IDP has DP in it, that DP must match one of the DPs in the CRL DP of the certificate of interest in order to ensure that the certificate is covered.

-----Original Message-----
From: Henry B. Hotz [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2012 3:12 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On Feb 22, 2012, at 2:21 AM, Santosh Chokhani wrote:

>>>> cert issued (simply bumping a Serialnumber AVA in the subject DName 
>>>> of the CAs certificate would be sufficient), at which point it will 

------------------------------------------------------
The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Tom Gindin <[email-masked]>
Date: Thu, 23 Feb 2012 20:55:11 -0500

Henry:

        I can't speak for Santosh, but only for myself.  However, I can 
reiterate my position on these things.  First, I don't believe that it's 
feasible to implement the use of more than a few issuers with revocation 
checking unless each certificate includes a transport address for 
revocation information.  The major ways of doing this are OCSP and CRL 
Distribution Points, and CRL Distribution Points work in this way only 
when they include a URL.  It is true that if relying parties need to 
individually configure each of those intermediate certificates which they 
accept, they can configure the corresponding CRL locations for each 
intermediate as well for a few times the effort.
        Second, the use of CRL Distribution Points to assign certificates 
to partitioned CRL's at the time of issuance is a legitimate design choice 
and has been used by major CA's in the past.  For very large scale PKI's, 
it seems IMHO to be more feasible than any other choice.
        My experience with RP deployments leads me to believe that CRL's 
can be used with Distribution Points containing URL's, or with the 
configuration technique I mentioned,  but are not very workable in 
non-internal PKI's otherwise.  It is also crucial NOT to regard nextUpdate 
as a precise expiration time for the CRL.  I don't want to overrate the 
quality of the CRL mechanism, but if you set those criteria and avoid that 
mistake it's at least good for something.  My experience does NOT cover 
browsers or other SSL clients which use more than a few trust anchors, and 
should not be taken to imply that I am sure that CRL's with distribution 
points are good enough for them.

Tom Gindin
P.S. - The opinions above are mine, and not necessarily those of my 
employer

From:   "Henry B. Hotz" <[email-masked]>
To:     Santosh Chokhani <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   02/22/2012 03:13 PM
Subject:        Re: [pkix] AuthKeyId and 
CrlEntryExtension.CertificateIssuer
Sent by:        [email-masked]

I think it would be more useful if you explained what you think 5280 is 
supposed to be saying.

There seem to be a significant number of people who believe that neither 
CRLs, nor OCSP provide the revocation functionality which is actually 
needed.  There also seem to be people (like you?) who believe that, given 
some kind of meta-knowledge, the existing capabilities and specifications 
are just fine.  I can't help wondering if that isn't behind some of these 
more localized disagreements.

>> I had that case explicitly covered above.  Not a problem.  Just move to 
a different CA cert early enough.  This is not about worst case, but what 
should be reasonably expected, with some safety margin.
>> Just the contrary.  Managing risk sensibly means that you want to limit 
the value of any single CA keypair, so that if anything very bad happens, 
you don't have to nuke the entirey PKI, but only that part of it that is 
actually affected.  Limiting the number of certs that are signed with a 
single CA keypair can significantly help here, and will work with every 
conforming RP, while only partitioning CRLs based on distribution point 
will not help at all, but may create interop problems with conforming RPs 
and makes things actually slower, because the CA MUST still provide the 
full CRL in addtion to the zoo of partitioned CRLs, and it is difficult to 
see how you can mix them in a fashion that they not intefere with each 
other, becaus the CRL distribution point extension of the certificate 
(rather than that of the CRL) does not support paritioning of CRLs based 
on distribution point names, only on reason codes.
>> That is not necessarily a problem, if you do not expect your CRLs to 
grow at the same rate (10M revocations within days).
>> 
>> 
>> The partitioning of CRLs by distribution point is ill-conceived, no 
matter how you look at it.  Whether a CA uses partitioning by CRL 
distribution point is *NOT* visible in the CRL distribution point 
extension of the Certificate at all!
>> An RP with an efficient implementation of revocation checking will be 
using CRLs, cache the CRLs and update the CRL cache strictly out-of-band, 
so that a revocation check will incur a single table lookup keying on 
issuer&serial, and zero PK-crypto operations and zero third party network 
communication in-band while authenticating peers.