On Thu, Mar 10, 2016 at 2:01 PM, John R Levine <johnl(_at_)taugh(_dot_)com>
wrote:
Its certainly true that the issuer of a cert using such a regex represented
name matters greatly now. (I wondered about the same issue in another
thread) A third party CA is going to have a much harder time
understanding
the local practices, and that represents a spoofing risk, though I suspect
it might be possible to communicate local practices to prevent that. A
workable scenario is that the certificate issuer is the email domain owner
who understands intimately the email local practices.
This is almost certainly a blind alley, and it'd help to back up and think
about what problem you're trying to solve.
It seems to me that even though the same S/MIME certificate is used for
signing and encryption, the two applications are quite different.
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.
Or if a sender does want to make an address on the fly for which it does
not yet have a certificate, if the CA is the sender's domain owner, it
should be straightforward invent to ask the CA at that time for a
certificate that matches the the address, and the CA can use whatever local
rules it wants to decide whether the desired address is one that belongs to
the requester and provide one or not.
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.
-Wei
This is extra work, but in the context of mail submission, it's not an
unreasonable amount of extra work.
For encryption of inbound mail, it doesn't matter what address is in the
certificate; if the recipient can decode the message it's the right one,
otherwise it's not. So the sender can ask the domain's key oracle for a
certficate for the address, the key oracle applies local rules and provides
a certificate that might have the exact requested address, or might have
another address that goes to the same recipient.
I'd think that something along these lines would not be particularly hard
to implement, and would require semantic changes neither to PKIX nor to
SMTP.
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp