Although we have a policy against using live certificates for testing, the policy was not followed in this case.
Can you share why? Can you share what steps you'll be taking to make sure policies are followed in the future? I think we've seen some pretty stark examples about what can happen when a CA doesn't follow its policies for test certificates - from CNNIC to Symantec. [JR] In this particular case, the cause was training/policy error in this case and mostly my fault (as one of the policy drafters). We have technical processes in place to prevent the issuance of certificates with test data. We have also repeatedly communicated that test certificates cannot be issued. However, we do not technically prevent engineers from applying for certificates on the domains they own. As such, the term “test certificate” wasn’t well-defined (similar to the current BR test certificate definition). We’ve since clarified that the policy not only prohibits certs with bad data but also encourages use of private CAs for testing rather than developers registering their own domain and getting a real cert through the ordering process. However, I think this discussion raises some very interesting points about real world scenarios and RFC 5280 that should be addressed. DigiCert actually has three items that routinely show up on CABLint: 1) Use of teletext in strings (although this only occurs in re-issues/duplicates of previously issued certificates) Is this in the issuer field? Or in the subject information? I can understand if your issuer cert has this issue, but I don't think there's any good reason for this for the subject information. [JR] Subject field. However, this was mostly a mistake as it was fixed for all new certificates but permitted for entities replacing an existing certificate with teletext string. Should be remediated soon. 2) Too long of fields, primarily the O and OU fields 3) Use of underscore characters in certs -cut- I gotta admit, this sounds pretty disheartening. "We know we have issues, we've known about them for a while, but we've kept doing it, because we don't think it's a big deal, and everyone else is doing it". The BRs, in part, exist to avoid that judgement call, because we see time and time again where CAs are making that judgement call and it's not ending well. If you don't think it belongs, then why not propose BR changes? If you don't think it's important, then why not propose root policy changes? [JR] If you recall, I did try to change the policy. I was told to change the RFC if I didn’t like the requirement. I find trying to change the RFC nearly impossible as PKIX is dead and there are too many other issues people would also like to change. I appreciate the effort towards only 169 validation methods, but how are we, the relying parties, supposed to know that DigiCert won't, say, deprioritize following the BRs on that because y'all decide it's not a big security issue, and instead want to focus on a new product offering, since (besides whatever revenue benefit it might have), it gets more sites on HTTPS? As for other CAs, shouldn't you be making sure your house is in order first? :) But also, if there are other issues, shouldn't you be pushing for greater disclosure and transparency? We constantly see this correlation between smoke and fire - and if you're seeing smoke, don't you think it should be raised? [JR] Fair point, and I think the issues should be raised (including ours – which is why I raised the other issues in response to this post). I didn’t really think of the listed reasons as excuses, more an explanation as to what our current cablint issues are and why we haven’t resolved all of them yet. We do have most of them on the roadmap, and this discussion has helped prioritize some of them higher 😊 The discussion also raises an interesting question of when issues become significant enough they need to be addressed on the Mozilla list or require revocation. For example, one of our cross-signed partners issued a large number of certificates that lacked the proper OID. Should each of these certs warrant a discussion and separate revocation decision? Discuss the problem - not the certificates. Discuss what you're doing to address the problem. What caused the issue. How many certificates did it affect? What steps are you taking? When will those be complete? [JR] The issue is already remedied and was logged as a bug with Mozilla. However, the number of certificates that required revocation and replacement seemed like a waste considering the certificates omitted an OID. Looking back, perhaps we can discuss whether some of these “mis-issues” really warrant a revoke and replace mechanism rather than simply disclosure to Mozilla and a discussion on what to do. Seems like a waste to throw all of those certs on a CRL when they function properly with browser software. Perhaps a better process than “disclose and replace” would be “disclose, discuss, and replace if necessary”. That way issues such like missing O field wouldn’t be so cost heavy on the revocation side.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
