[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
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Werner Koch
- [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Tom Ritter
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Daniel A. Nagy
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Stephen Paul Weber
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Jon Callas
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints David Shaw
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Jon Callas
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Designated Revokers Vincent Breitmoser
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Jon Callas
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Daniel Ranft
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Daniel A. Nagy
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] [eX-bulk] : Re: Fingerprints Christopher LILJENSTOLPE
- Re: [openpgp] [eX-bulk] : Re: Fingerprints Christopher LILJENSTOLPE
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- [openpgp] [RFC4880bis PATCH] Deprecate "Revocatio… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Neal H. Walfield
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Werner Koch
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… vedaal
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Paul Wouters
- Re: [openpgp] [Suspected Junk Mail] Re: [RFC4880b… vedaal
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [Suspected Junk Mail] Re: [RFC4880b… Daniel Kahn Gillmor