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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp