On 5/22/14, 9:38 AM, Kurt Roeckx wrote:
On Thu, May 22, 2014 at 08:50:02AM -0700, Kathleen Wilson wrote:
But really, since the websites and code signing trust bits are not enabled,
the hierarchy is already essentially constrained -- NSS would give an
exception for path validation of an SSL or code signing cert. So, the EKU
requirement doesn't really add value in this case.
There are other libraries than NSS making use of the root
certificates that do not all support having trust bits. As far as
I know there is also no standard format to indicate those trust
bits together with the certificate. This currently results in
other libraries just ignoring those trust settings.
I think our policy and process decisions need to be based on proper
usage of NSS, which means considering the trust bit settings when doing
certificate path validation.
However, I am concerned that there are folks out there using the NSS
root store without considering the trust bit settings.
The trust bit settings are in the same file as the list of included root
certs.
http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt
For each root the trust bit settings are specified with:
CKA_TRUST_SERVER_AUTH
CKA_TRUST_EMAIL_PROTECTION
CKA_TRUST_CODE_SIGNING
For example, to enable the websites trust bit:
CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_TRUSTED_DELEGATOR
and to disable the websites trust bit:
CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
Is there someplace in our NSS documentation where we need to make it
more clear that people who are using the NSS root store should also take
notice of the trust bit settings?
Have we provided sample code that needs to be updated to take the trust
bit settings into account when extracting the root certs from NSS?
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
