| Internet-Draft | OpenPGP identifiers for legacy devices | August 2026 |
| Schäfer | Expires 25 February 2027 | [Page] |
This document describes an approach for storing a shortened fingerprint-based identifier for OpenPGP private key material on hardware security devices.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-hko-openpgp-identifiers-for-legacy-devices/.¶
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/.¶
Source for this draft and an issue tracker can be found at https://codeberg.org/heiko/openpgp-identifiers-for-legacy-devices.¶
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 25 February 2027.¶
Copyright (c) 2026 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.¶
Private key material for OpenPGP component keys may be stored on hardware security devices (also see [I-D.dkg-openpgp-external-secrets]). Some such devices offer informational data fields for key identification based on OpenPGP fingerprints.¶
Many currently available hardware devices that target use with OpenPGP keys offer 20 octet identifier fields (originally designed to store OpenPGP v4 fingerprints).¶
For example, the "OpenPGP card" specification defines a 20 octet "fingerprint" field for each secret key packet stored on the card (see page 23 in [OPENPGP-SMARTCARD], under the tag "C5"). These fields were sized for OpenPGP version 4 fingerprints (based on SHA-1 hashes). Note that the field's name is "fingerprint", since that was its original intended use.¶
This document describes an interoperable scheme for using such size-constrained identifier fields to refer to OpenPGP component keys with version > 4. It deals with two limitations of existing identifier fields:¶
They don't allow storing the key packet version.¶
Modern OpenPGP fingerprints exceed the field size. For example, OpenPGP version 6 key packets use 32 octet SHA-256 fingerprints (see Section 5.5.4.3 of [RFC9580]).¶
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.¶
"Transferable Secret Key" or just "TSK" refers to an OpenPGP Transferable Secret Key (see Section 10.2 of [RFC9580]).¶
"Component key" refers to a single key object found within an OpenPGP certificate. A certificate's primary key is a "component key", and any subkey in the certificate is also a "component key".¶
"Keyholder" is the party that has legitimate access to the secret key material corresponding to the component keys in a certificate. The keyholder can sign messages that can be verified with the certificate, decrypt messages that were encrypted to the certificate, and update the certificate itself over time.¶
This draft describes an interoperable scheme for using a class of widely available hardware security devices (such as the "OpenPGP card" family of devices) for OpenPGP key packets with version > 4.¶
This scheme may be applied to handle OpenPGP key packets on hardware security devices that have 20 octet-sized informational key identification fields. The scheme MUST NOT be applied in other contexts, without a specification that describes why it is appropriate for that context.¶
This draft also outlines current practices for handling OpenPGP v4 keys on such devices, as informational context.¶
For the last decades, hardware security devices used for OpenPGP keys have typically stored full v4 key fingerprints as identifiers. While this fingerprint information is not required for performing cryptographic operations, it is useful for various purposes. More on this below.¶
Since identifier fields on many existing devices are size-limited, full modern fingerprints can not be stored in them. Separately, the key packet version can also not be stored explicitly.¶
This draft proposes an approach to storing identifiers for modern OpenPGP keys on existing hardware. The identifier scheme described here aims to match the properties of existing practice for v4 keys as closely as possible.¶
The identifier value stored on hardware devices can serve some or all of the following purposes.¶
Bare key material on a hardware device may be associated with different protocols. Even on "OpenPGP card" devices, some users may store cryptographic key material that is associated with other (non-OpenPGP) protocols.¶
It can be useful for applications to detect whether a key on a device is associated with an OpenPGP component key.¶
This detection is currently possible for v4 OpenPGP keys by testing if the v4 fingerprint stored on the device corresponds to the public key material stored on the device.¶
This draft extends this property for key version > 4.¶
Users or software can easily detect the OpenPGP key packet version of keys on a hardware device.¶
By default, version 4 is assumed, for historical reasons.¶
The scheme described in this draft explicitly encodes the key packet version in the identifier, for key packet version > 4.¶
Users or software can easily compare the identifier stored on a hardware device with fingerprints that are known to them.¶
By default, the identifier field is assumed to contain the fingerprint of a version 4 OpenPGP key packet.¶
The scheme described in this draft stores an 8 octet fingerprint prefix in the identifier field for key packet version >4. This fingerprint prefix can be visually inspected by users, or leveraged by applications for different purposes (more on this below).¶
Some applications may want to reconstruct the exact OpenPGP key packet that is associated with key material on a hardware device, without having a separate copy of the full key packet available.¶
The identifier field can be used to achieve positive confirmation that an OpenPGP key packet has been correctly reconstructed from the public parameters and metadata stored on the device.¶
This positive confirmation validates all parameters of a key packet, including the public key material, version number, creation time, algorithm id, additional elliptic curve or KDF parameters.¶
Validation of a reconstructed key packet is possible both for version 4 and version > 4, with the scheme outlined in this draft.¶
Note that this validation has the benefit that an application can detect cases where it doesn't interpret the intended usage of key material on a device correctly (e.g. because it doesn't implement some newer draft yet, and the data on the card is ambiguous and allows misinterpretation of the key as a format that the implementation does know about). This enables applications to back off gracefully and intentionally, instead of using key material in an unintended way, with potentially confusing outcomes for users.¶
This draft describes 20 octet-sized identifiers that represent OpenPGP key packets. These identifiers can be stored on hardware devices with fields of that fixed length.¶
Fingerprints for v4 key packets have been stored verbatim on devices with 20 octet identifier fields.¶
This draft notes this practice, and does not propose handling v4 key packets differently, going forward. However, this existing use of the identifier field interacts with this draft, which outlines a different mode of using the same field for keys with version > 4.¶
Existing practice for storing v4 key packets needs to be taken into account by implementers. Even implementations that don't support v4 keys need to be able to gracefully handle identifier fields that contain verbatim v4 fingerprints.¶
To store a fingerprint-based key identifier on a hardware device for OpenPGP keys with a version > 4, instead of the full fingerprint, applications should store the concatenation of:¶
The version marker clearly identifies the key packet version, while the fingerprint prefix enables both visual inspection and positive confirmation if key material on the device is associated with a specific OpenPGP key packet.¶
To encode an OpenPGP key packet with version > 4, applications should store the concatenation of the following two parts:¶
12 octets of version marker, consisting of 11 copies of the value 0x00, followed by one octet of the key version. For a version 6 key, the version marker is 000000000000000000000006.¶
The leftmost 8 octets of the full fingerprint.¶
Note that the legal values of the version marker overlap with a part of the v4 fingerprint namespace. Some legitimate v4 fingerprints will be interpreted as post-v4 identifiers, under this scheme (more on this below). The size of the version marker is intentionally large, so that the subset of the v4 fingerprint namespace that it overlaps with is small.¶
The full version 6 fingerprint of the primary key packet of the Transferable Secret Key in Appendix A.4 of [RFC9580] is cb186c4f0609a697e4d52dfa6c722b0c1f1e27c18a56708f6525ec27bad9acc9.¶
When uploading this component key to e.g. an OpenPGP card device, the identifier on the card should be set to 000000000000000000000006cb186c4f0609a697.¶
This text proposes use of (effectively) an 8 octet identifier to recognize a key on an OpenPGP card, instead of previously a 20 octet identifier.¶
This raises the question if there are any risks associated with that shortened identifier.¶
Conceivable risks fall into at least two classes:¶
Accidental occurrence of a duplicate identifier in a user's context.¶
Attackers who intentionally cause a duplicate identifier to be present in a user's context.¶
It is important to keep in mind that the identifiers stored on hardware security devices only exist within the user's local computing environment. They are only visible locally, when a user plugs in, for example, a USB device that implements the "OpenPGP card" application.¶
Accidental collisions of 8 octet fingerprint prefixes between multiple hardware-backed component keys in a user's local environment are exceedingly unlikely.¶
And even if they were to occur, they could be detected safely by applications, e.g. by reconstructing the full key packet and checking the complete fingerprint for each hardware-backed key.¶
This case only arises if an attacker can introduce hardware security devices into a user's computing environment.¶
For example, when an attacker underhandedly replaces a user's OpenPGP card.¶
In such a scenario, it's unclear that this draft - and in particular, the 8 octet fingerprint prefix stored as part of the identifier - adds any risks over the status quo for v4 key packets:¶
If an application takes the identifier field at face value, then an attacker can mislead the user by writing any value into that field, on a device that is used in an attack (including in the pre-existing v4 case). A longer value doesn't improve the situation, there.¶
Assuming an "honest" device (which reports the public key material correctly): If an application checks for consistency between the reported public key material and the reported identifier, it would require non-trivial effort to find an 8 octet collision with a pre-existing user key.¶
However, the user's software is not limited to checking the 8 octets of fingerprint prefix in the identifier field. It can instead compare the full fingerprint on the reconstructed key packet against the expected fingerprint.¶
Assuming a "dishonest" device (which reports "untrue" public key parameters to the host system), an attacker can mislead a user independent of the identifier scheme used. A dishonest device can report the expected public key material and fingerprint values, independent of the private key material on the device. The private key material that a hardware security device uses can by definition not be inspected directly by the host system.¶
In short, relying on self-reported information from a hardware device is always a losing proposition, if the device is malicious. This draft does not attempt to mitigate the risks associated with adversarial devices.¶
(As a side-note, it is unclear under which circumstances an attacker benefits from causing a target keyholder to use a different private key than the one they intended to use. While there might be edge cases in which such attacks that are important to consider, underhandedly replacing a user's private key material is not a typical attack scenario.)¶
When using the identifier scheme outlined in this text, applications can determine if a hardware device contains key material that corresponds to a given OpenPGP key packet, as follows:¶
Given an OpenPGP key packet, the application determines that component key's full fingerprint.¶
If the key packet is newer than version 4, the application considers only the leftmost 8 octets of the full fingerprint.¶
The application then checks that:¶
If a key on the device matches this identifier convention, the application assumes that it contains the expected key material.¶
In some contexts, it may be desirable to determine the full OpenPGP fingerprint of the OpenPGP key packet that corresponds to an on-device key, without relying on any data that is external to the device.¶
For example, given an OpenPGP card device, without any additional context, it is not possible to perform a keyserver lookup for an OpenPGP v6 key, based on the shortened identifier field alone:¶
Privacy-preserving public key servers don't allow lookup of version 6 keys by 8 octet fingerprint prefix. To perform a lookup on such a keyserver, the full 32 octet fingerprint is needed.¶
To obtain the full fingerprint of a post-v4 key that is stored on a legacy hardware device, applications can use the following method:¶
For the on-device key, the application obtains the following information from the device:¶
The basic algorithm setting (e.g. RSA, ECDH).¶
The key version (e.g. 0x06), if the first 12 octets of the identifier conform to the "version marker" format defined above.¶
8 octets of fingerprint prefix, from the identifier field.¶
The (4 octet) key creation timestamp.¶
The public key parameters of the key.¶
From this information, the application can construct a set of candidate OpenPGP public key packets, by iterating over all key packet properties that are unspecified on the card (for example, the set of plausible KDF parameters for ECDH key packets). Usually, this search space will be small, often it contains just one candidate.¶
The key packet version may be assumed to be 0x04, if the first 12 octets of the identifier on an OpenPGP card device don't conform to the "version marker" format. If the first 12 octets of the identifier do conform to the "version marker" format, the encoded version value is taken as the key packet's version number.¶
The full OpenPGP fingerprint is calculated for each of the candidate public key packets.¶
For key packets with version > 4, if the fingerprint of a candidate public key packet matches the 8 octet fingerprint prefix in the identifier, then the application may assume that this candidate public key packet corresponds to the key slot in question.¶
The full OpenPGP fingerprint for that public key packet can now be used for any purpose (e.g. for certificate lookup on a privacy-preserving key server).¶
With the scheme outlined in this text, given a key on a hardware security device, some additional work is needed to find the associated OpenPGP certificate:¶
Because the identifier field on the device only contains the first 8 octets of the full fingerprint, not all certificate lookup methods are directly applicable.¶
If an application has access to a set of certificates, locally, it may be able to search them by the 8 octet fingerprint prefix from the device. Depending on the application, it may be sufficient and acceptable to perform such a local lookup.¶
However, applications should consider if collisions of the 8 octet fingerprint prefix are a concern in the expected threat model of their users.¶
This should not normally be an issue if the lookup is performed on a set of intentionally curated certificates that the user considers controlled by themselves.¶
In order to perform a certificate lookup by fingerprint, an application can perform the "determining the full OpenPGP fingerprint" procedure (as described above), and then perform a network lookup based on the confirmed fingerprint, e.g. from public key servers.¶
Because the scheme outlined here reuses a pre-existing data field (which can legitimately contain any possible value), and uses this field to encode additional information, the scheme necessarily overloads a subset of that field's range of values.¶
This involves a tradeoff. Concretely, the chosen tradeoff is:¶
Identifiers for version 4 key packets with a fingerprint that starts with 12 octets that match the "version marker" format specified above become ambiguous. Such keys on a device would then be (mistakenly) interpreted as key packets with a different version.¶
In other words, to allow explicit encoding of key versions > 4, a (small) portion of the v4 fingerprint namespace gets reserved for special handling.¶
Concretely, the fraction of the v4 fingerprint namespace that becomes unusable with this scheme is 1 : 2^88 (any value in which the first 11 octets are all zero).
This text considers the blocked part of the namespace sufficiently small that it is disregarded in the remainder of the document.¶
Note that applications could in theory recognize and correctly handle OpenPGP v4 keys with fingerprints that start with what looks like a version marker segment. However, it is unclear if the added complexity of such special case handling would be well-spent. This draft does not recommend implementing handling of that case.¶
Since there is redundancy within the on-device data (public key material, associated metadata, and the identifier), the combination of values may appear inconsistent to applications.¶
This is true both for the long-established use of v4 OpenPGP keys on hardware devices and for the scheme outlined in this draft.¶
Such inconsistencies may have different underlying root causes. Those are discussed in the following.¶
Some key material stored on hardware devices (including on "OpenPGP card" devices) is not linked to an OpenPGP key packet.¶
Such keys won't have a consistent OpenPGP identifier set on the device. This fact is unchanged by this draft.¶
In some cases, even though the identifier is in fact consistent with all other on-device data, it may appear inconsistent to an application, because the application does not interpret the flavor of key material on the device correctly.¶
In this case, applications are expected to back off, and - if appropriate from a UX perspective - may inform the user about the issue.¶
When an application cannot find an internally consistent interpretation of the on-device data, it should assume that the device contains key material that it doesn't know how to handle. It must neither use that key on the device, nor alter it without explicit user confirmation.¶
In this case, the application has access to a key on a hardware security device, as well as to a complete representation of the OpenPGP key packet that is associated with this on-device key (e.g. the certificate associated with the hardware device may be available as part of the local state of the application).¶
If the application can verify that the public key material and other data on the device (including algorithm setting and key creation time) corresponds to a key packet that it can handle, and only the identifier information stored on the device is inconsistent, it may consider the key usable, and the identifier on the device to be in error.¶
In this case, the application may use the key on the device. It may also optionally update the identifier field on the device to conform to the guidance in this document.¶
This document does not require any action from IANA.¶
The option space for encoding a 20 octet identifier for a key packet is large. Some substantively different design options that were considered follow:¶
One alternative design could encode the first 20 octets of the full fingerprint on the device, matching the length of the field on the constrained device, without an explicit version marker. With this approach, applications would for example store the first 20 octets of a version 6 fingerprint on an OpenPGP card device.¶
For the version 6 fingerprint of the primary key packet of the Transferable Secret Key in Appendix A.4 of [RFC9580], the identifier on a hardware device would be set to cb186c4f0609a697e4d52dfa6c722b0c1f1e27c1 (truncated from the full fingerprint cb186c4f0609a697e4d52dfa6c722b0c1f1e27c18a56708f6525ec27bad9acc9).¶
This approach would also be practically viable.¶
However, the lack of an explicitly encoded version number is a downside. This is not in itself a reason to reject the approach. However, it has no known upsides that counterbalance this downside.¶
Another alternative design would omit any key-specific data from the identifier field, except for the key's version number.¶
For the version 6 fingerprint of the primary key packet of the Transferable Secret Key in Appendix A.4 of [RFC9580], the identifier on a hardware device would be set to 0000000000000000000000000000000000000006 (as it would be for any other version 6 key packet).¶
This scheme is sufficient for performing cryptographic operations, and it has the advantage that the data on the device can't be internally inconsistent.¶
However, as downsides, this scheme would not allow applications to reason about the key material on a device, in the absence of an externally available copy of the OpenPGP key packet data:¶
The following people have contributed in various ways to this draft, offering reviews, suggestions, corrections, and implementation notes:¶