Subject: [pkix] Self-issued certificates

From: Peter Bowen <[email-masked]>
Date: Sun, 12 Jul 2015 15:02:53 -0700

I'm trying to make sense of the definition of "self-issued
certificates" in RFC 5280 (and X.509)

Section 3.2 provides a definition: "Self-issued certificates are CA
certificates in which the issuer and subject are the same entity."
However section 6.1 says "A certificate is self-issued if the same DN
appears in the subject and issuer fields."

While it is clear that all certificates with the same DN for subject
and issue are self-issued, it is unclear to me whether a certificate
with different DNs could be self-issued.  Section 6.1 could be giving
one example of how a certificate could be self-issued or section 6.1
could be a limiting definition.

Consider the following example:
Example Trust Services has two different private keys.  Each key has a
single associated DN:
Key0 has DN O=Example Trust Services, OU=Global Trust Anchor
Key1 has DN O=Example Trust Services, OU=Commercial Trust Anchor

There is a CA certificate created with
Subject: O=Example Trust Services, OU=Commercial Trust Anchor
Subject Public Key: Key1
Issuer: O=Example Trust Services, OU=Global Trust Anchor
Signed by Key0

Is this CA certificate considered a self-issued certificate?

Thanks,
Peter

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 13 Jul 2015 03:52:16 +0200

Bonsoir Peter,

This isn't a self-issued certificate in X.509/RFC5280. It's a subordinate
CA. Section 6.1 clearly defines how one knows if issuer and subject are the
same entity.

Entities in X.509 are purely technical; your company named "Example Trust
Services" doesn't exist in this standard. If it existed, there should be a
way to express if it's the same entity when it's located in the US or in MY
(think about Digicert's certificates).

You're "free" to change the rule behind section 6.1 to match your idea of
what an entity is, for your own set of applications, but it will be
incompatible with the rest of the world. This has been done with electronic
passports (BAC), where an entity is defined by the countryCode alone when
validating CRLs, and the complete DN when validating a certificate chain.

-- 
Erwann.

---

From: Brian Smith <[email-masked]>
Date: Sun, 12 Jul 2015 21:57:11 -0400

> Is this CA certificate considered a self-issued certificate?

No, because the issuer and subject fields are not equal.

For further justification,, it helps to look at what "self-issued" is used
for in RFC 5280: exceptions for the normal path length constraints, policy
constraints, name constraints rules, and (IIRC) nothing else. There's
nothing to indicate that such exceptions would warranted for that
certificate.

In fact, mozilla::pkix doesn't recognize self-issued certificates at all,
and so doesn't implement those exceptions. So far, this has not caused any
problems, so as far as the Web PKI is concerned, it is likely we can forget
about the concept of self-issued certificate completely. And, that's what I
recommend that people do.

Cheers,
Brian

---

From: Peter Bowen <[email-masked]>
Date: Sun, 12 Jul 2015 21:46:09 -0700

> (think about Digicert's certificates).

Merci Erwann.  Taking this one step further, X.509 has the following
definitions:

authority: An entity, responsible for the issuance of certificates.
Two types are defined in this
[document]; a certification authority which issues public-key
certificates and an attribute
authority which issues attribute certificates

certification authority (CA): An authority trusted by one or more
users to create and assign public-key
certificates.

Do I take it correctly that a single business entity (e.g. société
anonyme or SARL) may operate multiple certificate authorities and that
the term "entity" in the above definition does not refer to the
business entity rather the existence of each CA as being independent,
separate, and self-contained?

Thanks,
Peter

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 13 Jul 2015 09:30:23 +0200

Hi Peter,

It is only RFC 5280 that is unclear. X.509 is quite clear. The X.509
definition is:

3.5.62	self-issued certificate: A CA 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.

The problem you are facing is that the term entity is not clearly defined.
Is a CA an entity or is CA is specific role for an entity among other roles
for the same entity?

The RFC 5280 definition seems to assume that a CA is an entity, and the two
CA you mention are different entities, while X.509 does not necessarily make
that assumption.

Kind regards,

Erik Andersen

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Peter Bowen
Sendt: 13 July 2015 00:03
Til: [email-masked]
Emne: [pkix] Self-issued certificates

I'm trying to make sense of the definition of "self-issued certificates" in
RFC 5280 (and X.509)

While it is clear that all certificates with the same DN for subject and
issue are self-issued, it is unclear to me whether a certificate with
different DNs could be self-issued.  Section 6.1 could be giving one example
of how a certificate could be self-issued or section 6.1 could be a limiting
definition.

There is a CA certificate created with
Subject: O=Example Trust Services, OU=Commercial Trust Anchor Subject Public
Key: Key1
Issuer: O=Example Trust Services, OU=Global Trust Anchor Signed by Key0

Thanks,
Peter

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

---

From: Carl Wallace <[email-masked]>
Date: Mon, 13 Jul 2015 07:14:26 -0400

From:  Brian Smith <[email-masked]>
Date:  Sunday, July 12, 2015 at 9:57 PM
To:  Peter Bowen <[email-masked]>
Cc:  PKIX <[email-masked]>
Subject:  Re: [pkix] Self-issued certificates

> 
> In fact, mozilla::pkix doesn't recognize self-issued certificates at all, and
> so doesn't implement those exceptions. So far, this has not caused any

Do you have a list of standard path validation features that were omitted
from mozilla::pkix? This could form the basis of a revised path validation
algorithm definition or at least keep folks from using a library that is
missing features that are present in their environment.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 13 Jul 2015 12:25:11 +0000

In X.509 (and PKIX) the name *is* the identity.  X.509 (and PKIX) binds keys to names; the key can change but the name remains invariant.  In contrast, SPKI/SDSI binds names to keys; the key remains invariant, but the name can change.

So if it has a different DN, it's not the same entity.  As a result there's no ambiguity in the RFC.

It is possible to bind the same key to different names.  Nothing stops you from presenting the same key to multiple CAs and claiming different names.  If your goal is pseudonymity, though, I wouldn't recommend this.  :)

It's also possible to use keys from X.509 certificates as entities and ignore the name--e.g., key continuity management (a.k.a. certificate pinning)--but this is outside the spec.

-- T 

> -----Original Message-----
> From: pkix [mailto:[email-masked]] On Behalf Of Peter Bowen
> Sent: Sunday, July 12, 2015 5:03 PM
> To: [email-masked]
> Subject: [pkix] Self-issued certificates
> 
> I'm trying to make sense of the definition of "self-issued certificates" in RFC
> 5280 (and X.509)
> 
> Section 3.2 provides a definition: "Self-issued certificates are CA certificates
> in which the issuer and subject are the same entity."
> However section 6.1 says "A certificate is self-issued if the same DN appears
> in the subject and issuer fields."
> 
> While it is clear that all certificates with the same DN for subject and issue are
> self-issued, it is unclear to me whether a certificate with different DNs could
> be self-issued.  Section 6.1 could be giving one example of how a certificate
> could be self-issued or section 6.1 could be a limiting definition.
> 
> Example Trust Services has two different private keys.  Each key has a single
> associated DN:
> Subject: O=Example Trust Services, OU=Commercial Trust Anchor Subject
> Public Key: Key1

---

From: 王文正 <[email-masked]>
Date: Mon, 13 Jul 2015 12:54:39 +0000

I think both X.509 and RFC 5280 are clear and equivalent with respect to the definition of self-issued certificates.

In clause 3.5.62 of X.509, the definition of self-issued certificates is as below:

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.

In section 3.2 of RFC 5280, the definition of self-issued certificates is as below:

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.

In clause 8.1.5 of X.509, it specifies that naming rule for self-issued certificates as below:

These types of CA-certificates are called self-issued certificates, and they can be recognized by the fact that the issuer

and subject names present in them are identical.

In section 6.1 of RFC 5280, it specifies that naming rule for self-issued certificates as below:

A certificate is self-issued if the same DN appears in the subject

and issuer fields (the two DNs are the same if they match according

to the rules specified in Section 7.1).

The logic behind is "A CA is certainly an entity. Once the DN of the entity is officially assigned by a naming authority, it should not be changed unless its identity is change in the future. Therefore, when a CA performs its key rollovers of policy changes, it should not change its DN. That is why self-issued certificates with the same issuer and subject names are generated to support key rollovers of policy changes."

Please note that there are some special certification path handling rules are based on the assumption of "a certificate is self-issued if the same DN appears in the subject and issuer fields" as mentioned in clause 8.1.5 of X.509:

Nevertheless, if self-issued certificates of this category are encountered in the path, they shall be processed as

intermediate certificates, with the following exception: they do not contribute to the path length for the purposes of

processing the pathLenConstraint component of the basicConstraints extension and the skip-certificates

values associated with the policy-mapping-inhibit-pending and explicit-policy-pending indicators.

The certificate path validation algorithm defined in section 6.1 of RFC 5280 also contains exceptional "self-issued certificates" handling rules which are equivalent to those required by the X.509 standard.

If a CA issues a certificate of which the issuer name and subject name are not the same, it will be handled as a normal certificate (either as an non-self-issued intermediate certificate or as an end-entity certificate) and thus those exceptional "self-issued certificates" handling rules will not apply to it.

Wen-Cheng Wang

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Monday, July 13, 2015 3:30 PM
To: [email-masked]
Subject: Re: [pkix] Self-issued certificates

Hi Peter,

It is only RFC 5280 that is unclear. X.509 is quite clear. The X.509 definition is:

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.

Is a CA an entity or is CA is specific role for an entity among other roles for the same entity?

The RFC 5280 definition seems to assume that a CA is an entity, and the two CA you mention are different entities, while X.509 does not necessarily make that assumption.

Kind regards,

Erik Andersen

-----Oprindelig meddelelse-----

Til: [email-masked]<mailto:[email-masked]>

I'm trying to make sense of the definition of "self-issued certificates" in RFC 5280 (and X.509)

Section 3.2 provides a definition: "Self-issued certificates are CA certificates in which the issuer and subject are the same entity."

However section 6.1 says "A certificate is self-issued if the same DN appears in the subject and issuer fields."

While it is clear that all certificates with the same DN for subject and issue are self-issued, it is unclear to me whether a certificate with different DNs could be self-issued.  Section 6.1 could be giving one example of how a certificate could be self-issued or section 6.1 could be a limiting definition.

Example Trust Services has two different private keys.  Each key has a single associated DN:

Key: Key1

Thanks,

Peter

pkix mailing list

[email-masked]<mailto:[email-masked]>

pkix mailing list

[email-masked]<mailto:[email-masked]>

Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

---

From: 王文正 <[email-masked]>
Date: Mon, 13 Jul 2015 13:50:35 +0000

In my experiences, Mozilla Firefox still worked fine for handling self-issued certificates for key rollover purposes. Actually, most browsers will simply treat self-issued certificates as regular intermediate CA certificates. Therefore, if there are no complex path length constrains or name constrains to be handled, the certification path processing will be fine even though browsers might not implement those exceptional handling rules for self-issued certificates.

What really caused our headaches was some web server such as Microsoft IIS does not recognize self-issued certificates. For a CA performing its key rollover with self-issued certificates, the certification path chaining up to the old root certificate will be as follows:

old root certificate (a self-signed certificate) --> new-with-old certificate (a self-issued certificate) --> subordinate CA certificate (an intermediate CA certificate) --> SSL certificate

During the SSL/TLS handshake, it is expected that the web server to send "new-with-old certificate --> subordinate CA certificate --> SSL certificate" to browsers (the client side).

However, it is unfortunately that Microsoft IIS wrongly treats the self-issued certificate as a self-signed certificate and therefore it will only send "subordinate CA certificate --> SSL certificate" to browsers. The result is that browsers such as Firefox might failed to chain the certification path up to the old root certificate. In the cases where browsers do not yet trust the new root certificate, the SSL/TLS handshake will be failed.

Our company had already send a bug report to Microsoft through their so-called premium tech support channel several months ago, however they seemed not yet decide whether they want to fix that IIS bug or not. Therefore, be warned if you want to perform a CA key rollover with self-issued certificates because there are still a lot servers and clients whose certification path processing implementations do not conform to RFC 5280 or X.509 standard.

Wen-Cheng Wang

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Brian Smith
Sent: Monday, July 13, 2015 9:57 AM
To: Peter Bowen
Cc: PKIX
Subject: Re: [pkix] Self-issued certificates

<snip>

In fact, mozilla::pkix doesn't recognize self-issued certificates at all, and so doesn't implement those exceptions. So far, this has not caused any problems, so as far as the Web PKI is concerned, it is likely we can forget about the concept of self-issued certificate completely. And, that's what I recommend that people do.

Cheers,

Brian

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 13 Jul 2015 16:01:29 +0200

Hi Timothy

I am not sure how the first paragraph leads to the second paragraph. Where
is that stated in RFC 5280 or X.509?

Regards

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Miller, Timothy J.
Sendt: 13 July 2015 14:25
Til: Peter Bowen; [email-masked]
Emne: Re: [pkix] Self-issued certificates

In X.509 (and PKIX) the name *is* the identity.  X.509 (and PKIX) binds keys
to names; the key can change but the name remains invariant.  In contrast,
SPKI/SDSI binds names to keys; the key remains invariant, but the name can
change.

So if it has a different DN, it's not the same entity.  As a result there's
no ambiguity in the RFC.

It is possible to bind the same key to different names.  Nothing stops you
from presenting the same key to multiple CAs and claiming different names.
If your goal is pseudonymity, though, I wouldn't recommend this.  :)

It's also possible to use keys from X.509 certificates as entities and
ignore the name--e.g., key continuity management (a.k.a. certificate
pinning)--but this is outside the spec.

-- T 

> one example of how a certificate could be self-issued or section 6.1 could
be a limiting definition.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 13 Jul 2015 14:41:35 +0000

> is that stated in RFC 5280 or X.509?

It's not stated, it's legacy.  Originally the DN was supposed to be the entity's location in the imaginary X.500 directory.  Two different DNs == two different locations, and therefore two different entities (because X.500 had a single DIT).  

In short, the name--in X.509 and PKIX--*is* the thing.  

This may seem like a philosophical issue but is has real implications.  In access control systems, once the user's authenticator is verified, the user's public key is discarded and the system uses the name (usually by binding that name to a proprietary access credential, e.g., a cookie).  This behavior is common to most PK-enabled systems, though the use of the DN is no longer exclusive (we have SANs now).  Change the name--even if the same key is bound to it--and you'll lose access.  Try it with a PK-enabled website.  

Similarly with S/MIME--change the relevant name (here the SAN rfc822Name), and the email won't verify.

-- T

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jul 2015 18:32:25 +0200 (CEST)

??? wrote:
> 
> What really caused our headaches was some web server such as
> Microsoft IIS does not recognize self-issued certificates.
> For a CA performing its key rollover with self-issued certificates,

A CA which attempts to perform key rollover with self-issued certificates
is violating the 1997 UN convention on the prohibition on the use of
anti-personel land mines.

Public CAs seem to do it properly and safely, and include a
generation identifier in the subject DNames of new CA keys.

Do not be surprised if your attempts to use self-issued certificates
fail with other PKI software as well.

-Martin

---

From: Peter Bowen <[email-masked]>
Date: Mon, 13 Jul 2015 11:19:40 -0700

> CA you mention are different entities, while X.509 does not necessarily make

OK.  Now I'm even more confused.

X.509 says an authority is an entity, responsible for the issuance of
certificates and says a certificate authority is a type of authority.

How is RFC 5280 any more or less clear than X.509?  Is X.509's take
the certificate I described different from that attributed to 5280?

Thanks,
Peter

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 14 Jul 2015 10:39:31 +0200

Hi Peter,

I understand the confusion.

I do not claim that X.509 is consistent. Sometime X.509 is more clear and sometime RFC 5280 is more clear. I often go to RFC 5280 to get some clarification.

It appears to me that there is no consistent, detailed model for PKI. People supplement the current model with their own interpretation based on legacy. That people have somewhat different models in mind is clear from many PKIX discussions.

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: Peter Bowen [mailto:[email-masked]] 
Sendt: 13 July 2015 20:20
Til: Erik Andersen
Cc: <[email-masked]>
Emne: Re: [pkix] Self-issued certificates

On Mon, Jul 13, 2015 at 12:30 AM, Erik Andersen <[email-masked]> wrote:
> 3.5.62  self-issued certificate: A CA 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.
>
> The RFC 5280 definition seems to assume that a CA is an entity, and 
> the two CA you mention are different entities, while X.509 does not 
> necessarily make that assumption.

X.509 says an authority is an entity, responsible for the issuance of certificates and says a certificate authority is a type of authority.

How is RFC 5280 any more or less clear than X.509?  Is X.509's take the certificate I described different from that attributed to 5280?

Thanks,
Peter

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 14 Jul 2015 14:30:19 +0200

Hi Timothy,

I understand what you are saying and agree that the name is the thing.
However, the model is not that clear. Attributes may be stored in a
directory entry either in X.500 or LDAP.

The X.500 definition is:

11.2.1	User certificate attribute
A user may obtain one or more public-key certificates from one or more CAs.
The userCertificate attribute type contains the end-entity public-key
certificates a user has obtained from one or more CAs.

userCertificate ATTRIBUTE ::= {
  WITH SYNTAX             Certificate
  EQUALITY MATCHING RULE  certificateExactMatch
  ID                      id-at-userCertificate }

The RFC  4523 defines an equivalent one for LDAP. 

The  object class needed for defining directory entries is:

11.1.1	PKI user object class
The PKI user object class is used in defining entries for objects that may
be the subject of public-key certificates.

pkiUser OBJECT-CLASS ::= {
  SUBCLASS OF  {top}
  KIND         auxiliary
  MAY CONTAIN  {userCertificate}
  ID           id-oc-pkiUser }

As it an auxiliary object class, it has no associated name form, but it
might be combined with a structural object class that has a name form
different from the name form used in any subject name.

If I get end-entity certificates from different CAs, they may not have the
same subject name. Are they then different entities? At least they may be
contained in the same directory entry.

By the way, I never believed in a single DIT, which made me a apostasy of a
religious belief at the time. I was closed to being crucified.

-----Oprindelig meddelelse-----
Fra: Miller, Timothy J. [mailto:[email-masked]] 
Sendt: 13 July 2015 16:42
Til: Erik Andersen; [email-masked]
Emne: RE: [pkix] Self-issued certificates

> I am not sure how the first paragraph leads to the second paragraph. 
> Where is that stated in RFC 5280 or X.509?

It's not stated, it's legacy.  Originally the DN was supposed to be the
entity's location in the imaginary X.500 directory.  Two different DNs ==
two different locations, and therefore two different entities (because X.500
had a single DIT).  

This may seem like a philosophical issue but is has real implications.  In
access control systems, once the user's authenticator is verified, the
user's public key is discarded and the system uses the name (usually by
binding that name to a proprietary access credential, e.g., a cookie).  This
behavior is common to most PK-enabled systems, though the use of the DN is
no longer exclusive (we have SANs now).  Change the name--even if the same
key is bound to it--and you'll lose access.  Try it with a PK-enabled
website.  

Similarly with S/MIME--change the relevant name (here the SAN rfc822Name),
and the email won't verify.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 14 Jul 2015 13:40:50 +0000

Welcome to directories.  Please check your common sense at the door.  :)

The fact that the DN in my cert and my user account DN in, say, Active Directory aren't the same isn't a problem because (a) one of my SANs is probably set for AD--e.g., UPN, and (b) most code doesn't force them to be consistent anyway.

In effect, when I load a cert into userCertificate or userSMIMECertificate the directory is binding that cert to that directory identity.  That's technically separate from the identity the CA was binding into the cert because the CA is using a separate directory.  This is a necessary consequence of multiple independent DITs.  Yay!

Are the different names different identities?  It depends.  If you consider only the computer's POV, then yes, they may be separate identities depending on the processing being done.  If you take a meatspace POV, then the answer is "not necessarily."

The only real identity that matters is "keyholder."  If I control the private key bound to any name--DN, SAN, account name, doesn't matter--then I *am* that identity for all computational intents and purposes.  If this doesn't align with meatspace, well, too bad.  The only binding between a key and a bag o' meat is the private key container--this is a big reason why we use smartcards (though under certain conditions even this binding can be invalidated--see Balfanz and Felton, 1999).

-- T

> From: Erik Andersen [mailto:[email-masked]]
> Sent: Tuesday, July 14, 2015 7:30 AM
> To: Miller, Timothy J.; [email-masked]
> Subject: SV: [pkix] Self-issued certificates
> 
> Hi Timothy,
> 
> However, the model is not that clear. Attributes may be stored in a directory
> entry either in X.500 or LDAP.
> 
> The X.500 definition is:
> 
> The PKI user object class is used in defining entries for objects that may be
> the subject of public-key certificates.
> 
> As it an auxiliary object class, it has no associated name form, but it might be
> combined with a structural object class that has a name form different from
> the name form used in any subject name.
> 
> It's not stated, it's legacy.  Originally the DN was supposed to be the entity's
> location in the imaginary X.500 directory.  Two different DNs == two different
> locations, and therefore two different entities (because X.500 had a single
> DIT).
> 
> This may seem like a philosophical issue but is has real implications.  In access
> control systems, once the user's authenticator is verified, the user's public
> key is discarded and the system uses the name (usually by binding that name
> to a proprietary access credential, e.g., a cookie).  This behavior is common to
> most PK-enabled systems, though the use of the DN is no longer exclusive
> (we have SANs now).  Change the name--even if the same key is bound to it-
> -and you'll lose access.  Try it with a PK-enabled website.
>

