Re: (Possible) DigiCert EV Violation

[Ryan Sleevi via dev-security-policy]

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

[Jeremy Rowley via dev-security-policy]

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

[Peter Bowen via dev-security-policy]

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

(Possible) DigiCert EV Violation

[Ryan Sleevi via dev-security-policy]

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: Suspicious test.com Cert Issued By GlobalSign

[Gervase Markham via dev-security-policy]

Hi Doug,

On 15/02/17 17:09, Gervase Markham wrote:
> But currently GlobalSign employees still are?
> 
> If so, can you help us understand why that's necessary? Given that you
> control the domains used for testing, you should be able to set them up
> to auto-pass some form of automated validation, so imposing a validation
> requirement for every addition would not, at least on a superficial
> understanding, lead to increased friction in testing.

It's been quite some time since this question was posed; when might you
have a response?

Thanks,

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign BR violation

[Nick Lamb via dev-security-policy]

On Monday, 27 February 2017 00:53:46 UTC, Itzhak Daniel  wrote:
> How those lines are parsed? what happens when a client reaches a whitespace? 
> Will this allow 'vietnamairlines.com' to use 'owa', 'mail' and 'autodiscover' 
> in their internal infrastructure?

Because they're dnsNames a correctly implemented TLS client needn't "parse" 
them further at all, either they are an exact case-insensitive match for the 
server's DNS name or they aren't.

On the other hand apparently we can't even rely on a CA to get this right, so 
who knows if any clients get it wrong.

The naming on this certificate suggests it was requested for use with 
Microsoft's Exchange product, so assuming Microsoft's Internet Explorer / Edge 
web browser, and their Outlook mail client get this right the certificate was 
probably simply useless as issued. It /is/ interesting that the subscriber had 
a previous certificate for the valid set of names, and today the 
https://owa.vietnamairlines.com/ server (OWA stands for "Outlook Web Access" ie 
it's a web UI for the mail service) is serving a wildcard from someone else, so 
perhaps the subscriber concluded GlobalSign were hopeless and stopped using 
them? I hope they got their money back.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy