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. > > (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.
And it is planned (is there a plan?) to store this information using the vendor-defined extensions you mentioned in your message? Where does NSS/PSM store the values of the three checkboxes you can set through the UI to decide whether a cert is trusted for web/SSL/code? > 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. (Question repeated for completeness) 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. 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 [EMAIL PROTECTED] https://lists.mozilla.org/listinfo/dev-tech-crypto
