Subject: [pkix] 5280 clarifications

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 12:58:39 -0400

David,

I have three suggestions for text for the 5280 clarifications doc:

In your latest rev there is added text that addresses one of the 
issues that arose in DANE re self-signed EE cert use in the TLS 
context.  I find that text confusing. I suggest the following text, 
which focuses on a different aspect
of SS-EE cert use. We need to ask the Security ADs if they feel the 
following text, or some combination of it and what you already wrote, 
addresses the
DANE issues.

Section 3.2: insert this new paragraph after the (current) last paragraph

The PKI model defined in X.509 requires that an entity that signs a 
(public key) certificate be a CA. The notion of a self-signed end 
entity certificate deviates from the X.59 model. A self-signed, end 
entity certificate generally is not compatible with the certificate 
path validation mechanism described in Section 6. However, as noted 
in Sections 6.1 and 6.1.1, a self-signed certificate may be used 
convey a trust anchor. In practice, if this trust anchor certificate 
fails to include the BasicConstraints extension, which is used to 
mark a certificate as a CA certificate, this does not adversely 
affect certificate path processing. Thus the preceding text 
discussing certificate types should be interpreted as follows: A 
self-signed certificate used exclusively to convey trust anchor data 
need not be marked as a CA certificate, although such marking is 
RECOMMENDED. All other self-signed certificates MUST be marked as CA 
certificates.

Sean Turner also suggested that we make an explicit reference to RFC 
5937, when we discuss path processing.  So, I suggest the following 
text change for 6.1.1:

Add the following text in 6.1.1, at the end of the section.

OLD:
Conforming implementations are not required to support the setting of 
all of these inputs.  For example, a conforming implementation may be 
designed to validate all certification paths using a value of FALSE 
for initial-any-policy-inhibit.

NEW:
Conforming implementations are not required to support the setting of 
all of these inputs.  For example, a conforming implementation may be 
designed to validate all certification paths using a value of FALSE 
for initial-any-policy-inhibit.
Implementers are encouraged to make use of the capabilities defined 
in RFC 5937, which describes how to make use of trust anchor 
constraints during path processing, including certificate policies, 
name constraints, and path length.

Finally, based on the discussions in SIDR and the docs that have been 
issued as RFCs, I suggest the following changes to text in the 
Secruity Considerations section:

Replace the following text with the new text below, in the security 
considerations section (Section 8)

OLD:
While X.509 mandates that names be unambiguous, there is a risk that 
two unrelated authorities will issue certificates and/or CRLs under 
the same issuer name. As a means of reducing problems and security 
issues related to issuer name collisions, CA and CRL issuer names 
SHOULD be formed in a way that reduces the likelihood of name 
collisions.  Implementers should take into account the possible 
existence of multiple unrelated CAs and CRL issuers with the same 
name.  At a minimum, implementations validating CRLs MUST ensure that 
the certification path of a certificate and the CRL issuer 
certification path used to validate the certificate terminate at the 
same trust anchor.

NEW:
While X.509 mandates that names be unambiguous, there is a risk that 
two unrelated authorities will issue certificates and/or CRLs under 
the same issuer name. This could occur accidentally or it might be 
part of an attack. In the latter case, a CA might issue certificates 
to CAs, inserting subject names that intentionally conflict with 
subject names in other, legitimate certificates. A CA behaving in 
this fashion might also assign certificate serial numbers to collide 
with entities being targeted in the attack.

To address the possibility of accidental name collisions, CA and CRL 
issuer names SHOULD be formed in a way that reduces the likelihood of 
name collisions. Examples of such techniques appear in Section 8 of 
[RFC 6487]. To address both accidental and malicious scenarios, 
implementers should take into account the possible existence of 
multiple unrelated CAs and CRL issuers with the same name (and 
possibly the same serial number).  At a minimum, implementations 
validating CRLs MUST ensure that the certification path of a 
certificate and the CRL issuer certification path used to validate 
the certificate terminate at the same trust anchor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2012 17:47:46 -0700

On Mar 19, 2012, at 9:58 AM, Stephen Kent wrote:

> In your latest rev there is added text that addresses one of the issues that arose in DANE re self-signed EE cert use in the TLS context.  I find that text confusing. I suggest the following text, which focuses on a different aspect
> of SS-EE cert use. We need to ask the Security ADs if they feel the following text, or some combination of it and what you already wrote, addresses the
> DANE issues.
> 
> The PKI model defined in X.509 requires that an entity that signs a (public key) certificate be a CA. The notion of a self-signed end entity certificate deviates from the X.59 model. A self-signed, end entity certificate generally is not compatible with the certificate path validation mechanism described in Section 6. However, as noted in Sections 6.1 and 6.1.1, a self-signed certificate may be used convey a trust anchor. In practice, if this trust anchor certificate fails to include the BasicConstraints extension, which is used to mark a certificate as a CA certificate, this does not adversely affect certificate path processing. Thus the preceding text discussing certificate types should be interpreted as follows: A self-signed certificate used exclusively to convey trust anchor data need not be marked as a CA certificate, although such marking is RECOMMENDED. All other self-signed certificates MUST be marked as CA certificates.

I prefer the paragraph currently in the document. The first two sentence above are an unattributed assertion, one that others have disagreed with. I do not think that putting them into a standards-track update document is warranted unless they are the consensus of both this WG and of the maintainers of X.509. Given the unlikelihood of that, the current text is better. Further, the last two sentences above go against current practice, and they replace sentences in the current draft that seem more in line with current practice.

> Sean Turner also suggested that we make an explicit reference to RFC 5937, when we discuss path processing.  So, I suggest the following text change for 6.1.1:
> 
> Conforming implementations are not required to support the setting of all of these inputs.  For example, a conforming implementation may be designed to validate all certification paths using a value of FALSE for initial-any-policy-inhibit.
> 
> NEW:
> Conforming implementations are not required to support the setting of all of these inputs.  For example, a conforming implementation may be designed to validate all certification paths using a value of FALSE for initial-any-policy-inhibit.
> Implementers are encouraged to make use of the capabilities defined in RFC 5937, which describes how to make use of trust anchor constraints during path processing, including certificate policies, name constraints, and path length.

That seems fine, and the appropriate level of emphasis given that RFC 5937 is informational, not standards track.

> Finally, based on the discussions in SIDR and the docs that have been issued as RFCs, I suggest the following changes to text in the Secruity Considerations section:
> 
> Replace the following text with the new text below, in the security considerations section (Section 8)
>  
> OLD:
> While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. As a means of reducing problems and security issues related to issuer name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions.  Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name.  At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor.
> 
> 
> NEW:
> While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. This could occur accidentally or it might be part of an attack. In the latter case, a CA might issue certificates to CAs, inserting subject names that intentionally conflict with subject names in other, legitimate certificates. A CA behaving in this fashion might also assign certificate serial numbers to collide with entities being targeted in the attack.
> 
> To address the possibility of accidental name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions. Examples of such techniques appear in Section 8 of [RFC 6487]. To address both accidental and malicious scenarios, implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name (and possibly the same serial number).  At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor.

Good addition, yes.

--Paul Hoffman

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 22 Mar 2012 09:15:56 -0400

As the past editor of X.509 and someone whose history participating in the X.509 standards group goes back 25 years to 1987, I'd like to confirm that the X.509 model (going back all the way to the first edition published in 1988) is one where public key certificate signers/issuers are exclusively CAs. Therefore the first two sentences in the new proposed text below are a correct interpretation of X.509. 

Cheers,
Sharon Boeyen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Monday, March 19, 2012 8:48 PM
To: PKIX
Subject: Re: [pkix] 5280 clarifications

On Mar 19, 2012, at 9:58 AM, Stephen Kent wrote:

> context.  I find that text confusing. I suggest the following text, which focuses on a different aspect of SS-EE cert use. We need to ask the Security ADs if they feel the following text, or some combination of it and what you already wrote, addresses the DANE issues.
> 
> Section 3.2: insert this new paragraph after the (current) last 
> paragraph The PKI model defined in X.509 requires that an entity that signs a (public key) certificate be a CA. The notion of a self-signed end entity certificate deviates from the X.59 model. A self-signed, end entity certificate generally is not compatible with the certificate path validation mechanism described in Section 6. However, as noted in Sections 6.1 and 6.1.1, a self-signed certificate may be used convey a trust anchor. In practice, if this trust anchor certificate fails to include the BasicConstraints extension, which is used to mark a certificate as a CA certificate, this does not adversely affect certificate path processing. Thus the preceding text discussing certificate types should be interpreted as follows: A self-signed certificate used exclusively to convey trust anchor data need not be marked as a CA certificate, although such marking is RECOMMENDED. All other self-signed certificates MUST be marked as CA certificates.

Good addition, yes.

--Paul Hoffman

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Mar 2012 07:37:12 -0700

> As the past editor of X.509 and someone whose history participating in the X.509 standards group goes back 25 years to 1987, I'd like to confirm that the X.509 model (going back all the way to the…

This in interesting to hear. It is relevant to X.509, although it would be more so if it was actually written in the spec.

There is the second issue of whether PKIX, the IETF's profile, is allowed to change that model. We have changed a lot of the X.509 model, and there is a huge amount of software that does so today under the assumption that PKIX (not X.509) allows this.

I'm not convinced that the PKIX document (in this case, the update to the PKIX document) needs to call out what the X.509 document intended here.

--Paul Hoffman

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 22 Mar 2012 10:57:35 -0400

PKIX is about public key infrastructure.   Self-signed EE certs are
unrelated to PKI.  The question is "should a PKIX document acknowledge
the existence of any non-PKI usage of data structures defined by X.509"?

I believe it should do so, in particular to recommend formatting such
certificates so that they cannot be confused with PKI certificates.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Hoffman
Sent: Thursday, March 22, 2012 10:37 AM
To: Sharon Boeyen
Cc: PKIX
Subject: Re: [pkix] 5280 clarifications

On Mar 22, 2012, at 6:15 AM, Sharon Boeyen wrote:

> As the past editor of X.509 and someone whose history participating in
the X.509 standards group goes back 25 years to 1987, I'd like to
confirm that the X.509 model (going back all the way to the first
edition published in 1988) is one where public key certificate
signers/issuers are exclusively CAs. Therefore the first two sentences
in the new proposed text below are a correct interpretation of X.509. 

This in interesting to hear. It is relevant to X.509, although it would
be more so if it was actually written in the spec.

There is the second issue of whether PKIX, the IETF's profile, is
allowed to change that model. We have changed a lot of the X.509 model,
and there is a huge amount of software that does so today under the
assumption that PKIX (not X.509) allows this.

I'm not convinced that the PKIX document (in this case, the update to
the PKIX document) needs to call out what the X.509 document intended
here.

--Paul Hoffman

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 22 Mar 2012 12:25:07 -0400

It IS written in the spec. You can download the 2009 edition of X.509 free of charge from http://www.x500standard.com/index.php?n=Ig.LatestAvail  (or pay for the current version). In the 2009 edition, in the definitions section you will find the following:

3.4.17	certification authority (CA ): An authority trusted by one or more users to create and assign public-key certificates. Optionally the certification authority may create the users' keys .

And

3.4.27	end entity : Either a public key certificate subject that uses its private key for purposes other than signing certificates, or an attribute certificate holder that uses its attributes to gain access to a resource, or an entity that is a relying party .

As well as:

3.4.57	self-issued certificate : A public-key certificate where the issuer and the subject are the same CA. A CA might use self-issued certificates, for example, during a key rollover operation to provide trust from the old key to the new key .

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, March 22, 2012 10:37 AM
To: Sharon Boeyen
Cc: PKIX
Subject: Re: [pkix] 5280 clarifications

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Thu, 22 Mar 2012 12:52:38 -0400

>3.4.57  self-issued certificate : A public-key certificate where the issuer and the subject are the same CA. A CA might use self-issued certificates, for example, during a key rollover operation to…

Hi Sharon - 

I don't actually read it that way - I'm sure you know what you intended, but that's not what it says.   

What you probably meant to say was:

>end entity : Either a public key certificate subject that uses its private key [ONLY] for purposes other than signing certificates, or an attribute certificate holder that uses its attributes to gain access to a resource, or an entity that is a relying party .

AIRC a CA certificate doesn't even need a basicConstraints extension - if it doesn't contain such extension, its imputed to be a CA certificate if it signs certificates.  

But nothing in X.509 seems to prevent a CA certificate from signing end-entity types of things.

So a self-signed certificate without a basicConstraints extension that also signs things other than certificates is both a CA certificate and an end-entity certificate?

I think I'm with Paul here....

