Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker"

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 03 Aug 2019 00:18:21 -0400

On Wed 2019-07-31 16:34:44 -0400, Daniel Kahn Gillmor wrote:
> This patch to the spec deprecates the "revocation key" subpacket and
> replaces it with a "designated revoker" subpacket that includes the
> full key, rather than the fingerprint.
[...]
> @@ -1039,7 +1039,7 @@ The value of the subpacket type octet may be:
>             9   Key Expiration Time
>            10   Placeholder for backward compatibility
>            11   Preferred Symmetric Algorithms
> -          12   Revocation Key
> +          12   Revocation Key (deprecated)
>      13 to 15   Reserved
>            16   Issuer
>      17 to 19   Reserved
> @@ -1058,6 +1058,7 @@ The value of the subpacket type octet may be:
>            32   Embedded Signature
>            33   Issuer Fingerprint
>            34   Preferred AEAD Algorithms
> +          35   Designated Revoker
>    100 to 110   Private or experimental
>  
>  An implementation SHOULD ignore any subpacket of a type that it does

I've updated the above to use subpacket ID 36 for "Designated Revoker"
instead of 35, since 35 is already in use in the wild by the "Intended
Recipient Fingerprint" subpacket in at least two implementations i'm
aware of.  (see message-id: 20180305231951.GA21944@calamity from
2018-03-05 on this mailing list, and subsequent discussion)

I've opened https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/19
to track the "Intended Recipient Fingerprint" subpacket.

   --dkg

---

From: Werner Koch <[email-masked]>
Date: Mon, 05 Aug 2019 19:44:01 +0200

On Wed, 31 Jul 2019 16:34, [email-masked] said:
> The "revocation key" subpacket is problematic.  It is the the most
> fragile piece of the specification wrt the fingerprint (collisions
> against a fingerprint can create surprising revocation effects).  And

With the move to v5 keys this will be solved en-passant.

> full key, rather than the fingerprint.

I view this as problematic in the light of our preparations to allow for
larger key material.  With PQC we may need megabyte large keys and then
including an entire key would double the size of a keyblock.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: [email-masked]
Date: Mon, 05 Aug 2019 14:23:26 -0400

>including an entire key would double the size of a keyblock.

=====

There is a workaround which could avoid this;

Generating a Revocation Certificate for the key, and keeping it in a separate place from the keyring,
and also sending it to whomever the user wants to be the 'designated revoker', 
(which could change from time to time, without having to update the keyblock itself).

If this seems reasonable, then maybe consider it as a 'suggestion/comment'  to the rfc section dealing with revocation.

vedaal

---

From: Paul Wouters <[email-masked]>
Date: Mon, 5 Aug 2019 14:24:22 -0400

> On Aug 5, 2019, at 13:44, Werner Koch <[email-masked]> wrote:
> 
> 

There is only one proposal in the NIST competition with that issue (McEliece) , and unlikely to be the winner, precisely because of that.

Paul

---

From: [email-masked]
Date: Mon, 05 Aug 2019 16:03:45 -0400

>>larger key material.  With PQC we may need megabyte large keys 
>and 
>>then
>Generating a Revocation Certificate for the key

=====

The command:   gpg --gen-revoke  
works fine in GnuPG 2.x exactly as it did in 1.x,
although  --gen-revoke is not listed in --dump-options for GnuPG 2.x 
(--desig-revoke is listed in both).

Are there any plans to do away with the --gen-revoke option in 2.x ?
(if possible, keep it, please, please  ;-)   it really is very useful at times.

TIA

vedaal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 05 Aug 2019 16:16:27 -0400

> With the move to v5 keys this will be solved en-passant.

Sure, but this isn't the most important part of the problem.

The important part is that people need to be able to see the public key
of the revoker, and it's not always clear that this will be available.

> including an entire key would double the size of a keyblock.

I agree with you that this would make such a packet larger.  And
therefore, the people who want to make use of such a scheme -- and the
peers that they contact -- would need to accept a larger
certificate/keyblock size as a result.  It's not quite doubling, though:
given that there may be subkeys the certificate, and non-negligible
certifications themselves (including self-sigs and subkey binding
signatures, etc), such a subpacket is likely to be smaller than the rest
of the surrounding certificate.  and in any case, it's comparatively
small compared to some things we distribute today in much more common
circumstances than a "designated revoker".

Moreover, the verifier who discovers a third-party revocation needs to
check fetch the associated public key somehow no matter what.  And it's
always possible to distribute a "designated revoker" packet alongside
the revocation itself.  This approach increases the size of a
revocation, but incurs *no extra cost* compard to "normal" certificate
size (and no metadata leakage).  For a single verification, this is
likely to be less traffic for the verifier than if they were obliged to
fetch the full transferable public key associated with the revoker in
the first place.

So: my argument here remains that shipping the revoker's key in
"designated revoker" has benefits in terms of:

 * more convenience for verifiers
 * higher likelihood that verifiers can actually assess and accept a
   delegated revocation when encountered
 * better metadata properties (self-contained messages reduce side
   channels for their users)
 * lower traffic/bandwidth costs for a verifier who encounters a
   delegated revocation from an unknown key

And is only a marginal costs in terms of:

 * in one possible deployment configuration, for the uncommon user of
   such a packet, a modest increase in certificate size.

This seems like a clear win to me, though i acknowledge that it is not
without some minor tradeoffs.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 05 Aug 2019 16:11:42 -0400

On Mon 2019-08-05 14:24:22 -0400, Paul Wouters wrote:
> There is only one proposal in the NIST competition with that issue
> (McEliece) , and unlikely to be the winner, precisely because of that.

I also note that PQ key material is most significantly relevant today
for *encryption/decryption* keys, which *are not* likely to be
designated revokers (McEliece itself is rarely used for signing, aiui).

           --dkg

---

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

> (--desig-revoke is listed in both).

it seems present for me in 2.2.17:

0 dkg@alice:~$ gpg --version | head -n1
gpg (GnuPG) 2.2.17
0 dkg@alice:~$ gpg --dump-options | grep revo
--quick-revoke-uid
--generate-revocation
--gen-revoke
--generate-designated-revocation
--desig-revoke
0 dkg@alice:~$ 

i don't think it's going away.

  --dkg