On Tuesday, 3 April 2018 20:19:40 UTC+3, Ryan Hurst 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. > > > 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
There's also (1) the case of wildcard/catch-all email addresses and (2) that of the email provider for hosted domains, provider that has access to the postmaster account. case (1) wildcard/catch-all addresses ( *@example.com ) are allowed by some services (even Google's G Suite) as a delivery method when an email address does not map to a traditional email account. RFC 5321 section 2.3.11. (Mailbox and Address) allows such usage of wildcard email addresses and they are VERY useful when used as receive-only addresses for anti-spam usage and as indicators of compromise in case of data leaks in 3rd party databases. S/MIME certificates for such wildcard addresses should not be allowed without strict verification - such certificates should require at least Domain Validation or a validation method of equal strength to what the domain already has (if it has a cert already). If the domain has an OV or EV certificate then the S/MIME certificate for the wildcard should use, in addition to DV, at least the same validation rules. I use a wildcard configuration with receive-only addresses tailored to the service that asks them and made up on the spot (e.g. <site-name>-<keyword1>-<YYYYMMDDHHMM>-<keyword2> @ domain), for almost anything that asks me for an email address. This way i can even use a pen on a traditional paper form and make up an unique email address JUST for filling on that form. If that address starts to receive unsolicited mail from anywhere else except the site/company it was designed for then that means that they either sold my data to a 3rd party or they had a data leak and the EU GDPR is very unforgiving with such usage. GMail's traditional plus-aliased addresses are not really usable anymore because many sites do not allow "plus" characters in email addresses. Wildcards are much more flexible for this. case (2): that of the email provider for hosted domains, provider that has access to the postmaster account - this is a form of delegation of email verification to a third-party. In this case the postmaster account used by the email provider for technical management of the service should not be allowed to be used to obtain wildcard S/MIME certificates (but they can obtain regular, non-wildcard ones). root or webmaster would be more suitable as contact addresses in this case. Again, i use G Suite as an example why: when using email for domains hosted at GMail then the domain owner must give access to the abuse and postmaster accounts to Google Support. In my opinion this access is ok for managing the service, but is not ok when performing validations to obtain S/MIME certs for wildcard catch-all addresses. ~~~~ Adrian R. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
