Subject: Signer certificate discovery for CRLs

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 6 Oct 2004 23:07:07 +0100

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: Denis Pinkas <[email-masked]>
Date: Thu, 07 Oct 2004 16:41:34 +0200

Stefan,

> CRL signer which may NOT be part of the original chain. 

You mean: "In these cases ..." since there are two cases.  :-)

 > In a directory

I suppose that a candidate certification path has been successfully built, 
but not yet validated as far as certificate revocation status is concerned.

In the first case (re-keyed CA), there may be multiple sub-cases, so you 
would have to be more specific to explain the scenario you have in mind.

In the second case (indirect CRL, no re-keyed CA), let us use a simple example.

A chain of certificates has been built with:
leaf certificate / CA Cert 1 / CA Cert 2 / ...

In the chain of certificates, if CA Cert 1 (issued by CA 2) includes an AIA 
extension with an AccessDescription id-ad-caIssuers, then the location of a 
repository that may contain CRL issuer certificates may be known: if CA 2 
postes the certificate designating the CRL issuer in that repository, then 
the problem is solved.

" [FROM RFC 3280] The accessLocation field specifies the location of the 
information. The retrieval mechanism may be implied by the accessMethod or 
specified by accessLocation. When id-ad-caIssuers appears as accessMethod, 
the accessLocation field describes the referenced description server and the 
access protocol to obtain the referenced description."

In the chain of certificates, if CA Cert 2 (issued by CA 3) includes an 
Subject Information Access (SIA) extension with an AccessDescription 
id-ad-caRepository, then the location of a repository that may contain CRL 
issuer certificates may be known: if CA 2 postes the certificate designating 
the CRL issuer in that repository, then the problem is also solved.

Even if these extensions are scarcely (not yet ?) used for that purpose,
I do not think it would be desirable to introduce a third way.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 7 Oct 2004 12:44:26 -0400

Stefan and Denis:

I have reviewed Denis's examples.  They do not seem clear to me.  But, for
both re-key and indirect case (there are several such as assigning a sub CA
or another CA in the PKI domain that is not in any certificate's
certification path), what Stefan has suggested for CRL is a good idea.

I assume that we all realize that having an AIA is not crypto binding.

Separately, while preparing for PKIX, I have had this idea for crypto
binding the certificate signer and CRL signer.  This could be in lieu of
certification path matching algorithm.  A CRL can contain a non-critical
extension which is a SEQUENCE or SET of key identifier (formed using hash
scheme recommended by 3280) of the CAs' certificate signing keys.  A key
identifier is included if the certificate signed using that key can be
included in that CRL.  Now, the relying party only needs to match the AKID
of the certificate with one of the values in this extension.

Please note that this check is a substitute for path matching.  IDP
discipline must still be observed in order to maintain security.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Thursday, October 07, 2004 10:42 AM
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: Signer certificate discovery for CRLs

Stefan,

> 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 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 a directory
> centric solution this is retrieved from the directory, but what if 
> such directory is not available or accessible.
> 
> 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.

In the second case (indirect CRL, no re-keyed CA), let us use a simple
example.

Even if these extensions are scarcely (not yet ?) used for that purpose, I
do not think it would be desirable to introduce a third way.

Denis