The trust anchor (i.e., the root CA) authenticates itself, as well as
the certificates it issues to other entities. A better diagram and
way of looking at it would be thus:
anchor (.) <- trust level
/ \
root subca <- authentication level
/ \
subsubCA endentity
It's rather like the "cache poisoning" attack against DNS which was
fixed many years ago -- 'root' and 'subca' could just as easily be
.net and .org, and they would tell the requester what their ideas of
what the root servers were supposed to be. The recursive server that
made the query, though, was (and is) what chose its own idea of what
the roots were, and the creators of BIND realized that they needed to
prevent the root cache from being tainted by untrusted servers...
i.e., verifying its integrity.
(In DNS vs. X.509, note that the responsibilities are shifted -- the
individual servers [administrative domains] are configured by the
administration to be trustworthy, and the machines that use those
servers implicitly use those servers' security policy. This could be
emulated in X.509 via the use of LDAP and querying for trusted root
certificates whenever it's checked... but in current implementations,
it's cached on or stored on the client.) One thing that's important
to remember about DNS is that the root is defined and referenced by
and within itself, with SOA, NS, and A records as appropriate. It
also delegates the "top level domains" (.com, .net, .org, .us, .uk,
.au, etc) from within itself, approximately the same way that a root
CA signs sub-CA certificates. (The TLDs manage their own contents,
but the delegation is basically the same as signing a delegated CA
certificate.)
There isn't an exact mapping between DNS and X.509, but the ideas are
similar enough that learning one provides a good insight into the
other... and the reasons behind some of the decisions made by it.
There isn't a level for anything to authenticate the root (unless the
root key doesn't have a certificate associated, OR there's a bridge CA
scenario) -- so, the trust anchor for the root needs to assert its own
identity (by certifying its own public key). The trust anchor also
asserts the identity of the subCAs that it signs, as well as any
bridges that it creates.
So, I have to think that "current practice" in everything except NSS
is broken, simply because of how the identity binding process works.
(Also: there's Authority Key Identifier, which allows the hash of the
public key that signs a subCA to be referenced, but there's also
Authority Identifier, which allows the DN of the CA to be referenced.
The latter is theoretically more robust, because if the key that the
CA uses is compromised, the CA can revoke its own certificate and
generate a new key and certificate to assert its identity. In
practice, this creates problems because the old signatures are no
longer valid, and new certificates must be generated for any entities
which the CA did not explicitly revoke the keys for.)
-Kyle H
On 9/28/06, Anders Rundgren <[EMAIL PROTECTED]> wrote:
Jean-Marc Desperrier wrote:
>> [...]. That Root is actually signed by the
>> same key and having the same issuer as Sub does not put it in the same level
>> as Sub since Root is selfsigned.
>I think you should rethink about the meaning of *self*-signed.
I don't claim to be the world's biggest expert on path validation so please bear
with me.
>The issuer of Root *is* Root, so Root and Sub *do* share the same
>issuer, and they are at the same level.
Since Root is also the issuer of Sub, the consequence of this logic actually
gives a self-signed Root certificate *two* places in a CA hierarchy:
Root
/ \
Root Sub
This can't hardly be correct. The problem is as far as I can tell, that the
"issuer" in a self-signed root is actually non-existent from a path-building
point of view. In fact, there are no rfc3280 requirements saying that trust
anchors (roots) must be certificates at all, a public key is good enough.
If you (as I did) distribute a root as a certificate, this should not change
the validation rules, it is just a convenient way of packaging roots.
Apparently the Mozilla certificate database use the logic you describe
but other parties (MS, Java[keystore] and Adobe) do not according to
my testing. After some consideration, I concluded that this is likely to
be a bug in Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=354628
thanx
Anders
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
-Kyle H
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
