Subject: RE: Comments on draft-santesson-pkix-vccrl-00.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 20 Oct 2006 14:22:01 -0700

This may be somewhat off the wall but bear with me.

If we are going to introduce a change here I would like to try to make it the last one. So I would like to anticipate as many needs as possible.

In particular I can see people using the CRL+certchain package as a handy means of transporting all the information associated with the Cert in one package.

The leads to the question could I produce such a package that only related to a single certificate? One way to do this would be to put a unique distribution point into every certificate. Another way that would be less intrusive would be to resurect the 'interval' scheme I proposed some years ago so the CRL would state 'this is the crl for all certs serial number X to y. To make this a single cert CRL it would say this is the CRL for all certs with serial numbers x to x inclusive.

What I then end up with is a package that contains all the material I need to authenticate a specific certificate in the context of a specific trust path.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Friday, October 20, 2006 12:22 PM
> To: Denis Pinkas; pkix
> Subject: RE: Comments on draft-santesson-pkix-vccrl-00.txt
> 
> 
> Hi Denis,
> 
> I will choose to disregard the comments on your perceived 
> shortcomings of RFC 3280 CRL validation. They are neither 
> improved nor degraded by this specification. It is a 
> discussion that belongs with RFC3280bis, which I think we 
> already have deabeted for a long time.
> 
> If you have any reason to believe that this specification 
> makes the problem worse, then I'm all ear.
> 
> > This has further direct consequences whether the proposed extension 
> > should be:
> > 
> >       ValidationCertificates  ::= SEQUENCE of Certificate or
> >       ValidationCertificate  ::= Certificate
> 
> This reflects the solution defined in the AIA in CRL RFC 
> which allows multiple certificates to be referenced.
> The relying party is responsible for doing the chain building 
> and will use the certificates that the RL regards as useful 
> for its set trust policy.
> 
> The source of the certificates does not change anything in 
> this regard.
> 
> > Besides these points, the proposal should be rejected on the basis
> that
> > if a CA chooses to use this extension, all CRLs will 
> inflate in size.
> > 
> > The idea would be acceptable if the CA would be able to continue to 
> > issue current CRLs, and, in addition, could also issue 
> augmented CRLs 
> > with this extension. However the proposal does not allow for this.
> 
> This specification is silent on this topic, with purpose, as 
> it only defines a OPTIONAL extension.
> All CRL's will not inflate in size if 1 CRL is amended with 
> certificates and a CA may issue several CRLs.
> 
> The introduction of the document is very clear that this is 
> not an optimal solution for all environments, hence the 
> extension is optional.
> It is however very useful in some environments and those 
> environments would benefit from a standardized way to do this.
> 
> 
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-ietf- 
> > [email-masked]] On Behalf Of Denis Pinkas
> > Sent: den 20 oktober 2006 01:16
> > To: pkix
> > Subject: Comments on draft-santesson-pkix-vccrl-00.txt
> > 
> > 
> > General comment
> > 
> > This draft should not be taken as a WG item and should not 
> amend RFC 
> > 3280 as it is proposed.
> > 
> > Detailed comments
> > 
> > The Security Considerations section states:
> > 
> >    Any use of certificates provided in the Validation 
> Certificates CRL
> >    extension, to validate signatures on a CRL, MUST be done 
> according
> >    rules and conventions defined in RFC 3280.
> > 
> > This is incorrect since the rules and conventions defined 
> in RFC 3280, 
> > when the CRL is not signed by the key of the CA, are insecure, very 
> > hazy and thus do not allow
> for
> > interoperability.
> > 
> > These rules do not address the cases where:
> > 
> >      a) two CAs in different branches of a certification tree would 
> > have the same DN, and
> > 
> >      b) two CAs in different trees of a certification forest would
> have
> > the same DN.
> > 
> > The impact is important because, with these insufficiently defined 
> > rules of today, a certification path for a CRL might be fully 
> > different from a certification path for a target 
> certificate, but the 
> > path validation rules are silent about this.
> > 
> > There are indeed security attacks possible with these loose rules.
> > 
> > The consequences are:
> > 
> >    a) when CA name collision is taken into consideration, a SINGLE 
> > certificate is missing since
> >        the certification path of the target certificate 
> MUST be used.
> > 
> >    b) when CA name collision is not taken into consideration,
> different
> > certification path would be needed,
> >        and thus a SEQUENCE of certificates would be needed.
> > 
> > This has further direct consequences whether the proposed extension 
> > should be:
> > 
> >       ValidationCertificates  ::= SEQUENCE of Certificate or
> >       ValidationCertificate  ::= Certificate
> > 
> > 
> > Besides these points, the proposal should be rejected on the basis
> that
> > if a CA chooses to use this extension, all CRLs will 
> inflate in size.
> > 
> > The idea would be acceptable if the CA would be able to continue to 
> > issue current CRLs, and, in addition, could also issue 
> augmented CRLs 
> > with this extension. However the proposal does not allow for this.
> > 
> > Denis
> > 
> > 
> 
> 
> 
>