Hi Jeremy Given the small number of certificates involved, it might make sense to just convert them to text and mention them inline, or put them somewhere we can all see them - if it's inconvenient to put them into the CT logs.
I think this situation will be useful as evidence of the value of not putting all ones eggs in one basket when it comes to subCA EKUs. If these had come from a subCA which wasn't constrained, we'd have a bigger (though at five specific certificates still manageable) issue. On Tuesday, 18 April 2017 17:10:39 UTC+1, Jeremy Rowley wrote: > The bug was introduced, ironically, in code we deployed to detect potential > errors in cert profiles. This error caused the specified code signing > certificates to think they needed dNSnames and serverAuth. Let me know if > you have questions. This irony might perhaps have been avoided if the code in question didn't have permission (never mind intent) to alter anything. I appreciate that what one would ideally like is to never issue a bad certificate, and to achieve that any checks must happen in a trusted part of the system. But it seems to me that there's a good deal of benefit, at practically zero risk, in building tooling that focuses on monitoring stuff which has already been signed, outside of the protected signing environment; and only subsequently after proving it there giving it the earlier, more powerful (and thus risky) role. Of course I know nothing of your specific circumstances, this is just a general observation about how I think I'd approach the question of improving issuance quality with minimal risk. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
