[Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key <distribution-key at intevation.de>"

[Bernhard Reiter]

Am Dienstag 06 August 2019 14:25:07 schrieb Daniel Kahn Gillmor:
> 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.

> 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",

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 
> 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?

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.

> 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?

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.)

> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20190806/35e88f14/attachment.sig>