Internet DRAFT - draft-gallagher-openpgp-replacementkey
draft-gallagher-openpgp-replacementkey
openpgp D. Shaw
Internet-Draft Jabberwocky Tech
Updates: 4880 (if approved) A. Gallagher, Ed.
Intended status: Informational PGPKeys.EU
Expires: 5 September 2024 4 March 2024
OpenPGP Replacement Key Signalling Mechanism
draft-gallagher-openpgp-replacementkey-00
Abstract
This document specifies a method in OpenPGP to suggest a replacement
for an expired or revoked 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/draft-gallagher-openpgp-
replacementkey. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-gallagher-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/draft-gallagher-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."
Shaw & Gallagher Expires 5 September 2024 [Page 1]
Internet-Draft OpenPGP Replacement Key Signalling Mecha March 2024
This Internet-Draft will expire on 5 September 2024.
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. The Replacement Key Subpacket . . . . . . . . . . . . . . . . 3
4. Format of the Replacement Key Subpacket . . . . . . . . . . . 3
5. Trust and Validation of the Replacement Key Subpacket . . . . 4
6. Placement of the Replacement Key Subpacket . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5
Appendix B. Document History . . . . . . . . . . . . . . . . . . 5
B.1. Changes Between draft-shaw-openpgp-replacementkey-00 and
draft-gallagher-openpgp-replacementkey-00 . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The OpenPGP message format [crypto-refresh] 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.
This document is to specify the format of a signature subpacket to be
optionally included in the revocation signature or in the self-
signature for a key that has an expiration date. This subpacket
contains a pointer to a suggested replacement for the revoked or
expired key.
Shaw & Gallagher Expires 5 September 2024 [Page 2]
Internet-Draft OpenPGP Replacement Key Signalling Mecha March 2024
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.
3. The Replacement Key Subpacket
The replacement key subpacket is a Signature Subpacket as defined in
[crypto-refresh], 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 ([crypto-refresh], 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.
The absence of a replacement key subpacket SHOULD NOT be interpreted
as meaning that there is no replacement for a revoked or expired key.
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.
4. 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
([crypto-refresh], 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
revoked or expired key. All other bits of the class octet are
currently undefined and MUST be set to zero.
Shaw & Gallagher Expires 5 September 2024 [Page 3]
Internet-Draft OpenPGP Replacement Key Signalling Mecha March 2024
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.
5. Trust and Validation of the Replacement Key Subpacket
No unusual trust in the replacement key should be implied by it being
designated as the replacement. Implementations SHOULD validate the
replacement key as they would any other key.
6. 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.
7. 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
[crypto-refresh], the security considerations there should be
carefully reviewed.
Shaw & Gallagher Expires 5 September 2024 [Page 4]
Internet-Draft OpenPGP Replacement Key Signalling Mecha March 2024
8. 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 |
+------+-----------------+---------------+
Table 1: Signature Subpacket Registry
9. Normative References
[crypto-refresh]
Wouters, P., Huigens, D., Winter, J., and N. Yutaka,
"OpenPGP", October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-
crypto-refresh-13>.
[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>.
Appendix A. Acknowledgments
The authors would like to thank Aron Wussler for his contributions.
Appendix B. Document History
Note to RFC Editor: this section should be removed before
publication.
B.1. 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.
Shaw & Gallagher Expires 5 September 2024 [Page 5]
Internet-Draft OpenPGP Replacement Key Signalling Mecha March 2024
Authors' Addresses
Daphne Shaw
Jabberwocky Tech
Email: dshaw@jabberwocky.com
Andrew Gallagher (editor)
PGPKeys.EU
Email: andrewg@andrewg.com
Shaw & Gallagher Expires 5 September 2024 [Page 6]