---

From: 王文正 <[email-masked]>
Date: Tue, 14 Jul 2015 15:56:42 +0000

Hi Martin,

Regarding your simile of "key rollover with self-issued certificates" as "the use of anti-personnel land mines", I appreciate your sense of humor.

However, since "key rollover with self-issued certificates" is the standard method suggested by X.509 and PKIX, your simile seems to implies both X.509 and PKIX are violating the 1997 UN convention. Do you really mean that? :)

I believe the philosophy of X.509 (or the whole X.500 series) is that a Distinguished Name (DN) represents the identity of an entity. Therefore, if the DN is changed, it means the identity of that entity has been changed. With this philosophy, the DN of each entity should not be changed unless its identity is changed. Especially, a root CA is the trust anchor, which should not change its DN between generations of CA keys, otherwise relying parties will be confused about whether they are the same root CA entity.
It is unfortunately that many COTS have not yet fully implement the certification path validation algorithm specified in X.509 or RFC 5280, therefore many root CAs choosed to change their DNs whenever they performed key rollovers. They actually bred logically new root CAs whenever they doing so. As a result, there were more and more root CAs created. Please take a look at trust lists maintained by browsers, Those lists are really messy adn it is hard to tell which one is which.

Wen-Cheng Wang

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Tuesday, July 14, 2015 12:32 AM
To: 王文正
Cc: PKIX
Subject: Re: [pkix] Self-issued certificates

A CA which attempts to perform key rollover with self-issued certificates is violating the 1997 UN convention on the prohibition on the use of anti-personel land mines.

Public CAs seem to do it properly and safely, and include a generation identifier in the subject DNames of new CA keys.

Do not be surprised if your attempts to use self-issued certificates fail with other PKI software as well.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 14 Jul 2015 22:12:54 +0200 (CEST)

> 
> However, since "key rollover with self-issued certificates" is the
> standard method suggested by X.509 and PKIX, your simile seems to
> implies both X.509 and PKIX are violating the 1997 UN convention.
> Do you really mean that? :)

The originaly idea in X.509 predates the UN convention, so it's only
current consumers that are making use of this half-baked misfeature
that are violatin the UN convention.

> 
> I believe the philosophy of X.509 (or the whole X.500 series) is that
> a Distinguished Name (DN) represents the identity of an entity.
> Therefore, if the DN is changed, it means the identity of that entity
> has been changed. With this philosophy, the DN of each entity should
> not be changed unless its identity is changed.

The last sentence is a non-sequitur.

>
> Especially, a root CA is the trust anchor, which should not change
> its DN between generations of CA keys, otherwise relying parties
> will be confused about whether they are the same root CA entity.

It's extremely difficult to believe that anyone could get confused
about the entity/entities represented by name that simply include
generation identifiers to avoid self-issued problems.

  "CN=VeriSign Class 3 Public Primary Certification Authority - G3, ..."
  "CN=VeriSign Class 3 Public Primary Certification Authority - G5, ..."

Distinguished names contain semantic structure on purpose.  Use whatever
RDName component you like to avoid the troubles and complexitis of
self-issued certificates.

For root CA certs, the distinguished name regularly does not describe
the true entity that operates the CA anyway, because many of them change
ownership once or more often while they're in use.  

  e.g.  RSA->VeriSign->Symantec

The fashion in which the processing of self-issued certificates is specified
actually _creates_ a security problem.  Normally, one might assume that using
a path len constraint of 0 in the certificate of an online CA would preclude
that an attacker who manages to briefly obtain control over a CA key to
issue himself a CA cert.  The official processing rules for self-issued
certs subverts that assumed protection -- the attacker can sign himself
a self-issued CA cert and use that to screw all RPs that process cert
chains in the fashion that X.509 / PKIX specifies.

>From the perspective of risk management, not supporting self-issued
certificates is IMHO a very resonable decision.

For CAs to do rollover with Generation identifiers in DNames
is a no-brainer.  It will also facilitate recognizing and
telling apart the CA certificates -- for RPs that start with an
empty trust store rather than a trust store prepopulated
with hundreds of omnipotent CAs -- or a dynamic trust store
such as that of newer Versions of Microsoft Windows, where you
essentially have no control over the trust anchors any more and
no idea who is trusted.

-Martin

---

From: 王文正 <[email-masked]>
Date: Wed, 15 Jul 2015 18:13:20 +0000

Hi Martin,

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Wednesday, July 15, 2015 4:13 AM
To: 王文正
Cc: [email-masked]; PKIX
Subject: Re: [pkix] Self-issued certificates

> that are violatin the UN convention.

IIRC, the notion of "key rollover with self-issued certificates" arose in RFC 2510 (1999) and the 4th edition of ITU-T X.509 (2000). Please take a look at the 1997 version of ITU-T X.509, the term "self-issued certificate" does not appeared in that version. Therefore, it does not predate the 1997 UN convention.

> The last sentence is a non-sequitur.

If the DN represents the identity, I do not see why the last sentence is a non-sequitur. The analogy is that if your name or your Facebook ID represents your identity, will you frequently change your name or your Facebook ID?

>   "CN=VeriSign Class 3 Public Primary Certification Authority - G5, ..."

Isn't it dangerous to trust two entities as the same one simply because they have similar DN? How do you know these two CA is the same one?
Besides, differnet CA might use different way add "generation identifiers" to their CN, O, or OU. There is no systematically secure way to tell whether they are the same entity. Your decision to accept G5 because your trust G3 is only based on your intuition and that might be dangrous.

> self-issued certificates.

Indeed, DNs are designed to contain semantic structure on purpose, and that is because X.500 wants every entity use the semantic structure to uniquely name themself to establish trust relationship based on their persistent DNs.

>  e.g.  RSA->VeriSign->Symantec

No mater who operates the CA, the CA is itself an entity and has its identity in the PKI world. People trust the VeriSign CA not because it is operated by Symantec Corp. or VeriSign Inc., it is because the CA fullfil some international security criteria and has been audited.

> chains in the fashion that X.509 / PKIX specifies.

Your reasoning is really illogical. If a CA key is compromised, nothing further can be trusted. I do not see why this secure problem will be more specific to a CA which adopt self-issued certificates for key rollovers. If an attacker obtains control over the certificate sining key of a CA which has a "generation identifier" in its DN, doesn't the attacker be able to sign a himself a subordinate CA certificate?

> essentially have no control over the trust anchors any more and

I assume you know the reason why the root CA key (usually in the form of a self-signed certificate) must be distributed to RPs through an out-of-band secure channel. If you do, you may realized what PKIX and X.509 tried to do is to specify a systematically secure way to distribute the next generation root CA key to RPs. There are at least two advantages if a root CA do its key rollover with self-issued certificates:

(1) Since RPs had already receieved the previous generation of the root CA key from a secure channel and trust it, the RPs can use the trusted root CA key to verified the new-with-old self-issued certificate and build the trust to the new generation of the root CA key (and therefore the new self-signed certificate of the root CA).

(2) The self-issued certificate can temporarily be used to chain the new certificate chain up to the old self-signed certificate of the root CA, before the new self-signed certificate is finally distributed to all RPs.

I do not see why adopting a non-systemantical and messy way such as adding Generation identifiers in DNames is more reasonable than the standard way suggested by X.509/PKIX. It is unfortunate that there are many RPs does not fully implement the certification path validation algorithm defined by X.509/PKIX. This might be the reason why many root CAs choose to adopt the messy way for key rollovers. I guess there are some CA implementors do not fully understand the standard way for key rollovers suggested by X.509/PKIX, they simply saw some big CA vendors do such thing and they learnt to do it.

Wen-Cheng Wang

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 15 Jul 2015 18:41:29 +0000

> Isn't it dangerous to trust two entities as the same one simply because they have similar DN? How do you know these two CA is the same one?

I suppose it bears mentioning that you should never accept a trust anchor without some kind of verification.  An RFC 4210 rollover announcement is fine and dandy if and only if you already trusted the old anchor.  If you don’t, then you need to go out-of-band, and part of that is verifying that the entity named is the entity you expect.

— T

---

From: 王文正 <[email-masked]>
Date: Thu, 16 Jul 2015 09:20:01 +0000

Hi Timothy,

> I suppose it bears mentioning that you should never accept a trust anchor without some kind of verification.  An RFC 4210 rollover announcement is fine and dandy if and only if you already trusted…

Exactly, thank you for helping to clarify that concept.

Wen-Cheng Wang

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 Jul 2015 16:12:17 +0200 (CEST)

Miller, Timothy J. wrote:
>
>> Isn't it dangerous to trust two entities as the same one simply because
>> they have similar DN? How do you know these two CA is the same one?
> 
> I suppose it bears mentioning that you should never accept a trust
> anchor without some kind of verification.  An RFC 4210 rollover
> announcement is fine and dandy if and only if you already trusted
> the old anchor.  If you don't, then you need to go out-of-band,
> and part of that is verifying that the entity named is the entity
> you expect.

An entity announcing a a key rollover and the coincidence to receive
a new self-signed cert with verbatim the same DName but a different
public key in it does not provide any verification or proof.

Only a signature of the new key with the old key could provide
such a proof.  But then, it becomes entirely irrelevant whether
the new cert bears a generation identifier in the subject DName
that differs from the subject DName of the original trust anchor.
It could even be a totally different name -- and for some of the
changes of ownership of the CA entity, a complete name change
could even make sense.

So really, self-issued certificates a fifth wheel on the PKIX cart
that can only get you in trouble.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 16 Jul 2015 14:43:29 +0000

> such a proof.  

Umm, that’s what an RFC 4210 CA Key Update Announcement is.  Actually, it contains the old key signed with the new key, the new key signed with the old key, and the new key self-signed.

— T

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 Jul 2015 17:44:49 +0200 (CEST)

Miller, Timothy J. wrote:
> Umm, that?s what an RFC 4210 CA Key Update Announcement is.
> Actually, it contains the old key signed with the new key,
> the new key signed with the old key, and the new key self-signed.

:-)

I'm sorry.

I had not recognized your term "RFC 4210 rollover announcement" as
something that refers to a technical protocol that includes
the relevant PDUs.

rfc4210 is sufficient complex and awkward that is not used anywhere
around TLS (at least the stuff that I come in contact with) nor common
web-service or pkcs#7/CMS based data exchange scenarios.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 16 Jul 2015 16:16:52 +0000

> web-service or pkcs#7/CMS based data exchange scenarios.

I didn’t say it was *used*, I said it would *work*.  ;)

— T

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 17 Jul 2015 04:21:46 +0000

>I didn’t say it was *used*, I said it would *work*.  ;)

You can't really claim that it'll work either.  CMP is sufficiently
dysfunctional and broken that it's really hard (in many cases almost
impossible) to get two implementations to talk to each other just to do a
standard "gimme a cert" (which is all that 99.5% of users really care about).
Given that, I'd put the chances of something as untried as a TA-update working
correctly at "vanishingly small", at best.  So the correct phrasing would be
something like "CMP has something that could, in theory, work, if someone
implemented it".

Peter.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 17 Jul 2015 01:58:17 -0400

> No mater who operates the CA, the CA is itself an entity and has its
> identity in the PKI world. People trust the VeriSign CA not because it is
> operated by Symantec Corp. or VeriSign Inc., it is because the CA fullfil
> some international security criteria and has been audited.

It may be worth noting: if you read the CPS and believe the company's
lawyers, then you probably would not trust most CAs.

Its strange the company's lawyers tell us the warez are not fit for
use, but we choose to trust them anyway....

Jeff

---

From: 王文正 <[email-masked]>
Date: Fri, 17 Jul 2015 14:37:53 +0000

>> something that refers to a technical protocol that includes the 
>> relevant PDUs.
>> 

Actually, according to my experiences, certification paths with self-issued certificates worked seamlessly in most TLS/SSL environments, except with Microsoft IIS.

In a case where the end-entity certificate is a SSL certificate, after the root key rollover, the certification path will be as follows:

old root self-signed cert --> new-with-old self-issued cert --> subordinate CA cert --> SSL cert

Most SSL/TLS servers, such as apache+openssl, is able to correctly send the certificates payload ("new-with-old self-issued cert --> subordinate CA cert --> SSL cert") to client sides during the SSL/TLS handshake.
Also, most browsers, including IE, Chrome, Firefox, Safari, and Opera, can successfully chain the certification path to the trust anchor (the old root self-signed cert) and successfully validate it because they simply treat the new-with-old self-issued cert as a normal intermediate certificate.

The only problem I had ever encountered is caused by Microsoft IIS. Unlike other SSL/TLS servers which can be configured to send whatever intermediate certificates you specified to the client side, Microsoft IIS insists to automatically decide which are the intermediate certificates for your SSL certificate. Unfortunately, Microsoft IIS incorrectly decides that the new-with-old self-issued cert is not an intermediate certificate to be sent to the client side. My guess is that Microsoft IIS mistakenly treat the self-issued cert as a self-signed root cert (it may thought any cert will be a self-signed cert if the same DN appears in the subject
and issuer fields), therefore it decides not to send it to the client side. The result is a broken certification path in the client side.

Interestingly, Microsoft IE itself can validate the certification path "old root self-signed cert --> new-with-old self-issued cert --> subordinate CA cert --> SSL cert" without any problem.

Wen-Cheng Wang

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 17 Jul 2015 15:36:41 +0000

> In a case where the end-entity certificate is a SSL certificate, after the root
> key rollover, the certification path will be as follows:
 
> old root self-signed cert --> new-with-old self-issued cert --> subordinate CA

While rolling over a self-signed certificate while preserving trust is an interesting problem (to me, anyway, 'cause I'm a fan of key continuity management ;) in general practice your example chain should never occur in TLS/SSL.  Rollover messages are certificate management messages; new-with-old and old-with-new are management artifacts and not intended for path construction.

I.e., if in your example:

- Root rollover is due to pending or past root key expiration, then the "old-root" trust anchor is replaced by "new-root;" the chain terminates at "new-root" and new-with-old doesn't appear.

- Root rollover is due to root key compromise, new-with-old can't be trusted, "old-root" trust anchor must be removed, and the chain is invalid.   

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 20 Jul 2015 12:39:25 +0000

> However, most relying parties rely on COTS such as browsers or operating
> systems to update their lists of trust anchors. After a root CA performed its
> key rollover, it will submit its new root cert to "Root Certificate Programs" of
> all mainstream browsers or operating systems. It might take server months
> or even more than half year before the new root cert is accepted by "Root
> Certificate Programs" of all mainstream browsers or operating systems.
> Before the new root cert is added to the lists of trust anchors of all
> mainstream browsers and operating systems, TLS/SSL servers would
> temporarily rely on the new-with-old certificate to assist relying parties to
> chain the certification path up to the old root cert (i.e., the old trust anchor).

In practice, commercial CAs act with enough foresight that this isn't a problem for the most part; they ensure that a new root is published (minimally by MS and Mozilla) before making it an active issuer.  It's not like you can't see key expiration coming and plan accordingly.

Private CAs have their own trust management avenues so while they have to do the same kind of planning, timelines are shorter.  

Most PKIs also create new CAs rather than deal with the complexities of rollover.  It's easier to just prune the PKI entity tree than to try to graft in a new parent node.  As each CA switches into CRL-only mode [1] you have another ready to take its place and operations continue without interruption.  

-- T

[1] If your CP and CPS is written according to best practices, a CA's actual lifetime is minimally double the maximum Subscriber key lifetime.  By doing so the CA can issue a Subscriber cert just before switching into CRL-only mode, that Subscriber gets a full life out of that cert, and the CA can be retired as soon as all Subscribers certs are either revoked (with a final CRL issued) or expired.

---

From: 王文正 <[email-masked]>
Date: Tue, 21 Jul 2015 13:47:18 +0000

> - Root rollover is due to pending or past root key expiration, then the "old-root" trust anchor is replaced by "new-root;" the chain terminates at "new-root" and new-with-old doesn't appear.

You are right, if the new root cert (new-with-new self-signed cert) has been distributed to relying parties, then the relying parties can directly use the new root cert as the trust anchor and therefore they do not need to build the certification path with the help of the new-with-old self-issued cert anymore. In the situations where relying parties already has the new root cert in their lists of trust anchors, the certification path will be as follows:

new root cert --> intermediate CA cert --> TLS/SSL cert

However, most relying parties rely on COTS such as browsers or operating systems to update their lists of trust anchors. After a root CA performed its key rollover, it will submit its new root cert to "Root Certificate Programs" of all mainstream browsers or operating systems. It might take server months or even more than half year before the new root cert is accepted by "Root Certificate Programs" of all mainstream browsers or operating systems. Before the new root cert is added to the lists of trust anchors of all mainstream browsers and operating systems, TLS/SSL servers would temporarily rely on the new-with-old certificate to assist relying parties to chain the certification path up to the old root cert (i.e., the old trust anchor).

> - Root rollover is due to root key compromise, new-with-old can't be trusted, "old-root" trust anchor must be removed, and the chain is invalid.

Yes, if the old root key was compromised, then both new-with-old and old-with-new are useless. In that situation, the root CA has to generate a new key pair and distribute the new root cert to relying parties as soon as possible. However, if a root CA of which root key had ever been compromised, I doubt that relying parties will trust the CA again.

Wen-Cheng Wang