Subject: RE: Possible clarification to RFC 2459

From: Tom Biskupic <[email-masked]>
Date: Tue, 8 Jun 1999 11:12:11 +0100

Alex, Ambarish,Russ,

Something to take into account here is that some CAs may use the IDP for 
full CRLs in order to distinguish them from a ARLs. I see this as a 
requirement for CAs posting to directories in which case the CRL and ARL go 
into the same location and without this extension, are indistinguishable.

This makes the criteria somewhat more muddy as a partial CRL is then 
defined as one which has an IDP containing a DP that is not the same as the 
default location for the issuing CA. That is, the only way to tell if this 
is a partial CRL is that it has something in the IDP to say it was issued 
to somewhere different to the default location.

You could argue that splitting a CRL between a CRL/ARL is effectively 
partitioning however in most cases the question you want answered is 
'Should this CRL contain this end user certificate if it is revoked" and 
this criteria won't help.

Now if CDPs where being used just to allow full CRLs to be published to a 
URI or some other type of location (ie a full CRL published to a URI) then 
you have no way to tell at all.

Tom Biskupic

On Tuesday, June 08, 1999 4:07 AM, Alex Deacon [SMTP:[email-masked]] 
wrote:
>
> OK, on first though this sound like a reasonable way to specify a full 
CRL.
> Basically, what you are saying is that if a cert using application gets a
> cert which contains a CDP pointing to a particular partition, but for 
some
> reason this application only has a CRL which does not contain an IDP, 
then
> they can be confident that they can verify the status of the cert based 
on
> this CRL.
>
> Right?
>
> Alex
>
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[email-masked]]
> > Sent: Monday, June 07, 1999 3:06 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: Possible clarification to RFC 2459
> >
> >
> >
> > I agree with what Tom wants - would like to be able to
> > distinguish whether a CRL is a full or a partial CRL. Can we
> > add the following paragraph to section 5.2.5:
> >
> > A full CRL from/for a CA MUST NOT contain the
> > issuingDistributionPoint extension, unless it is an indirect CRL,
> > in which case, it MAY contain the issuingDistributionPoint
> > extension with only the indirectCRL field set to true.
> >
> > Would this work for most people? Any objections?
> > Ambarish
> >
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect					         650.567.5457
> > ValiCert, Inc.				
> > [email-masked]
> > 1215 Terra Bella Ave.		              http://www.valicert.com
> > Mountain View, CA 94043-1833
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf
> > > Of [email-masked]
> > > Sent: Monday, June 07, 1999 8:25 AM
> > > To: Ambarish Malpani; [email-masked]
> > > Subject: Possible clarification to RFC 2459
> > >
> > >
> > >      The current definition of Issuing Distribution Point
> > > leaves it relatively
> > > unclear whether the presence of the "DistributionPoint" field
> > > within this
> > > extension indicates that the CRL at that distribution point
> > > is a partial CRL.  I
> > > would like to suggest that the following text be added to RFC
> > > 2459 section
> > > 5.2.5:
> > >
> > >      Where the issuingDistributionPoint extension contains
> > > either a DN or an
> > > RDN, the distribution point SHOULD contain only certificates
> > > which contain a CRL
> > > Distribution Point extension one of whose DistributionPoint's
> > > contains the same
> > > value in the "distributionPoint" field.
> > >
> > >      To make it clear that CRL Distribution Point's support
> > > partitioning even
> > > for URL's, the following existing text in section 4.2.1.14
> > > could be modified as
> > > follows:
> > > [Old]     the URI is a pointer to the current CRL for the
> > > associated reasons and
> > > will be issued by the associated cRLIssuer.
> > > [New]     the URI is a pointer to a current CRL for the
> > > associated reasons for
> > > those certificates and will be issued by the associated
> > > cRLIssuer.  The CRL so
> > > referenced SHOULD contain only certificates whose CRL
> > > Distribution Point
> > > extension contains this URI and certificates not containing
> > > any CRL Distribution
> > > Point extension.
> > >
> > >           Tom Gindin
> > >
> > >
> > >
> > >
> >

---

