RE: Possible clarification to RFC 2459

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

The preferred approach depends on how we choose to define "CA" for
scoping the requirement to "issue complete CRLs covering all
certificates it issues".

One could regard a CA as a "virtual CA" covering a single distribution
point, and the complete CRL requirement would be satisfied by a CRL
which covers all user certs, all CA certs, and all revocation reasons
for that distribution point plus all non-DP certs.

Or one could regard a CA as a single issuer DN, in which case the
complete CRL would cover all user certs, all CA certs, and all revocation
reasons for all distribution points plus all non-DP certs.

Since it is possible to create an arbitrary number of "CAs" (issuer
DNs) operating on a single piece of hardware or run by a single trained
operator, partitioning for CRL scaling purposes can be achieved by
creating more issuer DNs instead of creating more distribution points.
If the goal is to minimize the size of the largest CRL which must
be generated and distributed (through the directory system or otherwise)
when an administrative entity (an equipment operator with a Certificate
Policy) is responsible for a huge number of certs, then there is a
choice between:
1) treating each DP as a virtual CA for completeness purposes, and
2) creating a set of actual CAs (issuer DNs) sharing the same
   operator and CP.

I think that it is more natural and intuitive to have a single DN and a
set of DPs than a set of (somewhat artificial) DNs.  I think that
X.509, by allowing the directoryName form of distributionPoint,
recognizes the value of keeping a single issuer DN for multiple CRL
partitions.  But I recognize that regarding the DN/DP combination as
the definition of "it" in "covering all certificates it issues" might
not be intuitive.


I agree with your likely deployment scenarios.  One way to transition
from non-DP certs to exclusively DP certs would be to initially create
a single DP which is the default location for non-DP certs, and issue
certs (and CRLs) for only that DP until all non-DP certs have expired.
After the transition period has ended, additional DPs can be created.
Under that transition plan, there is no penalty for including non-DP
certs in the DP CRL.

Under a transition plan where a large number of DPs are created
immediately, there is a penalty for including non-DP certs in all of
the DP CRLs, but the penalty is temporary, lasting only until the
non-DP certs expire.

But if there must always be a non-DP CRL that covers all DP and non-DP
certs, then the penalty for maintaining that CRL never goes away.
That's what I'd like to avoid.

  Dave Kemp



> From: tgindin@us.ibm.com
>
>   [...]
>
>      In considering which CRL's should need to contain revocations for non-DP
> certificates (those which contain no CRLDistributionPoint extension), it might
> be useful to consider under what circumstances a CA would have generated both 
DP
> and non-DP certificates.  It seems to me that the  likeliest scenarios are
> first, that a software upgrade has been performed that "turns on" distribution
> points as a feature so that old certificates are non-DP while new ones are DP;
> second, that CA certificates are considered as belonging to an existing
> partitioned CRL of manageable size (one with no name, but with the
> onlyContainsCACerts flag set) so that they are non-DP while user certificates
> are DP; and third, a combination of the two effects, in which the only new
> non-DP certificates are CA certificates.  In all of these cases, no new non-DP
> user certificates are being issued.
>      The other issue here is how a verifier gets a CRL and then knows that he
> has obtained the correct CRL.  For any non-DP certificate, the verifier will
> have to try to get the CRL from the default repository for the CA.  Since the
> global CRL will have to be maintained anyway, in conformance to X.509's note f
> to section 12.6.1 (June '97 version) which states, "every CA shall, as a 
common
> fall-back approach, issue complete CRLs covering all certificates it issues", 
it
> will presumably be reachable there.  Thus I don't see why other CRL's should
> have to include the non-DP certificates.
> 
>           Tom Gindin