My fix is much simpler (because the BRs have traditionally avoided requiring reissuance of sub CAs). Require that all certs with serverauth, anyEKU, or no EKU be covered by the BRs. CAs required to issue certs that are covered but cannot conform (because of another policy) will get a qualified audit that can then be addressed with the browsers. There's no reason to make an exception since all three types can be used for server authentication. This gives everyone notice the CA is issuing non-compliant certs that may be risky but lets the browsers decide whether to accept the risk.
-----Original Message----- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Friday, March 4, 2016 2:20 PM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org; sanjay_m...@symantec.com Subject: Re: More SHA-1 certs On 04/03/16 04:18, Jeremy Rowley wrote: > 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. Neither certificates nor precertificates authenticate servers. Signed blobs of data don't do anything! It's the TLS client code that actually authenticates the server. So, IMHO, if precertificates are out of scope, then certificates are out of scope too. > "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... We'll have to agree to disagree then. > but I would (as always) support a ballot to fix this. The BR scope is > terrible and really should be remedied. +1. Let's make it so that there's no reason to disagree! > It's been a plague for over a year. I'm 100% supportive of any > proposal to include precerts and fix the language, IIRC, all previous proposals for fixing the BR scope have focused on features of the end-entity certificate profile. That's proved to be problematic, because some CAs want/need to issue certs that could technically be used for server authentication even though that's not the intent (e.g. Subject.CN is included and EKU is required to be anyEKU). Maybe we need to take a different approach that ignores the end-entity certificate profile completely. How about we propose that... - An X.509 certificate is in scope for the BRs if it's signed by an Issuing CA that is in scope. - An Issuing CA is in scope if: i) it chains to a Root Certificate that is trusted for server authentication and ii) there's no EKU "constraint" in that chain that excludes server authentication. and iii) it hasn't been whitelisted by browsers as "out of scope". ? > but, given the current wording, I don't agree that Symantec violated any rule > the Forum has set. > > -----Original Message----- > From: Rob Stradling [mailto:rob.stradl...@comodo.com] > Sent: Thursday, March 3, 2016 2:49 PM > To: Jeremy Rowley > Cc: mozilla-dev-security-pol...@lists.mozilla.org; sanjay_m...@symantec.com > 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 <rob.stradl...@comodo.com> wrote: >> >> On 03/03/16 04:52, sanjay_m...@symantec.com 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 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
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
