On Tue, 18 Sep 2018 17:53:34 -0700 Wayne Thayer via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> * The version of the CPS that I initially reviewed (4.0) describes a > number of methods of domain name validation in section 3.2.10.5 that > do not appear to fully comply with the BRs. This was corrected in the > current version, but one of the methods listed is BR 3.2.2.4.10, > which contains a known vulnerability. Since the time of the post about 3.2.2.4.10 the Let's Encrypt team (and others via the relevant IETF working group?) have developed a new realisation of 3.2.2.4.10 that is not vulnerable. Specifically tls-sni-01 and tls-sni-02 are replaced by tls-alpn-01 which as its name might suggest uses an ALPN TLS feature to ask a remote server to show the certificate. This involves a brand new ALPN sub-protocol with no other purpose. Suppliers who aren't trying to help their customers get certificates have no reason to develop/ enable/ configure such a feature. So it becomes reasonable (unlike with SNI) to assume that if the check passes, it was intended to pass by the name's real owner or by their agent. Section 3.2.10.5 doesn't specify how Identrust's checks work, and it would be desirable to have better descriptions for methods like 3.2.2.4.10 that are a bit vague, but it's definitely not true that all realisations of 3.2.2.4.10 are broken. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
