Subject: RE: Signer certificate discovery for CRLs

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 13 Oct 2004 14:44:32 +0100

Santosh,

I conclude that we are in complete and total agreement.
The question is how to go about this.

Could we do this amendment to RFC 3280 in its next revision?
It would hopefully just be a minor change.

It would not change the definition of AIA just add that it can be used also as CRL extension and list eventual restrictions and guidance for use with CRLs.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 oktober 2004 04:33
> To: 'pkix'
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Stefan:
> 
> In terms of certificate discovery, your proposal for AIA in CRL is more
> robust.  The whole idea of self-issued key rollover certificates and then
> using the new key to issue CRL is fraught with security problems.  A
> secure
> solution would be one where the new key is certified by the parent CA.  In
> that case to obtain the new certificate, you could use AIA in CRL.
> 
> As to indirect CRL, your proposal is a good one.  The CRL DP in
> certificate
> in question points to the indirect CRL.  You get that CRL.  The AIA in CRL
> gets you started for the indirect CRL issuer certification path and you
> are
> in business.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, October 12, 2004 7:30 PM
> To: David A. Cooper
> Cc: pkix
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> 
> David,
> 
> Thanks for the clarifications, they make sense.
> I did misread your pictures.
> 
> So can we conclude that for a re-keyed CA in accordance with RFC 3280,
> either the CRL issuer certificate itself, or the location of the CRL
> issuer
> certificate, will be clearly identified/available for the validating party
> in some cases, but not in others?
> 
> Can we also conclude that there is no real discovery solution for indirect
> CRLs?
> 
> Do you then agree then that it could be appropriate to allow AIA as a CRL
> extension to facilitate discovery of CRL signer certificate?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> ________________________________________
> From: David A. Cooper [mailto:[email-masked]]
> Sent: den 12 oktober 2004 21:14
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> I believe that you are misinterpreting the figures.  They really do
> represent three different cases, not three different certification paths
> that have been constructed through the same PKI architecture.
> 
> In figure 1, CA 1 has generated self-issued key rollover certificates.
> The
> Root CA has issued a certificate to CA 1's new key, but not its old key
> (either the Root CA never issued a certificate to CA 1's old key or that
> certificate has expired).
> 
> In figure 2, CA 2 has also generated self-issued key rollover
> certificates.
> The Root CA has issued a certificate to CA 2's old key, but not its new
> key.
> 
> In figure 3, when CA 3 performed key rollover, it requested a new CA
> certificate from the Root CA.  CA 3 did not generated self-issued key
> rollover certificates.
> 
> Of course, another realistic scenario would be one in which a CA generated
> self-issued key rollover certificates upon key rollover and then had the
> Root CA issue a CA certificate to its new key.  In this case, as you
> suggest, any of the certification paths from figures 1, 2, or 3 could be
> constructed.
> 
> As for the contents of the AIA extension, here is what I have specified in
> the "X.509 Certificate and CRL Extensions Profile for the Common Policy":
> 
> The authorityInfoAccess extension uses URIs for two purposes. When the
> id-ad-caIssuers access method is used, the access location specifies where
> certificates issued to the issuer of the certificate may be found. If LDAP
> is used, the URI must include the DN of the entry containing the relevant
> certificates and specify the directory attribute in which the certificates
> are located. If the directory in which the certificates are stored expects
> the "binary" option to be specified, then the attribute type must be
> followed by ";binary" in the URI. If HTTP is used, the URI must point to a
> file that has an extension of ".p7c" that contains a certs-only CMS
> message
> (see RFC 2633). The CMS message should include all certificates issued to
> the issuer of this certificate, but must at least contain all certificates
> issued to the issuer of this certificate in which the subject public key
> may
> be used to verify the signature on this certificate. .... For a
> certificate
> issued by "Good CA", some examples of URIs that may appear as the access
> location in an authorityInfoAccess extension when the id-ad-caIssuers
> access
> method is used are:
> ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
> te
> ,crossCertificatePair
> ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate;b
> in
> ary,crossCertificatePair;binary
> http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedToGo
> od
> CA.p7c
> For both LDAP and HTTP, the URI provides the exact location where
> information is to be located, so there is no requirement for the relying
> party to try to figure out where information is located.
> 
> The HTTP URI points to a certs-only CMS message that includes all
> certificates issued to the CA identified in the issuer field of the
> certificate.
> 
> The LDAP URI points to the cACertificate and crossCertificatePair
> attributes
> of the directory entry of the CA identified in the issuer field of the
> certificate.  These two attributes together hold all of the certificates
> issued to the CA:  the cACertificate attribute holds the CA's self-issued
> certificates and the crossCertificatePair attribute holds the
> cross-certificates issued to the CA by other CAs.
> 
> Dave
> 
> 
> Stefan Santesson wrote:
> 
> David,
> 
> Thanks for these good thoughts and very useful scenarios.
> 
> I have some comments and questions on this.
> 
> First of all we can conclude that in some scenarios (figure 1) where a
> self
> issued certificate is inserted into the path, you are likely to find the
> CRL
> issuer cert in the path. (given that the new CA have a common key and
> certificate for cert signing and CRL signing).
> 
> Figure 1, 2 and 3 describe the same case. It is just describing different
> path building strategies. An application that has access locally to all
> chaining options may however still choose path 2 for the certs and path 1
> for the CRL independent of each other (which I think figure 3 tries to
> describe)
> 
> Another comment is the structure of AIA extensions. The use I'm familiar
> with doesn't use AIA to describe a directory entry where it is left to the
> validation application logic to be intelligent enough to find appropriate
> certificate data from the directory. The model I'm familiar with is when
> the
> AIA URL explicitly identifies the exact location of the appropriate CA
> certificate file, relieving the validation software from complex
> information
> queries. If just location of explicit certificate files are identified
> through AIA, the presence of an AIA may not help finding the CRL signer
> cert
> if this is different from the CA certificate. This is also the problem
> with
> Denis proposal.
> 
> I think we share the basic conclusion that the ability to locate the CRL
> signer certificate directly through the CRL could be very useful. At least
> in the case of indirect CRL but it could also be proven very useful in CA
> re-keying scenarios.
> 
> The easiest solution would probably be to allow AIA to be used in its
> current shape and structure as a CRL extension (MUST NOT be critical). It
> would present a very clear and uncomplicated logic to certificate
> validating
> applications in many cases.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> ________________________________________
> From: David A. Cooper [mailto:[email-masked]]
> Sent: den 7 oktober 2004 18:35
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> I think what you are proposing is a good idea.  In most cases, path
> discovery algorithms assume that both the trust anchor (or trust anchors)
> and the end entity certificate are provided as input.  In this case, one
> may
> need to construct a certification path without a priori access to the end
> entity certificate (the one with the subject public key corresponding to
> the
> CRL signing key).  Including an AIA extension (or some other pointer) in
> the
> CRL would provide the relying party with a simple way to obtain the end
> entity certificate for the CRL signing key's certification path. On the
> other hand, I believe that a relying party should be able to construct the
> certification path even without an AIA extension in the CRL, so long as it
> is not an indirect CRL.  Attached is a drawing of the three basic
> scenarios
> that I expect a relying party may encounter:
> 
> In each of these scenarios, the CA has performed key rollover and is only
> signing CRLs with its new key.  The diagrams would look similar, however,
> if
> the CA simply choose to use different keys to sign certificates and CRLs
> for
> some other reason.
> 
> If the PKI architecture resembled figure 1, then the certification path
> for
> the CRL signing key would just be a subset of the certification path for
> the
> EE certificate, so no addition path discovery would be needed.
> 
> If the PKI architecture resembled figure 1, then it would be necessary to
> obtain the new-signed-with-old self-issued certificate.  In building the
> certification path to the EE certificate, however, the relying party will
> obtain the certificates pointed to by the AIA extension in the EE
> certificate.  This AIA extension will point to a location containing all
> certificates issued to CA 2, which would include both the certificate
> issued
> by the Root to CA 2 and CA 2's self-issued certificate.  So, even though
> the
> self-issued certificate would not be part of the certification path to the
> EE certificate, it would be downloaded by the relying party during the
> construction of that certification path.  (Yes, there are circular
> dependency issues in figure 2, but that is another issue.)
> 
> A similar situation would happen if the PKI architecture resembled figure
> 3.  The AIA extension in the EE certificate would point to a location
> containing certificates issued to CA 3.  When the relying party downloaded
> these certificates, it would obtain both of the certificates issued by the
> Root to CA 3 and so again would have the certificate needed to validate
> the
> CRL signing key.
> 
> In the case of an indirect CRL, things may not work as well.  If indirect
> CRLs were used, and the PKI architecture resembled figures 2 or 3
> (replacing
> "New Key" with a different CA), then the set of certificates pointed to by
> the AIA extension in the EE certificate would not include the certificate
> of
> the CRL signer.  One could find this certificate by building in the
> reverse
> direction and using the SIA extension, but that may not be the most
> convenient solution.
> 
> So, when indirect CRLs are being used, it seems that it would be very
> useful
> to have a pointer in the CRL to the CRL signing certificate.  When the CRL
> is not indirect, the need for this pointer does not seem to be as clear,
> but
> I can't see any harm in including it.
> 
> Dave
> 
> Stefan Santesson wrote:
> All,
> 
> I'm interested in the opinion from members on this list about discovery of
> CRL signer's certificate in non directory centric environments.
> 
> The problem is the following.
> 
> The relying party (RP) needs to check validity of a certificate and finds
> a
> CDP extension with a URL to the CRL. The RP retrieves this CRL which in
> this
> particular case is either signed by another key of the CA (re-keyed CA) or
> another entity (indirect CRL).
> 
> In this case the relying party needs to obtain the certificate of the CRL
> signer which may NOT be part of the original chain. In a directory centric
> solution this is retrieved from the directory, but what if such directory
> is
> not available or accessible.
> 
> The RP have thus no hint where to find the CRL issuers certificate unless
> the RP already have possession of it by some other means.
> 
> Is seems that CRLs would need an AIA extension with the option to point to
> the location of the signers certificate in the same manner as is possible
> for certificates.
> 
> Maybe AIA should be defined as both cert and CRL extension and not only
> certificate extension as today.
> 
> Thoughts and comments?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 13 Oct 2004 10:21:33 -0400

Stefan:

The change could be part of CRL related explanation (if the RFC Editor
wishes).

We could describe this as a mechanism to start the CRL issuer path
development process.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2004 9:45 AM
To: Santosh Chokhani; pkix
Subject: RE: Signer certificate discovery for CRLs

Santosh,

It would not change the definition of AIA just add that it can be used also
as CRL extension and list eventual restrictions and guidance for use with
CRLs.

Stefan Santesson

> In terms of certificate discovery, your proposal for AIA in CRL is 
> more robust.  The whole idea of self-issued key rollover certificates 
> and then using the new key to issue CRL is fraught with security 
> problems.  A secure solution would be one where the new key is 
> certified by the parent CA.  In that case to obtain the new 
> certificate, you could use AIA in CRL.
> 
> certificate in question points to the indirect CRL.  You get that CRL.  
> The AIA in CRL gets you started for the indirect CRL issuer 
> certification path and you are
> in business.
> 
> issuer certificate, will be clearly identified/available for the 
> validating party in some cases, but not in others?
> 
> Can we also conclude that there is no real discovery solution for 
> indirect CRLs?
> 
> Do you then agree then that it could be appropriate to allow AIA as a 
> CRL extension to facilitate discovery of CRL signer certificate?
> 
> Stefan Santesson
> represent three different cases, not three different certification 
> paths that have been constructed through the same PKI architecture.
> 
> The Root CA has issued a certificate to CA 1's new key, but not its 
> old key (either the Root CA never issued a certificate to CA 1's old 
> key or that certificate has expired).
> 
> certificates. The Root CA has issued a certificate to CA 2's old key, 
> but not its new key.
> 
> Of course, another realistic scenario would be one in which a CA 
> generated self-issued key rollover certificates upon key rollover and 
> then had the Root CA issue a CA certificate to its new key.  In this 
> case, as you suggest, any of the certification paths from figures 1, 
> 2, or 3 could be constructed.
> 
> As for the contents of the AIA extension, here is what I have 
> specified in the "X.509 Certificate and CRL Extensions Profile for the 
> Common Policy":
> 
> id-ad-caIssuers access method is used, the access location specifies 
> where certificates issued to the issuer of the certificate may be 
> found. If LDAP is used, the URI must include the DN of the entry 
> containing the relevant certificates and specify the directory 
> attribute in which the certificates are located. If the directory in 
> which the certificates are stored expects the "binary" option to be 
> specified, then the attribute type must be followed by ";binary" in 
> the URI. If HTTP is used, the URI must point to a file that has an 
> extension of ".p7c" that contains a certs-only CMS message (see RFC 
> 2633). The CMS message should include all certificates issued to the 
> issuer of this certificate, but must at least contain all certificates 
> issued to the issuer of this certificate in which the subject public 
> key may be used to verify the signature on this certificate. .... For 
> a certificate
> attributes of the directory entry of the CA identified in the issuer 
> field of the certificate.  These two attributes together hold all of 
> the certificates issued to the CA:  the cACertificate attribute holds 
> the CA's self-issued certificates and the crossCertificatePair 
> attribute holds the cross-certificates issued to the CA by other CAs.
> 
> Dave
> 
> 
> Stefan Santesson wrote:
> 
> David,
> 
> self issued certificate is inserted into the path, you are likely to 
> find the CRL
> Figure 1, 2 and 3 describe the same case. It is just describing 
> different path building strategies. An application that has access 
> locally to all chaining options may however still choose path 2 for 
> the certs and path 1 for the CRL independent of each other (which I 
> think figure 3 tries to
> describe)
> 
> Another comment is the structure of AIA extensions. The use I'm 
> familiar with doesn't use AIA to describe a directory entry where it 
> is left to the validation application logic to be intelligent enough 
> to find appropriate certificate data from the directory. The model I'm 
> familiar with is when the AIA URL explicitly identifies the exact 
> location of the appropriate CA certificate file, relieving the 
> validation software from complex information
> I think we share the basic conclusion that the ability to locate the 
> CRL signer certificate directly through the CRL could be very useful. 
> At least in the case of indirect CRL but it could also be proven very 
> useful in CA re-keying scenarios.
> 
> current shape and structure as a CRL extension (MUST NOT be critical). 
> It would present a very clear and uncomplicated logic to certificate 
> validating applications in many cases.
> 
> Stefan Santesson
> discovery algorithms assume that both the trust anchor (or trust 
> anchors) and the end entity certificate are provided as input.  In 
> this case, one may need to construct a certification path without a 
> priori access to the end entity certificate (the one with the subject 
> public key corresponding to the
> In each of these scenarios, the CA has performed key rollover and is 
> only signing CRLs with its new key.  The diagrams would look similar, 
> however, if the CA simply choose to use different keys to sign 
> certificates and CRLs for
> some other reason.
> 
> If the PKI architecture resembled figure 1, then the certification 
> path for the CRL signing key would just be a subset of the 
> certification path for the
> If the PKI architecture resembled figure 1, then it would be necessary 
> to obtain the new-signed-with-old self-issued certificate.  In 
> building the certification path to the EE certificate, however, the 
> relying party will obtain the certificates pointed to by the AIA 
> extension in the EE certificate.  This AIA extension will point to a 
> location containing all certificates issued to CA 2, which would 
> include both the certificate issued by the Root to CA 2 and CA 2's 
> self-issued certificate.  So, even though the
> A similar situation would happen if the PKI architecture resembled 
> figure 3.  The AIA extension in the EE certificate would point to a 
> location containing certificates issued to CA 3.  When the relying 
> party downloaded these certificates, it would obtain both of the 
> certificates issued by the Root to CA 3 and so again would have the 
> certificate needed to validate the CRL signing key.
> 
> In the case of an indirect CRL, things may not work as well.  If 
> indirect CRLs were used, and the PKI architecture resembled figures 2 
> or 3 (replacing "New Key" with a different CA), then the set of 
> certificates pointed to by the AIA extension in the EE certificate 
> would not include the certificate of
> useful to have a pointer in the CRL to the CRL signing certificate.  
> When the CRL is not indirect, the need for this pointer does not seem 
> to be as clear, but
> I'm interested in the opinion from members on this list about 
> discovery of CRL signer's certificate in non directory centric 
> environments.
> 
> The relying party (RP) needs to check validity of a certificate and 
> finds a CDP extension with a URL to the CRL. The RP retrieves this CRL 
> which in this
> In this case the relying party needs to obtain the certificate of the 
> CRL signer which may NOT be part of the original chain. In a directory 
> centric solution this is retrieved from the directory, but what if 
> such directory is not available or accessible.
> 
> The RP have thus no hint where to find the CRL issuers certificate 
> unless the RP already have possession of it by some other means.
> 
> Is seems that CRLs would need an AIA extension with the option to 
> point to the location of the signers certificate in the same manner as 
> is possible for certificates.
> 
> Maybe AIA should be defined as both cert and CRL extension and not 
> only certificate extension as today.
> 
> Thoughts and comments?
> 
> Stefan Santesson

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 13 Oct 2004 16:33:56 +0200

Stefan,

You are making a conclusion without letting me the time to respond.
I will need more time to look at the pictures (and understand them).

For the time being, I am still reluctant to accept "yet-another-method".
We already have too many.

> It would hopefully just be a minor change.

This is exactly what I feared.

We usually end-up with a "minor change" in an extension without saying 
cleary how and when it shall/should be used.

I still have in mind that:

  1) a certification path must first be constructed,
  2) then the revocation checking of that path must be done.

This means that information about CRL issuers certificates locations may 
certainly be found in that chain. If not, I would like an example.

Denis

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 14 Oct 2004 10:09:24 +0800

Stefan,

I think it is a good idea to include AIA extension in CRL to aid
RP in finding CRL issuer certificates.

However, I am concerning about the accessMethod OID to be
used. Currently, RFC 3280 only define id-ad-caIssuers OID,
which is intended to aid RP in finding CA certificates.
Since a CRL issuer might not be a CA, the name and definition
of the id-ad-caIssuers OID need to be changed (or extended).

In addition, the definition of the id-ad-caIssuers accessMethod
is very vague. I think this is a chance to clarify it. I suggest that
when doing this amendment the following things should be
clarified:

   1. What will be retrieved from the acceesLocation if it is an URI?
           I believe that the current practice is that an issuer certificate
           or a list of issuer certificates (in PKCS#7 format) will be
           retrieved if the acceesLocation is an HTTP or FTP URI.
           But it is not clear what will be retrieved if the acceesLocation
           is an LDAP URI?
   2. What will be the MIME type of the retrieved object?

Since id-ad-caIssuers is not a proper name for the the accessMethod
OID, I suggest that th name be changed to id-ad-issuerCertificates
(and of course the definition should also be changed).

Wen-Cheng Wang

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>; "pkix" <[email-masked]>
Sent: Wednesday, October 13, 2004 9:44 PM
Subject: RE: Signer certificate discovery for CRLs

Santosh,

Stefan Santesson