Subject: Re: [pkix] 5280 clarifications

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Apr 2012 10:34:50 -0700

Greetings again. I think I understand your problem with the current draft wording, namely that it mis-uses terms that already have specific meanings. I propose the following to replace both what you proposed and what David has in the current draft. I believe that this does not stomp on any current definitions but still makes it clear that such certificates exist.

Certificates with a signing key that is the same as the key in the subjectPublicKeyInfo, but that do not include a BasicConstraints extension that asserts the cA boolean, are commonly used to convey public keys without an expectation that the contents of such certificates can be validated. These certificates are sometimes used for transmitting a PKIX trust anchor or the unvalidated public key of an end entity; other uses are certainly possible as well. The format and use of such certificates are outside the scope of both X.509 and this specification. Note that these certificates cannot formally be called "self-signed" or "self-issued" because they do not follow the definition in the preceding paragraph.

Does this work for you? If not, are there any statements in it that are wrong, or do you want it to say more?

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Apr 2012 14:08:15 -0400

At 10:34 AM -0700 4/2/12, Paul Hoffman wrote:
>Greetings again. I think I understand your 
>problem with the current draft wording, namely 
>that it mis-uses terms that already have 
>specific meanings. I propose the following to 
>replace both what you proposed and what David 
>has in the current draft. I believe that this 
>does not stomp on any current definitions but 
>still makes it clear that such certificates 
>exist.
>
>Certificates with a signing key that is the same 
>as the key in the subjectPublicKeyInfo, but that 
>do not include a BasicConstraints extension that 
>asserts the cA boolean, are commonly used to 
>convey public keys without an expectation that 
>the contents of such certificates can be 
>validated. These certificates are sometimes used 
>for transmitting a PKIX trust anchor or the 
>unvalidated public key of an end entity; other 
>uses are certainly possible as well. The format 
>and use of such certificates are outside the 
>scope of both X.509 and this specification. Note 
>that these certificates cannot formally be 
>called "self-signed" or "self-issued" because 
>they do not follow the definition in the 
>preceding paragraph.
>
>
>Does this work for you? If not, are there any 
>statements in it that are wrong, or do you want 
>it to say more?
>
>--Paul Hoffman

Certificates with a signing key that is the same 
as the key in the subjectPublicKeyInfo, but that 
do not include a BasicConstraints extension that 
asserts the cA boolean, are commonly used to 
convey public keys without an expectation that 
the contents of such certificates can be 
validated.

I see several problems with the first sentence. 
First, it's too long :-) Second, a signing  key 
is a private key and the key in the SPKI field is 
a public key, so they are not the same key. 
Third, the last phrase "without and expectation 
Š" is confusing to me.

These certificates are sometimes used for 
transmitting a PKIX trust anchor or the 
unvalidated public key of an end entity

Let's just refer to a trust anchor, not a "PKIX trust anchor."

"unvalidated" may not be the best term here, it's 
"un-vouched for"  relative to a CA.  I'll try to 
think of a better term.

; other uses are certainly possible as well.

This statement seems rather vague., it that 
intentional?  I usually try to avoid such 
open-ended statement in standards documents. Can 
you describe the non-TA uses of interest, 
succinctly?

The format and use of such certificates are 
outside the scope of both X.509 and this 
specification.

I don't  think the format is an issue here, and 
this phrase might encourage folks not use the 
X.509/PKIX format, so I'd like to avoid that 
suggestion.

Note that these certificates cannot formally be 
called "self-signed" or "self-issued" because 
they do not follow the definition in the 
preceding paragraph.

This might be a good escape clause. I'll think about it some more.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Apr 2012 11:27:01 -0700

On Apr 5, 2012, at 11:08 AM, Stephen Kent wrote:

> "Certificates with a signing key that is the same as the key in the subjectPublicKeyInfo, but that do not include a BasicConstraints extension that asserts the cA boolean, are commonly used to convey public keys without an expectation that the contents of such certificates can be validated." I see several problems with the first sentence.  First, it's too long :-) Second, a signing  key is a private key and the key in the SPKI field is a public key, so they are not the same key. Third, the last phrase "without and expectation Š" is confusing to me.

The "too long" criticism might be fairer if you proposed shorter sentences that would still meet your requirements.

