openpgp                                                          D. ShawInternet-Draft                                          Jabberwocky TechUpdates: 9580 (if approved)                            A. Gallagher, Ed.Intended status: Standards Track                              PGPKeys.EUExpires: 16 April 2026                                   13 October 2025                        OpenPGP Key Replacement                  draft-ietf-openpgp-replacementkey-06Abstract   This document specifies a method in OpenPGP to suggest a replacement   for an expired, revoked, or deprecated primary key.About This Document   This note is to be removed before publishing as an RFC.   The latest revision of this draft can be found at   https://andrewgdotcom.gitlab.io/openpgp-replacementkey.  Status   information for this document may be found at   https://datatracker.ietf.org/doc/draft-ietf-openpgp-replacementkey/.   Discussion of this document takes place on the OpenPGP Working Group   mailing list (mailto:openpgp@ietf.org), which is archived at   https://mailarchive.ietf.org/arch/browse/openpgp/.  Subscribe at   https://www.ietf.org/mailman/listinfo/openpgp/.   Source for this draft and an issue tracker can be found at   https://gitlab.com/andrewgdotcom/openpgp-replacementkey.Status of This Memo   This Internet-Draft is submitted in full conformance with the   provisions of BCP 78 and BCP 79.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF).  Note that other groups may also distribute   working documents as Internet-Drafts.  The list of current Internet-   Drafts is at https://datatracker.ietf.org/drafts/current/.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   This Internet-Draft will expire on 16 April 2026.Shaw & Gallagher          Expires 16 April 2026                 [Page 1]Internet-Draft           OpenPGP Key Replacement            October 2025Copyright Notice   Copyright (c) 2025 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject to BCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents (https://trustee.ietf.org/   license-info) in effect on the date of publication of this document.   Please review these documents carefully, as they describe your rights   and restrictions with respect to this document.  Code Components   extracted from this document must include Revised BSD License text as   described in Section 4.e of the Trust Legal Provisions and are   provided without warranty as described in the Revised BSD License.Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4   3.  The Replacement Key Subpacket . . . . . . . . . . . . . . . .   5   4.  Format of the Replacement Key Subpacket . . . . . . . . . . .   5     4.1.  Key Imprints  . . . . . . . . . . . . . . . . . . . . . .   8     4.2.  Graph Topology  . . . . . . . . . . . . . . . . . . . . .   8   5.  Interpretation of the Replacement Key Subpacket . . . . . . .  10     5.1.  Identity Equivalence Binding  . . . . . . . . . . . . . .  10       5.1.1.  Time Evolution of Identity Equivalence  . . . . . . .  11       5.1.2.  Consequences of Identity Equivalence  . . . . . . . .  12     5.2.  Absence of an Identity Equivalence Binding  . . . . . . .  13       5.2.1.  Limiting Chaining of Non-Equivalent Replacements  . .  13     5.3.  Reasons for Revocation  . . . . . . . . . . . . . . . . .  14   6.  Selection of Encryption Subkeys . . . . . . . . . . . . . . .  14   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16   Appendix A.  Example Workflows  . . . . . . . . . . . . . . . . .  16     A.1.  Alice Generates a New Primary Key . . . . . . . . . . . .  16       A.1.1.  Alice's Actions . . . . . . . . . . . . . . . . . . .  16       A.1.2.  Bob's Actions . . . . . . . . . . . . . . . . . . . .  17       A.1.3.  Alice's Second Device . . . . . . . . . . . . . . . .  18     A.2.  Alice Revokes Her Deprecated Primary Key  . . . . . . . .  18       A.2.1.  Alice's Actions . . . . . . . . . . . . . . . . . . .  18       A.2.2.  Bob's Actions . . . . . . . . . . . . . . . . . . . .  18       A.2.3.  Carol's Actions . . . . . . . . . . . . . . . . . . .  19       A.2.4.  Alice's Second Device . . . . . . . . . . . . . . . .  19     A.3.  Time Evolution of an Identity Equivalence Group . . . . .  20   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  21Shaw & Gallagher          Expires 16 April 2026                 [Page 2]Internet-Draft           OpenPGP Key Replacement            October 2025   Appendix C.  Document History . . . . . . . . . . . . . . . . . .  21     C.1.  Changes Between draft-ietf-openpgp-replacementkey-05 and            -06  . . . . . . . . . . . . . . . . . . . . . . . . . .  21     C.2.  Changes Between draft-ietf-openpgp-replacementkey-04 and            -05  . . . . . . . . . . . . . . . . . . . . . . . . . .  22     C.3.  Changes Between draft-ietf-openpgp-replacementkey-03 and            -04  . . . . . . . . . . . . . . . . . . . . . . . . . .  22     C.4.  Changes Between draft-ietf-openpgp-replacementkey-02 and            -03  . . . . . . . . . . . . . . . . . . . . . . . . . .  23     C.5.  Changes Between draft-ietf-openpgp-replacementkey-01 and            -02  . . . . . . . . . . . . . . . . . . . . . . . . . .  23     C.6.  Changes Between draft-ietf-openpgp-replacementkey-00 and            -01  . . . . . . . . . . . . . . . . . . . . . . . . . .  23     C.7.  Changes Between draft-gallagher-openpgp-replacementkey-02            and draft-ietf-openpgp-replacementkey-00 . . . . . . . .  23     C.8.  Changes Between draft-gallagher-openpgp-replacementkey-01            and -02  . . . . . . . . . . . . . . . . . . . . . . . .  24     C.9.  Changes Between draft-gallagher-openpgp-replacementkey-00            and -01  . . . . . . . . . . . . . . . . . . . . . . . .  24     C.10. Changes Between draft-shaw-openpgp-replacementkey-00 and            draft-gallagher-openpgp-replacementkey-00  . . . . . . .  24   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  241.  Introduction   The OpenPGP message format [RFC9580] defines two ways to invalidate a   primary key.  One way is that the primary key may be explicitly   revoked via a key revocation signature.  OpenPGP also supports the   concept of key expiration, a date after which the key should not be   used.  When a primary key is revoked or expires, very often there is   another primary key that is intended to replace it.   A key owner may also create a new primary key that is intended to   deprecate and replace their existing primary key, but without   revoking or expiring that key.  This is useful during the rollout of   new key versions and algorithms which may not (yet) enjoy universal   support.  In such cases, a key owner may prefer that their   correspondents use their new primary key, but if this is not possible   for technical reasons they may continue to use the non-preferred key,   which remains valid.   In the past some key owners have created key transition documents,   which are signed, human-readable statements stating that a newer   primary key should be preferred by their correspondents.  It is   desirable that this process be automated through a standardised   machine-readable mechanism.Shaw & Gallagher          Expires 16 April 2026                 [Page 3]Internet-Draft           OpenPGP Key Replacement            October 2025   This document is to specify the format of a Signature Subpacket to be   optionally included in a revocation signature or direct self-   signature over a primary key.  This subpacket contains a pointer to a   suggested replacement for the (now deprecated) primary key that is   signed over, or one or more (deprecated) primary keys for which the   current primary key is the suggested replacement.  The replacement   certificate may then be automatically retrieved by the key owner's   correspondents and (if supported and validated) used instead of the   deprecated certificate.2.  Conventions and Definitions   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and   "OPTIONAL" in this document are to be interpreted as described in   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all   capitals, as shown here.2.1.  Terminology   In OpenPGP, the term "key" has often been used broadly to describe   different concepts, which can lead to confusion.  To avoid ambiguity   in this document, we define the following terms:   *  "Replacement Primary Key" and "Deprecated Primary Key": These      refer to a primary key as contained in an OpenPGP Certificate      (Section 10.1 of [RFC9580]) or Transferable Secret Key      (Section 10.2 of [RFC9580]).   *  "Target Key": This refers to either a replacement or deprecated      primary key that is referenced in a Replacement Key subpacket.   *  "Current Primary Key": This refers to the primary key that      contains the self-signature being discussed.   *  "Replacement Certificate", "Deprecated Certificate" and "Current      Certificate": These refer to the certificate that contains the      respective primary key.   The term "OpenPGP Certificate", or just "certificate", is used in   this document interchangeably with "OpenPGP Transferable Public Key".   This document also introduces the following terms:   *  An "identity" is any identifying label such as an email address or      "real name"; it is not limited to User IDs, for example it may be      a record in a local database.Shaw & Gallagher          Expires 16 April 2026                 [Page 4]Internet-Draft           OpenPGP Key Replacement            October 2025   *  An "identity claim" is any statement, explicit or implied, that an      identity belongs to a particular primary key; it does not need to      be a certification signature, and is not necessarily true.   *  An "identity link" is an identity claim that is considered to be      true and accurate by the receiving implementation.   *  An "Identity Equivalence Binding" is a doubly-linked, directed      relationship between two primary keys, one of which is the stated      replacement for the other.   *  An "Identity Equivalence Set" is a collection of two or more      primary keys whose Identity Equivalence Bindings form a maximal      connected graph.3.  The Replacement Key Subpacket   The Replacement Key subpacket is a Signature Subpacket as specified   in Section 5.2.3.7 of [RFC9580], and all general Signature Subpacket   considerations from there apply here as well.  The value of the   Signature Subpacket type octet for the Replacement Key subpacket is   100 (TEMPORARY, permanent code point TBC).   The Replacement Key subpacket is a statement by the key owner that   either:   *  The current primary key is replaced by another primary key.   *  The current primary key is the replacement for one or more      deprecated primary key(s).   Use of the Replacement Key subpacket is optional.  The absence of a   Replacement Key subpacket SHOULD NOT be interpreted as meaning that   there is no replacement or deprecated primary key(s) relating to the   current primary key.   The Replacement Key subpacket MUST only be used in the hashed   subpackets area of a Primary Key Revocation Section 5.2.1.11 of   [RFC9580] or Direct Key signature Section 5.2.1.10 of [RFC9580].  A   receiving implementation MUST ignore any Replacement Key subpacket   found elsewhere.4.  Format of the Replacement Key Subpacket   The format of the Replacement Key subpacket is:Shaw & Gallagher          Expires 16 April 2026                 [Page 5]Internet-Draft           OpenPGP Key Replacement            October 2025            +========+============================+==========+            | Octets | Field                      | Notes    |            +========+============================+==========+            | 1      | Class                      |          |            +--------+----------------------------+----------+            | 1      | Record length (1)          |          |            +--------+----------------------------+----------+            | 1      | Target Key Version (1)     |          |            +--------+----------------------------+----------+            | N1     | Target Key Fingerprint (1) |          |            +--------+----------------------------+----------+            | M      | Target Key Imprint (1)     |          |            +--------+----------------------------+----------+            | 1      | Record length (2)          | optional |            +--------+----------------------------+----------+            | 1      | Target Key Version (2)     | optional |            +--------+----------------------------+----------+            | N2     | Target Key Fingerprint (2) | optional |            +--------+----------------------------+----------+            | M      | Target Key Imprint (2)     | optional |            +--------+----------------------------+----------+            | ...    | ...                        | ...      |            +--------+----------------------------+----------+                Table 1: Replacement Key Subpacket Fields   The class octet contains flags that indicate the form and semantics   of the subpacket:   +==========+=======================+===============================+   | Flag bit | Flag name             | Form of remainder of packet   |   +==========+=======================+===============================+   | 0x01     | Backward reference(s) | Multiple targets may be given |   +----------+-----------------------+-------------------------------+                 Table 2: Replacement Key Subpacket Flags   The 0x01 bit of the class octet is the "backward reference(s)" bit.   When set, this means that the target key(s) identified by the packet   are the primary keys for which the current primary key is the   replacement primary key.  Otherwise, the subpacket represents a   forward reference and the target key is the replacement primary key   for the current primary key.   All other flag bits of the class octet are currently undefined.  All   undefined flags MUST be zeroed when generating the class octet.  An   implementation that encounters a class octet with nonzero bits that   it does not recognise MUST ignore those bits.Shaw & Gallagher          Expires 16 April 2026                 [Page 6]Internet-Draft           OpenPGP Key Replacement            October 2025   Note that if the critical bit on the Replacement Key subpacket is   set, a receiving implementation could consider the whole self-   signature to be in error (Section 5.2.3.7 of [RFC9580]).  The   critical bit therefore SHOULD NOT be set on the Replacement Key   subpacket.   The remainder of the subpacket contains one or more target records of   the form:( Record Length || Target Key Version || Target Key Fingerprint || Target Key Imprint )   The Record Length field contains a one-octet number which indicates   the length of the next three fields in octets.  If a receiving   implementation does not understand the target key version, it SHOULD   ignore the target record and skip to the next.  The Record Length   field is authoritative, and a receiving implementation MUST NOT infer   the length of a target record by any other means.  If the Record   Length field indicates that a target record contains more octets than   expected, a receiving implementation MUST ignore any trailing extra   octets.  If a target record contains fewer octets than expected, it   is malformed and MUST be ignored.   *  If the class octet does not have the 0x01 bit set, the subpacket      MUST contain exactly one target record to identify the replacement      primary key.   *  If the class octet has the 0x01 bit set, the subpacket contains      one or more target records, to identify the deprecated primary      key(s) that the current primary key is a replacement for.   If a subpacket contains an unexpected number of target records, it is   malformed and MUST be ignored.   The length of the Target Key Fingerprint field (N) MUST equal the   fingerprint length corresponding to the immediately preceding Target   Key Version field, e.g. 20 octets for version 4, or 32 octets for   version 6.  The length of the Target Key Imprint field (M) MUST equal   the length of the output of the digest algorithm used by the   enclosing signature, e.g. 32 octets for SHA2-256.   If a replacement or deprecated primary key is unknown, then a   Replacement Key subpacket SHOULD NOT be included in the signature.Shaw & Gallagher          Expires 16 April 2026                 [Page 7]Internet-Draft           OpenPGP Key Replacement            October 20254.1.  Key Imprints   An imprint of a public key packet is a generalisation of a   fingerprint.  It is calculated in the same way as the fingerprint,   except that it may use a digest algorithm other than the one   specified for the fingerprint.  Conversely, the fingerprint of a   public key packet can be considered a special case of an imprint.  A   public key packet has only one fingerprint, but may have any number   of imprints, each using a different digest algorithm.   When used in a Replacement Key subpacket, an imprint MUST use the   same digest algorithm as the enclosing signature.  This guards   against key-substitution attacks when referring to keys that use   weaker digest algorithms in their fingerprints.  If the signature's   digest algorithm is the same as that used by the fingerprint, then   the imprint and the fingerprint will be identical.  In such a case,   the imprint MUST still be included for parsing reasons.   A receiving implementation MAY use the fingerprint to locate a target   key, but MUST verify that the imprint matches.4.2.  Graph Topology   A given signature MUST contain at most one Replacement Key subpacket   in its hashed subpacket area.  If a signature contains more than one   such subpacket, even if malformed, a receiving implementation MUST   disregard them all.   A certificate MAY have multiple signatures that contain Replacement   Key subpackets, however at most one Replacement Key subpacket in a   certificate is current (and therefore meaningful) at any given time.   If the primary key is revoked with a Reason for Revocation of "Key is   superseded" Section 5.2.3.31 of [RFC9580], the current Replacement   Key subpacket (if any) is found in the most recent valid Key   Revocation signature.  If it is not revoked, the current Replacement   Key subpacket (if any) is found in the most recent valid Direct Key   signature.  If the most recent valid Key Revocation or Direct Key   signature does not contain a Replacement Key subpacket, or the   primary key is revoked with any other Reason for Revocation, then   there is no current Replacement Key subpacket.   This imposes a simple graph topology:   *  A deprecated certificate MUST NOT claim to have more than one      replacement.   *  A deprecated certificate that claims to have a replacement MUST      NOT claim to be the replacement for any other(s).Shaw & Gallagher          Expires 16 April 2026                 [Page 8]Internet-Draft           OpenPGP Key Replacement            October 2025   In addition, the order of the deprecated primary keys specified in a   backward-reference Replacement Key subpacket is meaningful.  If a   replacement primary key is supported by a receiving implementation,   but is not usable for the desired purpose (for example, it may not   have an encryption-capable subkey), the implementation MAY use the   ordering of the deprecated primary keys in its backward Replacement   Key subpacket (if one exists) to indicate which deprecated primary   key is preferred as a fallback.  The deprecated primary keys SHOULD   therefore be listed in order of decreasing preference.                                                   .---------------------.                                                  | Replacement Cert      |                                                  | +-------------------+ |                                                  | | Backward RKSP     | | .---------------------.                          | |                   | || Deprecated Cert 1     |                         | |  .-------------.  | || +-------------------+ | <-----------------------+-+-+ Target Record | | || | Forward RKSP      | |              "Replaces" | |  '-------------'  | || |  .-------------.  | |                         | |                   | || | | Target Record +-+-+-----------------------> | |                   | || |  '-------------'  | | "Replaced by"           | |                   | || +-------------------+ |                         | |                   | | '---------------------'                          | |                   | | .---------------------.                          | |                   | || Deprecated Cert 2     |                         | |  .-------------.  | || +-------------------+ | <-----------------------+-+-+ Target Record | | || | Forward RKSP      | |              "Replaces" | |  '-------------'  | || |  .-------------.  | |                         | |                   | || | | Target Record +-+-+-----------------------> | |                   | || |  '-------------'  | | "Replaced by"           | |                   | || +-------------------+ |                         | |                   | | '---------------------'                          | |                   | | .---------------------.                          | |                   | || Deprecated Cert 3     |                         | |  .-------------.  | || +-------------------+ | <-----------------------+-+-+ Target Record | | || | Forward RKSP      | |              "Replaces" | |  '-------------'  | || |  .-------------.  | |                         | |                   | || | | Target Record +-+-+-----------------------> | |                   | || |  '-------------'  | | "Replaced by"           | |                   | || +-------------------+ |                         | |                   | | '---------------------'                          | |                   | |                                                  | +-------------------+ |                                                   '---------------------'"RKSP" = Replacement Key Subpacket       Figure 1: Example Topology of Replacement Key SubpacketsShaw & Gallagher          Expires 16 April 2026                 [Page 9]Internet-Draft           OpenPGP Key Replacement            October 20255.  Interpretation of the Replacement Key Subpacket   The relationships expressed by Replacement Key subpackets may be   either singly- or doubly-linked.  Doubly-linked Replacement Key   subpackets have a more consequential interpretation.  If a   Replacement Key subpacket is found in a Key Revocation signature,   then the Reason for Revocation subpacket provides crucial additional   context.5.1.  Identity Equivalence Binding   The existence of a matching pair of forward- and backward-reference   Replacement Key subpackets on the most recent direct self-signatures   or key revocations over two primary keys, with each referring to the   other primary key, forms an Identity Equivalence Binding.  A   collection of certificates whose Identity Equivalence Bindings form a   maximal connected graph (see Section 4.2) is an Identity Equivalence   Set, and all members of that set are said to be Identity Equivalent   to each other.   If an implementation links a particular identity (such as a User ID   or a database record) to one primary key by a means other than   Identity Equivalence, then it SHOULD treat that identity as being   linked, in the same manner and to the same extent, with each other   primary key in the same Identity Equivalence Set. Each such "derived"   identity link is a subsidiary relationship of the original "direct"   identity link.  If the same identity is directly linked into the   Identity Equivalence Set by multiple identity claims, the derived   link(s) are subsidiary to the strongest or most reliable direct link.   A derived identity link is otherwise independent of any identity   claims over the other primary keys, or lack thereof.  Each distinct   identity SHOULD be modelled separately; a direct or derived link to   one identity makes no statement about any other identities found in   the Identity Equivalence Set.   The equivalence binding is invalidated under the following   circumstances:   *  if either primary key is revoked with a Reason for Revocation      other than "Key is superseded".   *  if either primary key overrides the equivalence binding with a new      direct self-signature that a) does not contain a Replacement Key      subpacket, or b) contains a Replacement Key subpacket that does      not refer to the other key, or c) contains a Replacement Key      subpacket that inverts the direction of the binding, and there is      no corresponding update to the other certificate.Shaw & Gallagher          Expires 16 April 2026                [Page 10]Internet-Draft           OpenPGP Key Replacement            October 2025   *  if either signature that forms the equivalence binding has      expired.   Note however:   *  If either primary key is expired or revoked with a Reason for      Revocation of "Key is superseded", the equivalence binding is      unaffected.   *  If either primary key is revoked with any other Reason for      Revocation, then the equivalence binding is invalidated but the      other key is not revoked.   *  Other properties (such as expiry dates, usage preferences, custom      notations) SHOULD NOT be applied to other members of the Identity      Equivalence Set.   If a backward Replacement Key subpacket refers to multiple deprecated   keys, it is possible that only some of those have a valid Identity   Equivalence Binding.  If a particular Identity Equivalence Binding is   invalid, it does not invalidate the other bindings associated with   the same backward Replacement Key subpacket.   Identity Equivalence is transitive; if A and B are both Identity   Equivalent to C (in other words, if C replaces both A and B), then A   is also Identity Equivalent to B.  This transitivity is the basis for   an Identity Equivalence Set, in which an identity linked to any of   the primary keys is linked to them all.  This equality of identity,   and the distinction between direct and derived identity links, is   independent of the order of preference of fallback primary keys   (Section 4.2).   Members of an Identity Equivalence Set MUST be treated as a single   key for the purposes of the Web of Trust, particularly when relying   on multiple independent certification pathways.5.1.1.  Time Evolution of Identity Equivalence   An implementation MUST NOT assume that Identity Equivalence Bindings   have any permanent significance.  For example, if an MUA relies   solely upon an Identity Equivalence Binding between A and B to   validate B, the validity of B at a future date depends on the   continuing validity of the Identity Equivalence Binding.  If the   binding is no longer valid, and there are no other certification   pathways to B, then B is no longer valid.Shaw & Gallagher          Expires 16 April 2026                [Page 11]Internet-Draft           OpenPGP Key Replacement            October 2025   It is therefore RECOMMENDED that applications attempt to find   alternative certification pathways for replacement certificates.  The   optimal method of obtaining alternative certification pathways is   application-dependent, and therefore beyond the scope of this   document.  It should be noted however that similar time evolution   concens also apply to other methods of validation, such as the Web of   Trust.5.1.2.  Consequences of Identity Equivalence   Identity Equivalence Binding operates at the same conceptual level as   subkey binding.  A subkey is linked to a particular identity if its   primary key is linked to that identity.  It is not possible to limit   the use of particular subkeys of the same primary to particular   identities.   Similarly, a primary key is linked to an identity if any of the   primary keys in its Identity Equivalence Group is so linked.  This   means that it is not possible to limit the use of particular   certificates in the group to particular identities.  Any identities   that the key owner's correspondents link to any member of an Identity   Equivalence Group will be equally linked to them all.   For example, if a key owner has a particular User ID in one   certificate, but not in an Identity Equivalent certificate, her   correspondents will still link that User ID with both certificates.   If so, they may (in some circumstances) send messages encrypted to   one of the certificates but addressed to an identity which that   particular certificate does not claim.   An implementation SHOULD warn the user if they try to create an   Identity Equivalence Group using certificates with mismatched current   User IDs.  It SHOULD similarly warn the user if they try to add a new   User ID to only one member of an Identity Equivalence Group, and (if   possible) offer to add it to all members instead.   This is a design limitation of the Key Replacement mechanism.  Since   Section 10.1 of [RFC9580] does not require a certificate to contain a   User ID, it MUST still be possible to link an identity to it by other   means.  If we were to require matching User IDs for Identity   Equivalence, the Replacement Key mechanism would not be fully   functional for identity links that did not rely on User IDs.Shaw & Gallagher          Expires 16 April 2026                [Page 12]Internet-Draft           OpenPGP Key Replacement            October 20255.2.  Absence of an Identity Equivalence Binding   The Replacement Key subpacket MUST NOT be treated as a Web of Trust   certification over either the current or replacement primary key.  In   the absence of an Identity Equivalence Binding, a receiving   implementation SHOULD validate the replacement certificate as they   would any other.   If an implementation supports the creation of unpaired Replacement   Key subpackets, it SHOULD warn the key owner that correspondents may   not be able to use the preferred certificate in the absence of other   means of identity verification.  For example, it could prompt the key   owner to ask the third parties who certified the User ID(s) on the   deprecated certificate to certify the corresponding User ID(s) on the   replacement.5.2.1.  Limiting Chaining of Non-Equivalent Replacements   It is possible for a singly-linked chain of certificates to exist,   where each (non-final) certificate contains a valid forward   Replacement Key subpacket with no equivalence binding.  Such a chain   may terminate, or may form a closed loop.  A generating   implementation SHOULD NOT intentionally create singly-linked chains   or loops, however they may be encountered in practice as a result of   a stale cache, user or implementation error, or malice.   It may be possible for the certificates in a singly-linked chain to   be validated without Identity Equivalence Bindings, such as by   provenance or Web of Trust.  In such a scenario, a receiving   implementation might be induced to process the chain of references   until it found the end, or a certificate that did not validate.  An   implementation SHOULD limit the maximum number of references it   follows (per invocation), and/or implement a loop detection mechanism   to prevent following a closed loop of references indefinitely.   For example, a receiving implementation MAY choose to process only   one unpaired forward Key Replacement subpacket per invocation.  Such   an implementation MAY however process a subsequent unpaired subpacket   on its next invocation, if the current certificate in the chain   successfully validated.  While this could result in unstable   behaviour, where the apparent preferred certificate of the   correspondent changes continually, each invocation will consume a   finite amount of resources.Shaw & Gallagher          Expires 16 April 2026                [Page 13]Internet-Draft           OpenPGP Key Replacement            October 20255.3.  Reasons for Revocation   If a Key Revocation signature contains a Replacement Key subpacket, a   Reason for Revocation subpacket MUST also be included, to prevent it   from being interpreted as "No reason specified".   *  if a Replacement Key subpacket is included in a Key Revocation      signature, then the Reason For Revocation subpacket MUST indicate      "Key is superseded".   *  if no Replacement Key subpacket is included in a Key Revocation      signature, but a Replacement Key might be specified at a later      date, then the Reason For Revocation subpacket MAY indicate "Key      is superseded".   *  otherwise, the Reason for Revocation subpacket SHOULD indicate      "Key is retired and no longer used", to explicitly state that the      revoked primary key has no replacement.   A receiving implementation MUST ignore any Reason for Revocation   subpacket present in a Key Revocation signature with a Reason for   Revocation that is not "Key is superseded".6.  Selection of Encryption Subkeys   If a replacement certificate has been validated, whether as a member   of an Identity Equivalence Set or otherwise, correspondents SHOULD   assign it preference over the current certificate.  When a   correspondent of the key owner selects subkeys for encryption, the   subkeys in the replacement certificate SHOULD therefore be considered   first.  If the subkeys in the replacement certificate are not usable,   then:   *  If there is an equivalence binding, the subkeys in the first      listed deprecated certificate SHOULD be considered next.  If the      subkeys in the first deprecated certificate are not usable, then      the subkeys in the next deprecated certificate (if any) SHOULD be      considered, and so forth.   *  If there is no equivalence binding, the subkeys in the current      certificate SHOULD be used.   When encrypting to herself, the key owner MAY use a different   encryption subkey selection algorithm from the one used for her   correspondents.Shaw & Gallagher          Expires 16 April 2026                [Page 14]Internet-Draft           OpenPGP Key Replacement            October 20257.  Security Considerations   If the Replacement Key subpacket was allowed in the unhashed   subpackets area, an attacker could add a bogus Replacement Key   subpacket to an existing signature.   An Identity Equivalence Binding requires the active consent of both   primary key owners.  This is to prevent one key owner from   unilaterally claiming signatures made by the other key owner, using   the same argument that motivates the embedded Primary Key Binding   signature in a signing-capable subkey's binding signature   (Section 5.2.1.9 of [RFC9580]).   The Target Key Imprint is included to mitigate against weaknesses in   the fingerprint digest algorithm used by older key versions.  By   including a digest over the key material in the target primary public   key packet, using the same digest algorithm as the enclosing   signature, we ensure that the indirect cryptographic binding between   the equivalent keys is of the same overall strength as a signature   made directly over the target primary public key (as in a   certification signature or subkey binding signature).  We   intentionally chose not to use embedded back-signatures or third-   party certifications, both to keep the design simple and to limit the   size of the subpacket(s) required.   In the absence of a complete Identity Equivalence Binding, the   Replacement Key subpacket is merely advisory.  In this scenario, it   provides information for the purposes of key discovery only, without   any actionable statement about the User IDs on the replacement.   In addition, as this document is an update of [RFC9580], the security   considerations there should be carefully reviewed.8.  IANA Considerations   This document requests that the following entry be added to the   OpenPGP Signature Subpacket registry:           +=================+=================+===============+           | Type            | Name            | Specification |           +=================+=================+===============+           | 100 (TEMPORARY) | Replacement Key | This document |           +-----------------+-----------------+---------------+                   Table 3: Signature Subpacket Registry9.  ReferencesShaw & Gallagher          Expires 16 April 2026                [Page 15]Internet-Draft           OpenPGP Key Replacement            October 20259.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/rfc/rfc2119>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.   [RFC9580]  Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,              "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,              <https://www.rfc-editor.org/rfc/rfc9580>.9.2.  Informative References   [Autocrypt]              Breitmoser, V., Krekel, H., and D. K. Gillmor, "Autocrypt              - Convenient End-to-End Encryption for E-Mail", n.d.,              <https://autocrypt.org/>.   [I-D.koch-openpgp-webkey-service]              Koch, W., "OpenPGP Web Key Directory", Work in Progress,              Internet-Draft, draft-koch-openpgp-webkey-service-20, 2              June 2025, <https://datatracker.ietf.org/doc/html/draft-              koch-openpgp-webkey-service-20>.Appendix A.  Example Workflows   In the following, Alice has a v4 primary keypair and subsequently   generates a new v6 primary keypair, then at a later date she revokes   her v4 primary key.  Bob is her correspondent who consumes the   updated certificate(s).  We do not assume that Alice's secret keys   are stored on the same hardware device.A.1.  Alice Generates a New Primary KeyA.1.1.  Alice's Actions   If Alice's client supports v6 certificates, and Alice only has a v4   certificate, it may suggest to Alice that she should generate a v6   primary keypair and certificate.  If the secret key material for the   v4 certificate is available, the client may offer to generate the new   keypair and certificate automatically.  The client should warn Alice   of potential compatibility issues with any other devices that she may   have which share the v4 secret key material.  The client should also   perform pre-flight checks that may include:Shaw & Gallagher          Expires 16 April 2026                [Page 16]Internet-Draft           OpenPGP Key Replacement            October 2025   *  Refreshing the certificate from the internet to check whether      another client has already created a replacement.   *  Attempting to sync with other devices in a multi-device      deployment, e.g. by emailing itself.   On creation of a v6 primary keypair and certificate, Alice's client   will:   *  Add a Direct Key signature to Alice's new (v6) certificate,      including a backward Replacement Key subpacket that references her      deprecated v4 certificate.   *  If the deprecated (v4) secret key is available, add a new Direct      Key signature to its certificate with a forward Replacement Key      subpacket that references the v6 replacement.   *  Publish the updated certificate(s) to a keyserver.   *  Back up the new secret key material and (if necessary) sync it to      any other devices.A.1.2.  Bob's Actions   *  Bob wants to send Alice a message and has Alice's deprecated (v4)      certificate.   *  Either Bob's copy of Alice's deprecated certificate already has a      Replacement Key subpacket that references her replacement (v6)      fingerprint, or Bob refreshes Alice's deprecated certificate from      a keyserver and sees the new Replacement Key subpacket.   *  If Bob has a v6 implementation, it can proceed with fetching      Alice's v6 replacement certificate, validating it, and using it to      send his message to Alice.   *  If Bob doesn't have a v6 implementation, it can continue to use      Alice's v4 deprecated certificate.   (WKD does not currently allow more than one valid certificate to be   returned for a query, therefore it cannot easily support this use   case.)   Bob's client has previously marked Alice's deprecated certificate as   usable for her email address.  If this was done directly (as opposed   to via the Web of Trust), Bob's client may also directly mark her   replacement certificate as usable.Shaw & Gallagher          Expires 16 April 2026                [Page 17]Internet-Draft           OpenPGP Key Replacement            October 2025A.1.3.  Alice's Second Device   Alice's client should perform regular consistency tests, by   performing the pre-flight checks above to discover whether another   client or device has published a different replacement certificate.   In such a scenario, the client should warn the user and attempt to   reconcile the differences by first syncing the secret key material,   and then updating the older "replacement" certificate to be an   additional deprecated certificate for the newer replacement, and   finally updating the proper replacement certificate to refer to the   additional deprecated certificate.A.2.  Alice Revokes Her Deprecated Primary KeyA.2.1.  Alice's Actions   On revocation of her v4 primary key, Alice's client will:   *  Add a forward Replacement Key subpacket to the Primary Key      Revocation signature, referencing the replacement.   *  If the replacement secret key is available, add a new Direct Key      signature to its certificate with a new or updated backward      Replacement Key subpacket that references the deprecated      certificate.   *  Publish the updated certificate(s) to a keyserver.A.2.2.  Bob's Actions   Bob already has both Alice's v4 and v6 certificates.   *  Bob's client refreshes Alice's certificates from a keyserver; her      deprecated certificate contains a Primary Key Revocation signature      with a Replacement Key subpacket but the preferred certificate is      unchanged.   *  There is an Identity Equivalence Binding between the deprecated      and replacement certificates, which Bob's client automatically      validates.   *  Bob's v6-aware client continues to use Alice's preferred      certificate as before.   Bob's client has previously marked Alice's deprecated certificate as   usable for her email address.  If it has not yet directly marked   Alice's replacement certificate as usable, it should do so now to   remove the requirement to validate the now-revoked v4 certificate.Shaw & Gallagher          Expires 16 April 2026                [Page 18]Internet-Draft           OpenPGP Key Replacement            October 2025A.2.3.  Carol's Actions   Carol wants to send Alice a message; Carol has Alice's deprecated   (v4) certificate but they have not corresponded for some time.   *  Carol's client refreshes Alice's deprecated certificate from a      keyserver; it contains a Primary Key Revocation signature with a      Replacement Key subpacket.   *  Carol's client looks up Alice's replacement (v6) certificate on a      keyserver.   *  There is an Identity Equivalence Binding between the deprecated      and replacement certificates, which Carol's client automatically      validates.   *  Carol's client uses Alice's replacement certificate instead of the      deprecated certificate.   (There are other means to achieve a similar result, such as WKD   [I-D.koch-openpgp-webkey-service] or [Autocrypt], but they may not be   available.  For example, Alice's service provider may not support   WKD, and Alice may not have sent Carol an autocrypt message since   revoking her deprecated primary key.)   Carol's client has previously marked Alice's deprecated certificate   as usable for her email address.  Carol's client should now directly   mark Alice's replacement certificate as usable.A.2.4.  Alice's Second Device   On receipt of the new (v6) certificate on a second device, Alice's   second client will:   *  Check to see if the certificate contains an unpaired backward      Replacement Key subpacket that refers to any of the available      secret keys.   *  If the reference is correct and Alice consents, add a Direct Key      signature to the affected certificate with a forward Replacement      Key subpacket.   *  Publish the updated certificate to a keyserver.   If Alice has a local encryption subkey that she prefers for   encryption to herself, her client MAY use it regardless of any   Replacement Key subpacket(s) in her published certificate.Shaw & Gallagher          Expires 16 April 2026                [Page 19]Internet-Draft           OpenPGP Key Replacement            October 2025A.3.  Time Evolution of an Identity Equivalence Group   Let’s say that Alice has two deprecated keys (one RSA and one ECC),   and a replacement key (ML-DSA).  Let’s also say that she has the   identity alice@example.com on the RSA and ML-DSA keys, and the   identity a.lovelace@example.com on the ECC and ML-DSA keys.                                                   .-----------------------.                                                  | Alice's ML-DSA Key      |        Bob's Second Signature--------------------+-> alice@example.com     |                                                  | a.lovelace@example.com  |Bob's First Signature---------.                   | +---------------------+ |                               |                  | | Backward RKSP       | | .------------------------.    |                  | |                     | || Alice's RSA Key          |   |                  | |                     | || alice@example.com <------+--'                   | |  .-------------.    | || +----------------------+ | <--------------------+-+-+ Target Record |   | || | Forward RKSP         | |           "Replaces" | |  '-------------'    | || |  .-------------.     | |                      | |                     | || | | Target Record +----+-+--------------------> | |                     | || |  '-------------'     | | "Replaced by"        | |                     | || +----------------------+ |                      | |                     | | '------------------------'                       | |                     | |                                                  | |                     | |                Bob's Third Signature             | |                     | |                             |                    | |                     | | .------------------------.  |                    | |                     | || Alice's ECC Key          | |                    | |                     | || a.lovelace@example.com <-+'                     | |  .-------------.    | || +----------------------+ | <--------------------+-+-+ Target Record |   | || | Forward RKSP         | |           "Replaces" | |  '-------------'    | || |  .-------------.     | |                      | |                     | || | | Target Record +----+-+--------------------> | |                     | || |  '-------------'     | | "Replaced by"        | |                     | || +----------------------+ |                      | |                     | | '------------------------'                       | |                     | |                                                  | +---------------------+ |                                                   '-----------------------'"RKSP" = Replacement Key Subpacket             Figure 2: Bob's View of Alice's Certificates   If Bob has made a certification signature (1) over alice@example.com   and the RSA key, then from his point of view there is a direct   identity link between alice@example.com and her RSA key, and a   derived identity link (via equivalence) between it and both of the   other two keys.  These derived links are subsidiary to the direct   link and do not have an independent existence - if Bob’sShaw & Gallagher          Expires 16 April 2026                [Page 20]Internet-Draft           OpenPGP Key Replacement            October 2025   certification expires, the direct link is invalidated and by   extension the derived links are also invalidated.  If however Bob   also made a certification signature (2) over Alice’s ML-DSA key, then   the expiration of the first certification would not invalidate the   second, and all three keys would remain linked to alice@example.com -   but now Bob’s certification over the ML-DSA key would anchor the   direct identity link, and the link between alice@example.com and her   RSA key would now be equivalence-derived.   None of the above has any consequence for the identity   a.lovelace@example.com.  Bob knows of no proof that Alice owns that   email address, and while her ECC certificate may claim   a.lovelace@example.com, and we may therefore infer that the owner of   the other certificates also claims a.lovelace@example.com (because   equivalence implies they are the same person), there is no supporting   evidence to elevate any of these claims to a concrete link.   But let’s say that Bob then receives an email from   a.lovelace@example.com with the ML-DSA certificate in its [Autocrypt]   header.  He MAY therefore infer that the identity   a.lovelace@example.com is directly linked (via the TOFU principle) to   the ML-DSA certificate - and thereby also to the other two   certificates.  This TOFU-based direct identity link may be considered   “weaker” than one based on a certification signature, and so the   derived identity links on the other two certificates SHOULD be   considered equally “weak".  If Bob subsequently certifies (3) the   identity a.lovelace@example.com on the ECC key (for example), all the   derived links would become subsidiary to that link, and also become   equally “strong”.Appendix B.  Acknowledgments   The authors would like to thank Bart Butler, Kai Engert, Daniel Kahn   Gillmor, Daniel Huigens, Simon Josefsson, Johannes Roth, Heiko   Schäfer, Falko Strenzke, Neal Walfield, Justus Winter and Aron   Wussler for suggestions and discussions.Appendix C.  Document History   Note to RFC Editor: this section should be removed before   publication.C.1.  Changes Between draft-ietf-openpgp-replacementkey-05 and -06   *  Specified "current" Replacement Key subpacket.   *  Record length is now one octet again.Shaw & Gallagher          Expires 16 April 2026                [Page 21]Internet-Draft           OpenPGP Key Replacement            October 2025   *  Removed references to "hard" and "soft" revocation reasons, and      tightened BCP14 language around reasons.   *  Cleaned up artwork.   *  Improved example workflows.   *  Various minor clarifications.C.2.  Changes Between draft-ietf-openpgp-replacementkey-04 and -05   *  Key Equivalence is now Identity Equivalence.   *  Specified Identity Equivalence Sets.   *  Defined terms "identity", "identity claim", "identity link",      "direct link", "derived link".   *  Moved 0x40 to 0x01 and renamed from "inverse relationship" to      "backward reference(s)".   *  Substituted "original" with "deprecated".   *  Expanded and improved "Terminology" section.   *  Merged content of "Placement of the Replacement Key Subpacket"      section into other sections.   *  Removed reference to draft-ietf-openpgp-persistent-symmetric-keys      (but kept the surrounding text).   *  Renamed and reordered some sections.   *  Added receiving implementation MUSTs in several places.   *  Various minor clarifications.C.3.  Changes Between draft-ietf-openpgp-replacementkey-03 and -04   *  Made target records forward-compatible.   *  Added additional guidance for Alice's client.   *  Removed unnecessary reference to WKD.   *  Removed requirement for unilateral reference to be treated as a      preference.Shaw & Gallagher          Expires 16 April 2026                [Page 22]Internet-Draft           OpenPGP Key Replacement            October 2025   *  Modified wording to avoid incompatibility with future encryption      subkey selection draft.C.4.  Changes Between draft-ietf-openpgp-replacementkey-02 and -03   *  Added section clarifying time evolution of equivalence.   *  Added section clarifying how to prevent resource exhaustion when      following chains.   *  Clarified description of equivalence transitivity.C.5.  Changes Between draft-ietf-openpgp-replacementkey-01 and -02   *  Added explanation of hard vs soft revocations.   *  Remove the "No Replacement" bit and use the Reason for Revocation      subpacket instead.   *  Record length field is now two octets.   *  Inverted treatment of undefined flag bits.   *  Remove references to the Preferred Key Server subpacket.   *  Expanded example workflows section and add reference to draft-      ietf-openpgp-persistent-symmetric-keys.   *  Various terminology nitpicking.C.6.  Changes Between draft-ietf-openpgp-replacementkey-00 and -01   *  Updated references to RFC9580.   *  Removed subpacket version octet.   *  Added guidance for encryption subkey selection.   *  Added record length fields.   *  Renamed to "OpenPGP Key Replacement" and normalised terminology.C.7.  Changes Between draft-gallagher-openpgp-replacementkey-02 and      draft-ietf-openpgp-replacementkey-00   *  Standardised capitalisation and terminology.Shaw & Gallagher          Expires 16 April 2026                [Page 23]Internet-Draft           OpenPGP Key Replacement            October 2025C.8.  Changes Between draft-gallagher-openpgp-replacementkey-01 and -02   *  Specified Public Key Imprints.   *  Specified inverse relationship flag and packet format.   *  Restricted graph topology.   *  Specified Identity Equivalence Binding.   *  Guidance re subpacket placement escalated from SHOULD to MUST, and      critical bit to SHOULD NOT.C.9.  Changes Between draft-gallagher-openpgp-replacementkey-00 and -01   *  Added example workflows.   *  Specifically describe "deprecation without expiry or revocation"      use case.   *  Add note about weakness of signatures over fingerprints.   *  Miscellaneous clarifications.C.10.  Changes Between draft-shaw-openpgp-replacementkey-00 and draft-       gallagher-openpgp-replacementkey-00   *  Changed algid octet to key version octet.   *  Changed initial subpacket version number to 1.   *  Clarified semantics of some edge cases.Authors' Addresses   Daphne Shaw   Jabberwocky Tech   Email: dshaw@jabberwocky.com   Andrew Gallagher (editor)   PGPKeys.EU   Email: andrewg@andrewg.comShaw & Gallagher          Expires 16 April 2026                [Page 24]