Re: Comments on <draft-ietf-pkix-crlaia-00.txt>

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Russ,

Your statement below is correct, but does not answer to any of my 
questions/issues. In particular, the last one. I am still awaiting your 
responses.

Denis

> Denis:
>
> RFC 3280 does not tell an implementor how for locate certificates for 
> any certification path construction.  There are several extensions that 
> provide pointers that may help an implementation, but other approaches 
> to obtaining the same certificates are always permitted.  I would fully 
> expect an implementation to check any local cache before accessing a 
> repository.
>
> The CRL AIA extension fits this pattern.  A method for locating a 
> certificate is provided, but any other mechanism for locating the same 
> certificate is acceptable.
>
> Russ
>
> > Stefan,
> >
> > I made the e-mail shorter. Your main arguments are the following:
> >
> > ========================================================================== 
> >
> >
> > [Stefan] But it has to provide a warning to something that is introduced
> > by the standard. This standard does not introduce the concept of CRL
> > signature checking or CRL issuer certificate validation, so that is
> > clearly out of scope. More about that below;
> >
> > [Denis] See below the last answer and also my arguments in the 
> > soon-to-be-posted answer to Russ.
> >
> > ========================================================================== 
> >
> >
> >
> > > > RFC 3280 [PKIX1] specifies the validation of certification paths.
> > > > One aspect involves the determination that a certificate has not been
> > > > revoked, and one revocation checking mechanism is the Certificate
> > > > Revocation List (CRL).  CRL validation is also specified in RFC 3280,
> >
> > > I would love this last sentence to be true but the reality is that:
> > > "CRL validation is NOT specified in RFC 3280". :-(
> >
> > [Stefan] In fact it is.
> >
> > RFC 3280, Section 6.3.3 CRL processing - on page 85:
> >
> >    (f)  Obtain and validate the certification path for the complete CRL
> >    issuer.  If a key usage extension is present in the CRL issuer's
> >    certificate, verify that the cRLSign bit is set.
> >
> >    (g)  Validate the signature on the complete CRL using the public key
> >    validated in step (f).
> >
> > [Denis] The text does not say how to obtain and validate the 
> > certification path for the complete (???) CRL issuer. The text is not 
> > clear enough so that two implementors only looking at this sentence 
> > will provide interoperable implementations.
> >
> > ========================================================================== 
> >
> >
> > [Stefan] It is my hope that the provided responses here can help
> > convince you to change your mind about that. If it doesn't I still argue
> > that the place to specify requirements and security considerations for
> > CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.
> >
> > [Denis] I can agree with your last sentence, ... which means that it 
> > should not be in the main body of the document. In the security 
> > considerations section, text is free and we shall at the very minimum 
> > warn implementers and we should provide some guidance. When the same 
> > certification path (i.e. the path used to validate the target 
> > certificate) is used, then there is no security issue: this should be 
> > said. For all other cases, there MAY be problems: this should also be 
> > said. It is as simple as that.
> >
> > Denis