RE: TLS-SNI-01 and compliance with BRs

[Mads Egil Henriksveen via dev-security-policy]

Hi Wayne

Buypass has used the TLS-SNI-01 method in our ACME Pilot running since last 
summer. We have issued some certificates using this method - less than 60 
certificates are still active and not revoked, most of them are issued to 
internal users and systems. 

We stopped using this method  immediately when notified by Let's Encrypt on 
January 10th and we have not used the method since.

Regards
Mads 



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+mads.henriksveen=buypass...@lists.mozilla.org]
 On Behalf Of Wayne Thayer via dev-security-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 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 this list?  I’m not picking on Ryan, but he’s the only 
> > root program representative that has expressed strong views on what 
> > is
> permitted
> > and what is not (else you have your CA revoked or root pulled from 
> > the program).
> >
>
> As Wayne has pointed out, CAs participating within the Mozilla program 
> are expected to be following this list.
>
> That said, in my past messages regarding .9 and .10, I thought it was 
> rather clear we’d like to see these methods removed if the community 
> is unable to make progress in securing them, such that the limited 
> exceptions can be removed and all can use them.
>
> Mozilla's position is as follows:

Given that the specific vulnerabilities present in BR 3.2.2.4 methods .9 and 
.10 were reported nearly two weeks ago, Mozilla's minimum expectation is that 
all CAs using either method have disclosed that fact and have described their 
response on this list. Any CA that has not is now requested to do so 
immediately. Currently, Mozilla views new or continued use of these methods for 
domain validation to be misissuance unless the CA has first implemented and 
disclosed an appropriate mitigation for the known vulnerabilities. While 
Mozilla is open to strengthening these methods, CAs are strongly discouraged 
from using them and are encouraged to migrate away from them until such 
improvements are vetted and standardized by the CA/Browser Forum.

Note: Please recognize that Mozilla's position applies to our own CA Program 
and in no way changes or overrides earlier statements made by Ryan representing 
Chrome on this list.

I have added issue #116 to the PKI Policy repository [1] to consider removing 
methods 1, 5, 9, and 10 from a future version of the root store policy.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues
___
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: TLS-SNI-01 and compliance with BRs

[Wayne Thayer via dev-security-policy]

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 list?  I’m not picking on Ryan, but he’s the only root
> > program representative that has expressed strong views on what is
> permitted
> > and what is not (else you have your CA revoked or root pulled from the
> > program).
> >
>
> As Wayne has pointed out, CAs participating within the Mozilla program are
> expected to be following this list.
>
> That said, in my past messages regarding .9 and .10, I thought it was
> rather clear we’d like to see these methods removed if the community is
> unable to make progress in securing them, such that the limited exceptions
> can be removed and all can use them.
>
> Mozilla's position is as follows:

Given that the specific vulnerabilities present in BR 3.2.2.4 methods .9
and .10 were reported nearly two weeks ago, Mozilla's minimum expectation
is that all CAs using either method have disclosed that fact and have
described their response on this list. Any CA that has not is now requested
to do so immediately. Currently, Mozilla views new or continued use of
these methods for domain validation to be misissuance unless the CA has
first implemented and disclosed an appropriate mitigation for the known
vulnerabilities. While Mozilla is open to strengthening these methods, CAs
are strongly discouraged from using them and are encouraged to migrate away
from them until such improvements are vetted and standardized by the
CA/Browser Forum.

Note: Please recognize that Mozilla's position applies to our own CA
Program and in no way changes or overrides earlier statements made by Ryan
representing Chrome on this list.

I have added issue #116 to the PKI Policy repository [1] to consider
removing methods 1, 5, 9, and 10 from a future version of the root store
policy.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Ryan Sleevi via dev-security-policy]

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
> before you can use it, the Root programs must review the
> design/implementation and can approve/reject them on a case by case basis.
> Is that where we are with these methods – Not approved unless disclosed and
> reviewed?
>

I think it’s a large leap to go from a potentially
vulnerable/underspecified method to “any other”. It seems you’re ignoring
that .6 and .8 share the same specificity (or lack thereof), or that
GlobalSign is apparently opposed to the removal of .5 and .1, which very
much are insecure in all forms.

I suspect if we are looking to improve security, removing .1 and .5 will go
much further, and much less risk.


> 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..  Maybe we need to post this on the CABF
> public list?
>
>
>
> 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 list?  I’m not picking on Ryan, but he’s the only root
> program representative that has expressed strong views on what is permitted
> and what is not (else you have your CA revoked or root pulled from the
> program).
>

As Wayne has pointed out, CAs participating within the Mozilla program are
expected to be following this list.

That said, in my past messages regarding .9 and .10, I thought it was
rather clear we’d like to see these methods removed if the community is
unable to make progress in securing them, such that the limited exceptions
can be removed and all can use them.

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

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

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 been authorized by the domain registrant to act on
> their behalf. This must be done using one or more of the 10 methods
> documented in section 3.2.2.4 of version 1.4.1 (and not any other version)
> of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly
> specify the procedure(s) that the CA employs, and each documented procedure
> should state which subsection of 3.2.2.4 it is complying with. Even if the
> current version of the BRs contains a method 3.2.2.4.11, CAs are not
> permitted to use this method.”
>
> While this clearly does call out that the methods are acceptable, it isn’t
> a results oriented statement.  The BRs also do not have clear results
> requirements for validation methods.
>
> 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 has been authorized by the domain registrant to act on
> their behalf” is not true.
>
>
I also think it may make sense for the root program policy to illuminate
specifically the nature and parameters of a successful outcome.

Maybe it's something like:

The validation is properly achieved when it 1) aligns to one of the
permitted BR validation mechanisms AND 2) successfully achieves the various
other goals that the program has.  Things like "provides reasonable
assurance that the issuance will be granted only to a party demonstrating
ownership or effective control of the related domain".

It's not clear today, absent further guidance, that the Mozilla root
program policy would call on a CA to preemptively stop utilizing a
compromised mechanism which is BR compliant prior to change of the BR.  If
the program were changed such that one of the outcomes to be considered at
the time of the validation is that the CA, via technical means, has strong
assurance that the issuance is to a party owning or controlling the domain
in question, then a publication of a vulnerability over a certain
validation method would certainly strike the CA's confidence in that
assertion and so guide that the validation can not be considered proper for
reliance for issuance.

Incorporating intended outcomes of the policies related to validation and
issuance pursuant to validations may be helpful in providing a default,
"automatic" guidance on how to handle an emerging vulnerability of a
previously acceptable method.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Wayne Thayer via dev-security-policy]

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..  Maybe we need to post this on the CABF
> public list?
>
> Just a reminder that Mozilla policy requires CAs to monitor this list. And
yes I would hope that any other CAs using this method would have disclosed
that fact and their response by now.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Wayne Thayer via dev-security-policy]

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 has been authorized by the domain registrant to act on
> their behalf” is not true.
>
> Will you describe a few examples of this?

I think the next step should be for Mozilla to clearly lay out the
> requirements for CAs and then the validation methods can be compared to see
> if they met the bar.
>
> Are you asking Mozilla to clarify these two potentially contradictory
statements in our policy? Or something more?

Thanks,

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

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

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
> before you can use it, the Root programs must review the
> design/implementation and can approve/reject them on a case by case basis.
> Is that where we are with these methods – Not approved unless disclosed and
> reviewed?
>
>
I wouldn't necessarily go that far as yet.  The only ones who can speak to
that are the root programs.  The limited guidance available so far suggests
that they won't tolerate perverse consequences to continue even if the
method is BR compliant.  Certainly, there would be no shortage of
supporters for removal of the #9 and #10 methods as written.



>
>
> 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..  Maybe we need to post this on the CABF
> public list?
>

One would think there must be no others.  In the alternative, someone is
dilatory.


>
>
> 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 list?  I’m not picking on Ryan, but he’s the only root
> program representative that has expressed strong views on what is permitted
> and what is not (else you have your CA revoked or root pulled from the
> program).
>
>
>

Therein is the real question.  If we go with the assumption that the
vulnerable methods are in fact BR compliant, someone should probably fix
the BRs.  More urgently, perhaps the root programs should all issue
guidance on acceptability of these methods or mitigations over the
methods.  The obvious safe leap of logic to make is to assume in the most
securely constrained light: that all the root programs reject the mechanism
underlying a method which has significant demonstrable holes when applied
in the real world.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: TLS-SNI-01 and compliance with BRs

[Doug Beattie via dev-security-policy]

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 before you can 
use it, the Root programs must review the design/implementation and can 
approve/reject them on a case by case basis.  Is that where we are with these 
methods – Not approved unless disclosed and reviewed?

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..  Maybe we need to post this on the CABF public list?

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 list?  I’m not picking on Ryan, but he’s the only root program 
representative that has expressed strong views on what is permitted and what is 
not (else you have your CA revoked or root pulled from the program).

Doug

From: Matthew Hardeman [mailto:mharde...@gmail.com]
Sent: Friday, January 19, 2018 1:45 PM
To: Doug Beattie <doug.beat...@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 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 like to point out that both Let's Encrypt recognized an issue and 
voluntarily disclosed and took measures in the direction of securing the WebPKI 
above and beyond any demands made of them.

Additionally, GlobalSign was obviously diligent in their responsibility to 
monitor this mailing list and others and actively discern whether any ongoing 
discussion may pertain to their operations.  As evidenced by their preemptive 
disclosure and shut down of their method #10 validation mechanism, they've 
shown strong adherence to the best practices espoused by this community -- 
actively monitoring the broad discussions and concerns and actively considering 
the impact of the issues surfaced in terms of their own CA operations.

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 remediated.  Further, perhaps those CAs should suffer the burden 
of mandatory revalidation under a different mechanism, as the vulnerability 
category has now been acknowledged in the community for some time and the 
recent press has been significant.

In contrast, I think any remediation plan should reward Let's Encrypt and 
GlobalSign for their diligence and compliance to best practice.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Ryan Sleevi via dev-security-policy]

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 remediated.  Further, perhaps those CAs should suffer the
> burden of mandatory revalidation under a different mechanism, as the
> vulnerability category has now been acknowledged in the community for some
> time and the recent press has been significant.
>
> In contrast, I think any remediation plan should reward Let's Encrypt and
> GlobalSign for their diligence and compliance to best practice.
>

I disagree with this notion of 'rewarding' some CAs by letting the first to
disclose be allowed to continue to use methods that put users at risk.
Global user trust is not a 'reward', and removing that trust is not a
'punishment' - it is a calculation of risks based on available and
mitigating factors.

Framing it as 'reward' or 'punishment' unduly manipulates the discussion,
because it suggests the notion of favorability / unfavorability, when the
reality is that it's an objective evaluation across a multitude of
dimensions.

Should those who have not come forward be called to task? Yes. Because
they're ignoring industry best practice and they should revoke all of their
certs due to the 'unacceptable risk' clause. That's not a punishment.
That's mitigation based on the available information (i.e. none, for those
that didn't self-disclose)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

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 like to point out that both Let's Encrypt recognized an issue and
voluntarily disclosed and took measures in the direction of securing the
WebPKI above and beyond any demands made of them.

Additionally, GlobalSign was obviously diligent in their responsibility to
monitor this mailing list and others and actively discern whether any
ongoing discussion may pertain to their operations.  As evidenced by their
preemptive disclosure and shut down of their method #10 validation
mechanism, they've shown strong adherence to the best practices espoused by
this community -- actively monitoring the broad discussions and concerns
and actively considering the impact of the issues surfaced in terms of
their own CA operations.

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 remediated.  Further, perhaps those CAs should suffer the
burden of mandatory revalidation under a different mechanism, as the
vulnerability category has now been acknowledged in the community for some
time and the recent press has been significant.

In contrast, I think any remediation plan should reward Let's Encrypt and
GlobalSign for their diligence and compliance to best practice.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

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 the point in hand which is asking if the ACME
> TLS-SNO-01 method is compliant with method 10.  If method 10 specified that
> you could validate the random number at the same IP address as the SAN
> being validated, then it would have said that.  How does validating the
> “Random Value within a Certificate on the IP address of the Authorization
> Domain Name” comply with validating the “Random Value within a Certificate
> on the Authorization Domain Name”?  The TLS-SNI method specifically directs
> the CA to check for the random number on a location other than the ADN.
>
>
I think many parties have made quite clear that the level of description in
BR method #10 covers a lot of possibilities, but there is insufficient
technical description in the method to call TLS-SNI-01.  Indeed, it appears
from discussions prior that BR method #10 was engineered to incorporate
sufficient flexibility for TLS-SNI-01 as well as some other mechanisms.
Part of the trouble is "on the Authorization Domain Name" doesn't mean
anything specific.


>
> 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 method 10
> listed, and with the DigiCert acquisition, it’s not clear if that CPS is
> still active.  We should find out on January 31st who else uses it.
>
> In the meantime, we should ban anyone from using TLS-SNI as a
> non-compliant implementation, even outside shared hosting environments.
> There could well be other implementations that comply with method 10, so
> I’m not suggesting we remove that from the BRs yet (those that don’t allow
> SNI when validating the presence of the random number within the
> certificate of a TLS handshake are better)


I think reliance upon TLS-SNI-01 should cease in the general case.  The
cause for which it should be rejected is because reliance strictly upon
TLS-SNI-01 is clearly demonstrated to yield a perverse consequence:
issuance of certificates to parties other than those who should be able to
receive them.  However, there is simultaneously a quite reasonable argument
that the TLS-SNI-01 method is fully compliant with BR method #10.  This
means the deficiency is in BR method #10, not strictly in TLS-SNI-01.  I
would submit that if complying with BR method #10 were the sole goal,
TLS-SNI-01 achieved and continues to achieve that.  And yet, clearly
TLS-SNI-01 can not be used for trust in the real world.  In fact, as now
specified, BR method #10 can not be used for trust in the real world.

As to any mechanism of implementing BR method #10 without reliance on SNI,
there is an equally strong case to be made that not relying on SNI is
getting you a different web context in many shared hosting environments
than specifying the correct ADN in the SNI would.  That, in turn, is
equally capable of causing issuance to parties other than intended.  You
can not have it both ways.  If method #10 is violated by sending the wrong
SNI value, an equally good argument exists that sending no SNI value at all
is also in violation.  The fact of the matter is that method #10 specifies
none of this, so it's all fair game.  Because method #10 is a vacuous
one-liner, there can be no reasonable support for compliance/non-compliance
on a concept that method #10 does not even touch on.


>
> Regarding the comment on the ACME protocol: “The ACME specification is
> useful in it's the first attempt I'm aware of that attempts to fully,
> normatively specify how to validate assurances in an open and interoperable
> way.”  Yes, open review of the protocol was good.  As you are likely aware,
> the specification points out [1] vulnerabilities with the use of ACME by
> hosting providers “The use of hosting providers is a particular risk for
> ACME validation.”  It appears that the detailed analysis into these risks
> wasn’t performed or considered prior to using ACME.  If the analysis was
> done the risk mitigation wasn’t documented in spec.
>

I concur that the evidence strongly suggests that the ACME working group
did an insufficient job of researching and documenting realities in
real-world deployment of website hosting environments, which is
disingenuous for those building a protocol to secure the issuance of PKI
certificates whose overwhelmingly prevalent use is the authentication and
encryption of web site traffic.


>
>
> Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai,
> Cisco, EFF, OVH and Chrome) using TLS-SNI-01?  I only call them out because
> as large financial supports, they may be more incentivized to use it than
> others.
>

This question 

Re: TLS-SNI-01 and compliance with BRs

[Jakob Bohm via dev-security-policy]

The following discussion is only a sketched out idea and thus does not
classify all the 10 blessed methods:


One rule that could reasonably be added to the BR or Mozilla
requirements for the various methods could be this general safety rule:

- Validation methods that check control over a single address (such as
 certificate responses, well-known URLs etc.) are only valid for the
 single name validated, not as proof of domain control.  Thus they
 cannot be used to validate control of an entire DNS zone, and thus is
 not sufficient for preauthorizing certs for subdomains, nor for
 getting wildcard certificates.

So for example, TLS-SNI-01 at best validates control of the requested
DNS name, possibly only of the used acme.invalid name.

In contrast the GlobalSign certificate method (as summarized in previous
posts here, I have not validated their exact procedures) apparently
validates the response for a specific name as both A/ recond and SNI
name, and then takes this as proof of only that single name.  (There was
some talk of wildcard use, which would not be OK under the stricter rule
above).

Examples of automatic validation methods good enough for proving full
zone control, as needed for wildcard certs or preauthorizing further
issuance would be DNS control over the zone apex, being the registrant
listed in whois or receiving e-mails for hostmaster@zoneapex.example.

For e-mail certificates (no current BR rules, only root program specific
rules), ability to receive emails for exam...@example.com validates (at
class 1 level) control of that one e-mail address.  While control of
postmas...@example.com or hostmas...@example.com or the DNS for
example.com validates (at class 1 level) control of all @example.com
e-mail addresses unless example.com is on the e-mail equivalent of a
public-suffix list.  (Thus postmas...@hotmail.com can't get certificates
for all the users without directly violating the sanctity of the e-mail
accounts).


On 19/01/2018 16:22, Doug Beattie 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 the point in hand which is asking if the ACME TLS-SNO-01 method 
is compliant with method 10.  If method 10 specified that you could validate 
the random number at the same IP address as the SAN being validated, then it 
would have said that.  How does validating the “Random Value within a 
Certificate on the IP address of the Authorization Domain Name” comply with 
validating the “Random Value within a Certificate on the Authorization Domain 
Name”?  The TLS-SNI method specifically directs the CA to check for the random 
number on a location other than the ADN.


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 method 10 listed, and 
with the DigiCert acquisition, it’s not clear if that CPS is still active.  We 
should find out on January 31st who else uses it.

In the meantime, we should ban anyone from using TLS-SNI as a non-compliant 
implementation, even outside shared hosting environments.  There could well be 
other implementations that comply with method 10, so I’m not suggesting we 
remove that from the BRs yet (those that don’t allow SNI when validating the 
presence of the random number within the certificate of a TLS handshake are 
better).

Regarding the comment on the ACME protocol: “The ACME specification is useful 
in it's the first attempt I'm aware of that attempts to fully, normatively 
specify how to validate assurances in an open and interoperable way.”  Yes, 
open review of the protocol was good.  As you are likely aware, the 
specification points out [1] vulnerabilities with the use of ACME by hosting 
providers “The use of hosting providers is a particular risk for ACME 
validation.”  It appears that the detailed analysis into these risks wasn’t 
performed or considered prior to using ACME.  If the analysis was done the risk 
mitigation wasn’t documented in spec.


Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai, Cisco, 
EFF, OVH and Chrome) using TLS-SNI-01?  I only call them out because as large 
financial supports, they may be more incentivized to use it than others.

Personally, I think the use of TLS-SNI-01  should be banned immediately, 
globally (not just by Let’s Encrypt), but without knowing which CAs use it, 
it’s difficult to enforce.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2


From: 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-pol...@lists.mozilla.org
Subject: Re: TLS-SNI-01 and compliance with BRs

I think others have already responded, but I do want to highlig

Re: TLS-SNI-01 and compliance with BRs

[Peter Bowen via dev-security-policy]

> 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 method 10 listed, and 
> with the DigiCert acquisition, it’s not clear if that CPS is still active.  
> We should find out on January 31st who else uses it.
> 
> In the meantime, we should ban anyone from using TLS-SNI as a non-compliant 
> implementation, even outside shared hosting environments.  There could well 
> be other implementations that comply with method 10, so I’m not suggesting we 
> remove that from the BRs yet (those that don’t allow SNI when validating the 
> presence of the random number within the certificate of a TLS handshake are 
> better).
[snip]

> Personally, I think the use of TLS-SNI-01  should be banned immediately, 
> globally (not just by Let’s Encrypt), but without knowing which CAs use it, 
> it’s difficult to enforce.

Doug,

I don’t agree that TLS-SNI-01 should be banned immediately, globally.  Amazon 
does not use TLS-SNI-01 today, so it would not directly impact Amazon 
operations.

I think we need to look back to the Mozilla Root Store Policy.  The relevant 
portions are:

"2.1 CA Operations

prior to issuing certificates, verify certificate requests in a manner that we 
deem acceptable for the stated purpose(s) of the certificates;

2.2 Validation Practices
We consider verification of certificate signing requests to be acceptable if it 
meets or exceeds the following requirements:

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 been authorized by the domain registrant to act on their 
behalf. This must be done using one or more of the 10 methods documented in 
section 3.2.2.4 of version 1.4.1 (and not any other version) of the CA/Browser 
Forum Baseline Requirements. The CA's CP/CPS must clearly specify the 
procedure(s) that the CA employs, and each documented procedure should state 
which subsection of 3.2.2.4 it is complying with. Even if the current version 
of the BRs contains a method 3.2.2.4.11, CAs are not permitted to use this 
method.”

While this clearly does call out that the methods are acceptable, it isn’t a 
results oriented statement.  The BRs also do not have clear results 
requirements for validation methods.

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 has been authorized by the domain registrant to act on their behalf” is not 
true.

I think the next step should be for Mozilla to clearly lay out the requirements 
for CAs and then the validation methods can be compared to see if they met the 
bar.

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

Re: TLS-SNI-01 and compliance with BRs

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 19, 2018 at 10:22 AM, Doug Beattie <doug.beat...@globalsign.com>
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 the point in hand which is asking if the
> ACME TLS-SNO-01 method is compliant with method 10.  If method 10 specified
> that you could validate the random number at the same IP address as the SAN
> being validated, then it would have said that.
>

I find your faith in the CA/Browser Forum's technical ability disturbing,
given the evidence.

I don't think it's off track to point out that it's the same level of
assurance as .6, .8, and .9.


> How does validating the “Random Value within a Certificate on the IP
> address of the Authorization Domain Name” comply with validating the
> “Random Value within a Certificate on the Authorization Domain Name”?  The
> TLS-SNI method specifically directs the CA to check for the random number
> on a location *other than* the ADN.
>

No, that's not correct. You're attempting to define a usage of the protocol
(TLS) that is not actually mandatory, in order to support the objection -
yet as pointed out, neither the BRs nor the relevant specification (TLS)
support that reading, nor do the other methods.


> 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 method 10
> listed, and with the DigiCert acquisition, it’s not clear if that CPS is
> still active.  We should find out on January 31st who else uses it.
>
>
>
> In the meantime, we should ban anyone from using TLS-SNI as a
> non-compliant implementation, even outside shared hosting environments.
> There could well be other implementations that comply with method 10, so
> I’m not suggesting we remove that from the BRs yet (those that don’t allow
> SNI when validating the presence of the random number within the
> certificate of a TLS handshake are better).
>

Your analysis is flawed, ergo your conclusions are derived from flawed
reasoning.


>
>
> Regarding the comment on the ACME protocol: “The ACME specification is
> useful in it's the first attempt I'm aware of that attempts to fully,
> normatively specify how to validate assurances in an open and interoperable
> way.”  Yes, open review of the protocol was good.  As you are likely aware,
> the specification points out [1] vulnerabilities with the use of ACME by
> hosting providers “The use of hosting providers is a particular risk for
> ACME validation.”  It appears that the detailed analysis into these risks
> wasn’t performed or considered prior to using ACME.  If the analysis was
> done the risk mitigation wasn’t documented in spec.
>
>
>
>
>
> Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai,
> Cisco, EFF, OVH and Chrome) using TLS-SNI-01?  I only call them out because
> as large financial supports, they may be more incentivized to use it than
> others.
>
>
>
> Personally, I think the use of TLS-SNI-01  should be banned immediately,
> globally (not just by Let’s Encrypt), but without knowing which CAs use it,
> it’s difficult to enforce.
>

While your reasons are incorrect on multiple technical dimensions, you are
correct that we want to see an immediate cessation of _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 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
>
>
>
> 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 concretely, Methods .6, .8, .9, and .10 are all effectively
> demonstrations over the IP address pointed to by a domain - rather than the
> domain itself. I mention .6 in there because there is, for example, no
> requirement to use a "Host" header - you could use HTTP/1.0 (as some CAs,
> I'm told, do).
>
>
>
> Similarly, one can read that .10 doesn't actually require the TLS
> handshake to complete, nor for a ServerKeyExchange to be in any way related
> to the Certificate. It is, for example, suffici

RE: TLS-SNI-01 and compliance with BRs

[Doug Beattie via dev-security-policy]

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 the point in hand which is asking if the ACME TLS-SNO-01 method 
is compliant with method 10.  If method 10 specified that you could validate 
the random number at the same IP address as the SAN being validated, then it 
would have said that.  How does validating the “Random Value within a 
Certificate on the IP address of the Authorization Domain Name” comply with 
validating the “Random Value within a Certificate on the Authorization Domain 
Name”?  The TLS-SNI method specifically directs the CA to check for the random 
number on a location other than the ADN.


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 method 10 listed, and 
with the DigiCert acquisition, it’s not clear if that CPS is still active.  We 
should find out on January 31st who else uses it.

In the meantime, we should ban anyone from using TLS-SNI as a non-compliant 
implementation, even outside shared hosting environments.  There could well be 
other implementations that comply with method 10, so I’m not suggesting we 
remove that from the BRs yet (those that don’t allow SNI when validating the 
presence of the random number within the certificate of a TLS handshake are 
better).

Regarding the comment on the ACME protocol: “The ACME specification is useful 
in it's the first attempt I'm aware of that attempts to fully, normatively 
specify how to validate assurances in an open and interoperable way.”  Yes, 
open review of the protocol was good.  As you are likely aware, the 
specification points out [1] vulnerabilities with the use of ACME by hosting 
providers “The use of hosting providers is a particular risk for ACME 
validation.”  It appears that the detailed analysis into these risks wasn’t 
performed or considered prior to using ACME.  If the analysis was done the risk 
mitigation wasn’t documented in spec.


Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai, Cisco, 
EFF, OVH and Chrome) using TLS-SNI-01?  I only call them out because as large 
financial supports, they may be more incentivized to use it than others.

