There are some pretty fishy things going on here...
If you accept a trust anchor with or without a [self-certified] name,
should not make a difference except that a named trust anchor is
[much] easier to manage.
Logically separating the public key from its cryptographically secured,
self-asserted name, IMHO serves no purpose, since they are only
different representations of the very same entity. This notion should
BTW apply to any self-signed certificate, rather than being limited to
CA root certificates.
Regarding my bug report, I doubt that the scheme you describe is the
culprit, I tend to believe that Mozilla uses a somewhat simplified
certificate database model, where issuer names are assumed to be
*globally* unique.
Anders
----- Original Message -----
From: "Kyle Hamilton" <[EMAIL PROTECTED]>
To: "Anders Rundgren" <[EMAIL PROTECTED]>
Cc: "Mozilla Crypto" <dev-tech-crypto@lists.mozilla.org>
Sent: Friday, September 29, 2006 14:35
Subject: Re: CA serial number clarification. Re: Mozilla's use of AIA caIssuers
URIs
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
