| Internet-Draft | OpenPGP identifiers for legacy devices | August 2026 |
| Schäfer | Expires 13 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 13 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 lookup based on OpenPGP fingerprints.¶
This document outlines an approach for how to use such identifier fields on hardware devices, when the field size is too constrained for the length of modern 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). However, modern OpenPGP version 6 component keys (as specified in Section 5.5.4.3 of [RFC9580]) use 32 octet (SHA-256) fingerprints, which cannot be directly stored in a 20 octet field.¶
This document describes an approach for using size-constrained identifier fields to refer to OpenPGP component keys with longer fingerprint sizes.¶
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.¶
To store a fingerprint-based key identifier on a hardware device when the target field is shorter than the fingerprint, instead of the full fingerprint, applications should store the concatenation of:¶
A "version marker" that specifies the key packet's version.¶
The leftmost octets of the full fingerprint.¶
OpenPGP card devices that implement [OPENPGP-SMARTCARD] version 3.4.1 (or earlier) offer a 20 octet identifier field for each key that is stored on the hardware device. Note that this field an OpenPGP smart cards is named "fingerprint", for historical reasons.¶
With OpenPGP version 4 keys, the size of the fields on the device matches the length of the OpenPGP fingerprint. However, OpenPGP version 6 keys use 32 octet fingerprints, so it is not possible to store these fingerprints on the card in full.¶
When importing a version 6 (or later) OpenPGP key onto an OpenPGP card device, applications should instead store 20 octets of identifier, concatenating the following two parts:¶
The full version 6 fingerprint of the primary key of the Transferable Secret Key in Appendix A.4 of [RFC9580] is cb186c4f0609a697e4d52dfa6c722b0c1f1e27c18a56708f6525ec27bad9acc9.¶
When uploading this component key to an OpenPGP card device, the identifier on the card should be set to 000000000000000000000006cb186c4f0609a697.¶
The value stored the hardware device as a shortened identifier (stored in the "fingerprint" field for OpenPGP card devices) serves the following purposes:¶
Positive confirmation that an OpenPGP key has been correctly reconstructed from the public key parameters on the card, and associated metadata. This positive confirmation validates any additional parameters (algorithm ID, creation time, version number, EC parameters...). Confirmation of OpenPGP public key packet reconstruction is the main purpose of this scheme.¶
Quick identification of keys stored in slots, by either humans and software. This is a low priority purpose.¶
Quick identification of the key version, by both humans and software. This is a low priority purpose.¶
Because the scheme outlined here limits itself to using a pre-existing data field (which can legitimately contain any possible value), and uses this field to encode additional information, the scheme necessarily involves a tradeoff.¶
Concretely, the chosen tradeoff is:¶
Version 4 key packets with a fingerprint that starts with 12 octets that match the "version marker" format specified above become unusable when following the guidance in this text, because they would be interpreted as key packets with a different version.¶
That is, to allow explicit encoding of key version other than 4, a (small) portion of the fingerprint namespace gets effectively blocked off.¶
This text considers the blocked part of the namespace sufficiently small that it is disregarded in the remainder of the document.
Concretely, the fraction of the v4 fingerprint namespace that becomes unusable with this scheme is 1 : 2^88 (any value in which the first 12 octets all have the same content).¶
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.¶
There are at least two classes of conceivable risks:¶
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 an OpenPGP card device only exist within the user's own local computing environment. They are only visible locally, for example when the user plugs in a USB device that implements the OpenPGP card application. These identifiers are never visible in more global namespaces.¶
It is exceedingly unlikely that the 8 octet prefix of an OpenPGP fingerprint has an accidental collision with a second card-backed component key, within any user's local environment.¶
First, it is unclear under which circumstances an attacker benefits from causing a target keyholder to use a different private key than the one they intend to use. While there might be attacks that are important to consider, underhandedly replacing a user's private keys is not a typical attack scenario.¶
Given that, this scheme does not add much new attack surface for an attacker who underhandedly replaces a user's OpenPGP card:¶
When using an "honest" OpenPGP card device in an attack, it remains non-trivial for an attacker to generate a malicious key pair that shares the 64 bit prefix with the user's key, even if the user relies solely on that identifier to ensure that they are using the correct private key material (however, the user's application is not constrained to checking only the identifier field on the card. It can easily also check that the full public key parameters, as reported by the card, correspond to the expected component key).¶
However, self-reported information from a hardware device cannot be relied on, if the device itself is malicious. A custom "fake" hardware device could report fingerprints and public key material that do not legitimately correspond to the private key material that the card uses.¶
This draft does not attempt to mitigate the risks associated with adversarial devices.¶
When using the method outlined in this text, applications can determine if an OpenPGP card contains the expected key material, as follows:¶
Given an OpenPGP key packet, the application determines that component key's full fingerprint.¶
If the fingerprint length exceeds 20 octets, the application considers only the leftmost 8 octets of the full fingerprint.¶
The application then checks that a) The first 12 octets of the identifier on the card conform to the "version marker" format described above. b) The following 8 octets of the identifier on the card correspond to the leftmost 8 octets of the fingerprint.¶
If the key slot on the card matches this convention, the application assumes that it contains the expected key material.¶
With the scheme outlined in this text, given a key slot on an OpenPGP card device, some additional work may be 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 can search them by (8 octet) fingerprint prefix. Depending on the application, it may be sufficient and acceptable to perform such a local key search.¶
However, applications should consider if collisions of the 8 octet fingerprint prefix are a concern in the expected threat model of their users.¶
In other contexts, it may be necessary to determine the full OpenPGP fingerprint of the key packet on an OpenPGP card device, without relying on any data that is external to the OpenPGP card device.¶
For example, given an OpenPGP card device, without any additional context, it is not possible to perform a keyserver lookup based on the shortened identifier field alone: Privacy-preserving public key servers do not 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 non-v4 key that is stored on an OpenPGP card device, applications can use the following method:¶
For each key stored on an OpenPGP card device, applications obtain the following information from the device:¶
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).¶
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 these candidate public key packets.¶
For key packets with a version greater than 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).¶
This document does not require any action from IANA.¶
An alternative design could encode the first octets of the full fingerprint on the card, 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.¶
This approach would also be practically viable. However, it would be in more tension with the guidance in (Section 14.1 of [RFC9580]).¶
The following people have contributed in various ways to this draft, offering reviews, suggestions, corrections, and implementation notes:¶