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

Reply via email to