This is interesting. We had one Sub CA who mis-issued some pre-certs but then never issued an actual certificate tied to the pre-certificate. There was a previous Mozilla discussion (link coming) where mis-issuance of a pre-certificate was akin to mis-issuance of the certificate itself. The pre-certificates were later revoked at our request. If no actual certificate issued, the pre-cert falls out of scope of the BRs right? Since it can't be used for actual server transactions thanks to the poison extensions? Obviously they still fall within the Mozilla policy as they contain serverAuth in the EKU. However, should they be reported as issues and should they be revoked in accordance with the BR?
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Nick Lamb via dev-security-policy Sent: Thursday, August 10, 2017 10:44 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Misissued certificates On Thursday, 10 August 2017 16:55:22 UTC+1, iden...@gmail.com wrote: > certificates contain the issue. Three (3) of these are real > certificates; however, one has expired. We have revoked the other two > certificates. The remaining two (2) are pre-certificates. To clear this up for anybody who didn't go look: They're specifically pre-certificates _for_ the other two certificates, so there is nothing further here that could be revoked. And as Ryan writes, what we'd want to see here in m.d.s.policy isn't revocations (though those are required by the BRs anyway so we do expect them) but an investigation of what went wrong and a summary of what was done to ensure we won't be back here reading about the same problems at the same CAs. Like an Accident Investigator my focus is not on "punishing the guilty" but on the Prevention of Future Harm. We can't undo the fact that a certificate was mis-issued, but we can try to reduce the number of future mis-issuances by learning from past mistakes and putting in place technologies, policies and practices that avoid mis-issuance in the future. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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
