Re: [openpgp] Web Key Directory I-D -07

[Bart Butler <[e-mail]>]

Hi Phil,

You got it spot on, and were much more articulate than I was able to be despite multiple attempts. Thank you!

Yes, all I want to do is relax that one sentence in the spec so that no UserID match, however that is defined, is required in terms of the key returned by the WKD server. We can still require a valid UserID packet of course.

I also like leveraging HTTP cache control headers in the way you suggested, though that can be discussed separately at a later date.

-Bart


Sent from ProtonMail, encrypted email based in Switzerland.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 14, 2018 7:03 PM, Phil Pennock <[e-mail]> wrote:

> On 2018-11-14 at 10:26 -0500, Paul Wouters wrote:
>
> > On Tue, 13 Nov 2018, Bart Butler wrote:
> >
> > > So if I request from ProtonMail [e-mail], I would get a key back with [e-mail], and the clients could then prompt on unrecognized types of mismatches if desired because they would know that the server is returning the canonical form of the address.
> >
> > We went through this with OPENPGPKEY and SMIMEA. You will get the SMTP
> > people blocking your draft when you try to interpret (or like above,
> > even rewrite) addresses based on "common mail provider rewrites". Their
> > firm believe is only receiving SMTP servers can interpret email addresses.
>
> Bart isn't suggesting encoding common rewrites into OpenPGP, although I
> believe that Werner might be. As an MTA maintainer, I think Bart's
> suggestion is entirely appropriate and inline with the ethos of
> federated SMTP. I'll proceed on the assumption that my analysis of
> Bart's intent is correct. Bart, please correct me if wrong.
>
> In Bart's suggestion, the WKD server, run within the same autonomous
> mail-system (or email administrative domain) as the SMTP servers, can
> decide to map addresses and return a key suitable for use for that email
> address. This does not change where the MUA should send email, but does
> adjust how a well-integrated MUA might choose an appropriate OpenPGP key
> for use for a given email address.
>
> This is entirely in line with the federated design and only the owner of
> the systems at that location getting to make such decisions. There are
> implications around caching, because such a rewrite becomes a long-term
> commitment if it's to be stored as ancillary data in the keyring for
> choosing the correct key.
>
> Thus if presented with a new address [e-mail] and needing
> to get a key for it, with Bart's proposal, the MUA and the OpenPGP
> client software can make no assumptions. It must not normalize anything
> to the left of the '@' sign. But the MUA can use WKD and get back a key
> for [e-mail]; the software can then record a mapping of
> [e-mail] -> [e-mail] in OpenPGP recipient key
> selection preferences. When later sending email to
> [e-mail], the SMTP transaction proceeds unmodified: the MUA
> does not rewrite the recipient, you have to preserve the address
> as-given. The remapped OpenPGP key selection proceeds as suggested
> though. If sending email to [e-mail] then another WKD
> lookup needs to be made. (Future work might look at protocols for
> indicating patterns to avoid repeated lookups).
>
> Because server-side mapping decisions are being held elsewhere, and
> because people do change PGP keys (in particular: security teams which
> cycle their keys annually) this does suggest that the HTTP cache control
> expiration headers might play into SHOULD controls on how the OpenPGP
> client expires mappings and puts in place refresh checks.
>
> The spirit of Bart's proposal, as I read it, is a great fit for the
> autonomy of mail administrative domains.
>
> -Phil
>
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp