]> Jabberwocky Tech

dshaw@jabberwocky.com

PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated key. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the OpenPGP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The OpenPGP message format defines two ways to invalidate a key. One way is that the key may be explicitly revoked via a revocation signature. OpenPGP also supports the concept of key expiration, a date after which the key should not be used. When a key is revoked or expires, very often there is another key that is intended to replace it. A key owner may also create a new key that is intended to deprecate and replace their existing 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 key, but if this is not possible for technical reasons they may continue to use the deprecated key, which remains valid even if it is not preferred. In the past some key owners have created key transition documents, which are signed, human-readable statements stating that a newer key should be preferred by their correspondents. It is desirable that this process be automated through a standardised machine-readable mechanism. This document is to specify the format of a signature subpacket to be optionally included in a revocation signature or self-signature on a key. This subpacket contains a pointer to a suggested replacement for the key that is signed over. This replacement key may then be automatically retrieved and (if supported and validated) used instead of the original key.

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 when, and only when, they appear in all capitals, as shown here.

The Replacement Key Subpacket The replacement key subpacket is a Signature Subpacket as defined in , section 5.2.3.7, 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 (insert this later). A preferred key server subpacket (, section 5.2.3.26) MAY be included in the revocation or self-signature to recommend a location and method to fetch the replacement key. Note however that since this subpacket automatically also applies to the current key, it cannot be used to set the replacement key's preferred keyserver to a different value than that of the current key. The absence of a replacement key subpacket SHOULD NOT be interpreted as meaning that there is no replacement for the current key. The "no replacement" bit SHOULD be used instead (see below). The replacement key subpacket is only meaningful in a key revocation or self-signature. It SHOULD NOT be present in any other sort of signature.

Format of the Replacement Key Subpacket The format of the replacement key subpacket is 1 octet of subpacket version and 1 octet of class, followed by an optional 1 octet of key version and N octets of fingerprint. The subpacket version octet MUST be set to 0x01 to indicate the version of the replacement key subpacket as specified in this document. An implementation that encounters a subpacket version octet that is different than the version(s) it is capable of understanding MUST disregard that replacement key subpacket. Note that if the critical bit for the replacement key subpacket is set, this MAY also mean considering the whole signature to be in error (, section 5.2.3.7). The 0x80 bit of the class octet is the "no replacement" bit. When set, this explicitly specifies there is no replacement for the current key. All other bits of the class octet are currently undefined and MUST be set to zero. If the class octet does not have the 0x80 bit set to indicate there is no replacement, the replacement key subpacket also contains 1 octet for the key version of the replacement key and N octets for the fingerprint of the replacement key. If present, the length of the fingerprint field MUST equal the fingerprint length corresponding to the key version field, e.g. 20 octets for version 4, or 32 octets for version 6. If the intent is to state that the replacement key is unknown, then no replacement key subpacket should be included in the revocation signature. If multiple replacement key subpackets are present, implementations MAY use any method desired to resolve which key (or keys) are the chosen replacement.

Trust and Validation of the Replacement Key Subpacket The existence of a Replacement Key subpacket MUST NOT be considered in any trust calculation over either the current or replacement key. Receiving implementations SHOULD validate the replacement key as they would any other key. If the replacement key is supported, and validates successfully, it SHOULD be preferred over the current key when determining which key to use for correspondence. Since a Replacement Key subpacket only contains a fingerprint and not a full key, the signature made over it forms a weaker binding than a Certification Signature. A key owner SHOULD therefore also make a Certification Signature over the replacement key using their existing key. It is also suggested that the key owner asks the third parties who certified their current key to certify the replacement key. Distribution of the replacement key over a trusted mechanism (such as WKD) MAY also be used to confer legitimacy.

Placement of the Replacement Key Subpacket While nothing prevents using the replacement key subpacket on a subkey revocation or self-signature, it is mainly useful on a primary key revocation or self-signature as a replacement subkey can be directly added by the keyholder with no need for the indirection provided by this subpacket. The replacement key subpacket SHOULD be placed in the hashed section of the signature to prevent a possible key substitution attack. If the replacement key subpacket was allowed in the unhashed section of the signature, an attacker could add a bogus replacement key subpacket to an existing revocation or self-signature.

Security Considerations The replacement key subpacket provides non-sensitive information only. Nevertheless, as noted above, implementations SHOULD NOT trust a replacement key subpacket that is located in the unhashed area of the signature packet, and SHOULD validate the replacement key as they would any other key. In addition, as this document is an update of , the security considerations there should be carefully reviewed.

IANA Considerations This document requests that the following entry be added to the OpenPGP Signature Subpacket registry: Type Name Specification TBC Replacement Key This document

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Example Workflows

Alice Revokes her Key Bob wants to send Alice a message, but they have not corresponded for some time. Bob's client refreshes Alice’s key from a keyserver (by fingerprint); it contains a revocation signature with a replacement key subpacket. Bob's client looks up Alice’s new key from a keyserver (by fingerprint); it is certified by the same people that certified her old key (some of whom Bob may trust) and/or Alice’s old key itself (which Bob's policy may consider sufficient). Bob's client uses Alice’s new key instead of the old key. There are other means to achieve a similar result, such as WKD or Autocrypt, but they may not be available. For example, Alice’s service provider may not support WKD, and Alice may not have sent Bob an autocrypt message since revoking her old key.

Alice Creates a V6 Key Bob wants to send Alice a message and has Alice's v4 key. Either Bob's copy of Alice's key already has the replacement key subpacket pointing to a v6 key, or Bob refreshes Alice's key from a keyserver and sees a new replacement key subpacket. If Bob has a v6 implementation, it can proceed with fetching Alice's v6 key, validating it, etc, and then use it to send his message to Alice. If Bob doesn't have a v6 implementation, it can continue to use Alice's v4 key. WKD does not currently allow more than one valid key to be returned for a query, therefore it cannot easily support this use case.

Acknowledgments The authors would like to thank Daniel Kahn Gillmor, Simon Josefsson, Heiko Schäfer, Falko Strenzke and Aron Wussler for suggestions and discussions.

Document History Note to RFC Editor: this section should be removed before publication.

Changes Between -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.

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.