On Wed, May 15, 2019 at 9:28 AM Ryan Hurst via dev-security-policy < [email protected]> wrote:
> Pedro, > > That scenario is addressed by Wayne proposed change. > > That same change does not allow for applications that use GMail or there > federated authentication providers to use client certificates without > sending each user to the CA. > Ryan, 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. As Wayne mentioned, it's already covered in CA forbidden practices, so I do not see how moving that existing language would meaningfully change things. If the new language prohibits it, then so to does the old language. 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. To be clear: I have serious and extensive reservations about the suggested reliance on OAuth/OIDC in the context of validation, and the scenario presented is one that I see incredible danger and harm in, if left at that level. I do, however, agree there are secure deployments that can exist, and likely does in the case you're describing - but I don't think we should muddy those waters yet, because I think trying to capture explicitly what you're proposing will require considerably more details. Hopefully, my analysis above, of the principles of the validation process, demonstrate a more reasonable and reliable level of assurance in the validation process. Hopefully, this analysis avoids the emotive aspects of the previous posts, and focuses purely on what technical steps are being provided. 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 :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
