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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 31 July 2019 20:34 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F109E12004F for <openpgp@ietfa.amsl.com>; Wed, 31 Jul 2019 13:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=uLcSzGBK; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=06fH4RKs
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01fTxWxiLOfS for <openpgp@ietfa.amsl.com>; Wed, 31 Jul 2019 13:34:49 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AEA120018 for <openpgp@ietf.org>; Wed, 31 Jul 2019 13:34:49 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1564605288; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : from; bh=hmGnuW2KV/zvduIvu8TA4LcVT+R++tRZl1jg2eQGDSE=; b=uLcSzGBKo24iVcFX9gsOPFF3u1hTXneFEs3kqZNJuRJE3a/OTkzdexoy P+p5SQQLjR2mXldryk3lTUOLCxE7Dw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1564605288; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : from; bh=hmGnuW2KV/zvduIvu8TA4LcVT+R++tRZl1jg2eQGDSE=; b=06fH4RKs/5I40kvSZK2+9BMUDmZekShUwRkSb/mNIlwppiFmgXWxYRCN 0BvPSpwU6ZmyrKm11hH/xocNbIOUF0FTgyFK3oXnB6QDpn3M3k7mFf6YVP XOE9uGkFhUvzVkEcVPWhG7OfsfFvpSTg//TBND85r7kuc3vy/Tx6kgWeFU E5ZwqemuUc+tQq/geuZxtJpYeRKO9E++dp+cHXyH4gOlAt6+ifWvq6XH3O u+R+Ppp2nTprwEcDSDRBEcjfToJBBNbs3igIvnMTUuo7Mqo6Avz+3m/oSN /JPsoL/SQ0Bc4wJlp4Ana4IcFcxxUI2yqrSxS3YbW+k7qQOT8OnchQ==
Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CDA0EF99D for <openpgp@ietf.org>; Wed, 31 Jul 2019 16:34:47 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id F23252025E; Wed, 31 Jul 2019 16:34:44 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: IETF OpenPGP WG <openpgp@ietf.org>
Date: Wed, 31 Jul 2019 16:34:44 -0400
Message-Id: <20190731203444.4822-1-dkg@fifthhorseman.net>
X-Mailer: git-send-email 2.20.1
In-Reply-To: <87iocqepta.fsf@littlepip.fritz.box>
References: <87iocqepta.fsf@littlepip.fritz.box>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/mWlYCvE18JssVNyoApmSg_7deGg>
Subject: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker"
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 20:34:52 -0000

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
it is potentially difficult to rely on for clients which might not be
able to find the revoking key (for example, if keyservers are
unavailable).

It is also not currently widely used.

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.

The only cost here appears to be slightly increased size of the new
subpacket type by comparison, which is an entirely reasonable cost
that the (rare) users of this feature should be able to bear.

I've cargo-culted in the "class" octet from "Revocation Key".  I'm not
sure that octet is particularly useful, and i'd be happy to drop it if
folks want to, but i didn't want to muddle the waters with a semantic
change in addition to this mechanical change.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
---
 middle.mkd | 61 ++++++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 46 insertions(+), 15 deletions(-)

diff --git a/middle.mkd b/middle.mkd
index 51f71a6..a2d3ae6 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -757,7 +757,7 @@ These meanings are as follows:
       directly on a key.  It binds the information in the Signature
       subpackets to the key, and is appropriate to be used for
       subpackets that provide information about the key, such as
-      the Revocation Key subpacket.  It is also appropriate for
+      the Designated Revoker subpacket.  It is also appropriate for
       statements that non-self certifiers want to make about the
       key itself, rather than the binding between a key and a
       name.
@@ -766,7 +766,7 @@ These meanings are as follows:
   :   Key revocation signature. The signature is calculated
       directly on the key being revoked. A revoked key is not to
       be used.  Only revocation signatures by the key being
-      revoked, or by an authorized revocation key, should be
+      revoked, or by a designated revoker, should be
       considered valid revocation signatures.
 
 0x28
@@ -774,7 +774,7 @@ These meanings are as follows:
       directly on the subkey being revoked. A revoked subkey is
       not to be used.  Only revocation signatures by the top-level
       signature key that is bound to this subkey, or by an
-      authorized revocation key, should be considered valid
+      designated revoker, should be considered valid
       revocation signatures.
 
 0x30
@@ -782,7 +782,7 @@ These meanings are as follows:
       earlier User ID certification signature (signature class
       0x10 through 0x13) or direct-key signature (0x1F).  It should
       be issued by the same key that issued the revoked signature
-      or an authorized revocation key.  The signature is computed
+      or a designated revoker.  The signature is computed
       over the same data as the certificate that it revokes, and
       should have a later creation date than that certificate.
 
@@ -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
@@ -1294,18 +1295,48 @@ description of the syntax is found in [](#regular-expressions) below.
 
 #### Revocation Key
 
-(1 octet of class, 1 octet of public-key algorithm ID, 20 or 32 octets
-of fingerprint)
+(1 octet of class, 1 octet of public-key algorithm ID, 20 octets
+of v4 fingerprint)
 
-V4 keys use the full 20 octet fingerprint; V5 keys use the
-full 32 octet fingerprint
+This mechanism is deprecated.  Applications MUST NOT generate such a
+subpacket.  An application that wants this functionality SHOULD
+instead produce a Designated Revoker subpacket described in
+[](#designated-revoker).  The advantage of the Designated Revoker
+packet is twofold: it can be used unambiguously to validate
+revocations without causing an extra lookup; and it is resistant to
+any flaws found in the fingerprint.
 
-Authorizes the specified key to issue revocation signatures for this
-key.  Class octet must have bit 0x80 set.  If the bit 0x40 is set,
-then this means that the revocation information is sensitive.  Other
-bits are for future expansion to other kinds of authorizations.  This
-is only found on a direct-key self-signature (type 0x1f).  The use on
-other types of self-signatures is unspecified.
+This packet authorizes the specified v4 key to issue revocation
+signatures for this key.  Class octet must have bit 0x80 set.  If the
+bit 0x40 is set, then this means that the revocation information is
+sensitive.  Other bits are reserved and MUST be 0.  This is only found
+on a direct-key self-signature (type 0x1f).  The use on other types of
+self-signatures is unspecified.
+
+If the "sensitive" flag is set, the keyholder feels this subpacket
+contains private trust information that describes a real-world
+sensitive relationship.  If this flag is set, implementations SHOULD
+NOT export this signature to other users except in cases where the
+data needs to be available: when the signature is being sent to the
+designated revoker, or when it is accompanied by a revocation
+signature from that revoker.  Note that it may be appropriate to
+isolate this subpacket within a separate signature so that it is not
+combined with other subpackets that need to be exported.
+
+#### Designated Revoker
+
+(1 octet of class, N octets of public key)
+
+Authorizes the embedded public key to issue revocation signatures for
+this key.  Class octet must have bit 0x80 set.  If the bit 0x40 is
+set, then this means that the revocation information is sensitive.
+Other bits are for future expansion to other kinds of authorizations.
+This is only found on a direct-key self-signature (type 0x1f).  The
+use on other types of self-signatures is unspecified.
+
+The remaining N octets of the of the packet MUST consist of a complete
+Public-Key Packet (tag 6) that can be used to verify revocation
+signatures.
 
 If the "sensitive" flag is set, the keyholder feels this subpacket
 contains private trust information that describes a real-world
-- 
2.20.1