RE: CrlDistributionPoint extension

[Peter Whittaker <pww@xxxxxxxxxxx>]

>Our top level CA has issued certificates to national CAs containing
>the national CA's CrlDistributionPoint rather than its own 
>CrlDistributionPoint. 
>Well, this was not the way they were supposed to do it, at least not
>the way the X.509v3 standard defines this extension. But what do we
>do now ? 
>
>If the top level CA revokes all these certificates nobody will know
>that they are revoked because the respective certificates contain
>the wrong CrlDistributionPoint.

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