Re: Signer certificate discovery for CRLs

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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