On Thu, Mar 24, 2016 at 5:25 AM, Miller, Timothy J.
<tmiller(_at_)mitre(_dot_)org>
wrote:
Could Yahoo! (in this example) not provide a means for their users to
update
the key lookup service? As the user is authenticated through their UI,
he or
she could upload the keys they want in a secure way. (A realistic
deployment caveat might be that Yahoo! puts some restrictions on e.g.
Yahoo! might not support self-signed, weak key sizes etc). One might
argue
Yahoo! wouldn't want to provide a key service, but then that's fine.
Without
the SRV RR, things should be defined to fall back to the current state of
things.
First, consider a user forwarding mail from Yahoo! to some other service,
or using a single client to access multiple mailboxes but replying from a
single address. Who attests to what in these cases?
I don't believe a key service complicates these scenarios, rather as you
say the underlying PKI 'who' question does.
Second, by adding provider-side infrastructure you're increasing the cost
of providing the mail service with no direct benefit to the mail provider
himself. There's an indirect benefit in which you're making the service
slightly more attractive to a certain niche of users, but that's probably
not even measurable as that niche is exceedingly small. IOW, there's no
incentive.
Providing a key service would be up to the provider. Some might choose not
to, and thereby solely use MUA based distribution.
Where a key service is provided, I would think there could be these
benefits:
* Keep private the initial conversation
* Certificate renewal upon expiry or similarly when revoked
* Describe the allowed trust anchor (for verification which shouldn't be
all the time)
* Potentially handle email address name variants e.g. subaddressing,
capitalization
-Wei
My advice is to keep it as simple as possible. MUAs interact directly
with users, so it should be MUAs that provide assurance, not mail
providers. This relieves the provider from having to worry about it, and
users can opt in or out at will using any mail provider or key
infrastructure they choose (up to and including roll-your-own).
-- T
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime