They are not currently logged to CT (because they were supposed to be code signing certificates). We can add them to our log though.
Jeremy From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Tuesday, April 18, 2017 10:22 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificate issues On Tue, Apr 18, 2017 at 12:09 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Hi everyone, On Friday at 1:00 pm, we accidently introduced a bug into our issuance system that resulted in five serverAuth-code signing certificates that did not comply with the Baseline Requirements. The change modified a handful of code signing certificates into a pseudo- SSL profile. Because they were intended to be code signing certificates, the certificates issued off a code-signing intermediate (with code-signing as the sole EKU). The certificates contain a servauth EKU despite the intermediate's EKU restriction. The certificates also lack a domain name. Instead, the CN and dNSName include the code signing applicant's name. Because the certs lack a domain name and there is an EKU mismatch between the issuer and end entity certs, the certs can't be misused. Our systems detected the issue shortly after the change. We corrected the code, and revoked the certificates. We already scanned our entire certificate database to ensure these are only the certificates affected by the bug. The certificates in question are: * 02CD2F16F3CA4FCC7378C917FFD5F6A0 * 09A88902AF0698841167E814DB8B3FB8 * 0D7C350D52821BFD2326270B9215DCE5 * 0356D3A74CFA29BB5E65569E0532F134 * 089FBE93D335ADB8BDFCDCF492083B68 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. Thanks, Jeremy Thanks for posting this, Jeremy. Are these certificates logged to Certificate Transparency? While not wanting to suggest I'm doubting you, being able to demonstrate that all intermediates they chain to are restricted from the serverAuth EKU is useful. I realize that's asking you to go above and beyond what you've disclosed so far. I think if/once we can add clarity to the Baseline Requirements regarding the scope, it would likely be clearer that these would be out of scope of the Baseline Requirements, and thus any such disclosure only be relative to root programs that recognize those paths as code-signing capable.
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
