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
> 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
> 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
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
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.
dev-security-policy mailing list