On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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? > > I created an issue for clarifying this language: https://github.com/mozilla/pkipolicy/issues/127 > > 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). > > My opinion on this method and on Adrian's comments is that the CA/Browser Forum, with it's new-found ability to create an S/MIME Working Group, is a better venue for formulating secure email validation methods. Does it make sense for us to define more specific email validation methods in this forum when it's likely the CA/Browser Forum will do the same in the next year or two? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