Personally, I think the use of TLS-SNI-01  should be banned immediately, 
globally (not just by Let’s Encrypt), but without knowing which CAs use it, 
it’s difficult to enforce.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2


From: 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-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 concretely, Methods .6, .8, .9, and .10 are all effectively demonstrations 
over the IP address pointed to by a domain - rather than the domain itself. I 
mention .6 in there because there is, for example, no requirement to use a 
"Host" header - you could use HTTP/1.0 (as some CAs, I'm told, do).

Similarly, one can read that .10 doesn't actually require the TLS handshake to 
complete, nor for a ServerKeyExchange to be in any way related to the 
Certificate. It is, for example, sufficient merely to send a Client Hello and 
Server Hello+Certificate and terminate the connection.

This is the challenge of defining validation methods in the abstract, rather 
than with concrete specifications. The ACME specification is useful in it's the 
first attempt I'm aware of that attempts to fully, normatively specify how to 
validate assurances in an open and interoperable way. The historic ambiguities 
derived from the BRs, working in abstract, technology-neutral ways, necessarily 
leads to these sorts of contrived scenarios. For example, .7 doesn't 
demonstrate control over an ADN - in as much as it allows control over a 
subdomain of an ADN to be treated as control over the ADN itself (if it has a 
leading prefix). .9 doesn't require the domain name appear within the Test 
Certificate - similar to the point being raised here about the domain name not 
appearing within the TLS handshake for .10.

On Thu, Jan 18, 2018 at 4:46 PM, Doug Beattie via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
The point is, you don’t really connect to the Certificate on the Authorization 
Domain Name, you connect to a certificate on the same IP address as the ADN, 
but you actually intentionally ask for a different server name, which has no 
relationship to the ADN (except they h

RE: TLS-SNI-01 and compliance with BRs

[Tim Hollebeek via dev-security-policy]

My recollection is that there were a number of CA/B forum participants 
(including me) who asked repeatedly if method #10 could be expanded 
beyond a single sentence.

I don't remember anyone speaking up in opposition, just silence.

I continue to support making sure that all of the validation methods have
enough detail so that their security properties can be fully analyzed.
Hopefully that would help avoid incidents like this in the future.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.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...@mozilla.com>
> Subject: 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 carefully-specified-and-validated mechanisms
instead
> of individuality has worked rather well for other security-critical
operations,
> like the very transport security this whole infrastructure exists to
support.
> Perhaps that argument could be re-opened.
> 
> J.C.
> 
> 
> On Thu, Jan 18, 2018 at 3:25 PM, Matthew Hardeman
> <mharde...@gmail.com>
> wrote:
> 
> >
> >
> > 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 there via TLS, within the
> >> certificate, should be the random value (somewhere). 3.2.2.4.10 was
> >> written to permit ACME's
> >> TLS-SNI-01 while being generic enough to permit CAs to accomplish the
> >> same general validation structure without following the
> >> ACME-specified algorithm.
> >>
> >> J.C.
> >
> >
> > 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 real world experience of a (presumably)
> > compliant application of method #10 as it exists today was deficient
> > in mitigating the provision of certificates to incorrect/unauthorized
parties.
> >
> ___
> 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: TLS-SNI-01 and compliance with BRs

[J.C. Jones via dev-security-policy]

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-and-validated mechanisms
instead of individuality has worked rather well for other security-critical
operations, like the very transport security this whole infrastructure
exists to support. Perhaps that argument could be re-opened.

J.C.


On Thu, Jan 18, 2018 at 3:25 PM, Matthew Hardeman 
wrote:

>
>
> 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 there via TLS, within the certificate, should be
>> the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
>> TLS-SNI-01 while being generic enough to permit CAs to accomplish the same
>> general validation structure without following the ACME-specified
>> algorithm.
>>
>> J.C.
>
>
> 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
> real world experience of a (presumably) compliant application of method #10
> as it exists today was deficient in mitigating the provision of
> certificates to incorrect/unauthorized parties.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[J.C. Jones via dev-security-policy]

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-SNI-01 while being generic enough to permit CAs to accomplish the same
general validation structure without following the ACME-specified algorithm.

J.C.

On Thu, Jan 18, 2018 at 1:47 PM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 domain names point to can serve certificates, and
> that seems like a reasonable interpretation of the intent of that sentence,
> which TLS-SNI-01 fulfills.
>
> Alex
>
> On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > 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 control over the FQDN by confirming the
> > presence of a Random Value within a Certificate on the Authorization
> Domain
> > Name which is accessible by the CA via TLS over an Authorized Port.
> >
> > But it's my understanding that the CA validates the presence of the
> random
> > number on "random.acme.invalid" and not on the ADN specifically.  Is the
> > validation done by confirming the presence of a random number within the
> > certificate on the ADN, or some other location?  I'm probably misreading
> > the ACME spec, but is sure seems like the validation is not being done on
> > the ADN.
> >
> > Doug
> >
> > ___
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Matthew Hardeman via dev-security-policy]

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 circumstances.  Clearly Let's Encrypt
does too, for why else would they have disabled the mechanism?

If we assume a world with more complex infrastructure, the case can be made
that they're not attaching to the authorization domain name, because they
failed to submit that name via SNI to the endpoint to which they are
attached, which may cause the validation to be routed incorrectly within
certain more complex hosting architectures.  On the other hand, they did
access the right IP address via DNS lookup to the correct target
authorization domain name, meaning they're talking to the right endpoint at
the IP layer.

Nothing in the BRs makes clear what would be a correct interpretation.
It's hard to imagine that one could not defend that "on the Authorization
Domain Name" via TLS over an Authorized Port means no more than at an IP
address discovered as an A or  record after having dereferenced the
authorization domain name as necessary via typical DNS resolution rules
(allowing for CNAME, etc.) on port 443.

Nowhere within the BRs is it formally specified that the TLS session over
which this validation is taking place need to even implement SNI (an
optional feature) much less that there should be regard for the value.

Having said all that, and having read the very limited specifications of
the 10 blessed methods, I have, as an outsider looking in, arrived at the
conclusion that each and every of these methods is ridiculously
underspecified.  I'm convinced that each of the 10 should be scrutinized
thoroughly before being discarded or in the alternative formally specified
in egregious detail, such that questions such as this one may not be
raised.

On Thu, Jan 18, 2018 at 3:46 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The point is, you don’t really connect to the Certificate on the
> Authorization Domain Name, you connect to a certificate on the same IP
> address as the ADN, but you actually intentionally ask for a different
> server name, which has no relationship to the ADN (except they happen to
> share the same IP address).  It seems like misissuance to me.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[Alex Gaynor via dev-security-policy]

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 domain names point to can serve certificates, and
that seems like a reasonable interpretation of the intent of that sentence,
which TLS-SNI-01 fulfills.

Alex

On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 control over the FQDN by confirming the
> presence of a Random Value within a Certificate on the Authorization Domain
> Name which is accessible by the CA via TLS over an Authorized Port.
>
> But it's my understanding that the CA validates the presence of the random
> number on "random.acme.invalid" and not on the ADN specifically.  Is the
> validation done by confirming the presence of a random number within the
> certificate on the ADN, or some other location?  I'm probably misreading
> the ACME spec, but is sure seems like the validation is not being done on
> the ADN.
>
> Doug
>
> ___
> 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