> I must admit, I'm confused. Based on your concerns as I understand them, > either the scenario you're describing is already prohibited today (and thus > no change from existing policy), or its already permitted today and would > continue to be permitted with this change. I'm hoping you can succinctly > explain where we might disagree.
Given the inconsistent interpretation, I have heard from many in this area of what is allowed and is not I will abstain from inserting my own opinion on that matter. Instead, I just want to make sure that whatever changes are made make it clear what is allowed and is not. I also want to make sure that while that is done that the whole problem is looked at. > However, I don't think the new or old language prohibits this. The flow > you've described is functionally a relationship between Google (as the > GMail operator) and the CA. Google requests certificates on the users' > behalf - much like a reseller does - and provides them to the user. The CA > validates that Google is authorized for the gmail.com domain for each of > these requests, potentially relying on previously completed domain > validations (e.g. the reuse of data), and then lets Google validate the > local-part as appropriate. I believe the case where Google requests a certificate from the CA is accommodated but not the case where SAAS requests a certificate from the CA based on the authentication of the user it did with Google. I believe this is an important case to support as it allows the development of scenarios where seamless use of certificates happen. I also believe that the nature of how email addresses are used, and how many there are (billions) suggests that delegation should be allowed if scoped very narrowly. > Hopefully, this analysis avoids the emotive aspects of the previous posts, > and focuses purely on what technical steps are being provided. I was not trying to be emotive, I was trying to make sure the consequences of the proposed wording is clear. > Perhaps I overlooked something, but I don't see the requirement for 'ping' > emails or > the like, so I do not understand why it's relevant to the policy > discussion. If I'm missing something, though, hopefully, you'll be able to > point it out :) It is true that ping mails could be replaced with users logging being redirected from the application they use to a CA where they authenticate to the CA via one of these federated authentication schemes and then be federated back. This has all the same issues and is not materially different than a ping mail though when looking at usability which is why I omitted it but as you point out it is still possible. It is also possible for a mail service provider to become a CA, or provide certificates through a CA by proving control of the base domain and then being authoritative for the local part of the address but this limits the use of certificates in this case to email providers that have built this. These options leave SAAS providers with the following choices: a) use private trust certificates d) use public trust certificates and accept it makes your user experience non-competitive c) do not use certificates because it makes your user experience non-competitive _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
