Subject: Re: [pkix] new version of 5280 clarifications

From: [email-masked] (Martin Rex)
Date: Thu, 12 Jul 2012 01:31:28 +0200 (CEST)

Peter Yee wrote:
>
> The updated draft has been posted.  Please let me know if further changes
> are required.
> 
> Steve Kent wrote: 
>> A new version of 5280 clarifications will be published shortly.
>>
>> Peter Yee has taken over from David Copper as the document editor.
>> 
>> There are very few changes since the last published version. The only major
>> change is a new paragraph on our favorite topic of self-signed EE certs.
>> Hopefully this text will be acceptable.

A brief scan of the -05 diffs
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-05

creates the impression of a slight inconsistency with rfc5937 Section 2
by making appear the "optionality" of trust anchor constraints differ between
the 3 rfc5914 formats (TrustAnchorInfo, Certificate, and TBSCertificate)
and rfc5280-update.

in rfc5937 section 2, they appear fully equivalent to me:

  http://tools.ietf.org/html/rfc5937#section-2

   2. Identifying Trust Anchor Constraints

   TAF supports three formats for representing trust anchor information:
   TrustAnchorInfo, Certificate, and TBSCertificate.  In all three
   cases, trust anchor constraints may be represented as extensions.  In
   the TrustAnchorInfo structure, certificate policies, policy
   constraints, name constraints, inhibit any policy, and basic
   constraints do not appear as extensions and instead appear as part of
   the CertPathControls field.

   Extensions may be marked critical or not critical.  When trust anchor
   constraints are enforced, clients MUST reject certification paths
   containing a trust anchor with unrecognized critical extensions.
   When trust anchor constraints are not enforced, clients MAY accept
   certification paths containing a trust anchor with unrecognized
   critical extensions.  Information appearing in the CertPathControls
   field of a TrustAnchorInfo object MUST be processed, ensuring
   enforcement of the constraints indicated by this field in all cases.

Excerpts from 5280-update-05:

      The path validation algorithm presented
   |  in Section 6.1 does not assume that trust anchor information is
   |  provided in self-signed certificates

huh?  rfc-5280 currently makes these statements in 6.1.1:

   (d)  trust anchor information, describing a CA that serves as a
        trust anchor for the certification path.  The trust anchor
        information includes:

         (1)  the trusted issuer name,
         (2)  the trusted public key algorithm,
         (3)  the trusted public key, and
         (4)  optionally, the trusted public key parameters associated
              with the public key.

      The trust anchor information may be provided to the path
      processing procedure in the form of a self-signed certificate.

The only trust anchor format mentioned in rfc5280 is *self-signed* certificate
so "does not assume that trust anchor information is provided in self-signed
certificate looks weird to me.

To me, rfc5280 says that trust anchors *ARE* often supplied as self-signed
certificates to the path validation function, but there *may* exist different
trust anchor formats, or formats where a self-signed cert is a subset of
the (trust anchor) information (though the latter is unfortunately
unsupported by rfc5914).

  |
  |  and does not specify processing
  |  rules for additional information included in such certificates.

and neither for any other Trust Anchor Format there might be.

  |  However, [RFC5937] provides an example of how additional information
  |  included in self-signed certificates may be used to initialize the
  |  path validation inputs.  Implementations that use self-signed
  |  certificates to specify trust anchor information are free to make
  |  use of any additional information that is included in the
  |  certificates, or to ignore such information.

RFC5937 section 2 IMO declares constraints in *ALL 3* TAFs defined by rfc5914
to be equivalent.  It looks weird for this new text to reference rfc5937,
but single out the "additional information" of only self-signed certificates
to be "freely ignored"--shouldn't this apply to trust anchor constraints
for all 3 rfc5914 TAFs in the same fashion?

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Thu, 12 Jul 2012 08:30:58 -0400

On 7/11/12 7:31 PM, "Martin Rex" <[email-masked]> wrote:
<snip>

>for all 3 rfc5914 TAFs in the same fashion?

Perhaps replacing the two sentences in your snip with the following would
address your concern:

However, [RFC5914] defines several formats for representing trust anchor
information, including self-signed certificates, and [RFC5937] provides an
example of how information included in a trust anchor may be used to
initialize the path validation inputs. Implementations are free to make
use of any additional information that is included in a trust anchor, or
to ignore such information.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Jul 2012 11:03:50 -0400

Martin,

I agree that the cited text gives the wrong impression.

I like Carl's suggested replacement text.

What do you, and others, think?

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 12 Jul 2012 14:16:37 -0400

Carl,

This text isn't quite correct since it refers to "information included 
in a trust anchor."  Note that the abstract for RFC 5914 begins:

    This document describes a structure for representing trust anchor
    information.  A trust anchor is an authoritative entity represented
    by a public key and associated data.

So this text is confusing a trust anchor with trust anchor information.

Another problem is that the proposed changes are to text that has been 
taken out of context.  The entire paragraph (with proposed 
modifications) is:

|  Where a CA distributes self-signed certificates to specify trust
|  anchor information, certificate extensions can be used to specify
|  recommended inputs to path validation.  For example, a policy
|  constraints extension could be included in the self-signed
|  certificate to indicate that paths beginning with this trust anchor
|  should be trusted only for the specified policies.  Similarly, a name
|  constraints extension could be included to indicate that paths
|  beginning with this trust anchor should be trusted only for the
|  specified name spaces.  The path validation algorithm presented
|  in Section 6.1 does not assume that trust anchor information is
|  provided in self-signed certificates and does not specify processing
|  rules for additional information included in such certificates.
|  However, [RFC5937] provides an example of how additional information
|  included in self-signed certificates may be used to initialize the
|  path validation inputs.  Implementations that use self-signed
|  certificates to specify trust anchor information are free to make
|  use of any additional information that is included in the
|  certificates, or to ignore such information.

So, adding a reference to RFC 5914's definition of several formats for 
representing trust anchor information into a paragraph that is all about 
self-signed certificates is rather awkward.

Dave

---

From: Carl Wallace <[email-masked]>
Date: Thu, 12 Jul 2012 14:35:54 -0400

>So this text is confusing a trust anchor with trust anchor information.

Minor edit below to address this.

>self-signed certificates is rather awkward.

The sentence before the two sentences for which replacement text was
provided states that trust anchor information is not necessarily provided
in a self-signed certificate.  Noting that RFC 5914 defines several
formats seems fair here.  New candidate text:

"However, [RFC5914] defines several formats for representing trust anchor
information, including self-signed certificates, and [RFC5937] provides an
example of how such information may be used to initialize the path
validation inputs. Implementations are free to make use of any additional
information that is included in a trust anchor representation, or to
ignore such information."

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 12 Jul 2012 15:52:21 -0400

> The updated draft has been posted.  Please let me know if further changes

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 22:47:12 +0100

Folks,

FWIW, as a co-author of 5280, I think -05 of this would
be ok to move ahead.

Even though I do think that some of David's points might
be worth fixing, I'd say that shooting ahead and fixing
them during IETF LC or IESG evaluation would be fine in
this case, if its the case that only a couple of people
care.

Cheers,
S.

On 07/12/2012 08:52 PM, David A. Cooper wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> 
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 14 Jul 2012 15:28:57 -0400

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

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 16 Jul 2012 12:28:53 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, July 14, 2012 3:29 PM
To: IETF PKIX
Subject: Re: [pkix] new version of 5280 clarifications

Russ

On 07/12/2012 08:52 PM, David A. Cooper wrote:
>> The updated draft has been posted.  Please let me know if further 
>> changes are required.
> 
> Peter,
> 
> appear at the end of Section 3.2.  The text that you included in the 
> -05 draft says:
> 
> | 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.
> 
> Turner 
> (http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html)
> 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
> 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:
> 
> 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?
> 
> 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 
> 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 
> 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.
> 
> 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)?
> 
> 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
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Jul 2012 08:30:56 -0400

Dave:

Correct, but the document we are discussing is about clarifications to RFC 5280.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jul 2012 15:00:12 -0400

David,

The text in the -05 version of the clarification doc notes that, despite 
the 5280 mandate to include the Basic Constraints extension (with the CA 
flag = TRUE), this is often not the case.The recommendation is expressed 
in this context. This is what DANE and other folks have asked for, and 
what we are expressing.

Version 1 certificates are not in scope for 5280 (as per the abstract 
"This memo profiles the X.509 v3 certificate ...") so your question 
about the relationship between the clarification text and v1 
certificates is also out of scope.

