WKD: conveying intent of encrypt-by-default?

[Werner Koch]

Hi Phil,

To clarify: Why do you put keys intended only for signing into the WKD?
The only purpose of the WKD is to discover keys used to encrypt outgoing
data/mail.  To verify a signature the WKD does not really help because
there is no way to look up the key by fingerprint.  Well, one of the
fallbacks is:

  /* If the above methods didn't work, our next try is to retrieve the
   * key from the WKD.  This requires that WKD is in the AKL and the
   * Signer's UID is in the signature.  */

However, to be able to do this, the signer needs to specify the signing
key by NAME (e.g. wk at gnupg.org) and not key fingerprint or keyid (e.g.
AEA84EDCF01AD86C4701C85C63113AE866587D0A) as suggested.  Or to use the
--sender option.

Is this your use-case?  Makes some sense to me.  Summary of options:

1. Upload sign-only keys (strip the encryption subkey).  You can't use
   the Web Key Service in this case.  You have to resort to another
   mechanism like build a local mirror and rsync it.

2. Add a notation to the key not to use the encryption key without
   asking.  This requires all clients to understand this notation and
   act acordingly.

3. Add a WKD policy not to use the key for opportunistic encryption.
   Also needs cleint changes.

4. A variant of 1 which strips the encryption subkey after the
   publication has been confirmed.  This can be done with a WKS protocol
   extension.  Advantage is that it can be done on a key by key base.



Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20221004/419a243b/attachment.sig>