RE: Signer certificate discovery for CRLs

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Denis,

I think my reply to David Cooper also cover your mail and need not to be
repeated.

I don't agree to your conclusion. Just because current available methods
(e.g. use of AIA in certificates) may provide sufficient functionality
in some cases does not make a good rationale for not applying a better
and simpler solution that actually works in all situations.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Denis Pinkas
> Sent: den 7 oktober 2004 16:42
> 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)
> >
> >
> >
>