Subject: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.)

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Apr 2011 13:04:55 +0100

Sorry to drag this out but I think its worth being clear as to
where the possible disagreement lies since that might influence
how dane approaches handling TLS servers with these kind of
self-signed data structures.

On 15/04/11 18:00, Stephen Kent wrote:
> 5280 is not silent on this topic.  

This is where one of the pkix chairs and one of the authors
of 5280 (me:-) disagree. "This topic" is whether or not
self-signed x.509 structures that are not for CAs are
"covered" by 5280. I believe Steve is saying that 5280 says
that such things are not allowed, whereas I believe that
5280 says nothing about them. I guess we both believe our
interpretation is the right one:-)

> It says that a certificate is either
> and EE certificate of a CA certificate, and that CA certificates are of
> 3 types, one of which is self-signed. This is pretty clearly a partition
> of X.509 certificates in to EE and CA, and a further delineation of
> types of CA certificates. there is no ambiguity here, nor did I
> "misread" the RFC.  

Disagree. Quoting (end of p12):

   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.

That says that some CA certs are self-signed. It does not say that
all self-signed certs are CA certs. It does not partition EE certs
into any classes at all.

A little further down it says that:

   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.

I recall this being added as a result of some confusion as to what
a self-issued vs. self-signed cert might be. I do not recall it being
added as anything normative (indeed there is no 2119 language there).
In any case, in context, it clearly is only referring to CA certs
since those are the only kind for which different (informative)
classes are called out.

And finally:

   End entity certificates
   are issued to subjects that are not authorized to issue certificates.

So I think in 5280 terms its probably fair to say that the term
"self-signed end entity cert" is a bit of a misnomer. However, that
is at this stage a fairly well understood term so I'm not sure if
we'll benefit from trying to get folks to use a different term.

> I am aware of no text in 5280 or in X.509 that
> suggests a self-signed certificate is anything other than a CA certificate.

That's consistent with either interpretation.

So I also took a look at the pkix list archives, and found only one
relevant thread from 2004 that unfortunately doesn't really help. [1]

   [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html

I also found some offlist mail from the design team that we had to
develop 3280bis (which became 5280). It just says:

   "Harmonize language in path validation. Some places used the defined
    term “self-issued” certificate while some places states the
    requirement that subject and issuer names are identical. These
    definitions differ since the term “self-issued” also requires that
    names must be non-empty." (That was issue#65 in a spreadsheet
    Dave Cooper constructed collecting issues for 3280bis dated
    Jan 14 2005, not sure if there's a public archive for that
    [email-masked] list or not.)

So again that doesn't help us here. I didn't find any other mails
with "self" in the subject line from my copy of the 3280bis design
team mails.

My conclusion is that neither 5280 nor the pkix archives justify
any conclusion about self-signed end-entity certs.

I guess if more consideration of this is needed, we should move
the discussion to pkix alone, until there's a conclusion that dane
can use. (So if following up on just the pkix aspect, removing
dane from the cc list is probably the right thing to do.)

To the extent it helps, the W3C web security context WG did also
consider this topic, and included text in their recommendation about
self-signed certs. [2] I think that clearly shows that that group
did envisage the use of this kind of thing for some web servers.
(I was involved in that group as an invited expert, but I don't
recall this particular aspect being in any way controversial there.
There was debate about what to do with such things, but not about
the terminology that I recall.)

   [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts

Stephen.

PS: Note that Steve's on vacation so this might just sit for a
few weeks until he's back to argue his side of the issue.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 18 Apr 2011 23:28:53 +0200

Stephen,

So let me land somewhere in-between.

I understand what you mean by self-signed end-entity certs, but the term
is misleading.

A self signed cert is simply a convenient way to communicate a public key
for an entity that has not been certified by a CA.
I would say that it is a self signed cert. Period. Disregarding what type
of entity it represents.

The internet is full of them. Denying their valid existence does not help
anyone.
As far as RFC 5280 goes, it only deals with these certificates when used
as trust anchors in path validation.

When self-signed certificates are found in e.g. Signed metadata of an
identity federation, that federation may have its own conventions
regarding their use. They are not subject to 5280 path validation so all
of that is out of scope.

/Stefan

On 11-04-18 2:04 PM, "Stephen Farrell" <[email-masked]> wrote:

>    term ³self-issued² certificate while some places states the
>    definitions differ since the term ³self-issued² also requires that
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Apr 2011 18:00:13 -0400

I agree that Kent is right on what the spec says.

But the standard is set by the consensus and the running code which
recognize self-signed certs..

I see the following courses of action as being open:

D1) DANE says nothing at all about this issue in the DANE spec (I see no
reason it need be mentioned at all).

