[Top] [All Lists]

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

2016-03-20 18:10:32
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, 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.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ietf-smtp] [pkix] why you shouldn't even try to canonicalize local parts, John R Levine <=