The use of a self-signed certificate that is not marked as a CA 
certificate (as per 5280) is incompatible with the section 6 rules in 
several respects. For example, the initialization of the path validation 
algorithm (in 6.1.1) refers to several policy constraints extension 
values (policy-mapping-inhibit, explicit-policy, inhibit anyPolicy), and 
to the permitted and excluded subtrees in the name constraints 
extension. These extensions appear _only_ in CA certs. So, if these 
extensions were to appear in a self-signed cert used as a TA, and that 
cert were not marked as a CA cert, then these aspects of path validation 
initialization could not apply. Also, the text in 6.1.1 talks about "a 
CA that serves as a trust anchor ..." This text must be interpreted in 
the context of the extant 5280 definition of a CA, which calls for the 
CA flag to be set in the Basic Constraints. These observations motivate 
the statement that use of a
self-signed cert that is not marked as a CA cert is incompatible with 
path processing.

You ask for examples of certificates used to convey TAs as self-signed 
certificates, without the CA flag set. I suggest you talk with Paul 
Hoffman and other folks in the DANE WG who have made this observation, 
which motivated this text.

WGLC ended for this doc on Friday. There were no other comments on the 
text. We're done.

Steve

---

From: Tom Gindin <[email-masked]>
Date: Wed, 18 Jul 2012 20:43:00 -0400

David:

        Several unexpired V1 certificates are distributed in the "Trusted 
Root" list of Windows XP.  GTE Cybertrust Global Root is a V1. Admittedly, 
it's a 1024-bit key using MD5.  FESTE, Public Notary Certs, is similar. 
Japan Certification Services' SecureSign RootCA certificates are 2048-bit 
with SHA-1 signatures, and don't expire until 2020.  They aren't RFC 5280 
certificates, but they certainly are self-signed X.509 certificates 
without BC used to convey trust anchor information. 

Tom Gindin

From:   "David A. Cooper" <[email-masked]>
To:     Peter Yee <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   07/12/2012 03:52 PM
Subject:        Re: [pkix] new version of 5280 clarifications
Sent by:        [email-masked]

> The updated draft has been posted.  Please let me know if further 
changes

Peter,

of generating self-signed certificate without BasicConstraints 
extensions)?

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 19 Jul 2012 10:33:04 -0400

Tom,

Steve Kent claimed that "Version 1 certificates are not in scope for 
5280."   While he is incorrect about that, I believe the statement that 
"this convention is often not adopted in practice" was intended to refer 
to version 3 certificates that do not include a BasicConstraints 
extension [with cA=TRUE] and not to version 1 certificates.

Notice that I also inquired about version 1 certificates.  The proposed 
text says that a self-signed certificate that does not contain a 
BasicConstraints extension is implicitly an EE certificate.  In my 
comments on the draft (below) I asked "Does this mean that all version 1 
certificates are implicitly EE certificates?"

Dave

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 19 Jul 2012 10:52:40 -0400

I would say that a self-signed certificate that does not contain any extension in it need NOT be an end entity certificate.  Per Section 6 of 5280, it can be a trust anchor.

So, if I understand David Cooper, I agree with him and any final approved changes are incorrect.

My comment is independent of V1 or V2 issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Thursday, July 19, 2012 10:33 AM
To: Tom Gindin
Cc: [email-masked]
Subject: Re: [pkix] new version of 5280 clarifications

Tom,

Steve Kent claimed that "Version 1 certificates are not in scope for 
5280."   While he is incorrect about that, I believe the statement that 
"this convention is often not adopted in practice" was intended to refer to version 3 certificates that do not include a BasicConstraints extension [with cA=TRUE] and not to version 1 certificates.

Notice that I also inquired about version 1 certificates.  The proposed text says that a self-signed certificate that does not contain a BasicConstraints extension is implicitly an EE certificate.  In my comments on the draft (below) I asked "Does this mean that all version 1 certificates are implicitly EE certificates?"

Dave

On 07/18/2012 08:43 PM, Tom Gindin wrote:
>          David:
>
>          Several unexpired V1 certificates are distributed in the 
> "Trusted Root" list of Windows XP.  GTE Cybertrust Global Root is a 
> V1. Admittedly, it's a 1024-bit key using MD5.  FESTE, Public Notary Certs, is similar.
> Japan Certification Services' SecureSign RootCA certificates are 
> 2048-bit with SHA-1 signatures, and don't expire until 2020.  They 
> aren't RFC 5280 certificates, but they certainly are self-signed X.509 
> certificates without BC used to convey trust anchor information.
>
> Tom Gindin
>
>
>
>
>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 19 Jul 2012 11:13:40 -0400

On 07/17/2012 03:00 PM, Stephen Kent
wrote:

Version 1 certificates are not in scope for
5280 (as per the abstract “This memo profiles the X.509 v3
certificate …”)
so your question about the relationship between the
clarification text and v1 certificates is also out of scope.

While conforming CAs cannot issue version 1 certificates, that
doesn't mean that version 1 certificates are not in scope for 5280.
For example, Section 6 is very clear that the path validation
algorithm in that section is not limited to accepting certificates
issued in conformance with the PKIX profile.  In fact, Section 6.1.4
includes the following step:

(k)  If certificate i is a version 3 certificate, verify that
the

basicConstraints extension is present and that cA is set
to

TRUE.  (If certificate i is a version 1 or version 2

certificate, then the application MUST either verify that

certificate i is a CA certificate through out-of-band
means

or reject the certificate.  Conforming implementations
may

choose to reject all version 1 and version 2 intermediate

certificates.)

The proposed text says that a self-signed certificate that does not
contain a BasicConstraints extension "is not compatible with the
path validation rules described in Section 6."  Certainly if the
scope of the path validation algorithm in Section 6 includes version
1 certificates as intermediate certificates in a certification path,
it includes the use of self-signed version 1 certificates as the
source of trust anchor information.

Note also that the text in Section 6.1.4 says for a version 1
intermediate certificate to "verify that certificate i is a CA
certificate through out-of-band means," which indicates that a
version 1 certificate [that does not contain a BasicConstraints
extension] is not implicitly an EE certificate.

The use of a
self-signed certificate that is not marked as a CA certificate
(as per 5280) is incompatible with the section 6 rules in
several respects. For example, the initialization of the path
validation algorithm (in 6.1.1) refers to several policy
constraints extension values (policy-mapping-inhibit,
explicit-policy, inhibit anyPolicy), and to the permitted and
excluded subtrees in the name constraints extension.

The initialization of the path validation algorithm in Section 6.1.1
does not refer to any certificate extensions.  Section 6.1.1
specifies inputs to the path validation algorithm.  The input
initial-policy-mapping-inhibit is a boolean that may be assigned a
value of either TRUE or FALSE by the relying party.  Notice that the
value of initial-policy-mapping-inhibit is explicitly not considered
to be trust anchor information.  This input is used by the relying
party to affect the path validation process, not by the trust
anchor.  While the value of initial-policy-mapping-inhibit may
affect the same state variable as the inhibitPolicyMapping field of
the policyConstraints extension, it is the relying party that
ultimately decides the value of initial-policy-mapping-inhibit, even
if the relying party uses a self-signed certificate as the source of
trust anchor information and that self-signed certificate happens to
include constraints extensions in it.

CAs impose constraints by either not issuing certificates that
violate those constraints or by including constraints extensions in
the certificates that they issue (e.g., not including a
policyMappings extension in any certificates that it issues and
include a policyConstraints extension with inhibitPolicyMapping
present with a SkipCerts value of 0).

These extensions appear only in CA certs. So,
if these extensions were to appear in a self-signed cert used
as a TA, and that cert were not marked as a CA cert, then
these aspects of path validation initialization could not
apply. Also, the text in 6.1.1 talks about “a CA that serves
as a trust anchor …

Again, these inputs to path validation are not listed as trust
anchor information for a reason.  So, the contents of the
self-signed certificate used as the source of trust anchor
information is irrelevant.  As noted in Section 6.2, a relying party
may choose use use information included in a self-signed certificate
as the basis for selecting the values for the path validation
inputs, but that is a relying party decision.

This text must be interpreted in the context of
the extant 5280 definition of a CA, which calls for the CA
flag to be set in the Basic Constraints. These observations
motivate the statement that use of a

self-signed cert that is not marked as a CA cert is
incompatible with path processing.

In what sense is it "incompatible with path processing"?  As Section
6.1.1 notes:

certificate, this self-signed certificate is not included as part
of

the prospective certification path.

Self-signed certificates may be used as the source of trust anchor
information, but they are never used as part of path processing.

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Jul 2012 18:47:07 +0200 (CEST)

Santosh Chokhani wrote:
>
>
> I would say that a self-signed certificate that does not contain
> any extension in it need NOT be an end entity certificate.
> Per Section 6 of 5280, it can be a trust anchor.

Per Section 6.1.4 (k) of rfc5280, even a path CA cert can be X.509v1:

      (k)  If certificate i is a version 3 certificate, verify that the
           basicConstraints extension is present and that cA is set to
           TRUE.  (If certificate i is a version 1 or version 2
           certificate, then the application MUST either verify that
           certificate i is a CA certificate through out-of-band means
           or reject the certificate.  Conforming implementations may
           choose to reject all version 1 and version 2 intermediate
           certificates.)

> extension [with cA=TRUE] and not to version 1 certificates.

Steve's statement seems too broad and prone to misunderstanding.
The most that can be said, is, that rfc5280 does not profile X.509v1 certs.
The way I understood the purpose of PKIX was to leverage, rather than
kill, the installed base of X.509.  Since the underlying technology (X.509v3)
is quite complex and awkward, there is a lot of bad practice out there
in the installed base, which RPs have to deal with in one way or another.

Remaining completely silent (=chicken out) on potential or real interop
issues that have been identified does not seem appropriate for an
IETF standard with an awfully huge installed base.

> BasicConstraints extension is implicitly an EE certificate.
> In my comments on the draft (below) I asked "Does this mean that all
> version 1 certificates are implicitly EE certificates?"

The current text in rfc 5280 6.1.4 (k) quoted above makes a clear
distinction between X.509v3 certs without Basic Constraints and
X.509v1 certs, and suggests that the latter (X.509v1 certs) MUST use
other means than cert attributes (out-of-band / meta-data)
to distinguish CA from EE certs.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 19 Jul 2012 16:50:41 -0400

Martin,

Do you agree that V1, V2, or V3 self-signed certificate without any extensions or without basic constraint extension present in it can be a trust anchor for path validation?

I would even go as far as to say that even if cA = FALSE is present in basic constraints, per Section 6 one can use it as a trust anchor for path validation.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, July 19, 2012 12:47 PM
To: Santosh Chokhani
Cc: David A. Cooper; Tom Gindin; [email-masked]
Subject: Re: [pkix] new version of 5280 clarifications

Santosh Chokhani wrote:
>
>
> I would say that a self-signed certificate that does not contain any 
> extension in it need NOT be an end entity certificate.

David A. Cooper wrote:
> "this convention is often not adopted in practice" was intended to 
> refer to version 3 certificates that do not include a BasicConstraints 

Steve's statement seems too broad and prone to misunderstanding.
The most that can be said, is, that rfc5280 does not profile X.509v1 certs.
The way I understood the purpose of PKIX was to leverage, rather than kill, the installed base of X.509.  Since the underlying technology (X.509v3) is quite complex and awkward, there is a lot of bad practice out there in the installed base, which RPs have to deal with in one way or another.

Remaining completely silent (=chicken out) on potential or real interop issues that have been identified does not seem appropriate for an IETF standard with an awfully huge installed base.

> 
> Notice that I also inquired about version 1 certificates.  The 
> proposed text says that a self-signed certificate that does not 
> contain a BasicConstraints extension is implicitly an EE certificate.

The current text in rfc 5280 6.1.4 (k) quoted above makes a clear distinction between X.509v3 certs without Basic Constraints and
X.509v1 certs, and suggests that the latter (X.509v1 certs) MUST use other means than cert attributes (out-of-band / meta-data) to distinguish CA from EE certs.

-Martin

---

From: Tom Gindin <[email-masked]>
Date: Thu, 19 Jul 2012 20:04:40 -0400

A better wording for the idea in the draft would say "a 
self-signed version 3 certificate that does not contain a BasicConstraints 
extension is implicitly an EE certificate", since we've clearly settled 
that v1 (and presumably v2) self-signed certificates are still used as 
trust anchors.  Do you agree that this rule is appropriate, or not?
        I'm not arguing against you on this issue.  While an application 
CAN import anything containing the proper fields as a trust anchor, 
including a TLS server certificate, it SHOULD NOT do so when a certificate 
is clearly an EE.  Directly trusted EE certificates, although they have 
their place in many implementations of PKI-using applications, are out of 
scope for certificate validation and don't constitute trust anchors.

Tom Gindin

P.S.    The above opinions are mine, and not necessarily those of my 
employer.

From:   "David A. Cooper" <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, 
Cc:     "[email-masked]" <[email-masked]>
Date:   07/19/2012 10:33 AM
Subject:        Re: [pkix] new version of 5280 clarifications

Tom,

Dave

>          Several unexpired V1 certificates are distributed in the 
"Trusted
> Japan Certification Services' SecureSign RootCA certificates are 
2048-bit

---

From: [email-masked] (Martin Rex)
Date: Fri, 20 Jul 2012 04:22:22 +0200 (CEST)

Tom Gindin wrote:
> is clearly an EE.

If the only means offered by PKI software, to mark a peer's certificate
as trusted, is to import it as a trust anchor, then importing certs
that are clearly EEs (and enforcing this as trust anchor constraint")
is actually a perfectly reasonable action.

Importing TLS server certs that are valid CA certs is the real problem,
because it may have very serious unintended consequences.

>
> Directly trusted EE certificates, although they have their place
> in many implementations of PKI-using applications, are out of 

Peer certificates that are directly trusted usually bypass all of PKI(X).

While they may not constitute "trust anchors" in the original sense as
input to the 6.1 certificate path validation, most PKI(X) software is
not particularly helpful in distinguishing "trusted communication peer
certificates" from "trust anchors", in terminology and documentation.

Have you ever clicked on a self-signed cert in a file "somecert.cer"
in a popular OS and observed where the certificate wizard will suggest
to place that cert?

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 20 Jul 2012 06:00:53 +0200 (CEST)

Santosh Chokhani wrote:
> 
> Do you agree that V1, V2, or V3 self-signed certificate without any
> extensions or without basic constraint extension present in it can
> be a trust anchor for path validation?

That is what rfc5280 says (per 6.1.1 (d)).  The certificate path
validation function does might ignore any (certificate) attributes
that accompanied the "trust anchor" on "arrival".

> 
> I would even go as far as to say that even if cA = FALSE is present
> in basic constraints, per Section 6 one can use it as a trust anchor
> for path validation.

While it feels wrong somehow, this is explicitly permitted by rfc5280,
last sentence of last paragraph of section 6.2:

                              Implementations that use self-signed
   certificates to specify trust anchor information are free to make
   use of any additional information that is included in the
   certificates, or to ignore such information.

If I would implement this, I would probably _not_ ignore an CA=FALSE
BasicConstraint, but instead limit the "path validation" capability
of such a cert to an exact match of itself.

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 20 Jul 2012 07:39:55 +0200

> scope for certificate validation and don't constitute trust anchors.
If an application can use *anything* that carries the necessary
information of a trust anchor, so be it.
Why would one want to restrict the form of the container?
Because it looks like something that can or cannot be use
in whatever other context?

It is not "using a self signed ee cert or ca cert of v4711 cert
as a trust anchor"  but IMO rather "If a structure that
syntactically looks like a certificate is used as a trust anchor,
then fields unusable for that purpose, e.g., version,
a basicconstraints  extension, issuer? ...   have no meaning
or not the meaning when used as certificate in the context
of pathvalidation"

> Tom Gindin
Peter

---

From: Sean Turner <[email-masked]>
Date: Fri, 20 Jul 2012 08:24:37 -0400

Having watched this issue play out based on a request in my AD review 
back in 2011-08-02 (yep that's about a year ago), here's my proposal:

   Remove the proposed updates for s3.2 to RFC 5280 (i.e.,
   delete s2 entirely from the draft).

AD's don't get everything they want ;)  I think it's time to get the 
text that has consensus published.

spt

On 6/19/12 11:17 AM, Stephen Kent wrote:
> There are very few changes since the last published version. The only
> major change is a new paragraph on our favorite topic of self-signed EE
> certs.

---

From: Tom Gindin <[email-masked]>
Date: Fri, 20 Jul 2012 09:12:34 -0400

Martin:

        I don't see much difference between treating such a certificate as 
a directly trusted EE and limiting the "path validation" capability of 
such a cert to an exact match of itself.  Thus, I think we agree how to 
treat this in practice.  However, there's no obvious way to store such an 
agreement in RFC 5914's format although you could probably fudge something 
using Name Constraints.

Tom Gindin

From:   [email-masked] (Martin Rex)
To:     Santosh Chokhani <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>, "David A. Cooper" 
<[email-masked]>, Tom Gindin/Watson/IBM@IBMUS, "[email-masked]" 
<[email-masked]>
Date:   07/20/2012 12:02 AM
Subject:        Re: [pkix] new version of 5280 clarifications

-Martin

---

From: Tom Gindin <[email-masked]>
Date: Fri, 20 Jul 2012 09:18:45 -0400

Peter:

        Admittedly, my word choice was inconsistent.  I should have said "
still used as sources for trust anchors", to match the later reference to 
"importing".  However, the issuer of a v3 non-CA certificate, whether the 
subject or not, does not intend that anyone use that key and name to 
validate other certificates.  Therefore, code which creates trust anchors 
by importing certificates should not do so with a v3 non-CA certificate, 
although it may deem these certificates to be directly trusted EE's if it 
so chooses.

Tom Gindin

From:   Peter Sylvester <[email-masked]>
To:     [email-masked], 
Date:   07/20/2012 01:40 AM
Subject:        Re: [pkix] new version of 5280 clarifications
Sent by:        [email-masked]

Peter

---

From: Carl Wallace <[email-masked]>
Date: Fri, 20 Jul 2012 09:23:04 -0400

>agreement in RFC 5914's format although you could probably fudge

In RFC 5914, you can create a TA that cannot be used path processing by
using the TrustAnchorInfo structure and omitting the CertPathControls
field.  This is noted in section 2.5.  However, there's not a
straightforward way to use a certificate and mark it as not suitable for
path processing (since certificates are stored in CertPathControls).  As
you note, constraints could be used to fudge something where using a
certificate is desired.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 20 Jul 2012 17:30:16 +0200

> although it may deem these certificates to be directly trusted EE's if it
Trust and distrust are not transitive.
Code which creates trust anchors are importing trust anchor
information containers, if they happen to look like something
else, it doesn't matter.

Anyway, if I have a certficate, I can create my self signed and
add whather I want. Does trust anchor establishing code
look at the issuer of a cert?

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Jul 2012 17:46:37 -0700

On Jul 20, 2012, at 5:24 AM, Sean Turner wrote:

> Having watched this issue play out based on a request in my AD review back in 2011-08-02 (yep that's about a year ago), here's my proposal:
> 
> AD's don't get everything they want ;)  I think it's time to get the text that has consensus published.

Please: no. Instead, the chairs could be more active about building consensus. The current method (let topics wander around without specific consensus calls) hasn't worked, but other methods probably will.

And it is not just for what ADs want here: this was a very real problem that caused a lot of wasted time in a different WG (DANE), and could absolutely affect other WGs in the future (tls and httpbis).

--Paul Hoffman

---

From: [email-masked] (Martin Rex)
Date: Mon, 23 Jul 2012 19:47:17 +0200 (CEST)

> although it may deem these certificates to be directly trusted EE's if it 

Unfortunately, the world is not as simple as we might like it to be:

  http://www.entrust.net/knowledge-base/technote.cfm?tn=7869

To me it appears that neither the admin who created the cert,
nor the software that he used for this, nor any of the Browser vendors/
suppliers adequately complained about the obvious invalidity of this
X.509v3 RootCA cert, before it was wide shipped and put in use.

Our own PKI software did not allow use of such a cert as "trust anchor"
(i.e. signer of other certs), so I received a few support calls back then.

-Martin

---

From: Tom Gindin <[email-masked]>
Date: Mon, 23 Jul 2012 21:24:57 -0400

Martin:

        I do know that certificate, and I have had a copy of it for 
several years.  Entrust issued another one with the same key and name and 
standard extensions.  I've had a copy of that one for over two years as 
well.
        I would characterize the older of the two certificates as a 
"non-compliant CA certificate" rather than as a "non-CA certificate", 
since its NetscapeCertType extension indicates that it's a CA.  Its 
notBefore date is less than a year after RFC 2459.
        Would you think my wording would be more appropriate as "a 
certificate containing a KeyUsage extension without keyCertSign set"? That 
thing doesn't have a KeyUsage, and most v3 EE certificates do.

Tom Gindin

From:   [email-masked] (Martin Rex)
To:     Tom Gindin/Watson/IBM@IBMUS, 
Cc:     Peter Sylvester <[email-masked]>, [email-masked]
Date:   07/23/2012 01:52 PM
Subject:        Re: [pkix] new version of 5280 clarifications

-Martin