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
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, August 10, 2017 10:44 AM
Subject: Re: Misissued certificates

On Thursday, 10 August 2017 16:55:22 UTC+1,  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

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to