RE: Signer certificate discovery for CRLs

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Santosh,

It seams that we are in agreement regarding AIA in CRLs.

I agree that crypto binding between certificate issuer and CRL is a
useful and important feature for the purpose you mention. Just applying
name matching seems a bit week and could in worst case increase the
vulnerability for attacks thanks to poor implementations or miss
configuration errors.

It would actually be easier to process than path comparison rules but
have the drawback of introducing a new extension. Let's consider that
closer.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Santosh Chokhani
> Sent: den 7 oktober 2004 18:44
> To: ietf-pkix@xxxxxxx
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> 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)
> >
> >
> >
> 
>