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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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