RE: TLS-SNI-01 and compliance with BRs

-policy Sent: tirsdag 23. januar 2018 23:12 To: Ryan Sleevi <r...@sleevi.com> Cc: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman <mharde...@gmail.com>; Alex Gaynor <agay...@mozilla.com> Subject: Re: TLS-SNI-01 and com

Re: TLS-SNI-01 and compliance with BRs

On Sat, Jan 20, 2018 at 1:07 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Based on this, do we need a ballot to remove them from the BRs, or put in > > a statement in them to the effect that they can be used only if approved > by > > Google on

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 3:58 PM Doug Beattie wrote: > Matthew, > > > > That’s a good summary. It seems we have 2 methods that can be used only > if the CAs using the methods have the design and risk mitigation factors > reviewed and approved. It’s basically the

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 11:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > For a certificate capable of being used for SSL-enabled servers, the CA > must ensure that the applicant has registered the domain(s) referenced in > the certificate or has

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 1:58 PM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Given this discussion, there must be no other CAs using method 9 or 10, > else they would have come forward by now with disclosures and have > demonstrated their compliance..

Re: TLS-SNI-01 and compliance with BRs

Peter, On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What does Mozilla expect to be verified? We know the 10 methods allow > issuance where "the applicant has registered the domain(s) referenced in > the certificate or

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 2:58 PM, Doug Beattie wrote: > Matthew, > > > > That’s a good summary. It seems we have 2 methods that can be used only > if the CAs using the methods have the design and risk mitigation factors > reviewed and approved. It’s basically the

RE: TLS-SNI-01 and compliance with BRs

eat...@globalsign.com> Cc: r...@sleevi.com; Alex Gaynor <agay...@mozilla.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: TLS-SNI-01 and compliance with BRs One opinion I'd like to add to the discussion... In as far as that at this point, it looks like it's time for guidance fr

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 1:44 PM, Matthew Hardeman wrote: > Ultimately, if it should arise that other CAs who rely on mechanisms > implementing or claiming to implement method #10 have similar risk and > vulnerabilities, those CAs should be called to task for not having

Re: TLS-SNI-01 and compliance with BRs

One opinion I'd like to add to the discussion... In as far as that at this point, it looks like it's time for guidance from the root programs officially on whether or not and under what circumstances TLS-SNI-01 and/or any other mechanism based on method #10 are allowable moving forward I'd

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 9:22 AM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think we’ve gotten off track. While the general discussion is good and > we need to update the validation methods to provide more precise details, I > want to get back to

Re: TLS-SNI-01 and compliance with BRs

Gaynor <agay...@mozilla.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: TLS-SNI-01 and compliance with BRs I think others have already responded, but I do want to highlight one other problem with the reasoning being offered here: SNI is not mandatory in TLS. It's an extensi

Re: TLS-SNI-01 and compliance with BRs

> On Jan 19, 2018, at 7:22 AM, Doug Beattie via dev-security-policy > wrote: > > Many CA’s haven’t complied with the Mozilla requirement to list the methods > they use (including Google btw), so it’s hard to tell which CAs are using > method 10. Of

Re: TLS-SNI-01 and compliance with BRs

Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Thursday, January 18, 2018 7:25 PM > *To:* Doug Beattie <doug.beat...@globalsign.com> > *Cc:* Alex Gaynor <agay...@mozilla.com>; mozilla-dev-security-policy@ > lists.mozilla.org > > *Subject:* Re: TLS-SNI-01 and compliance with BRs

RE: TLS-SNI-01 and compliance with BRs

, January 18, 2018 7:25 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: Alex Gaynor <agay...@mozilla.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: TLS-SNI-01 and compliance with BRs I think others have already responded, but I do want to highlight one ot

RE: TLS-SNI-01 and compliance with BRs

zilla.org] On Behalf Of J.C. Jones > via dev-security-policy > Sent: Thursday, January 18, 2018 3:34 PM > To: Matthew Hardeman <mharde...@gmail.com> > Cc: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security- > pol...@lists.mozilla.org; Alex Gaynor <agay...

Re: TLS-SNI-01 and compliance with BRs

That would be the right place. At the time there was not universal desire for these validation mechanisms to be what I'd call 'fully specified'; the point of having them written this way was to leave room for individuality in meeting the requirements. Of course, having a few

Re: TLS-SNI-01 and compliance with BRs

As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked through it in the Validation Working Group. The ADN lookup is DNS, and what you find when you connect there via TLS, within the certificate, should be the random value (somewhere). 3.2.2.4.10 was written to permit ACME's

Re: TLS-SNI-01 and compliance with BRs

The trouble is that the BRs for those methods are really really vague. I don't know that one can make a stronger case for misissuance versus properly issued in these cases. I'm certainly no fan of the mechanism in TLS-SNI-01 and regard it deficient in the face of real world deployment

Re: TLS-SNI-01 and compliance with BRs

I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01 performs a DNS lookup for the ADN, connects to that IP, and initiatives a TLS connection with the .acme.invalid SNI value. Certificates don't exist on Domain Names if we think really hard about it, but servers with IPs that

TLS-SNI-01 and compliance with BRs

Now that I'm more familiar with method 9 and 10 domain validation methods and heard a few side discussions about the topic, it's made me (and others) wonder if the ACME TLS-SNI-01 is compliant with BR Method 10. The BRs say: 3.2.2.4.10. TLS Using a Random Number Confirming the Applicant's