urity-policy
Sent: tirsdag 23. januar 2018 23:12
To: Ryan Sleevi
Cc: Doug Beattie ;
mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman
; Alex Gaynor
Subject: Re: TLS-SNI-01 and compliance with BRs
On Sat, Jan 20, 2018 at 1:07 AM, Ryan Sleevi via dev-security-policy <
dev-securit
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 this
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 old “any other method”, except
>
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 be
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..
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 h
I concur that framing as reward versus punishment was not right.
No where did I meant to imply that early actors should get a free pass in
as far as continuing unmitigated validation using a vulnerable validation
method.
The early discoverers and those who reacted early to the vulnerability and
s
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 old “any other method”, except
...@sleevi.com; Alex Gaynor ;
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 from the
root programs officially on whether or not and
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 timely
> disclosed and reme
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 li
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 th
ev-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 extension (RFC 6066) that is optional.
More co
> 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 the CA CPSs I checked, only Symantec has m
_any_ use of the .9
and .10 methods, and then evaluate on a case by case basis the mitigating
factors and risks that may necessitate a gradual phase out on a per-CA
basis.
>
>
> [1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2
>
>
>
>
>
> *From:* Ryan S
: Thursday, January 18, 2018 7:25 PM
To: Doug Beattie
Cc: Alex Gaynor ;
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
ozilla.org] On Behalf Of J.C.
Jones
> via dev-security-policy
> Sent: Thursday, January 18, 2018 3:34 PM
> To: Matthew Hardeman
> Cc: Doug Beattie ; mozilla-dev-security-
> pol...@lists.mozilla.org; Alex Gaynor
> Subject: Re: TLS-SNI-01 and compliance with BRs
>
> That
ddress). It seems like misissuance to me.
>
>
> From: Alex Gaynor [mailto:agay...@mozilla.com]
> Sent: Thursday, January 18, 2018 3:47 PM
> To: Doug Beattie
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: TLS-SNI-01 and compliance with BRs
>
> I guess it
> I would presume that the CABforum would be the place to explore further
> details, but it seems that the specifications for the #10 method should be
> reexamined as to what assurances they actually provide with a view to
> revising those specifications. At least 1 CA so far has found that the
>
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 carefully-specified-an
On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
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
TLS
On Thu, Jan 18, 2018 at 2:47 PM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Certificates don't exist on Domain Names if we think really hard about it,
> but servers with IPs that domain names point to can serve certificates, and
> that seems like a reas
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 circumstanc
IP address). It
seems like misissuance to me.
From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, January 18, 2018 3:47 PM
To: Doug Beattie
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: TLS-SNI-01 and compliance with BRs
I guess it depends how you define
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 d
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 contro
27 matches
Mail list logo
