RE: Signer certificate discovery for CRLs

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Re-sending since original html mail was too long with pictures from David Cooper.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: Stefan Santesson 
Sent: den 12 oktober 2004 16:41
To: 'David A. Cooper'
Cc: pkix
Subject: RE: Signer certificate discovery for CRLs

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:david.cooper@xxxxxxxx] 
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.  Below I have drawn 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)