Kyle Hamilton wrote, On 2008-06-05 07:46:
> I must also point out something:
>
> NSS (at least up until 2004 -- I don't know if this has been changed,
> but the MoFo position espoused by I believe Nelson and Frank was that
> it wouldn't change) doesn't rely on any of the X.509v3 certificate
> fields of embedded trust anchors when figuring out whether to extend
> trust.
The statement that "NSS ... doesn't rely on *any* of the X.509v3 certificate
fields of embedded trust anchors when figuring out whether to extend
trust" just isn't true, and never has been. I don't recall absolutely
everything I've ever written on the subject, but I'm pretty certain I
would not have written something about it that I knew to be untrue.
However, if you replace "any" with "some" in that statement, it is true.
In NSS, certs may be marked as trust anchors for particular usages (EKUs).
In all versions of NSS up through NSS 3.11.x, marking a certificate as a
trust anchor for a particular EKU causes SOME aspects of the cert itself to
be overridden when checking a chain's validity for that usage. These
include:
- The signature on the trust anchor cert is ignored.
- The absence of a Basic Constraints extension is treated as if the
extension was present and shows that the cert is a CA and that the path
length is unlimited. However, if the Basic Constraints extension is
present, its values are honored as-is. A cert whose basic constraints
extension is present and says it is NOT a CA certificate cannot be a trust
anchor even if marked as such.
- These extensions are ignored (overridden) in the marked trust anchor cert
- Key Usage (KU)
- Extended Key Usage (EKU)
- Name Constraints
That is, trust anchors are valid for all key usages and for all name
spaces, for the Extended Key Usage (or usages) for which it was marked
trusted.
> Thus, changing it won't have any practical value anyway.
By "it", I believe you are referring to the expiration date of the cert.
The Validity Period of a cert is never overridden.
> (The argument was that X.509 makes a good container format for
> distributing trust anchors -- the public keys -- along with display
> metadata, but that the trust anchor itself could be distributed
> separately from the X.509 container and thus should not be subject to
> any policy statements included in that container. Which didn't make
> any sense to me at the time, and still doesn't -- since that container
> is signed by that key anyway, and I would expect it to adhere to the
> CPS espoused by that key -- but that's how it was explained.)
I recall a long discussion on this list in which certain people observed
(or opined) that the cert path validation algorithm defined in RFC 3280
has the characteristics you describe above. That is, the claim was made
that RFC 3280's algorithm does not require a trust anchor to be anything
more than a public key, and does not impose any checks on it for validity
dates, key usages, extended keys usages, name constraints, etc. etc.
In other words, the claim was that RFC 3280 considers a trust anchor to
be absolutely trusted in all respects for all purposes at all times.
(Put another way, the criteria for selection of a trust anchor are outside
the scope of the algorithms defined in RFC 3280, and any such criteria
have already been applied to the trust anchor before the algorithm defined
in RFC 3280 begins.)
The above views were used as the basis for a claim that the scheme used
in Mozilla (and other products) of having multiple self-signed CA certs
and using them all as trust anchors was non-conformant to the RFC. One
writer seemed to believe that, to conform to the RFC, it would be
necessary for the mozilla clients to have a single trust anchor key, and
for Mozilla (or its clients) to actually issue certificates,
cross-certifying the {subject name, key} pairs that appear in the root
certificates that Mozilla clients now mark as individual trust anchors
with trust flags.
I recall writing that the scheme that NSS now uses, with a set of root CA
certs marked with trust flags, is equivalent to the cross-certification
scheme that the writer wanted, and that the RFC allows any scheme that is
equivalent and produces the same results. I gather that the writer did
not accept that claim of equivalence, but never explained why.
/Nelson
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
