I thought we'd had this type of conversation before... or maybe it
was on the TLS discussion list, and I'm not remembering. Regardless...
A "trust anchor" is a public key. (It's not a certificate that
contains the public key, or anything which can be validated with the
public key -- it's the public key itself. It just so happens that an
X.509 certificate is a convenient package for it.)
A "CA" is a string of characters. It's not a public key or a trust
anchor. (This is the concept that made possible the "S/MIME
including bogus CA certificate disables certificate validation"
attack of a few years ago.)
All of the workarounds that have been emplaced are limited,
necessarily, by these two concepts. Now, you're advocating placing
an external limit on the trust allowed to be delegated from a trust
anchor. (which is also what EV requires.) However, this is an
explicit violation of the concept of a trust anchor: a trust anchor
is the anchor for absolute trust.
Within the X.500 model, the better way to do this would be to
generate a CA for Mozilla, convert the self-signed trust anchors into
CSRs, have the Mozilla CA re-sign them with the appropriate
restrictions and validations, and embed the Mozilla root into the
library as the absolute trust anchor. (This would also provide an
"audit trail" for the operations performed... i.e., "who said that
this CA can't sign a bank's certificate?" "Why can't I verify this
person's cert even though he's a citizen of the country that signed
it, and he's living abroad at the moment?" and others.)
I am ABSOLUTELY against any concept of a "silent and unaccountable"
restriction being placed, on anything. With unaccountability and
silence comes a "what the hell is it set that way for? I'll just fix
it..." mentality without the benefit of being able to see the
reasoning behind it. At least if there's a true anchor that signs
things, an explanatory URL could be placed in its X.509 package and
they could see an explanation of the reasoning.
-Kyle H
On Mar 20, 2007, at 5:08 AM, Gervase Markham wrote:
> Nelson Bolyard wrote:
>> Your proposal would require storing the equivalent of a name
>> constraints
>> extension along with the root CA cert. It would also require
>> additional
>> processing, because name constraints are generally not processed
>> inside
>> trust anchors. That is, usually a CA puts the name constraints
>> extension
>> into subordinate CA certs that it issues, and a root CA does not
>> attempt
>> to constrain itself. Standard RFC 3280 cert chain validation does
>> not
>> expect the "trust anchor" (root) to have any such constraints, and
>> the
>> algorithm in that standard does not use such into in a root cert,
>> if present.
>
> OK. And the root certificate is treated as a special case in the cert
> chain validation? In other words, the work would be more than doing
> the
> equivalent of changing:
>
> if (!root)
> {
> check_name_constraints():
> }
>
> into
>
> if (!root || cert.has_external_name_constraints_imposed)
> {
> check_name_constraints();
> }
>
> ?
>
>> (As an aside, EV also requires non-standard behavior and if
>> implemented in
>> NSS would also require similar (though fewer) non-standard
>> extensions. EV
>> requires the storage of one or more EV policy OIDs that are
>> permitted to be
>> used in certs issued by the root CA and its subordinates. (One
>> universal EV
>> policy OID would have eliminated this extra burden).
>
> ...but would have removed the possibility of us easily revoking the EV
> status of some CAs, but not others.
>
>> Alternatively these non-standard extensions could be implemented
>> in PSM.
>> PSM would be free to store the information in any non-standard format
>> it likes. After a cert chain has been validated by NSS's cert path
>> validation code, PSM could do additional checks on policy OIDs and/or
>> RFC 822 names according to the rules/info it has stored.
>
> I presume it has access to the information it would need via the API?
>
>> Since mozilla clients are likely the only NSS-based applications that
>> will want these extensions, I think a case can be made that these
>> extensions should be done in PSM rather than in NSS.
>
> OK. It's good to know that you have no objections to it being added in
> this way.
>
> My concern about implementing it "on top of" NSS is that, as I
> understand it, it would require a parallel database to be kept of
> "certificate metadata". Would this not raise architectural objections?
>
> Gerv
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