From: Tom Biskupic <[email-masked]>
Date: Tue, 8 Jun 1999 19:06:44 +0100

Ambarish,

Yes I understand what you are saying. Yes as I said you could argue (and in 
fact you did) that in the case where you have a CRL/ARL split the presence 
of an IDP does indicate the CRL has been partitioned but I am saying there 
is no way to tell if the CRL has been split in other ways.

The issue is based on my assumption that there will be many systems that 
split a CRL into a CRL and ARL but few that split further. If a CRL 
containing a IDP is encountered which has the 'onlyContainsUserCerts' 
optional flag (which we believe is a common occurence) there is no way to 
tell if the set of revoked certificates has been partitioned further or if 
this is the only split criteria. Ok strictly speaking the CRL is split but 
in this case that's not very useful as what you really want to know is 
where to go to check the validity of the (usually) end user certificate you 
are holding.

A more serious problem occurs in the second case I highlighted - an 
organisation has no directory service (ie an LDAP server) so they 
distribute their CRLs through a URI. Every issued certificate (maybe even 
including CA certificates) contains a CDP extension pointing at this URI. A 
complete CRL is posted to that location every day. In this case the 
presence of an IDP extension in the CRL does not indicate a partial CRL. 
Essentially the lack of an IDP implies a full CRL but the presence of an 
IDP may not indicate a partial CRL.

Where does that get us? Hmm I'm not sure.

Tom Biskupic

On Tuesday, June 08, 1999 6:42 PM, Ambarish Malpani 
[SMTP:[email-masked]] wrote:
> I am not clear why what I proposed wouldn't work.
>
> Assumption: A full CRL contains *all* the revoked and unexpired
> certs issued by this CA. This would include both end user and
> CA certs.
>
> The full CRL doesn't need to contain the IDP extension unless it
> is an indirect CRL, in which case, it will contain the IDP
> extension, but with *only* the indirectCRL field set.
>
> You could still issue end user CRLs with IDP and
> onlyContainsUserCerts set or ARLs, with IDP and onlyContainsCACerts -
> neither of these are the full CRL.
>
> Am I missing something?
>
> Regards,
> Ambarish
>
>
> ValiCert, Inc.				        [email-masked]
> > Of [email-masked]
> > Sent: Tuesday, June 08, 1999 5:23 AM
> > To: Tom Biskupic
> > Cc: 'Alex Deacon'; Ambarish Malpani [[email-masked]] (E-mail);
> > Ietf-Pkix (E-mail)
> > That's precisely what Jonah does - we need to be able to determine by
> > inspection whether a given CRL is a user CRL or an ARL, and
> > the only way we
> > could find to do this was to use the "onlyContainsUserCerts" and
> > "onlyContainsCACerts" flags within the IDP extension.
> >
> > John
> >
> >
> >
> >
> >
> > Tom Biskupic <[email-masked]>@imc.org on 06/08/99 06:12:11 AM
> >
> > Sent by:  [email-masked]
> >
> >
> > To:   "'Alex Deacon'" <[email-masked]>, "Ambarish Malpani
> >       [[email-masked]] (E-mail)" <[email-masked]>
> > cc:   "Ietf-Pkix (E-mail)" <[email-masked]>
> >

---

From: [email-masked]
Date: Tue, 8 Jun 1999 19:34:15 -0400

Russ Housley <[email-masked]> on 06/08/99 08:11:53 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: Possible clarification to RFC 2459

Tom:

Your proposed text is too simple.  Consider the Indirect CRL case.  CA1
uses a CRL Distribution Point (CDP) extension to specifify that CA2 will
issue CRLs for reason CA compromise.  Also, CA3 uses a CRL Distribution
Point (CDP) extension to specifify that CA2 will issue CRLs for reason key
compromise.  So, CA3's CRL must include at least reason codes for CA
compromise and key compromise.

Russ

[Tom Gindin]   The proposed amendment is not intended to restrict the use of the
other four fields in Issuing DP.  It merely states that all those certificates
included under a DP whose Issuing DP extension contains a directory name should
be ones issued with that name in the CRL DP extension.  In the Indirect CRL
case, don't the certificate-issuing CA's include the name of the distribution
point to be used?

