Re: [pkix] [smime] Key lookup service via draft-bhjl-x509-srv-00

[Wei Chuang <[e-mail]>]

On Thu, Mar 24, 2016 at 5:25 AM, Miller, Timothy J. <[e-mail]>
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
>
>
>