If you recall, the fact that pre-certs are out of scope of the BRs was one of the reasons against putting them into the BRs in the first place. The decision to add them was to assist CAs who may have an overly strict reading on scope considering the very loose language originally used: "These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet." The fact the BRs mention a document out of scope is not evidence of an intent to include them given the history of that particular language.
Other comments: "CT assists with "authenticating servers accessible through the Internet", because it helps detect misissued certs. When CT is enforced, you can have increased confidence that the server you've connected to is indeed "authentic"." - Intending to assist is NOT the same thing as actually intending to authenticate servers accessible through the Internet. "I think it's clear that precertificates _are_ "intended to be used for authenticating servers accessible through the Internet" and that they are in-scope for the BRs." - Completely disagree. I think it's clear they are NOT in scope... but I would (as always) support a ballot to fix this. The BR scope is terrible and really should be remedied. It's been a plague for over a year. I'm 100% supportive of any proposal to include precerts and fix the language, but, given the current wording, I don't agree that Symantec violated any rule the Forum has set. -----Original Message----- From: Rob Stradling [mailto:[email protected]] Sent: Thursday, March 3, 2016 2:49 PM To: Jeremy Rowley Cc: [email protected]; [email protected] Subject: Re: More SHA-1 certs On 03/03/16 15:39, Jeremy Rowley 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). Jeremy, I have to disagree with you on that point. The BRs say... "7.1.2.5 Application of RFC 5280 For purposes of clarification, a Precertificate, as described in RFC 6962 - Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements." Precertificates must be in scope (for the BRs) for it to be within the BRs' remit to declare them to be out of scope for RFC5280! CT assists with "authenticating servers accessible through the Internet", because it helps detect misissued certs. When CT is enforced, you can have increased confidence that the server you've connected to is indeed "authentic". I think it's clear that precertificates _are_ "intended to be used for authenticating servers accessible through the Internet" and that they are in-scope for the BRs. > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