At 11:25 AM 6/7/99 -0400, [email-masked] wrote:
>     The current definition of Issuing Distribution Point leaves it relatively
>unclear whether the presence of the "DistributionPoint" field within this
>extension indicates that the CRL at that distribution point is a partial
>CRL.  I
>would like to suggest that the following text be added to RFC 2459 section
>5.2.5:
>
>     Where the issuingDistributionPoint extension contains either a DN or an
>RDN, the distribution point SHOULD contain only certificates which contain a
>CRL
>Distribution Point extension one of whose DistributionPoint's contains the
same
>     To make it clear that CRL Distribution Point's support partitioning even
>for URL's, the following existing text in section 4.2.1.14 could be
modified as
>follows:
>[Old]     the URI is a pointer to the current CRL for the associated reasons
>and
>[New]     the URI is a pointer to a current CRL for the associated reasons for
>those certificates and will be issued by the associated cRLIssuer.  The CRL so
>referenced SHOULD contain only certificates whose CRL Distribution Point
>extension contains this URI and certificates not containing any CRL
>Distribution
>Point extension.
>
>          Tom Gindin
>
>

---

From: Tom Biskupic <[email-masked]>
Date: Wed, 9 Jun 1999 09:39:02 +0100

Dave,

I was thinking of the case where you have a certificate without a CDP 
extension and you have a cached CRL containing an IDP. Do I need to get 
another CRL or should this certificate be contained in the one I have?

I think the bottom line is you can only use the CRL if its DP matches your 
certificate's (either explicitly through a CDP extension or implicitly). 
Presence/absence of an IDP is not enough to determine this.

I'm really arguing against Ambarish's statement (and not som much the other 
Tom's [TomG's] original comments) so I guess we are off-topic a bit:-

"A full CRL from/for a CA MUST NOT contain the
issuingDistributionPoint extension, unless it is an indirect CRL,
in which case, it MAY contain the issuingDistributionPoint
extension with only the indirectCRL field set to true."

Tom Biskupic

On Tuesday, June 08, 1999 8:30 PM, David P. Kemp 
[SMTP:[email-masked]] wrote:
>
> > From: Tom Biskupic <[email-masked]>
> > To: "'Ambarish Malpani'" <[email-masked]>
> > Cc: "[email-masked]" <[email-masked]>, "'Tom Biskupic'"
> <[email-masked]>, "'Ietf-Pkix (E-mail)'" <[email-masked]>, 
"'Alex
> Deacon'" <[email-masked]>
> Tom,
>   As you say, the presence of an IDP extension (with onlyUserCerts,
> onlyCACerts, and onlySomeReasons all absent) in the CRL does not indicate
> whether the CRL covers every cert issued by the CA or only some certs.
> A CA's CRLs could, for example, be partitioned by serial number, or by
> the phase of the moon at the start of the certificate's validity, or at
> random.
>
> But why is that a problem?  If you have a cert with CrlDP, then you can
> determine the revocation status of that cert unambiguously without
> needing to know whether the CRL is full or partial.  That is a feature,
> not a bug, because it allows CAs to do dynamic partitioning.
>
> If you have a set of certs without CrlDP, then the CA has chosen not to
> partition those certs in a manner that can't be described in the IDP,
> and the status of any particular cert is still unambiguous.
>
> Why do people feel it is necessary or desirable to know whether a given
> CRL is full or partial?  The only question that must be answered is
> whether a CRL or set of CRLs is complete with respect to a given
> certificate.  RFC 2459 already satisfies that requirement.  Any
> "clarification" to RFC 2459 that would prevent a CA from issuing new
> certs under a different CRL than existing certs is undesirable.
>
> Dave Kemp
>
>
>
> > Date: Tue, 8 Jun 1999 19:06:44 +0100
> >
> > Ambarish,
> >

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 9 Jun 1999 10:31:27 -0400 (EDT)

> another CRL or should this certificate be contained in the one I have?

I believe Russ' analysis answered the question.  If the cached CRL is not
an ICRL, and it is not partitioned by user/CA/reasons, then the cert without
a CRLdp MUST be contained in the cached CRL.

