Re: [pkix] new version of 5280 clarifications

["Kemp, David P." <[e-mail]>]

The quoted paragraph from Section 6 clearly says that the self-signed certificate is not included in the path.  It does not prohibit a profile from imposing requirements on data structures used to distribute trust anchor information in the name of consistency of understanding across CAs and applications, in the case where such information is distributed in the form of certificates.  TAMP imposes such requirements on its data structures, 5280 may also do so.  In light of the confusion and resulting extended discussion, it seems reasonable to mandate a distinction between certificates containing trust anchors and those which applications should not accept as trust anchors.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Saturday, July 14, 2012 3:29 PM
To: IETF PKIX
Subject: Re: [pkix] new version of 5280 clarifications

The path validation algorithm in Section 6 of RFC 5280 starts with a trust anchor, and self-signed certificates are a convenient way to distribute such trust anchors.  However, RFC 5280 does not, and should not, impose any particular approach to trust anchor distribution.  This proposed clarification RECOMMENDS that the self-signed certificate include the basic constraints extension with the CA-bit set.  Nothing in Section 6 justifies this recommendation.

In fact, Section 6 is quite clear to say that it does not impose any requirements on self-signed certificates that are used to distribute a trust anchor:

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   is provided as inputs to the certification path validation algorithm
   (Section 6.1.1).

Russ


On 07/12/2012 08:52 PM, David A. Cooper wrote:
> On 06/30/2012 12:58 AM, Peter Yee wrote:
>> The updated draft has been posted.  Please let me know if further 
>> changes are required.
> 
> Peter,
> 
> I disagree with the changes that you made for the new paragraph to 
> appear at the end of Section 3.2.  The text that you included in the 
> -05 draft says:
> 
> |  In some cases, a self-signed certificate that does not contain a  
> | BasicConstraints extension (and thus is implicitly an EE 
> | certificate)  is used to convey a public key. Such a certificate 
> | (i.e., a self-  signed certificate not marked as a CA certificate) 
> | is not compatible  with the path validation rules described in 
> | Section 6, or the  definitions in the paragraph above. This document 
> | RECOMMENDS that  self-signed certificates used to convey trust 
> | anchor data be marked  (see Section 4.2.1.9) as CA certificates, but 
> | acknowledges that this  convention is often not adopted in practice. 
> | Other uses of self-  signed EE certificates are outside the scope of this specification.
> 
> The inclusion of this paragraph was prompted by a request from Sean 
> Turner 
> (http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html)
> that was motivated by discussions in other working groups, such as 
> DANE.  These discussions were about the use of self-signed 
> certificates for purposes other than conveying trust anchor 
> information, not about whether self-signed certificates used to convey 
> trust anchor information should include a BasicConstraints extension.  
> Yet, the paragraph in the
> -05 draft, unlike in the -04 draft, is all about including 
> BasicConstraints extensions in self-signed certificates used to convey 
> trust anchor information. Section 4.2.1.9 of RFC 5280 already says 
> that conforming CAs MUST include a BasicConstraints extension in 
> self-signed certificates used to convey trust anchor information:
> 
>   Conforming CAs MUST include [the BasicConstraints]
>   extension in all CA certificates that contain public keys
>   used to validate digital signatures on certificates and
>   MUST mark the extension as critical in such certificates.
> 
> So, adding a sentence to Section 3.2 that RECOMMENDS including a 
> BasicConstraints extension would be inconsistent.  So, why not remove 
> all the text about whether a self-signed certificates used to convey 
> trust anchor information should include a BasicConstraints extension 
> and replace it with text (such as was in the -04 draft) that addresses 
> the use of self-signed certificates for purposes other than conveying 
> trust anchor information?
> 
> I also believe that the proposed text in the -05 draft is wrong for 
> several other reasons.
> 
> The text states that a self-signed certificate that does not contain a 
> BasicConstraints extension is implicitly an EE certificate.  Does this 
> mean that all version 1 certificates are implicitly EE certificates?
> Additionally, the text goes on to talk about the use of these 
> certificates to convey trust anchor information.  However, according 
> to
> X.509 an EE certificate is a certificate issued to an end entity, and 
> an end entity is a certificate subject that uses its private key for 
> purposes other than signing certificates.  So, if the subject of the 
> self-signed certificate signs certificates (and if it didn't then why 
> would anyone be using the its self-signed certificate as a trust 
> anchor for path validation) then it is not an end entity and the 
> self-signed certificate is not an EE certificate.
> 
> The proposed paragraph then goes on to incorrectly state that the use 
> of a self-signed certificate that does not contain a BasicConstraints 
> extension as the source of trust anchor information is not compatible 
> with the path validation rules specified in Section 6 of RFC 5280.
> However, Section 6 of RFC 5280 simply says that trust anchor 
> information consists of a name and a public key, and that this 
> information may be obtained from a self-signed certificate.  So, there 
> is no basis for an assertion that it is incompatible with Section 6 of 
> RFC 5280 to obtain trust anchor information from a self-signed 
> certificate that does not include a BasicConstraints extension.
> 
> The next sentence in the proposed paragraph says that the document 
> acknowledges that the convention of including a BasicConstraints 
> extension in a self-signed certificate used to convey trust anchor 
> information is often not adopted in practice.  What is the basis of 
> this assertion?  Can you provide examples of self-signed certificates 
> used to convey trust anchor information that do not include 
> BasicConstraints extensions (and not just the names of software 
> products that are capable of generating self-signed certificate without BasicConstraints extensions)?
> 
> I haven't even addressed the fact that a certificate could include a 
> BasicConstraints extension, but set the cA flag to FALSE.
> 
> RFC 5280 already specifies what information conforming CAs need to 
> include in certificates, including self-signed certificates, so there 
> is no need to add this paragraph to address that.  So, why not revert 
> to the text that was in the -04 draft, which addressed the issue that 
> was supposed to be covered by this new text, the use of self-signed 
> certificate for purposes other than conveying trust anchor 
> information, rather than the text in this draft?
> 
> Dave
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
> 
> 

_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix