Good point Nick. Can someone from Identrust provide more details on Identrust's use and implementation of validation method 3.2.2.4.10?
- Wayne On Sat, Sep 22, 2018 at 3:43 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