I can see your pedantic disagreement about the "signing key", but the fix for that would make the sentence longer.

"without an expectation" is indeed unclear.

Fixing the second and third issue: Certificates signed with a private key whose public key is the same as the key in the subjectPublicKeyInfo, but that do not include a BasicConstraints extension that asserts the cA boolean, are commonly used to convey public keys when the signing part does not have an expectation that the contents of such certificates can be validated.

> "These certificates are sometimes used for transmitting a PKIX trust anchor or the unvalidated public key of an end entity" Let's just refer to a trust anchor, not a "PKIX trust anchor." "unvalidated" may not be the best term here, it's "un-vouched for"  relative to a CA.  I'll try to think of a better term.

Fixed: "These certificates are sometimes used for transmitting a trust anchor or a end entity's public key that is not vouched for"

> "; other uses are certainly possible as well."
> 
> This statement seems rather vague., it that intentional?  I usually try to avoid such open-ended statement in standards documents. Can you describe the non-TA uses of interest, succinctly?

Good point. Let's nuke that.

> "The format and use of such certificates are outside the scope of both X.509 and this specification." I don't  think the format is an issue here, and this phrase might encourage folks not use the X.509/PKIX format, so I'd like to avoid that suggestion.

Fixed: "The use of such certificates are outside the scope of both X.509 and this specification"

> "Note that these certificates cannot formally be called "self-signed" or "self-issued" because they do not follow the definition in the preceding paragraph." This might be a good escape clause. I'll think about it some more.

Please do so. In looking at this and the text above, I realize I should be more specific that these definitions need to be made more specific for PKIX.

Current proposed wording:

Certificates signed with a private key whose public key is the same as the key in the subjectPublicKeyInfo, but that do not include a BasicConstraints extension that asserts the cA boolean, are commonly used to convey public keys when the signing part does not have an expectation that the contents of such certificates can be validated. These certificates are sometimes used for transmitting a trust anchor or a end entity's public key that is not vouched for. The use of such certificates are outside the scope of both X.509 and this specification. Note that these certificates cannot formally be called "self-signed PKIX certificates" or "self-issued PKIX certificates" because they do not follow the definition in the preceding paragraph.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Apr 2012 14:54:08 -0400

Paul,

Thanskfor the clarifications of intent, and the challenge to re-word 
the text to yield shorter sentences.

How about:

It is common practice to use the X.509/PKIX certificate format to 
transmit a trust anchor or the public key of an end-entity. These 
certificates are delivered via channels that are deemed  secure by 
the RPs that accept them.  Typically such certificates do not include 
a BasicConstraints extension that asserts the cA Boolean, i.e., they 
are not marked as CA certificates.  A certificate of this sort is 
validated using the public key from the subjectPublicKeyInfo field, 
i.e., no CA has signed the certificate.  These certificates cannot 
formally be called "self-signed certificates" or "self-issued 
certificates" because they do not follow the definition in the 
preceding paragraph. The use of such certificates is outside the 
scope of both X.509 and this specification, with regard to 
certificate path processing.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Apr 2012 12:11:15 -0700

On Apr 5, 2012, at 11:54 AM, Stephen Kent wrote:

> Paul,
> 
> Thanskfor the clarifications of intent, and the challenge to re-word the text to yield shorter sentences.
> 
> How about:
> 
> It is common practice to use the X.509/PKIX certificate format to transmit a trust anchor or the public key of an end-entity. These certificates are delivered via channels that are deemed  secure by the RPs that accept them.  Typically such certificates do not include a BasicConstraints extension that asserts the cA Boolean, i.e., they are not marked as CA certificates.  A certificate of this sort is validated using the public key from the subjectPublicKeyInfo field, i.e., no CA has signed the certificate.  These certificates cannot formally be called "self-signed certificates" or "self-issued certificates" because they do not follow the definition in the preceding paragraph. The use of such certificates is outside the scope of both X.509 and this specification, with regard to certificate path processing.

Excellent, and certainly much better than mine.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Apr 2012 15:13:01 -0400

>Paul,

It occurs to me that we might be able to make this even more concise 
and tighten the scope.  The current text says that these certs don 
contain a basic constraints extension with the CA flag set to true. 
Do they contain a basic constraints extension at all?

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 05 Apr 2012 15:15:42 -0400

On 04/05/2012 02:27 PM, Paul Hoffman wrote:

Paul,

I don't think adding "PKIX" in front of "self-signed" and
"self-issued" will help to clarify things given the definition in
X.509:

3.4.60 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.

3.4.61 self-signed certificate: A special case of
self-issued certificates where the private key used by the CA to
sign the certificate corresponds to the public key that is
certified within the certificate. A CA might use a self-signed
certificate, for example, to advertise their public key or other
information about their operations.

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

While the definition and the note seem contradictory, since the
definition implies that self-issued and self-signed certificates are
always issued by CAs, and the note implies otherwise, my guess is
that the reason is that the definitions define the terms as they
are used in X.509, whereas the note is mentioning a use of
such certificates that is outside the scope of the standard.

I think trying to avoid the use of the term "self-signed" when
referring to a certificate in which the public key that appears in
the subjectPublicKeyInfo field of the certificate can be used to
verify the signature on the certificate will just lead to
confusion.  Besides, this entire effort is based on Sean Turner's
statement that "this draft needs to also address the issue of
self-signed EE certificates."  Why avoid the use of the term
"self-signed" in addressing the issue of self-signed EE
certificates?

Also, the proposed text seems to say that all (what I'll call)
self-signed certificates "that do not include a BasicConstraints
extension that asserts the cA boolean" cannot formally be called
"self-signed PKIX certificates" and "are outside the scope of both
X.509 and this specification."  However, it also says that "[t]hese
certificates are sometimes used for transmitting a trust
anchor...."  Isn't the new paragraph supposed to discuss self-signed
certificates that are not intended to be used as a source of trust
anchor information, regardless their contents (e.g.,
BasicConstraints), rather than self-signed certificates that "that
do not include a BasicConstraints extension that asserts the cA
boolean," regardless of their intended use?

How about a very short paragraph, like this:

In some cases, a self-signed certificate is used to
convey a public key that is not intended to be used to begin
certification paths.  Such certificates are commonly referred to
as self-signed end-entity certificates.  The use of self-signed
end-entity certificates is outside the scope of this
specification.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 05 Apr 2012 15:34:39 -0400

On 04/05/2012 02:54 PM, Stephen Kent wrote:

Paul,

Thanskfor the clarifications of intent, and the challenge to
re-word the text to yield shorter sentences.

How about:

It is common
practice to use the X.509/PKIX certificate format to transmit
a trust
anchor or the public key of an end-entity. These certificates
are
delivered via channels that are deemed  secure by the RPs that
accept them.

Does "these certificates" mean all certificates used to transmit a
trust anchor and all end-entity certificates?

Typically such
certificates do not include a
BasicConstraints extension that asserts the cA Boolean, i.e.,
they are
not marked as CA certificates.

Doesn't this say that certificates used to transmit a trust anchor
typically "are not marked as CA certificates"?

A certificate
of this sort is
validated using the public key from the subjectPublicKeyInfo
field,
i.e., no CA has signed the certificate.

Is the "no CA has signed this certificate" statement true of
certificates used to transmit a trust anchor?  Also, where is there
text in the preceding sentences that constrains "a certificate of
this sort" to being being certificates "where the digital signature
may be verified by the public key bound into the certificate" (i.e.,
self-signed certificates)?

These
certificates
cannot formally be called "self-signed certificates" or
"self-issued certificates" because they do not follow the
definition in the preceding paragraph.

Even if it is used to transmit a trust anchor?  Also, I don't think
there is anything to be gained by trying to insist that certificates
"where the digital signature may be verified by the public key bound
into the certificate" cannot be called self-signed unless the issuer
is a CA.  X.509 specifically mentions "self-issued certificates and
self-signed certificates issued by other than CAs" (stating that
they are out of scope), and I don't think others will stop calling
them self-signed certificates just because this document says that
can't formally be called that.

The use of
such certificates is
outside the scope of both X.509 and this specification, with
regard to
certificate path processing.

Why the phrase "with regard to certificate path processing"?  Are
they within the scope of this specification with regard to something
else?

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 5 Apr 2012 15:46:43 -0400

I agree with David Cooper's objection that refusing to call such
certificates "self-signed" increases confusion, not clarity.  If they
cannot formally be called self-signed because they do not follow the
definition in the preceding paragraph(s), that is evidence that the
paragraphs should be generalized.  This would shorten the new text by
eliminating the explanation of the conflict, because there would be no
conflict requiring explanation.

The first instance of each "CA" in these paragraphs can be replaced by
"entity" or deleted without adversely affecting the intent of 5280.  The
second instance in each paragraph can remain as is, because those
sentences specifically refer to CA operations:

	3.4.60 self-issued certificate: A public-key certificate where
the issuer and the subject are the same entity. 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.
	
	3.4.61 self-signed certificate: A special case of self-issued
certificates where the private key used to sign the certificate
corresponds to the public key that is [certified<--contained] within the
certificate. A CA might use a self-signed certificate, for example, to
advertise their public key or other information about their operations.

Dave K

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Thursday, April 05, 2012 2:54 PM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [pkix] 5280 clarifications

Paul,

Thanskfor the clarifications of intent, and the challenge to re-word the
text to yield shorter sentences.

How about:

It is common practice to use the X.509/PKIX certificate format to
transmit a trust anchor or the public key of an end-entity. These
certificates are delivered via channels that are deemed  secure by the
RPs that accept them.  Typically such certificates do not include a
BasicConstraints extension that asserts the cA Boolean, i.e., they are
not marked as CA certificates.  A certificate of this sort is validated
using the public key from the subjectPublicKeyInfo field, i.e., no CA
has signed the certificate.  These certificates cannot formally be
called "self-signed certificates" or "self-issued certificates" because
they do not follow the definition in the preceding paragraph. The use of
such certificates is outside the scope of both X.509 and this
specification, with regard to certificate path processing.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Apr 2012 12:50:07 -0700

> Do they contain a basic constraints extension at all?

Good call: no.

--Paul Hoffman

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 05 Apr 2012 15:56:02 -0400

David,

The text that you are proposing to edit is from the definitions section 
of X.509.

The text in RFC 5280 is:

    This specification covers two classes of certificates: CA
    certificates and end entity certificates.  CA certificates may be
    further divided into three classes: cross-certificates, self-issued
    certificates, and self-signed certificates.  Cross-certificates are
    CA certificates in which the issuer and subject are different
    entities.  Cross-certificates describe a trust relationship between
    the two CAs.  Self-issued certificates are CA certificates in which
    the issuer and subject are the same entity.  Self-issued certificates
    are generated to support changes in policy or operations.  Self-
    signed certificates are self-issued certificates where the digital
    signature may be verified by the public key bound into the
    certificate.  Self-signed certificates are used to convey a public
    key for use to begin certification paths.  End entity certificates
    are issued to subjects that are not authorized to issue certificates.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Apr 2012 12:57:01 -0700

> conflict requiring explanation.

Fully disagree. While it is clear to me that both X.509 and PKIX totally muffed the definition of "self-signed" by also requiring the cA bit, we have to life with that (and similar muffage).

This thread started off with Steve "Dr. Pedantic" Kent bringing up the issue of the self-signed definition in the DANE WG. It came as a shock to some of us who had worked with PKIX for over a decade that the definition of self-signed disagreed with the common notion, but he was indeed correct based on multiple revs of this RFC. Now saying "we now create two definitions for 'self-signed'" seems to be more likely to create, not reduce, confusion.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Apr 2012 15:33:33 -0400

At 12:11 PM -0700 4/5/12, Paul Hoffman wrote:
>>the RPs that accept them.  Typically such certificates do not 
>>include a BasicConstraints extension that asserts the cA Boolean, 
>>i.e., they are not marked as CA certificates.  A certificate of 
>>this sort is validated using the public key from the 
>>subjectPublicKeyInfo field, i.e., no CA has signed the certificate. 
>>These certificates cannot formally be called "self-signed 
>>certificates" or "self-issued certificates" because they do not 
>>follow the definition in the preceding paragraph. The use of such 
>>certificates is outside the scope of both X.509 and this 

It was a team effort!

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 05 Apr 2012 17:29:03 -0400

Paul,

X.509 says:

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

So, I don't see how you can use X.509 as a basis for arguing that the 
term "self-signed" cannot be used.

As for PKIX, if the final paragraph of Section 3.2 of RFC 5280 implies 
that only a CA can issue a "self-signed certificate" and yet the update 
to 5280 is going to discuss certificates that are not issued by CAs 
"where the digital signature may be verified by the public key bound 
into the certificate" then let's reword the current text rather than 
trying to insist that some certificates "where the digital signature may 
be verified by the public key bound into the certificate" are not 
"self-signed."

Dave

On 04/05/2012 03:57 PM, Paul Hoffman wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Apr 2012 23:39:03 +0200 (MEST)

> Do they contain a basic constraints extension at all?

Unfortunately, this differs from the "existing practise" in the
installed base, where the majority of self-signed TLS server certs
in use carries the "Basic Constraints:cA=TRUE" attribute.

This is probably due to the popularity of Apache+OpenSSL.
IIRC only the self-signed proto-certs created by Sun JDK-1.5+ 
carry a Basic Constraints:cA=FALSE attribute.

Data pulled from the August 2010 EFF SSL Observatory dataset
about publicly accessible TLS serves on the Internet:

https://www.ietf.org/mail-archive/web/dane/current/msg02348.html

Peter additionally mailed this (but it was not copied to the list):

=
= s/acerts/all_certs (I have a copy of the db with the older acerts name
= that I was querying, and forgot to edit the query to not confuse people).
=
= select count(*) from all_certs
= where subject=issuer
=   and LOCATE("TRUE",`X509v3 extensions:X509v3 Basic Constraints:CA`);
= +----------+
= | count(*) |
= +----------+
= |   830796 |
= +----------+
= 
= This is just the number of self-signed CA certs; there are more servers than
= that because certs are duplicated.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Apr 2012 14:52:44 -0700

On Apr 5, 2012, at 2:29 PM, David A. Cooper wrote:

> So, I don't see how you can use X.509 as a basis for arguing that the term "self-signed" cannot be used.

I'm completely confused by that. The quoted text says "self-signed certificates issues by other than CAs". That's exactly what we are talking about.

> As for PKIX, if the final paragraph of Section 3.2 of RFC 5280 implies that only a CA can issue a "self-signed certificate" and yet the update to 5280 is going to discuss certificates that are not issued by CAs "where the digital signature may be verified by the public key bound into the certificate" then let's reword the current text rather than trying to insist that some certificates "where the digital signature may be verified by the public key bound into the certificate" are not "self-signed."

I hear that's what you want; I still think it is a bad idea to make PKIX more confusing than it is now.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 20:57:55 -0400

>in use carries the "Basic Constraints:cA=TRUE" attribute.

a self-signed CA cert is already acceptable under X.509 and 280, and 
thus is not
the subject of this text.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 10 Apr 2012 08:38:59 -0400

If that is not the subject of this text then what is?  I thought the 
subject of the text was self-signed certificates that are used to convey 
public keys that are not intended to be used to begin certification paths.

On 11/13/2011 09:36 PM, Sean Turner wrote:
> Tim,
>
> You're right there's no such thing as an EE self-signed cert according
> to RFC 5280.  The point is for RFC 5280 to be updated to say that there
> are such things as EE self-signed certs, which reflects reality (e.g.,
> dane).
>
> spt
>
> On 11/14/11 9:55 AM, Miller, Timothy J. wrote:
>> Um, maybe I missed something but there's no such thing as an end-entity
>> self-signed certificate.  Since constraints can't be enforced every
>> self-signed cert is potentially a CA, and should be treated as such.
>>
>> -- T
>>
>> On 11/13/11 7:18 PM, "Sean Turner"<[email-masked]>   wrote:
>>
>>> So maybe I'm being simple minded but this is pretty much what I was
>>> asking for.
>>>
>>> spt
>>>
>>> On 9/28/11 12:16 AM, Kemp, David P. wrote:
>>>> Change 1 - on page 12 replace:
>>>>      "X.509 v3 also includes an extension that identifies the subject of a
>>>>       certificate as being either a CA or an end entity, reducing the
>>>>       reliance on out-of-band information demanded in PEM.
>>>>
>>>> with:
>>>>       X.509 v3 also includes two extensions that identify ...
>>>>
>>>>
>>>> Change 2 - on page 12-13 replace:
>>>>      "This specification covers two classes of certificates: CA
>>>>       are issued to subjects that are not authorized to issue certificates."
>>>>
>>>> with:
>>>>
>>>>      "This specification covers two classes of certificates: CA
>>>>       certificates and end entity certificates.  CA and EE certificates may be
>>>>       further divided into three classes: CA-issued certificates, self-issued
>>>>       the two CAs.  Self-issued certificates are certificates in which
>>>>       certificate.  Self-signed CA certificates are used to convey a public
>>>>       Self-signed end entity certificates are used to convey a public key
>>>>       and other information directly to relying parties without using
>>>>       a PKI."
>>>>
>>>>
>>>>
>>>>
>>>> Paul Hoffman
>>>> Sent: Tuesday, September 27, 2011 9:55 AM
>>>> To: PKIX
>>>> Subject: [pkix] End-entity self-signed certs (was: Re: AD Review
>>>> ofdraft-ietf-pkix-rfc5280-clarifications-03.txt)
>>>>
>>>>> On Aug 22, 2011, at 5:52 AM, Sean Turner wrote:
>>>>>
>>>>>> I think the -03 version is just about ready to go.  That is I have no
>>>> comments on the existing text though I expect getting it through the
>>>> IESG will be interesting (Apps ADs love to discuss about anything to do
>>>> with characters strings/sets).  But, I think this draft needs to also
>>>> address the issue of self-signed EE certificates.  I know at least the
>>>> DANE WG had a lengthy discussion about self-signed EE certificates, I
>>>> see that Max's EST draft also includes them, and they're used in the
>>>> wild.  I want to see text included that addresses them.
>>>> This thread started there, but then sidetracked on more "improvements"
>>>> on trust anchors that are express as certificates. Could we please have
>>>> two threads?
>>>>
>>>> --Paul Hoffman
>>>>
>>>>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Apr 2012 08:22:16 -0700

>>>>> On Thu, 5 Apr 2012 12:57:01 -0700, Paul Hoffman <[email-masked]> said:

PH> Fully disagree. While it is clear to me that both X.509 and PKIX
PH> totally muffed the definition of "self-signed" by also requiring the
PH> cA bit, we have to life with that (and similar muffage).

If the term is "muffed" then replace it.  You're unlikely to fix it.  In
particular, the majority of the under-educated geeks in the world that
are throwing the "self-signed" term around use it in one context in
their head: "A certificate with a public key and the whole ball of wax
was signed by the corresponding private key".  90% of the people using
the term have *no* notion that a cA component even exists.

So...  if you're going to try and "clarify what self-signed actually
means" then you'll only succeed in re-educating the original 10% that
already understood it.  The other 90%, that never read the RFC and
probably learned everything through word of mouth or badly-assumed
context, will not be corrected and the term will continue to be misused.

How about use a new term instead, if it needs to be discussed in 5280bis
(which it certainly does).  Let self-signed be the parent term and have
a (new) special-case term for the other special-case sub-categories you
wish to define.

[Others have already hinted at doing something close to this, so I'm
just generically expressing my opinion about the fact that we can't fix
the world's terminology usage at this point.  It's *way* too in-use to
recall the bad usage at this point.]
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Apr 2012 22:17:25 +0200 (MEST)

Stephen Kent wrote:
>Martin Rex wrote:
>thus is not the subject of this text.

We're talking past each other.

The text we're discussing is _exactly_ about self-signed EE certs used by
communication peers, what they should look like and how they should be
processed _in_the_future_.

Since X.509 and PKIX were previously silent about this mode of operation,
you will find all possible solutions in the installed base: X.509v1,
X.509v3 non-CA and X.509v3 CA certs, and the probability for each solution
is related to default behaviour/default configuration of the software
that was used to create these certs.

With X.509v1, CA and non-CA certs can only be distinguished by meta-knowledge.

Self-signed X.509v3 certs used by communication peers of the currently
installed base can also only be distinguished by meta-knowledge,
because the attributes in the certificates that distinguish CA from non-CA
uses very often do not reflect conscious intent of the admin / cert creator,
but rather an implementation decision of the software creator or software
distributor trying to obtain wire-level interop.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Apr 2012 21:03:21 -0400

>...

self-signed certs that contain the basic constraint extension and are marked
as CA certs are not what prompted this discussion.  Hence my comment that they
are not the focus of the next text.

>.

v1 certs were superceded by v3 certs, so v1 certs are definitely not relevant
to this discussion.

Steve