Re: [pkix] Self-issued certificates

[王文正 <[e-mail]>]

Hi Martin,

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

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

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.

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

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?

> 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, ..."

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.

> Distinguished names contain semantic structure on purpose.  Use whatever
> RDName component you like to avoid the troubles and complexitis of
> 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.

> 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

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.

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

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?



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

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

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.