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

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 10 May 2005 00:24:34 +0100

Denis,

I think all arguments have been spoken about this by now.

The bottom line is not whether your arguments are right or wrong. It is
that your discussion is out of scope for this draft.

In the end of the day that is the reason why we are reluctant to add
your proposed text in this document. Unless you can find others to
support you, you are in clear minority and as such I will not agree to
do any changes.

I second WG last call for this draft.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 9 maj 2005 15:05
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 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

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 10 May 2005 09:00:29 +0200

Stefan,

> I think all arguments have been spoken about this by now.

  ... but not all replied.

> your proposed text in this document. 

More important, I am requesting the *deletion* of two sentences in the 
security considerations section. See my response posted to Russ.

Denis

> Unless you can find others to