Subject: Re: [openpgp] WKD for OpenPGP certificate "Intevation File Distribution Key <[email-masked]>"

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 06 Aug 2019 08:25:07 -0400

[ Adding [email-masked] as i think this discussion is more
  standards-relevant, and is not just gpg4win-specific ]

On Mon 2019-08-05 13:32:33 +0200, Thomas Arendsen Hein wrote:
> The WKD RFC does not allow publishing multiple keys for the same
> email address, unless all but one of they keys has been revoked.
>
> But it makes sense to only publish the new key, so I just replaced
> it.

Thanks for updating the key!

I read
https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-5
and i can see how to read it via your interpretation, but i confess i
read it with some ambiguity:

   The HTTP GET method MUST return the binary representation of the
   OpenPGP key for the given mail address.  The key needs to carry a
   User ID packet ([RFC4880]) with that mail address.  Note that the key
   may be revoked or expired - it is up to the client to handle such
   conditions.  To ease distribution of revoked keys, a server may
   return revoked keys in addition to a new key.  The keys are returned
   by a single request as concatenated key blocks.

So when i read this, i think the MUST applies to the fact that a binary
representation of the key needs to be present in the HTTPS response
body, but other material can also be included.

I don't see any constraint like "MUST NOT return multiple non-revoked
keyblocks", and i *do* see "it is up to the client to handle such
conditions…" which makes me think that clients will need to understand
what to do if multiple non-revoked OpenPGP certificates are returned
anyway.

What should a sensible OpenPGP client do if it encounters this case?

Even if there was a "MUST NOT" added, what should a sensible OpenPGP
client do if it encounters such a response?  reject all the
certificates?  take only the first non-revoked one?  take only the last
non-revoked one?  take the one with the most recent creation date that
has algorithms that the local implementation can handle?

What if two subsequent queries to the WKD endpoint (within an hour of
each other, let's say) return different certificates?  what should a
client do?

> Andre, do you think it would be helpful to keep old keys available
> via WKD? If yes, either the WKD RFC needs to be adjusted (which
> possibly can be helpful for people having multiple keys, too, e.g.
> ed25519 and a more compatible fallback rsa3072 key, or during key
> rollover when emails are still signed with the old key, but a new
> key already is available)

I think it would be concretely useful in cases of a planned key
transition to be able to return multiple still-valid certificates via
WKD.

> or we need to use different email addresses,
> e.g. distribution-key+2016@... for a key generated in 2016.

Please don't resort to this approach.  E-mail addresses should establish
a constant long-term identity.

  --dkg

---

From: Bernhard Reiter <[email-masked]>
Date: Tue, 6 Aug 2019 16:58:05 +0200

> keyblocks",

This could be clarified in the next revision.
Implicitely from the intentions as written down in section
  3.  Web Key Directory
it is understandable to have one public key delivered and that is considered 
the currently associated pubkey for the email address that should be taken 
for encryption.

> and i *do* see "it is up to the client to handle such 

Display that sending the email will be less secure (towards evesdropping)
as something is strange (against the WKD specification). It is up to the user 
to decide if the email should still be send in this case. If the contents is 
highly sensitive, the user will decide to not send. Otherwise the user will 
not care, not paying attention to the display and send anyway (not caring if 
it is encrypted or not).

The email client can then do whatever it would do if it has several
pubkeys for an email address in its key store.

> each other, let's say) return different certificates?  what should a

Use the one gotten each time, and use the information into the trust level 
calculation for the second time, possibly downgrading the display of the 
envisoned security to the email in question.
(Maybe reading https://wiki.gnupg.org/AutomatedEncryption is interesting at 
this point.)

> transition to be able to return multiple still-valid certificates via

The idea with the current WKD is to solve the main use case first and
well. And simple to implement. Other use cases can be considered afterwards.

Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 06 Aug 2019 12:25:38 -0400

> the currently associated pubkey for the email address that should be taken 

I agree that this should be clarified one way or the other.

> not care, not paying attention to the display and send anyway (not caring if 

I'd love to see some studies about the usability of such a warning.  how
many fine gradations of "valid" is the user able to distinguish between
in an actionable way?

fwiw, i agree that more explicit and opinionated guidance for
implementers would be useful here too.  I would be pretty sad if that
guidance was to specify some sort of "you should be worried, but
probably you can't do anything differently to address that worry" alarm.
Alarm fatigue is a real and well-studied thing:

   https://en.wikipedia.org/wiki/Alarm_fatigue

> well. And simple to implement. Other use cases can be considered afterwards.

Here we have a concrete use case for an important vendor of
OpenPGP-related software, who has found that WKD didn't align with their
standard practice until an outside party brought it to their attention.
I am in complete agreement with you that we should focus on the main use
case, but if it's clear that the implemnentation doesn't work for
important real-world cases, we ought to be able to reconsider it (or
recommend some other approach that *does* match that use case).

          --dkg

---

From: Bernhard Reiter <[email-masked]>
Date: Wed, 7 Aug 2019 09:53:24 +0200

> I agree that this should be clarified one way or the other.

From my reading it is clear from the whole document.
I agree that the phrasing can be improved at the place you were pointing out.

> > If the contents is highly sensitive, the user will decide to not send.
> > Otherwise the user will not care, not paying attention to the display and
> > send anyway (not caring if it is encrypted or not).
>
> I'd love to see some studies about the usability of such a warning. 

The idea is not to have a "warning", but to show the state next to reach 
recipient and in addition combined in vicinity close to the send action 
element. The user can pay attention to it, but is not hassled by it either.

(It would be fun and very useful to have more usability studies, but this 
seems unrealistic as we yet do not know how to get a solid funding for 
important parts of the core infrastructure like the keyserver implementation. 
OpenPGP implementations and the software and infrastructure for a good user 
experience are underfunded and have been underfunded for many years.)

> how  many fine gradations of "valid" is the user able to distinguish between
> in an actionable way?

Many, I believe, because:
This is more close to how people model talking about diffent things
in "real life". If you happen to say something sensitive who will check whom 
you are talking to and where. You would not say something bad about your 
school with the teacher on the next table for example.

>    https://en.wikipedia.org/wiki/Alarm_fatigue

It shall be modelled not like an alarm, but as a normal situation
as there are many reasons why a trust can be reduced. The issue is, that if 
you are really sending something sensitive you'll double check, most of the 
time you won't pay much attention.

> standard practice until an outside party brought it to their attention.

Which use case and which vendor?
(So far I was not aware of a use case in this conversation. The only vendor I 
was aware of was Gpg4win which would be us.)

Getting other active pubkeys or old pubkeys can be handled by the public 
keyserver network. (On gnupg-devel@ I've pointed out how an improved
keyserver implementation can handle necessary data privacy requirements,
be de-central, transport third-party signatures, including searchable 
non-email ones, and defend against spamming and flooding attacks.

Regards,
Bernhard