On Monday, May 13, 2019 at 10:25:18 AM UTC-7, Wayne Thayer wrote: > The BRs forbid delegation of domain and IP address validation to third > parties. However, the BRs don't forbid delegation of email address > validation nor do they apply to S/MIME certificates. > > Delegation of email address validation is already addressed by Mozilla's > Forbidden Practices [1] state: > > "Domain and Email validation are core requirements of the Mozilla's Root > Store Policy and should always be incorporated into the issuing CA's > procedures. Delegating this function to 3rd parties is not permitted." > > I propose that we move this statement (changing "the Mozilla's Root Store > Policy" to "this policy") into policy section 2.2 "Validation Practices". > > This is https://github.com/mozilla/pkipolicy/issues/175 > > I will appreciate everyone's input on this proposal. > > - Wayne > > [1] > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
Though it seems the thread has largely expressed my concerns I do want to chime in and stress that I believe that it is important that this text gets clarified. Email addresses are, as has been pointed out, tricky. Today it is common practice for CAs to send "ping mails" for every certificate that is sent, this has been a common interpretation for what "email certificate" validation has to look like. This, however, excludes things like: > Using MX records, as a means to look at which mail service is authoritative > for that domain and delegating the local part to the entity operating the > mail service. > Using DNS records as a means to determine who is authoritative for that > domain and delegating the local part to that entity. > Relying on OAUTH based redirection flows from mail service providers such as > Google, Microsoft, and others. These options all offer strong and friction-free user experiences for the associated use cases. I also think that since emails have become the most common account identifier excluding the ability for a CA to enter into an RA agreement essentially precludes the use of email certificates by anyone other than a) the CA or b) the mail service provider. This means, as an example, one could not use Mozilla trusted certificates at scale for mail or document signing unless it was provided by one of those two entities. This is because out of context ping emails to individual users (what many CAs offer today) is essentially a deal breaker. The scale and nature of email validation are such that RA style agreements should, in my personal opinion, be within reason to accommodate. This is particularly problematic in that even if other root stores allowed the use of RA agreements for email certificates it would no longer be allowed; in essence, precluding the adoption of publicly trusted client certificates for mainstream SASS applications. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
