On Mon, May 13, 2019 at 9:13 PM Ryan Hurst via dev-security-policy < [email protected]> wrote:
> > 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. > > Does replacing the existing "require practice" language by adding the following sentence to the Root Store Policy achieve the clarity you're seeking and avoid the problems you've pointed out? "CAs MUST NOT delegate validation of the domain name part of an email address to a 3rd party." 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. > > A deal breaker due to the poor usability involved in interrupting a task while the user retrieves an email and confirms receipt? The scale and nature of email validation are such that RA style agreements > should, in my personal opinion, be within reason to accommodate. > > It's not clear to me if you are arguing for the policy I proposed above, or the ability for a CA to also delegate the validation of the domain name part to a 3rd party RA? > 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
