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

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 20 Oct 2006 10:15:42 +0200

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 20 Oct 2006 17:22:24 +0100

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.

>       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,

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
> 
> by the key of the CA, are insecure, very hazy and thus do not allow
for
> interoperability.
>      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.
> 
>    b) when CA name collision is not taken into consideration,
different
> certification path would be needed,
> Besides these points, the proposal should be rejected on the basis
that
> if a CA chooses to use this extension,