Gervase Markham wrote: > Bob Relyea wrote: >> In addition, we only parse these kinds of constraints on intermediate >> certs (we currently don't have a mechanism to place name constraints >> on a trusted root. Even if the trusted root had constraints itself, >> they would be ignored once we identify the cert as trusted. > > Would someone be able to estimate how much work it would be to extend > the name constraints mechanism to the trusted roots, and add the ability > for NSS to store its own name constraints, to be added to any in the > root itself?
I won't estimate in man hours, but I will say that a) what is being proposed is non-standard behavior, and if implemented in NSS requires non-standard extensions to standards-based APIs to accomplish. b) it would require changes to many different parts of NSS, if it is done inside of NSS. c) it could be done by PSM, and perhaps it should be. 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. (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). EV requires additional non-standard processing, during the validation of a cert chain, to check that an EE cert's policy OID is the one permitted for that root CA.) NSS stores certificates and meta-information about certificates in its cert DB which is inside of a PKCS#11 module. The interface to that data is the PKCS#11 API, which is a standardized API. PKCS#11 allows vendor-defined extensions to its API. It allows vendor- defined object types and vendor-defined attributes for standard objects. NSS already uses vendor defined "trust" objects to store trust information about certs stored in the PKCS#11 module. The extensions for your proposal and for EV would necessitate creating more vendor-defined extensions (objects and/or attributes). It would require a) database changes b) PKCS#11 module changes, c) changes to the cert chain validation code (which has recently been reimplemented to be fully RFC 3280 compliant, albeit this work is not yet integrated). 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. 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. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
