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
