> On May 12, 2017, at 3:48 PM, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about >> suggesting a good format for sharing this info across libraries though. >> Discussing that on a list dedicated to a single library (such as NSS or >> OpenSSL) would be pointless. >> > > And in the original message, what was requested was > "If Mozilla is interested in doing a substantial public service, this > situation could be improved by having Mozilla and MDSP define a static > configuration format that expresses the graduated trust rules as data, not > code." > > Mozilla does express such graduated trust rules as data, not code, when > possible. This is available with in the certdata.txt module data as > expressive records using the NSS vendor attributes. > > Not all such requirements can be expressed as code, not data, but when > possible, Mozilla does. That consuming applications do not make use of that > information is something that consuming applications should deal with.
One thing that doesn’t happen today but would likely be broadly compatible would be to replace certain self-signed root certs in the trust store with certs that appear to be cross-signed with restrictions. They could in reality have fixed values in the signature section, but this would allow adding constraints directly in certificate structure. Examples could include adding or modifying extensions such as extendedKeyUsage, nameConstraints, or private key usage period. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
