The BRs indeed do not have many requirements about the validation of email addresses, but Mozilla policy is much more proscriptive here. See, for example, the first two items of section 2.2.
These make it pretty clear that unverified addresses are prohibited by Mozilla policy, and validation of email addresses is not just a "best practice"; it's required. -Tim > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On > Behalf Of pekka.lahtiharju--- via dev-security-policy > Sent: Tuesday, August 21, 2018 6:18 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Telia CA - problem in E validation > > I agree that this culminates to what does it mean when requirement is "verified > by CA". When that is not specified anywhere and specifically not in E validation > chapter of BR I have interpreted that also weak E verification methods are > acceptable. I understand that it would be "nice" to use stronger methods but > the point is that is it "illegal" to use weak method when such method is not > prohibited. > > In our old process we have accepted personal addresses because in some cases > a single person is really the "support point" of a server. In practise personal > address has only been accepted if the same person is also the technical or > administrative contact of the application. If anybody would complain or we > notice in our visual check that the name or address can't be correct we revoke > or don't accept. In practice there hasn't been any complaints ever related to > our approved E values (except now in the this discussion). Note that all used E > values have originated from authenticated customers' CSR. > > Note! Because we want to follow "best practices" we have already stopped > using these weak methods based on these discussions. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/M8RQ_FBpnEWessS6VTb2TML0gjx1vzlJ- > To0H9f1Upk=?d=mm6rf8hUuQt34DHH- > 53_nlyLzE85Upq8F9coCGaDGTmCGJqbCuAdYHeE6BZrlgL64266orhG4- > qpaAxW71xS5LPicNsPA_DXJT563uavmGor9blfsKv5oGec1ZEtL6DeN_B2af59ky > WJgTwRpJgPyaePtW0bS56tNfBkLD37- > _2hgrxOetTnhO0RZE_zIAMg5JQcDNT7HI1pv- > VWy3I8yTyEv6uw4jcgBZnvM1M8tEXKyVuA9YACauy_kKPqA96LdRL15tLb65uhB > KHNxSLMNPu3DyrV7cqoOYtj5T0WnlzQCvr8w5KvOuRlrR3p9Em4zmnyGVioHn6 > 64CTycuByUDrGAL6BB806izNaJ_mduZaFq5fgCRIz1Cyjo- > 0WVWuWqcwLrJFX0Ro- > 4igDlcfMXvP_f1rwhPByjdggp4xXTQ%3D%3D&u=https%3A%2F%2Flists.mozilla. > org%2Flistinfo%2Fdev-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