Mike

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 22 Mar 2012 18:17:35 +0100

In 8.4.2.1 (basicConstraints) has a NOTE 1 saying:" If this extension is not
present, or is flagged non-critical and is not recognized by a
certificate-using system, then the certificate is to be considered an
end-entity certificate and cannot be used to verify certificate signatures."

I read this to say that in a version 3 public-key certificate this extension
shall be present if the subject is acting as a CA signing public-key
certificates.

As this note seems normative, it will in the next edition be changed to
normal text.

Erik

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af
Michael StJohns
Sendt: 22. marts 2012 17:53
Til: Sharon Boeyen; Paul Hoffman
Cc: PKIX
Emne: Re: [pkix] 5280 clarifications

At 12:25 PM 3/22/2012, Sharon Boeyen wrote:
>It IS written in the spec. You can download the 2009 edition of X.509 free
of charge from http://www.x500standard.com/index.php?n=Ig.LatestAvail  (or
pay for the current version). In the 2009 edition, in the definitions
section you will find the following:
>
>3.4.17  certification authority (CA ): An authority trusted by one or more
users to create and assign public-key certificates. Optionally the
certification authority may create the users' keys .
>
>And
>
>3.4.27  end entity : Either a public key certificate subject that uses its
private key for purposes other than signing certificates, or an attribute
certificate holder that uses its attributes to gain access to a resource, or
an entity that is a relying party .
>
>As well as:
>
>3.4.57  self-issued certificate : A public-key certificate where the issuer
and the subject are the same CA. A CA might use self-issued certificates,
for example, during a key rollover operation to provide trust from the old
key to the new key .

Hi Sharon - 

I don't actually read it that way - I'm sure you know what you intended, but
that's not what it says.   

What you probably meant to say was:

>end entity : Either a public key certificate subject that uses its private
key [ONLY] for purposes other than signing certificates, or an attribute
certificate holder that uses its attributes to gain access to a resource, or
an entity that is a relying party .

AIRC a CA certificate doesn't even need a basicConstraints extension - if it
doesn't contain such extension, its imputed to be a CA certificate if it
signs certificates.  

But nothing in X.509 seems to prevent a CA certificate from signing
end-entity types of things.

So a self-signed certificate without a basicConstraints extension that also
signs things other than certificates is both a CA certificate and an
end-entity certificate?

Mike

>> As the past editor of X.509 and someone whose history participating in
the X.509 standards group goes back 25 years to 1987, I'd like to confirm
that the X.509 model (going back all the way to the first edition published
in 1988) is one where public key certificate signers/issuers are exclusively
CAs. Therefore the first two sentences in the new proposed text below are a
correct interpretation of X.509. 
>
>
>This in interesting to hear. It is relevant to X.509, although it would be
more so if it was actually written in the spec.
>
>There is the second issue of whether PKIX, the IETF's profile, is allowed
to change that model. We have changed a lot of the X.509 model, and there is
a huge amount of software that does so today under the assumption that PKIX
(not X.509) allows this.
>
>I'm not convinced that the PKIX document (in this case, the update to the
PKIX document) needs to call out what the X.509 document intended here.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Mar 2012 17:44:59 +0000

Hi Sharon,

Two things on this.

a) I agree with others that whatever the intent, the text is not clear
either way and to me doesn't preclude self-signed cert-like things not
generated by CAs. I'm pretty confident of that for 5280, since I
checked, but haven't read x.509 for quite a while. (And anyway, how
could those documents preclude them? I can show you one anytime you
like.)

But *much* more importantly:

b) There is no way in the world that self-signed certs that are not from
CAs are going to disappear and attempting to specify them out of
existence would just be dumb. That's not only due to installed base,
nor only due to the fact that regardless of X.509 or 5280 other IETF
protocols (TLS, notably) allow for and see deployments of these, but
is also because sometimes these things are useful and easier than
setting up a pseudo or personal CA.

If someone cares enough to invent some new/better terminology, that
might of course be useful, but I'm not sure it'd be worth what'd be
bound to be a gigantic and (I predict;-) mostly pointless debate.

If someone else wanted to release some OSS that did the make a pesudo-CA
thing in an easy to use way that'd be great too and who knows might
reduce the need for self-signed certs (not generated by a CA).

My personal take fwiw, no hats and all that,
S.