In other words, the *only* way to do partitioning other than by
user/CA/reasons is by using CRLdp extensions in certificates.

I think it is already obvious, but would not disagree with the following
clarification:

  "A CRL containing an issuingDistributionPoint extension with the
  distributionPoint field present MUST be authoritative for all
  certificates* that do not contain a CRLDistributionPoints extension."
  
  *user certs, CA certs, or both, as specified in the IDP.

> extension with only the indirectCRL field set to true."

I disagree with this restriction, because it prevents the cached CRL
(which may have been pushed or manually configured) from containing
a pointer enabling its successor to be pulled.

---

From: [email-masked]
Date: Wed, 9 Jun 1999 11:43:20 -0400

"David P. Kemp" <[email-masked]> on 06/09/99 10:31:27 AM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Possible clarification to RFC 2459

[Tom Gindin]   Should that really be "with the distributionPoint field present"
or "without the distributionPoint field present"?  It would seem to be true when
the distributionPoint field is absent.  I would say that "A CRL containing an
issuingDistributionPoint extension with the   distributionPoint field containing
a DN MUST be authoritative for all   certificates that contain that value of the
field in their  CRLDistributionPoints extension", and also that "A CRL
containing an issuingDistributionPoint extension without the distributionPoint
field present MUST be authoritative for all certificates* that do not contain a
CRLDistributionPoints extension."  What isn't obvious, I suppose, is whether
CRL's at named distribution points (with a DN name, as there are specifics about
DP's with URI names) cover certificates without distribution points.

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 9 Jun 1999 17:00:37 -0400 (EDT)

>> [Dave]

> the distributionPoint field is absent.

I meant "with the distributionPoint field present or absent", but intended to
emphasise that the case where it is present should be interpreted no differently
with respect to certs without CRLdp than the case where it is absent.

> I would say that "A CRL containing an

Tom,
That is an excellent statement of the problem!

Assume that a CA issues three certs with:
  Cert1[no CRLdp]  Cert2[CRLdp 2]    Cert3[CRLdp 3]

And assume that the CA may publish three CRLs, with the following
distributionPoint fields:
  CRL1[no DP]      CRL2[DP 2]        CRL3[DP 3]

Then the CRLs are authoritative for the following certs:

  CRL1             CRL2              CRL3
  -----            -----             -----
  Cert1            Cert1?            Cert1?
  Cert2            Cert2               -
  Cert3              -               Cert3

As you say, it may not be obvious that CRLs at named distribution
points cover certs without distribution points (the ones marked
with a ? in the table).

I believe that RFC 2459 should be clarified, if necessary, to ensure
that CRL2 and CRL3 MUST be authoritative for Cert1.  That way, CRL2 can
be regarded as a "full CRL", so can CRL3, and the CA has maximum
flexibility in deciding whether to populate the CRLdp extension in its
certs.  A CA taking maximum advantage of dynamic partitioning would
never have to issue a bulky CRL1 but could still meet the requirement
of publishing a "full CRL".

That's why I disagree with Ambarish's proposal that only CRL1 (the one
with no DP field) be defined as a "full CRL".

---

From: [email-masked]
Date: Wed, 9 Jun 1999 18:51:40 -0400

Dave has proposed that all CRL's, whether they have a distributionPoint
field in their IDP (issuingDistributionPoint) extension or not, must be
considered authoritative for those certificates issued by that CA which do not
have distribution points.  Because of the potentially very large number of CRL's
with distributionPoint fields containing DN's for such CA's, I propose that they
should not be considered authoritative for such certificates, but only those
CRL's which are either missing the IDP extension or have no DN in its
distributionPoint field should be considered authoritative for such
certificates.
     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

"David P. Kemp" <[email-masked]> on 06/09/99 05:00:37 PM

To:   [email-masked]

Tom,

  CRL1             CRL2              CRL3
  -----            -----             -----
  Cert1            Cert1?            Cert1?
  Cert2            Cert2               -
  Cert3              -               Cert3

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 10 Jun 1999 10:58:53 -0400 (EDT)

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: [email-masked]
>   [...]