On Monday, September 24, 2018 at 1:09:07 PM UTC-4, Wayne Thayer wrote: > Good point Nick. Can someone from Identrust provide more details on > Identrust's use and implementation of validation method 3.2.2.4.10?
[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS. We also confirm that we have not used this validation method for any certificate issuance. > - 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. [IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS. We also confirm that we have not used this validation method for any certificate issuance. > > 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. [IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS. We also confirm that we have not used this validation method for any certificate issuance. Marco S. > > _______________________________________________ > > 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