---

From: Alan Sill <[email-masked]>
Date: Thu, 22 Mar 2012 13:11:31 -0500

I also agree that this is likely to be a pointless argument, as it is  
technically possible to generate self-signed certificates, and  
unambiguously trivial to identify them.

In practice, any set of CP and/or CPS statements for a CA will include  
statements describing the route of trust.  The matter of trust in a  
particular PKI will be driven by a profile.  It is not necessary for  
the base specification (X.509 and/or 5280) to specify statements as to  
whether self-signed certificates are allowed or not, as this will be  
necessarily covered in the profile.

An example I can hold out that has real application in large-scale PKi  
implementations is the Grid Certificate Profile, GFD.125 from OGF,  
which covers the conditions for accreditation used by the  
International Grid Trust Federation for large-scale grids.   
(Significant work is going on to extend the use of tools based on  
these into cloud architectures as well).  This document is currently  
in informational status, but has started the process to become a  
proposed recommendation from OGF.

   http://ogf.org/documents/GFD.125.pdf

This profile (properly named) gives the conditions for application of  
X.509 and RFC3280 -- the document in progress as a proposed  
recommendation will update this to 5280.  It then serves as input to a  
trust federation (the IGTF), that enforces this and other conditions  
on the accreditation of certification authorities to be used in its  
distribution,

   http://www.igtf.net

Since the decisions on whether or not to trust CAs will in principle  
be made either by a trust federation of tis nature, or by processes  
with equivalent constraints such as those used for browser inclusion,  
and since the consumer not part of such federations and using such CAs  
is warned of the existence of a self-signed cert, is this really a  
problem that PKIX needs to solve?  I argue no, as this is essentially  
always extended by a profile.

Alan

On Mar 22, 2012, at 12:44 PM, Stephen Farrell wrote:

> There is no way in the world that self-signed certs that are not from

---

From: Jay McGuerty <[email-masked]>
Date: Thu, 22 Mar 2012 11:13:19 -0700

Please remove me from this email list

-- 
Jay McGuerty CISSP, GCIH, GPEN, GWAPT
Principal Security Engineer
SAIC/IISBU
10260 Campus Point Drive
Jay McGuerty
Principal Security Engineer
Science Application International Corporation
10260 Campus Point Drive
San Diego, CA 92121
858.826.7309 w
858.663.5209 c

This communication may contain information that is legally privileged,
confidential or exempt from disclosure.  If you are not the intended
recipient, please do not read, disseminate, distribute or copy this
communication.  Anyone who receives this message in error should notify the
sender immediately by telephone or by return e-mail and delete it from his
or her computer.

------ Forwarded Message
From: Alan Sill <[email-masked]>
Date: Thu, 22 Mar 2012 13:11:31 -0500
To: PKIX <[email-masked]>
Subject: Re: [pkix] 5280 clarifications

[email-masked]

------ End of Forwarded Message

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2012 19:22:51 +0100 (MET)

Sharon Boeyen wrote:
> 
> As the past editor of X.509 and someone whose history participating
> in the X.509 standards group goes back 25 years to 1987, I'd like
> to confirm that the X.509 model (going back all the way to the first

I think we all know *that* limitation of X.509, which is IMHO hard to
misunderstand (once found) in X.509 11/2008, section 3.4.61:

3.4.61 self-signed certificate: [...]

   NOTE  Use of self-issued certificates and self-signed certificates
   issued by other than CAs are outside the scope of this
   Recommendation | International Standard.

The interesting question is really what should PKIX say instead
so that a pretty common practice in the installed base can migrate from
being "implementation defined" to a more coherent/consistent behaviour
in the future.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Mar 2012 11:46:43 -0700

>   Recommendation | International Standard.

This sentence was the one that made the most sense to me when we discussed the topic of self-issued certs last year in the DANE WG. If X.509 puts them out of scope, PKIX can say whatever it wants, and PKIX should reflect the real world.

--Paul Hoffman

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 23 Mar 2012 10:48:04 +0100

What that note say is that if you outside the standard, you are on your own
and Good bless you. Standards are not laws. You follow them for
interoperability reasons. If you want to cut corners, nobody can stop you.

Erik

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Paul
Hoffman
Sendt: 22. marts 2012 19:47
Til: PKIX
Emne: Re: [pkix] 5280 clarifications

>   Recommendation | International Standard.

This sentence was the one that made the most sense to me when we discussed
the topic of self-issued certs last year in the DANE WG. If X.509 puts them
out of scope, PKIX can say whatever it wants, and PKIX should reflect the
real world.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Mar 2012 04:19:56 -0400

Paul,

I found the text that David offered to be confusing, at best.

For example, if a TLS server transmits a self-signed cert in the 
handshake, and there is no subordinate cert representing the site, 
does this cert begin the cert path or not? Is there no cert path 
because there is just one cert? Is this cert not treated as a TA and 
used to verify a sig in a fashion consistent with
what TAMP allows?

Why does the text say that "... self-signed end-entity certificates 
SHOULD NOT include a BasicConstraints extension that asserts the cA 
boolean." If the cert has this flag set, then it is a CA cert, not an 
EE cert. I don't find this text to be clear or helpful. The final 
sentence of David's text is certainly non-judgmental, which appears 
to be what you would like to see, but that was not the message I (and 
others, see below) wanted to convey.

All three of the blocks of text that appear in my message were sent 
to Sean Turner, Tim Polk, and Russ Housley, prior to being sent to 
David. There was
no disagreement with the wording I proposed. David chose to ignore 
two of blocks of text, and transformed the first one into the text 
that you prefer. So, we have an internal communication problem with 
the author :-).

Let me reiterate that this text, while written by me, was reviewed by 
other, long-time PKIX contributors, two of whom (Russ and Tim) are 
co-authors of 5280, and its predecessors. The one 5280 co-author who 
has said, publicly, that he didn't view self-signed EE certs as not 
being inconsistent with 5280 and X.509 is Stephen Farrell. Sharon 
Boyen just indicated that, fro her perspective as editor, the X.509 
model assumes that the signer of a cert is a CA.

My goal in writing the text about self-signed  certs was to clarify the
5280 position on them, saying that they are OK in certain, limited 
contexts. At the same time I want to state that, in general, PKIX 
prefers certs to be verified using CA certs, consistent with the 
X.509 model and general practice.

I am open to revising the text in question, but I do  not find what 
David has provided is useful.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 28 Mar 2012 18:25:22 -0400

On 03/26/2012 04:19 AM, Stephen Kent wrote:

When Steve Kent sent me these three blocks of text, the only thing
that his message said about the text was "Here is proposed text for
5280bis to move forward."  There was no indication in any way that
the text had been reviewed by anyone else before Steve sent it to
me.  I did not use the first block of text that Steve proposed as it
appeared to state that self-signed end-entity certificates MUST be
marked as CA certificates, and so I did my best to come up with
alternative text.  I tried my best to incorporate the ideas from the
other two blocks of text, but I incorporated the ideas into areas of
the document that were more appropriate: mention of RFC 5937 in the
text that already mentions using extensions in a self-signed
certificate to set the inputs to path validation and mention of
actions that a malicious CA could take in the paragraph that
discusses the risk of CA compromise.

When I posted the draft I asked Sean Turner if it was acceptable to
him, since the draft was updated based on a request from him to
address self-signed end-entity certificates
(http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html),
and Sean said that he thought the revised draft looked okay.

I saw that this draft was discussed during the PKIX session:

This topic was added at the beginning of the meeting, at
Paul Hoffman's request. David Cooper, the document author was not
present. Paul suggests that we work on the list to revise the text
dealing with self-signed end-entity certificates, as the primary,
remaining open issue for this document. Steve Kent agreed to work
with Paul on revised text on this topic.

So, I expect to see new text on self-signed end-entity certificates
proposed on the list at some point.  In addition, Paul Hoffman has
proposed updated text for the Abstract and Introduction.  Unless I
see further discussion on the list, I will take the meeting minutes
to indicate that no further changes are required to any of the other
text in the draft.

---

From: [email-masked]
Date: Thu, 29 Mar 2012 14:23:42 +0200

David,

A point I mentioned during my presentation about rfc2560bis (slide 3).

" which keyUsage bits and extended key usage OIDs shall be present 
in the CA certificate is not even said".

In RFC 5280 , for the key usage bits we have in particular:

keyCertSign             (5),
cRLSign                 (6),

We do not have OCSPSign.

It would be nice both in RFC 5280 and in rfc2560bis to clarify which 
fields or extensions allow to know 
that the entity is allowed to sign OCSP responses directly.

Denis 

De :    "David A. Cooper" <[email-masked]>
A :     PKIX <[email-masked]>
Date :  29/03/2012 00:25
Objet : Re: [pkix] 5280 clarifications
Envoyé par :    [email-masked]

When Steve Kent sent me these three blocks of text, the only thing that 
his message said about the text was "Here is proposed text for 5280bis to 
move forward."  There was no indication in any way that the text had been 
reviewed by anyone else before Steve sent it to me.  I did not use the 
first block of text that Steve proposed as it appeared to state that 
self-signed end-entity certificates MUST be marked as CA certificates, and 
so I did my best to come up with alternative text.  I tried my best to 
incorporate the ideas from the other two blocks of text, but I 
incorporated the ideas into areas of the document that were more 
appropriate: mention of RFC 5937 in the text that already mentions using 
extensions in a self-signed certificate to set the inputs to path 
validation and mention of actions that a malicious CA could take in the 
paragraph that discusses the risk of CA compromise.

When I posted the draft I asked Sean Turner if it was acceptable to him, 
since the draft was updated based on a request from him to address 
self-signed end-entity certificates (
http://www.ietf.org/mail-archive/web/pkix/current/msg29661.html), and Sean 
said that he thought the revised draft looked okay.

I saw that this draft was discussed during the PKIX session:
This topic was added at the beginning of the meeting, at Paul Hoffman's 
request. David Cooper, the document author was not present. Paul suggests 
that we work on the list to revise the text dealing with self-signed 
end-entity certificates, as the primary, remaining open issue for this 
document. Steve Kent agreed to work with Paul on revised text on this 
topic.

So, I expect to see new text on self-signed end-entity certificates 
proposed on the list at some point.  In addition, Paul Hoffman has 
proposed updated text for the Abstract and Introduction.  Unless I see 
further discussion on the list, I will take the meeting minutes to 
indicate that no further changes are required to any of the other text in 
the draft.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Tom Gindin <[email-masked]>
Date: Thu, 29 Mar 2012 20:49:16 -0400

Denis:

        As you know, the flag is in EKU and is called id-kp-OCSPSigning, 
and OCSP responders should have it set.  So there are three questions 
which 2560-bis must cover:
1)      Should an OCSP response be accepted which is signed by a 
certificate with EKU present if id-kp-OCSPSigning is not set?
2)      Should an OCSP response be accepted which is signed by a v3 
certificate with no EKU extension?
3)      Should an OCSP response be accepted which is signed by a v1 or v2 
certificate?
        2560-bis section 2.5.6.1 says that unless the RP's local 
configuration contains the signing certificate individually, the answer to 
all three of these questions is "only if it's the issuer's certificate".

Tom Gindin

From:   [email-masked]
To:     "David A. Cooper" <[email-masked]>, 
Cc:     PKIX <[email-masked]>
Date:   03/29/2012 08:24 AM
Subject:        Re: [pkix] 5280 clarifications
Sent by:        [email-masked]

David, 

keyCertSign             (5), 
cRLSign                 (6), 

We do not have OCSPSign. 

Denis

---

From: [email-masked]
Date: Fri, 30 Mar 2012 13:59:13 +0200

Tom,

Slide 3 is not about the delegated case, nor about a local configuration.

It is about what is called in rfc2560bis the "Integrated OCSP Responders" 
case.

In RFC 5280 we should say briefly what is used for OCSP in that case.

In rfc2560bis-05 we should provide details. The key point is: if the 
certificate from the OCSP responder 
does not include an id-kp-OCSPSigning extension, and if there is no local 
configuration then what
should be the content of the key usage extension and what other controls 
should be done on the certificate
by the client.

Once these controls will be written, we will need to add some more 
material in the security considerations section.

Denis

De :    Tom Gindin <[email-masked]>
A :     [email-masked]
Cc :    "David A. Cooper" <[email-masked]>, PKIX <[email-masked]>
Date :  30/03/2012 02:49
Objet : Re: [pkix] 5280 clarifications

        Denis:

Tom Gindin

David, 

keyCertSign             (5), 
cRLSign                 (6), 

We do not have OCSPSign. 

Denis