Perhaps this is something we should clarify in the BRs or Mozilla
policy.  While I'm glad an actual cert was not issued in this case, it
is important to maintain consistency between precertificates and
certificates, if only for the CT logs tell a consistent story.

In particular, I would propose that in this case, the serial number of
the precertificate should be considered used and revoked, and that
status should be reflected in the CRL and OCSP.

Sent from my iPhone.  Please excuse brevity.

> On Mar 3, 2016, at 07:40, Jeremy Rowley <[email protected]> wrote:
>
> The RFC says "misissuance of a precertificate is considered equal to 
> misissuance of a final certificate". This raises an interesting question. Pre 
> certificates are not required to comply with the Cab forum's BRs as they fall 
> out of scope (not intended to be used for TLS authentication). Sha1 certs are 
> only considered misissued because the BRs say issuance of a SHA1 certificate 
> is prohibited. If the certificate is never issued, the misissuance never 
> occurred because the precertificate was not missused (no reqs against SHA1 
> precerts) and a certificate in violation of the BRs was never created.
>
>
> Rob Stradling <[email protected]> wrote:
>
>> On 03/03/16 04:52, [email protected] wrote:
>> On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
> <snip>
>>> I couldn't help but notice this SHA-1 precertificate issued by Symantec
>>> a couple of days ago:
>>> https://crt.sh/?id=13407116&opt=cablint
> <snip>
>> Rob,
>
> Sanjay, thanks for investigating.
>
>> This was a pre-certificate. Our systems do not allow issuance of SHA-1 
>> certificates and no certificate was issued.
>
> Were you aware that RFC6962 says that "misissuance of the Precertificate
> is considered equal to misissuance of the final certificate"?
>
>> The pre-certificate was logged but then rejected. We are still investigating.
>
> What do you mean by "...but then rejected"?
>
> Serial number 64:a9:32:73:a4:19:d1:64:3f:6b:2d:a3:ca:97:f0:89 is not
> currently listed on the CRL.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to