RE: Signer certificate discovery for CRLs

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Denis Pinkas
Sent: Thursday, October 07, 2004 10:42 AM
To: Stefan Santesson
Cc: ietf-pkix@xxxxxxx
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 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.

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

 > 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.

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



> Thoughts and comments?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
>