On Monday, April 2, 2018 at 1:10:13 PM UTC-7, Wayne Thayer wrote: > I'm forwarding this for Tim because the list rejected it as SPAM. > > > > *From:* Tim Hollebeek > *Sent:* Monday, April 2, 2018 2:22 PM > *To:* 'mozilla-dev-security-policy' <mozilla-dev-security-policy@ > lists.mozilla.org> > *Subject:* Complying with Mozilla policy on email validation > > > > > > Mozilla policy currently has the following to say about validation of email > addresses in certificates: > > > > “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.” > > > > “If the certificate includes the id-kp-emailProtection extended key usage, > then all end-entity certificates MUST only include e-mail addresses or > mailboxes that the issuing CA has confirmed (via technical and/or business > controls) that the subordinate CA is authorized to use.” > > > > “Before being included and periodically thereafter, CAs MUST obtain certain > audits for their root certificates and all of their intermediate > certificates that are not technically constrained to prevent issuance of > working server or email certificates.” > > > > (Nit: Mozilla policy is inconsistent in it’s usage of email vs e-mail. I’d > fix the one hyphenated reference) > > > > This is basically method 1 for email certificates, right? Is it true that > Mozilla policy today allows “business controls” to be used for validating > email addresses, which can essentially be almost anything, as long as it is > audited? > > > > (I’m not talking about what the rules SHOULD be, just what they are. What > they should be is a discussion we should have in a newly created CA/* SMIME > WG) > > > > -Tim
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. 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 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
