> 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."
If Mozilla wishes to preclude modern web applications from using digital certificates that contain their email address without : a) having to know that a certificate is in use, b) having to know that the certificate is coming from a specific CA, c) and stopping the associated transaction to enroll for a certificate or require pre-enrollment of a certificate. Then this does make things better. I say this because by my read if that text is that it allows the CA to: 1) Delegate the local part of the validation to the mail providers via mechanisms like DNS or MX records, 2) Do their own OAUTH based email validation workflows, 3) To continue to do ping mail based validation. With that said, I do not think that this goes far enough. Let me provide some background. The two most common cloud email providers represent around 1.5billion users and OAUTH based authentication into third-party services has become the norm. Basically, nearly every email provider on the planet likely supports OAUTH (or similar) federation at this point. To put this in perspective, there are less than 340 million domains. I bring this up because using these federated authentication flows like this are really the best way to validate a user in control of an email address. This is the case because it happens silently on every authentication and is asserted by the entity that knows the best, the mail operator. So, if we wanted to allow a SAAS service to enroll a client for a certificate at login, or transaction time, via a federated login, what would such an RA agreement look like? In my mind it would say: "if the mail operator, via an approved mechanism, which includes ONLY the use of OAUTH based federated authentication to a mail provider (MS, Google, Yahoo, etc) says the user controls that address then you can get the certificate, under no other circumstances can you". The value the CA provides here is that: a) they are trusted, b) they enforce this contract. > > 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? Yes, I think so. As an example, in the EU document signing solutions have used certificates since their inception, in the US, on the other-hand we insert a picture of a signature derived from a font. When we look at the solutions that were in the EU, up until very recently, these solutions forced people through the path of interacting with the CA to get a certificate. As a result (at least in part) we saw was signing was not adopted anywhere near as much as it was the US where you could just "click" and move on with your life despite extensive marketing. As a user, the reality is if you are using a signing service you have no need to know: a) a CA is involved, b) or which CA is involved. I also believe all signing certificates need to have either an email or a phone number and all SHOULD have an email address. This means that a decision to not allow RA agreements precludes any Mozilla CA from offering certificates to a SAAS that use certs like this, even if other root programs allow for it. I should note, I have created such a service prior to joining Google so I say this with a bias, but I do think that having solutions where: a) the user is the only one in control of their signing key, b) the user doesn't have to know certificates are in use at all, c) there is no unnecessary third-party interacting with the user. If your interested here is a quick video of the signing experience in that solution. https://www.dropbox.com/s/z5omfzew15g5bb7/Hancock%20for%20Wayne.mov?dl=0 While I talked about the document signing use case above, this is not limited to those use cases. There are lots of use cases where SAAS applications could make their offerings more secure with end-user certificates if doing so did not ruin the user experience. Ryan (personal hat) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
