Re: CrlDistributionPoint extension

[Petra Gloeckner <gloeckne@xxxxxxxxxxxxxxxx>]

Peter Whittaker wrote:
> 
> At the risk of proposing a solution without having thought about it too
> deeply, it doesn't seem like a great problem.  The cRLDistributionPoint
> extension names the directory entry that would contain the RL that would
> indicate whether the certificate had been revoked.  There is no reason
> why such an entry could not contain multiple values of the revocation
> list in question, that is, multiple values of the
> authorityRevocationList attribute (since these are CA certificates).
> 
> (OK, this may seem like it defeats the point of cRLDistributionPoints,
> but when faced with thorny problems sometimes a little pragmatism is
> needed.)
> 
> The top-level CA could revoke the national CA certificates, creating
> appropriate ARLs, and writing each of these ARLs to the each national
> CA's cRLDistributionPoint entry.  It would then issue new certificates,
> referencing the correct cRLDistributionPoint entry.
> 
> This would mean that in the authorityRevocationList attribute of each
> national CA's cRLDistributionPoint entry, there would be two revocation
> list values, at least until the original national CA certificates had
> expired:  one would be the ARL issued by the top-level CA, and
> containing only the national CA's old certificate, the other would be
> the national CA's current authority revocation list.
> 
> That's where the pragmatism comes in:  the idea of a
> cRLDistributionPoint entry is to allow RLs to broken into more
> manageable chunks (either for reasons of size or revocation reason, or
> what-have-you).  Having two RLs as values of the same attribute in a
> single cRLDistributionPoint entry would seem to violate this idea, but
> the ARL issued by the top-level CA would be small (would only contain
> the national CA's original certificate, and would never grow, as the
> top-level CA has started using its own cRLDistributionPoint entry) and
> this ARL would eventually be removed, that is, once the national CA's
> original certificate expires and need no longer be listed on the ARL;
> the ARL becomes obsolete and is removed.  Note that this ARL will have
> to be long-lived.
> 
> Clients retrieving the ARL from the national CA's cRLDistributionPoint
> entry would find two values, and would have to deal with this, but one
> of those values would be quite small, and would be ignored in most
> cases, as the clients would be looking for an ARL issued by the national
> CA in question.
> 
> Note that the national CA, if it uses the potential maximum size of the
> RL as a criteria for deciding when to create a new cRLDistributionPoint
> entry (for example, to accommodate clients with memory limitations),
> would have to adjust its size criteria accordingly (memory limit -
> (safety factor + sizeof("the little ARL"))).
> 
> >This would require that for the duration of this operation the top-level CA
> >be given write-access to each national CA's cRLDistributionPoint entry;  once
> >the operation completes, this access could be revoked; alternatively, the
> >ARLs could be transferred to the national CAs in some out-of-band manner, and
> >they would write them into the directory themselves, thereby avoiding any
> >potential problems with opening their directory access permissions.
> >
> >Maybe it's not such a bad idea after all to change the meaning of
> >this extension in a way that a CA certificate really contains its OWN
> >CrlDistributionPoint instead of the issuing CA's CrlDistributionPoint !
> >Then this extension would be used in CA certificates only.
> 
> No, this would cause interoperability problems, grief, and churn for
> those who used the cRLDistributionPoint as it was intended (I suspect
> that this is a large-and-getting-larger percentage of the
> V3-cert-and-V2-RL-using community).  Furthermore, it would require that
> the issuer CA always have write access to the subject's
> cRLDistributionPoint entry, something which may be unpopular with the
> managers of the subject's directory (they may be willing to allow it for
> a single operation, but probably not on an ongoing basis).
> 
> pww

No, it wouldn't require that the issuer CA has write access to the 
subject's cRLDistributionPoint entry.
Each CA publishs his CRL at his own cRLDistributionPoint. Only the 
verification procedure will be different because a certificate user 
won't find the respective cRLDistributionPoint in the user certificate 
but one level above in the issuing CA's certificate.
So the certificate extension cRLDistributionPoint wouldn't contain the  
CRL which might contain this certificate, but the CRL issued by this CA
which might contain certificates issued by this CA.

But I agree with you that probably too many people have already 
implemented the X.509v3 extensions, so there would be great 
interoperability problems.

Thank you very much for the detailed answer. I will recommend to our top 
level CA to follow the proposed procedure.

Best regards, Petra