Subject: Re: [ietf-smtp] [pkix] why you shouldn't even try to canonicalize local parts

From: "John R Levine" <[email-masked]>
Date: 20 Mar 2016 19:10:22 -0400

>> For signing, a random recipient having verified that the signature matches
>> the message body wants to check that an address in the certificate matches
>> the sender's address, typically the one on the From: line.  In my
>> experience, even those of us with a zillion inbound addresses don't use all
>> that many addresses for outbound mail, so it's practical to enumerate them
>> all in certificates.
>
>I agree with Richard that subaddressing remains an issue.

If so, we could probably come up with a constrained syntax to describe
subaddresses like

  name <char> <string of chars>

but you'd still need some way to call back to the domain to ask whether 
that subaddress syntax was one it agreed with.  Note there are plenty of 
mail systems like Yahoo that support only a small number of subaddresses, 
like three per address.

>I would agree this could work but wanted to point out that generating
>signing certs on demand could constrain the deployment of S/MIME to large
>email providers that have resources to support being a CA due to possible
>auditing, hardware HSM and the like requirements.

Naah.  For signatures from google.com, an HSM and an auditor makes sense. 
For the rest of us, we sign our DNSSEC zones with a python script and 
would do the same for locally signed S/MIME certs.  The only assertion you 
can make with a locally signed cert is "this is my user" and in most cases 
that's not a particularly powerful assertion.

If you're going to do local signing, the reasonable way to publish the 
signing cert is with DNSSEC as I suggest in draft-bhjl-x509-srv-00 section 
5.  But with DNSSEC, the security is the security of one's registrar 
accound, which is usually a user name and password. Anything stronger than 
that down the line is security theater.

R's,
John