D2) DANE says that the EE cert can be a self signed EE cert in accordance
with customary Internet usage

P1) PKIX writes draft on how to specify self signed EE certs so that this is
properly understood. I.E. relying applications MUST NOT rely on any claims
other than the POP of the key and any restrictions on validity/usage.

P2) PKIX ignores the issue.

Note that D1/2 and P1/2 are orthogonal.

These certs exist and I can't see there being a consensus likely to emerge
to require a chain with a CA cert at the head. Nor can I see a requirement
to introduce a downref to X.509v1 to try to circumvent this.

On Mon, Apr 18, 2011 at 5:28 PM, Stefan Santesson <[email-masked]>wrote:

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

-- 
Website: http://hallambaker.com/

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Apr 2011 00:49:28 +0200 (MEST)

Phillip Hallam-Baker wrote:
> to require a chain with a CA cert at the head.

I have very little experience with / exposure to the discussions
in the PKIX WG, so I don't know how much I like (P1).

>From the data collected by EFF, there appear to be

  ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet
           with the BasicConstraint cA=TRUE
  ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet

  ~  56000 self-signed X.509v3 Web Server certs installed on the internet
           without the BasicConstraint cA=TRUE

There may be a much higher number of use case for self-signed certs
on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
probably irrelevant for DANE because most are on private IP-Addresses and
don't use officially registered DNS domains on their internal networks.

>
> Nor can I see a requirement

I do not see the particular gripe that you have with X.509v1.

X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.

The beauty of X.509v1 certs is that they're *MUCH* easier to create
and hard to get wrong in an interop-impairing fashion.

And, the biggest advantage: enforcing a rule "do not accept as signers
of other certs" is trivial and fool-proof to implement, so that you
don't create immediate and serious problems when you add such
certs to the list of trusted keys for your PKI software along
with Trust Anchors from commercial CAs.

When you mix up self-signed CA certs from some web-servers into the
list of trusted keys next to rootCAs from commercial CAs, then
you may put yourself at risk today.

But what are you real options today, with programmatic clients?
Either disable the peer certificate check entirely, or add some
peers self-signed certs to the same file as the self-signed certs
of the commercial rootCAs.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 19 Apr 2011 09:45:37 +0200

Martin,

For self signed certs in general I think X.509 v1 certs are just fine.

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 19 Apr 2011 09:18:48 -0400

There's nothing wrong with self-signed X.509 v1 certs except the "X.509"
part and the "certificate" part.

Self-signed keys have nice properties other than proof of possession -
they allow an entity to "stake a claim" on a
cryptographically-guaranteed-unused identity and support
continuity-based (or reputation-based) trust in that identity, in
addition to standard out-of-band mechanisms.  If wishes were horses ...
everyone would use a PKIX-standard signed key assertion that was NOT a
syntactically-valid X.509 certificate.  I don't see how using X.509v1
instead of x.509v3 for self-signed end-entity keys prevents applications
from misusing them as CA certs.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, April 19, 2011 3:46 AM
To: [email-masked]; Phillip Hallam-Baker
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:

Martin,

/Stefan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Apr 2011 10:40:07 -0400

There is no problem with using X.509v1 certs.

But there is a very big problem with trying to make a normative reference in
a new standards proposal to a standard that has been deprecated (ITU) or
made HISTORIC (IETF).

Given the vast number of v1 certs in circulation plus the very long
lifetimes on many of them, I can't see a problem with requiring relying
applications to process v1 certs. The use case here would be to support a
device that shipped with a built in v1 device cert without having to rekey
the device.

But I can see a very big problem with attempting to get round the PKIX
lawyering with a requirement that cannot be supported in a reasonable manner
using the current standards.

I really don't see this as a DANE issue. I see it as a requirement to
clarify the PKIX spec as follows:

* CA signing key usage MUST be set for keys used to sign certificates for
any key OTHER THAN THEMSELVES.

* EE certs may be CA signed or self-signed.

* Security considerations for using self-signed certs (probably two pages
worth at least). Specifically, no positive claims can be relied on other
than POP for the key, all use restrictions and validity conditions MUST be
observed.

Since this is currently the largest class of server certificate deployed by
number of certs it would be ostrich-like behavior to ignore them. I can't
see programmers deciding that they want to have applications that generate
self-signed certs create a chain of two certs for no other purpose than to
comply with the spec.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Apr 2011 15:51:30 +0100

So can we take the discussion over to pkix then and have this be
the last message on this topic to dane until pkix has come to some
conclusion?

So *please* remove dane from followups.

S.

On 19/04/11 15:40, Phillip Hallam-Baker wrote:
> But there is a very big problem with trying to make a normative
> reference in a new standards proposal to a standard that has been
> deprecated (ITU) or made HISTORIC (IETF).
> 
> 
> applications to process v1 certs. The use case here would be to support
> a device that shipped with a built in v1 device cert without having to
> rekey the device. 
> 
> lawyering with a requirement that cannot be supported in a reasonable
> manner using the current standards. 
> 
> 
> * CA signing key usage MUST be set for keys used to sign certificates
> for any key OTHER THAN THEMSELVES.
> 
> * Security considerations for using self-signed certs (probably two
> pages worth at least). Specifically, no positive claims can be relied on
> other than POP for the key, all use restrictions and validity conditions
> MUST be observed.
> 
> 
> Since this is currently the largest class of server certificate deployed
> by number of certs it would be ostrich-like behavior to ignore them. I
> can't see programmers deciding that they want to have applications that
> generate self-signed certs create a chain of two certs for no other
> purpose than to comply with the spec.
> 
> 
> 
> 
> 
> On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of
>     Stefan Santesson
>     To: [email-masked] <mailto:[email-masked]>; Phillip Hallam-Baker
>     Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     On 11-04-19 12:49 AM, "Martin Rex" <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     >[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 20 Apr 2011 03:01:19 +1200

Stephen Farrell <[email-masked]> writes:

>So can we take the discussion over to pkix then and have this be the last
>message on this topic to dane until pkix has come to some conclusion?

What if they never come to a conclusion (which is not unusual whenever a tough
topic comes up)?  We should probably set a timer to expire after which
(shudder) things start up here again.

(Sorry, still sent to DANE since it's relevant here.  "Kick it over to PKIX"
presupposes that it'll converge on a solution at some point).

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 19 Apr 2011 14:22:53 -0400

[dane omitted]

From: Stefan Santesson

> A self signed cert is simply a convenient way to communicate
> a public key for an entity that has not been certified by a CA.
> I would say that it is a self signed cert. Period. Disregarding
> what type of entity it represents.

+1.  It is also syntactically a "certificate" but semantically not a
certification, regardless of what type of entity it represents.

From: Stephen Farrell

> My conclusion is that neither 5280 nor the pkix archives
> justify any conclusion about self-signed end-entity certs.

+1.  PKIX describes three types of CA certificates, one of which is an
assertion by an entity about itself, not a certification by some other
authority.  Saying "some CA certificates are self-signed" is not a
prohibition against "some non-CA certificates" also being self-signed,
it is silence.

From: Phillip Hallam-Baker

> I really don't see this as a DANE issue. I see it as
> a requirement to clarify the PKIX spec as follows:
>
> * CA signing key usage MUST be set for keys used to sign
> certificates for any key OTHER THAN THEMSELVES.
>

RFC 5280 Section 4.2.1.3 Key Usage says:

       Conforming CAs MUST include this extension
       in certificates that contain public keys that are used
       to validate digital signatures on other public key
       certificates or CRLs.

So the first bullet is unnecessary, PKIX is already perfectly clear.

> And, the biggest advantage [of X.509v1]: enforcing a rule
> "do not accept as signers

Section 6.1.4 of Basic Validation says:

      (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.)

So that is not an advantage of v1 vs. v3.  If a cert does not include a
basic constraints extension, it is already "trivial and foolproof" to
implement the rule that it is not a CA cert, yet apparently some
application developers have managed to botch it.  How likely is it that
the version field would be a "more foolproof" indicator of non-CA-ness
than basic constraints?

>  ~ 830000 self-signed X.509v3 Web Server Certs installed
>    on the internet with the BasicConstraint cA=TRUE
>  ~  56000 self-signed X.509v3 Web Server certs installed
>    on the internet without the BasicConstraint cA=TRUE

What impact can PKIX have, with or without additional guidance, on the
issuers of these certs?  5280 may be complex, but the part about EE
certs not being CA certs seems clear enough.  Yet the number of CA certs
issued by EEs to themselves dwarfs the number of v1 certs and EE certs
combined.

I prefer Stefan's clarification - self-signed certs have properties X, Y
and Z regardless of type of entity named in the subject field.  But I
have no illusions about the likelihood of any such clarification being
"foolproof".

Dave

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Apr 2011 11:42:46 -0700

> certification, regardless of what type of entity it represents.

Excellent distinction!

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Apr 2011 19:47:44 +0100

>> certification, regardless of what type of entity it represents.

Yeah that nails it nicely,
S

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Apr 2011 22:00:58 +0200 (MEST)

> certification, regardless of what type of entity it represents.
 
+1, nicely put.

> prohibition against "some non-CA certificates" also being self-signed,

+1

> So the first bullet is unnecessary, PKIX is already perfectly clear.

There is another "Conforming CAs MUST include" about the
BasisConstraints extensions for CA certificates in rfc5280.

>            choose to reject all version 1 and version 2 intermediate

seems to distinguish the requirements for a "conforming CA" significantly
from the requirements for a "conforming PKI implementation", in that
it allows (but not require) PKI implementation to process X.509v1
intermediate CA certs.

The rfc5280 requirements for "conforming PKI implementations" are overly
soft "may reject version 1 and version 2 intermediate certificate".
Personally, I would prefer a "MUST reject all version 1 intermediate
certificates" (I can not comment on version 2).

And on top of that, I would appreciate something like this:

"Conforming implementations may choose to reject "TAs", that are distributed
 as self-signed version 1 certificates, as signers of other certificates."

If you currently want to furnish a programmatic https client
(like wget/curl linked to openssl) with a list of trusted keys for
downloading data from TLS servers, you can not provide a list of
self-signed server certs seperately from a list of commercial rootCA
certs.

Dealing with self-signed CA certs of some servers is significantly harder,
because they're indistinguishable from organizational CAs -- and limiting
what certs organizational CAs may issue is also often not possible with
the existing TLS clients and existing convenience APIs provided by
TLS toolkits.

DANE might, at some point in the future, provide a useful limitation
for the validity of self-signed X.509v3 CA certificates installed
on many web servers out there.  But it wouldn't hurt to provide
additional options for existing software and for environments
where DANE will not apply (many private&home networks)
with a reduced risk by using X.509v1 certs and disabling
X.509v1 cert usage in certificate path validations, i.e. as
signers of other certs.

> the version field would be a "more foolproof" indicator of non-CA-ness

What I meant: disabling X.509v1 certs as valid CA certs _entirely_
within the PKI software should be trivial and foolproof while not
breaking any existing reasonable PKI.

Dealing sensibly with the large number of self-signed X.509v3 CA certs
installed on Web-Servers is much more difficult.  DANE is one possible
future solution, Browsers that allow pinning of server certs (while
limiting that certs validity to a single hostname), may be an existing
workable solution.

But for a number of _existing_ programmatic TLS clients, a workable solution
for X.509v1 self-signed server certs might be much easier than for
X.509v3 self-signed server certs with BasicConstraints cA=TRUE.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Apr 2011 21:26:06 -0400

It PKIX never comes to a conclusion that what DANE is doing is bad, then
DANE need take no action.

[DANE dropped from followups as per direction of AD]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Apr 2011 17:30:17 -0400

That works for me too.

[But to be strictly precise, I never said that the existing spec was
unclear, I merely stated that it was necessary to clarify it. I don't think
we need elaborate on that distinction.]

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 22 Apr 2011 23:11:48 +1200

"Kemp, David P." <[email-masked]> writes:

>It is also syntactically a "certificate" but semantically not a

We could really get into some semantic nitpicking here :-), but I'd say that a 
self-signed cert is an assertion if not necessarily a certification.  Mind you 
what many commercial CAs do is just an assertion as well, so in neither case 
could you really call them certifications.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 22 Apr 2011 07:46:39 -0400

> could you really call them certifications.

Yeah, but unlike a self-asserter commercial CAs can be held liable (within unclear and probably variable limits).  That's probably as good as we're going to get, so I'm good with calling them certifications.  :)

-- T

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 23 Apr 2011 00:21:31 +1200

"Miller, Timothy J." <[email-masked]> writes:

>Yeah, but unlike a self-asserter commercial CAs can be held liable (within
>unclear and probably variable limits).

Hmm, you haven't been following the discussion on the Mozilla policy list have
you?  Effectively once a commercial CA has issued enough certs to become Too
Big To Fail, it's absolved of any liability (that's a very, very cut-down
summary of an interminable discussion, see the thread "Response from Comodo"
for the full thing).

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 22 Apr 2011 09:20:28 -0400

So how is that different from my MSEE from Princeton University*?  I'm
sure they would refuse any and all liability, yet most people would
consider that piece of sheepskin more authoritative than an MS degree I
awarded to myself.

Dave

* I didn't go to Princeton, but I do have a MSEE from an institution of
similar reputation.  See me over a beer if you care which one.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Gutmann
Sent: Friday, April 22, 2011 8:22 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane]
[keyassure] Use cases document.)

>unclear and probably variable limits).

Hmm, you haven't been following the discussion on the Mozilla policy
list have
you?  Effectively once a commercial CA has issued enough certs to become
Too
Big To Fail, it's absolved of any liability (that's a very, very
cut-down
summary of an interminable discussion, see the thread "Response from
Comodo"
for the full thing).

Peter.

---

From: Kyle Hamilton <[email-masked]>
Date: Fri, 22 Apr 2011 23:15:06 -0700

A self-signed certificate structure has the semantic meaning of "I am
that which can be identified with this public key, and the
self-signature proves both that the private key to this public key
exists and that its holder approved this statement."

What everyone forgets is that X.509 is a means of carrying a chain of
semantic authority through signatures provably chained from how that
authority is identified (the authority's public key).

Why must the signature structure in the outermost wrapper of the
TBSCertificate be the only place where those signatures can be
asserted?

-Kyle H

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Apr 2011 02:09:43 +0200

This might be true, but unnecessarily complex and potentially confusing.

I'd say that a self signed certificate is:

"Information associated with a public key, asserted by the holder of the
corresponding private key."

And that is all it is.

/Stefan

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 25 Apr 2011 20:51:51 -0400

> corresponding private key."

I would say a self-signed certificate is even less conclusive:
s/the holder/a holder/

The belief that the corresponding private key is controlled by a single 
"holder" can not come from the self-signed certificate.

Every single element of trust must be established by non-crypto means. 
Thereafter, crypto merely transposes trust from a context to the next.

Regards,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: Eric Norman <[email-masked]>
Date: Tue, 26 Apr 2011 08:09:32 -0500

On Apr 25, 2011, at 7:51 PM, Thierry Moreau wrote:

> The belief that the corresponding private key is controlled by a single "holder" can not come from the self-signed certificate.

But proof of possession will come from usage.  I.e. the purported owner won't be
able to sign or decrypt without the private key.

EJN

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 26 Apr 2011 09:34:28 -0400

Actually, the belief that the corresponding private key is controlled by a *single* holder doesn't come from any cert.  It comes from the issuance policy and the technology used to enforce it.  All the cert does is tell you which sections of which CP & CPS to go read.  :)

-- T

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 26 Apr 2011 11:36:39 -0400

> able to sign or decrypt without the private key.

Granted, but that just partially counters the threat spectrum:

1) The bogus self-signed certificate may be stored alongside legitimate 
ones,

2) Bogus self-signed certificates may be used in a proxy 
(man-in-the-middle).

3) The bogus self-signed certificate may be required for a short period 
of time by the adversary.

This is why self-signed certificates should not be used as an assertion 
by the purported owner without other basis for trust.

- Thierry Moreau

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 26 Apr 2011 11:37:01 -0400

> Actually, the belief that the corresponding private key is controlled by a *single* holder doesn't come from any cert.  It comes from the issuance policy and the technology used to enforce it.  All…

The "technology used to enforce [self-signed certificate]" is a bit of a 
misnomer (aren't we in a discussion about semantics?). I question the 
word "enforce".

A relying party has a local policy to trust (or not) such and such 
certificates. In practice, this policy seems embedded in a software 
installation package. Relying parties are not subject to non-compliance 
enforcement. They just bear higher risk (if too accommodating) or 
operational hindrance (if too strict) in face of very difficult trust 
assessment.

Furthermore, the "issuance policy" appears as an ineffective as the rest 
of the self-signed certificate for detecting a bogus one.

- Thierry Moreau

> ------------------------------------------------------------------------
>

---

From: Eric Norman <[email-masked]>
Date: Tue, 26 Apr 2011 20:21:18 -0500

To get back to what seems to be the original question, I think the text of the appropriate
RFCs should make it clear that:

A valid path can have a length as small as 1 if the public key from the end-entity
certificate is used to establish a trust anchor in the relying party's software.

Note that this requirement applies whether the end-entity certificate is self-signed
or not.

EJN