Subject: RE: What if the CRL distribution points for a CA change?

From: Sharon Boeyen <[email-masked]>
Date: Wed, 1 Mar 2000 10:14:42 -0500

Need to separate these into two separate issues:

1) Multiple name forms for the same CRL DP
2) Changing the value of a name form for a CRL DP

1 is accomodated in the CRL DP extension itself. You can allow 
access to the same CRL via various mechanisms through the
DistributionPointName
component of the cRLDistributionPoints extension. The syntax for the
fullName choice 
is GeneralNames so more than one name form for the the same CRL DP can be
included.
Note that the X.509 DAM contains an Annex on CRL generation and processing
(written 
by Santosh) that explains how these are used on the processing side.

2 - This requirement (and some other related ones) has been addressed in the
X.509 DAM. The 
statusReferrals extension is a new CRL extension that serves two purposes.
One is to publish 
a "trusted list" of CRLs to help relying parties find the CRLs of interest
to them (in case 
CRL DP is not included in a cert) and the other is to redirect a relying
party when following 
a pointer (e.g. a CRL DP extension in a cert) that has been changed since
the cert was issued. 
For details see 12.5.2.6 of the 509 DAM at:

ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc

If you prefer to work from the draft restructured complete 509 document, let
me know and I'll 
send a copy to you. I expect to have this available on the web as well
shortly.  

> -----Original Message-----
> From: Tammy Green [mailto:[email-masked]]
> Sent: Friday, February 25, 2000 1:27 PM
> To: [email-masked]
> Subject: Re: What if the CRL distribution points for a CA change?
> 
> 
> Some clarification seems to be in order....
> 
> The idea of having multiple distribution points in a 
> certificate seems very reasonable in our context at Novell.  
> For our PKI, it is quite convenient to name at least two 
> distribution points:  one which is an X.500 name and one 
> which is an LDAP address.  Since our PKI is integrated with 
> our directory (NDS), it is natural for us to prefer 
> retrieving the CRLs directly from NDS rather than using LDAP. 
>  But, because there are applications out there that are not 
> NDS-aware, we'd like to include other distribution points 
> which can be accessed from outside of the company via HTTP or LDAP.  
> 
> As for changing the distribution points, there are a couple 
> of scenarios that I can envision where they would be changed. 
>  How true-to-life these scenarios are is something that I'm 
> hoping to discover.
> 
> 1.  The one externally-available distribution point (say it 
> is LDAP) currently listed in the certificates just doesn't 
> have enough bandwidth to accommodate all the queries.  Or, 
> the software package that the CEO of the company is using 
> can't use LDAP to get CRLs ? it must use HTTP.  The CA 
> Administrator is forced to add additional distribution points 
> to accommodate other protocols and/or unexpected traffic.
> 
> 2.  One of the distribution points is being phased out (for 
> whatever reason).  Maybe the company no longer wants to 
> support LDAP access to its directory.  Or maybe the company 
> has made an agreement with another organization to post its 
> CRLs on their high-volume servers.
> 
> 3.  The CA in question issues a million certificates a year 
> and expects that half of all of those certificates will be 
> revoked.  The CRLs for that CA would become quite large, and, 
> after some calculations, the CA Administrator decides that 
> CRLs of that size are unacceptable.  He therefore decides to 
> change the CRL distribution points every year.  So, 
> basically, for those certificates issued in the first year, 
> their CRLs would be found on distribution points A and B.  
> For those certificates issued in the second year, their CRLs 
> would be found on distribution points C and D.  If my option 
> (b) were used here, then the CRLs found on A, B, C, and D 
> would contain a maximum of 1 million certificates 
> certificates each in the worst case where all the 
> certificates were revoked (CRL on A = CRL on B; CRL on C = 
> CRL on D; CRL on A != CRL on C).  [If option (a) were used 
> here, the CA Administrator would have a nasty surprise in 
> that the CRLs on A, B, C, and D would be exactly the same and 
> contain 2 million certificates in the worst case scenario.]
> 
> 
> Are these scenarios something that you would find in the real 
> world?  If so, then is it acceptable to make the CRLs on all 
> distribution points ever specified the same?  Or, should they 
> contain only the minimum number of certificates?
> 
> 
> Tammy Green
> [email-masked] 
> Software Engineer
> Novell, Inc.
> 
> >>> "Bob Jueneman" <[email-masked]> 02/24/00 09:55PM >>>
> Don't do that?
> 
> I.e., :
> 
> 1.  Don't issue certificates containing multiple distribution points.
> 
> 2.  If issuing certificates with multiple distribution points 
> is absolutely necessary (for some reason I can't quite 
> fathom), don't change the distribution points unless you are 
> prepared to implement option b.
> 
> If we restrict the type of distribution points to LDAP 
> queries, wouldn't it be possible to remap the DNS name of the 
> server as might be required for load balancing, leaving the 
> LDAP query itself unmodified?  Doesn't this eliminate the 
> entire problem?
> 
> Bob
> 
> 
> 
> >>> Tammy Green 02/24/00 08:58PM >>>
> Say a CA begins minting certificates with distribution points 
> A, B, and C in the certificates.  It issues 10 certificates.  
> Then, at time t1, it changes the distribution points to A, D, 
> and E and issues 10 more certificates.
> 
> Now say that at time t2 certificate 1 was revoked as well as 
> certificate 11.  What should the CA do when it comes time to 
> issue the CRL?  [Assume here that the CA is only issuing a 
> basic CRL that is not subdivided by reason codes, etc.]  It 
> appears that there are two options.
> 
> (a)  Issue one CRL containing entries for certificate 1 and 
> 11.  Post that CRL to distribution points A, B, C, D, and E.
> 
> (b)  Issue one CRL containing entries for certificate 1 and 
> 11 and post that CRL to distribution point A.  Then issue 
> another CRL containing an entry for only certificate 1 and 
> post that CRL to distribution points B and C.  Finally issue 
> yet another CRL containing an entry for only certificate 10 
> and post that CRL to distribution points D and E.
> 
> Option a has the disadvantage of causing needless bloat to 
> the CRLs posted on distribution points B, C, D, and E:  no 
> one will look for revocation information about certificate 1 
> on distribution point D or E, and, likewise, no one will look 
> for revocation information about certificate 11 on 
> distribution point B or C.  Option a does have the advantage 
> of being far easier to implement, however.
> 
> Option b has the disadvantage of being much more complex.  
> And, each time the set of distribution points is modified, 
> the complexity increases as does the time required to 
> generate all of the CRLs which are required.  However, the 
> advantage is that the CRLs that are posted to the 
> distribution points contain only useful information.
> 
> Are there other solutions?  Preferences?  Implementations?  
> Guidelines?
> 
> 
> Tammy Green
> [email-masked] 
> Software Engineer
> Novell, Inc.
> 
>

---

From: "Tammy Green" <[email-masked]>
Date: Wed, 01 Mar 2000 14:19:57 -0700

The X.509 DAM has proved to be quite enlightening.  As it turns out, I was trying to address the two issues which you highlight as well as a third issue:

3) Limiting the scope of a CRL

all at once using only those extensions defined in RFC 2459 (and the new part1 draft).  The crlScope and statusReferrals extensions provide exactly what I need.

What are the status of these extensions?  Are they going to be put into the new part1 draft?

And, if you could send me a copy of the restructured X.509 doc when it's ready I'd be most appreciative.

Thanks!

Tammy Green

>>> Sharon Boeyen <[email-masked]> 3/1/00 8:14:42 AM >>>

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 2 Mar 2000 09:01:29 -0500 (EST)

Sharon,

Tammy's question raised a question in my mind - the two issues you
identify (multiple DPs and changing DPs) and a third: identifying the
CRL(s) which apply to a certificate.

The first two are operational issues - how can the RP know where to
find revocation information.  Ideally the RP could look for CRLs in
application-configured locations, CRL DP URIs, locations configured in
a network naming service, etc., and the locally-configured locations
could be changed on the fly without any involvement of the CA.

The third is a security issue - CAs and RPs must have a common
understanding of what constitutes the entire set of revocation
information for a given cert.  This trust linkage could be accomplished
with a location-independent identifier, in the same manner that
subjectKeyIdentifier/authorityKeyIdentifier link a cert to an
appropriate parent.

To solve Tammy's problem, would it not be appropriate to place
a directoryName (or maybe even a registeredID) in
DistributionPointName:fullName, and use some non-CA mechanism to
configure the RP applications to locate and retrieve the CRLs?

Dave

> From: Sharon Boeyen <[email-masked]>
> To: "'Tammy Green'" <[email-masked]>, [email-masked]
> Subject: RE: What if the CRL distribution points for a CA change?
> Date: Wed, 1 Mar 2000 10:14:42 -0500 
>

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 2 Mar 2000 09:11:00 -0500

The status of the DAM and its contents is:
 
Technically, the collaborative ITU-T / ISO/IEC group believes it is solid
and it has completed the early round ballots in ISO. Many folks have 
been pointing out editorial and ASN.1 bugs and I am having these addressed
at the next ITU-T meeting later this month.
 
From a process standpoint, the next step is the ITU-T approval. The docs
will be considered formally by ITU-T SG 7 at this month's meeting. 
Assuming approval from that group, then the final ISO/IEC ballot will occur
later this year (probably the summer/fall timeframe) and we will 
hopefully have the next edition of X.509 formally approved by both bodies by
year end.
 
Bugs and defects will of course continue to be addressed, but as editor, I
currently envision no major changes to the technical content, based 
on formal and informal feedback.
 
Tammy, I'll forward a copy of the combined draft separately to you.
 
Sharon

-----Original Message-----
From: Tammy Green [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 4:20 PM
To: [email-masked]; [email-masked]
Subject: RE: What if the CRL distribution points for a CA change?

The X.509 DAM has proved to be quite enlightening.  As it turns out, I was
trying to address the two issues which you highlight as well as a third
issue:

all at once using only those extensions defined in RFC 2459 (and the new
part1 draft).  The crlScope and statusReferrals extensions provide exactly
what I need.
 
What are the status of these extensions?  Are they going to be put into the
new part1 draft?
 
And, if you could send me a copy of the restructured X.509 doc when it's
ready I'd be most appreciative.

Thanks!
 
Tammy Green

ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc
<ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc>