Re: [pkix] Self-issued certificates

[[e-mail] (Martin Rex)]

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