On 10/10/2011 12:16 PM, Wan-Teh Chang wrote: > After you match a trust object to a certificate, check the > CKA_TRUST_SERVER_AUTH, CKA_TRUST_EMAIL_PROTECTION, and > CKA_TRUST_CODE_SIGNING attributes in the trust object. > > In the current version of certdata.txt, these attributes may have only > three possible values: > - CKT_NSS_TRUSTED_DELEGATOR: this means the CA is trusted for that purpose. > - CKT_NSS_TRUST_UNKNOWN: this means the CA is not trusted for that > purpose, but is trusted for some other purpose. > - CKT_NSS_NOT_TRUSTED: this means the certificate (which may not be a > CA) is explicitly distrusted. > > Note: I recommend that the scripts assert that these attributes only > have these three values, so that it can detect when this assumption is > no longer true. > > The scripts must exclude the certificates whose trust objects contain > CKT_NSS_NOT_TRUSTED in any of the CKA_TRUST_SERVER_AUTH, > CKA_TRUST_EMAIL_PROTECTION, and CKA_TRUST_CODE_SIGNING attributes. I agree this should be the minimum processing these scripts do. Ideally these scripts should also look at the trust fields they are interested in, for instance CKA_TRUST_SERVER_AUTH. Not all uses have this level of granularity, so it's not a requirement.
Scripts should also have a way to output the NSS trust values, or an appropriate mapping thereof for So users of the output of these scripts can see them... At some point the users of these cert trust values will need to find some way to encode explicitly revoked certs as well. That is starting to get far afield from the original issue, so I think it's more of a 'throw away' communication to them. Not really a solution to the bug. bob > Wan-Teh Chang
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
