On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote: > > I agree that name constraints would be difficult to implement in this > scenario, but I'm less convinced that section 2.2(2) doesn't permit this. > It says: > > > *For a certificate capable of being used for digitally signing or > encrypting email messages, the CA takes reasonable measures to verify that > the entity submitting the request controls the email account associated > with the email address referenced in the certificate or has been authorized > by the email account holder to act on the account holder’s behalf.*
I can see that covering it. Maybe this could be provided as an explicit example of how that might happen? > > Another case I think is interesting is that of a delegation of email > > verification to a third-party. For example, when you do a OAUTH > > authentication to Facebook it will return the user’s email address if it > > has been verified. The same is true for a number of related scenarios, for > > example, you can tell via Live Authentication and Google Authentication if > > the user's email was verified. > > > > The business controls text plausibly would have allowed this use case also. > > > > I'm not a fan of expanding the scope of such a vague requirement as > "business controls", and I'd prefer to have the CA/Browser Forum define > more specific validation methods, but if section 2.2(2) of our current > policy is too limiting, we can consider changing it to accommodate this use > case. I dislike business controls also, however in this case the LARGE majority of authentication on the web happens via OAUTH and federated user authentication is a thing we won't se going away. It seems broken to have a policy that prohibits this in the case of secure email or other related use cases of these certificates. Maybe this can be addressed through an explicit carve out for the case of federated authentication systems that provide a reliable verification of control of an email address. Alternatively, maybe Mozilla should maintain a listing common provider where Mozilla says this is allowable (Google, Microsoft, Facebook, and Twitter, for example). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
