(Possible) DigiCert EV Violation
The EV Guidelines require certificates issued for .onion include the cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of these certificates. This is required by Section 11.7.1 (1) of the EV Guidelines, reading: "For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant’s control over the .onion Domain Name in accordance with Appendix F. " The intent was to prevent collisions in .onion names due to the use of a truncated SHA-1 hash collision with distinct keys, as that would allow two parties to respond on the hidden service address using the same key. Last week, a SHA-1 collision was announced. In examining the .onion precertificates DigiCert has logged, available at https://crt.sh/?q=facebookcorewwwi.onion , I could not find a single one bearing this extension, which suggests these are all misissued certificates and violations of the EV Guidelines. During a past discussion of precertificates, at https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ , Mozilla did not discuss whether or not it considered precertificates misissuance, although one module peer (hi! it's me!) suggested they were. This interpretation seems consistent with the discussions during the WoSign issues, as some of those certificates examined were logged precertificates. Have I missed something in examining these certificates? Am I correct that they appear to be violations? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: (Possible) DigiCert EV Violation
On Mon, Feb 27, 2017 at 1:41 PM, Ryan Sleevi via dev-security-policy wrote: > The EV Guidelines require certificates issued for .onion include the > cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of > these certificates. This is required by Section 11.7.1 (1) of the EV > Guidelines, reading: "For a Certificate issued to a Domain Name with .onion > in the right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant’s control over the .onion > Domain Name in accordance with Appendix F. " I don't see anything requiring this extension to be included in certificates. (hat tip to Andrew Ayer for noticing the lack of requirement) > The intent was to prevent collisions in .onion names due to the use of a > truncated SHA-1 hash collision with distinct keys, as that would allow two > parties to respond on the hidden service address using the same key. > > Last week, a SHA-1 collision was announced. > > In examining the .onion precertificates DigiCert has logged, available at > https://crt.sh/?q=facebookcorewwwi.onion , I could not find a single one > bearing this extension, which suggests these are all misissued certificates > and violations of the EV Guidelines. > > During a past discussion of precertificates, at > https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ > , Mozilla did not discuss whether or not it considered precertificates > misissuance, although one module peer (hi! it's me!) suggested they were. > > This interpretation seems consistent with the discussions during the WoSign > issues, as some of those certificates examined were logged precertificates. > > Have I missed something in examining these certificates? Am I correct that > they appear to be violations? > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: (Possible) DigiCert EV Violation
I was just going to respond with something similar. Appendix F: "A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DERencoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output." The requirements don't specify what to do with this information. I know our product team interpreted this as part of the validation methods and exchange of key information, not something that was included in a certificate. We can include this information, but the guidelines are unclear what we do with this. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Peter Bowen via dev-security-policy Sent: Monday, February 27, 2017 3:12 PM To: Ryan Sleevi Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: (Possible) DigiCert EV Violation On Mon, Feb 27, 2017 at 1:41 PM, Ryan Sleevi via dev-security-policy wrote: > The EV Guidelines require certificates issued for .onion include the > cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of > these certificates. This is required by Section 11.7.1 (1) of the EV > Guidelines, reading: "For a Certificate issued to a Domain Name with .onion > in the right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant’s control over the .onion > Domain Name in accordance with Appendix F. " I don't see anything requiring this extension to be included in certificates. (hat tip to Andrew Ayer for noticing the lack of requirement) > The intent was to prevent collisions in .onion names due to the use of a > truncated SHA-1 hash collision with distinct keys, as that would allow two > parties to respond on the hidden service address using the same key. > > Last week, a SHA-1 collision was announced. > > In examining the .onion precertificates DigiCert has logged, available at > https://crt.sh/?q=facebookcorewwwi.onion , I could not find a single one > bearing this extension, which suggests these are all misissued certificates > and violations of the EV Guidelines. > > During a past discussion of precertificates, at > https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ > , Mozilla did not discuss whether or not it considered precertificates > misissuance, although one module peer (hi! it's me!) suggested they were. > > This interpretation seems consistent with the discussions during the WoSign > issues, as some of those certificates examined were logged precertificates. > > Have I missed something in examining these certificates? Am I correct that > they appear to be violations? > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ 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
Re: (Possible) DigiCert EV Violation
On Mon, Feb 27, 2017 at 2:19 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The requirements don't specify what to do with this information. I know > our product team interpreted this as part of the validation methods and > exchange of key information, not something that was included in a > certificate. We can include this information, but the guidelines are > unclear what we do with this. Yeah, let's fix this in the EVGs over in the CA/Browser Forum. As you know from our private and public conversations, Jeremy, Google's support for allowing this issuance was contingent upon that extension appearing within the certificate, as that was the only mitigation .onion owners had to detect different-key, same-name collisions. It was this property - the combined implicit logging (due to Chrome's CT policy, although not explicitly required of CAs) and explicit extension that provided the safety bar for sites. This is also why we pushed for the revocation of the existing certs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: (Possible) DigiCert EV Violation
On 27/02/17 21:41, Ryan Sleevi wrote: > During a past discussion of precertificates, at > https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ > , Mozilla did not discuss whether or not it considered > precertificates misissuance, although one module peer (hi! it's me!) > suggested they were. On this particular point, the CT RFC says that issuing a pre-certificate is a binding statement of intent to issue the certificate. Therefore, for example, one can exempt the cert itself from CAA checking if the pre-cert was checked. Therefore, I would say that we do consider mis-issued pre-certs as misissuance. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy