On Tue, Apr 3, 2018 at 10:19 AM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Reading this thread and thinking the current text, based on the > interpretation discussed, does not accommodate a few cases that I think are > useful. > > For example, if we consider a CA supporting a large mail provider in > providing S/MIME certificates to all of its customers. In this model, the > mail provider is the authoritative namespace owner. > > In the context of mail, you can imagine gmail.com or peculiarventures.com > as examples, both are gmail (as determined by MX records). It seems > reasonable to me (Speaking as Ryan and not Google here) to allow a CA to > leverage this internet reality (expressed via MX records) to work with a CA > to get S/MIME certificates for all of its customers without forcing them > through an email challenge. > > In this scenario, you could not rely on name constraints because the > onboarding of custom domains (like peculiarventures.com) happens real > time as part of account creation. The prior business controls text seemed > to allow this case but it seems the interpretation discussed here would > prohibit it. > > 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.* In this example, the entity submitting the request (Google) controls the email account because it controls the server the MX record points to. > > 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 think a policy that does not allow a CA to support these use cases would > severly limit the use cases in which S/MIME could be used and I would like > to see them considered. > > Ryan Hurst > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
