| Internet-Draft | OpenPGP identifiers for legacy devices | July 2026 |
| Schäfer | Expires 29 January 2027 | [Page] |
This document describes an approach for storing a shortened fingerprint-based lookup hint 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 29 January 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 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 lookup 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 lookup key on a hardware device when the target field is shorter than the fingerprint, instead of the full fingerprint, applications should store the concatenation of:¶
OpenPGP card devices that implement [OPENPGP-SMARTCARD] version 3.4.1 (or earlier) offer a 20 octet lookup 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 lookup hint, 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 lookup hint on the card should be set to 060606060606060606060606cb186c4f0609a697.¶
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 of the same value (e.g. 12 octets of 0x06) become unusable when following the guidance in this text, because they are 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 lookup hints 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 lookup hints 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 lookup hint 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 lookup hint on the card each correspond to the key packet version. b) The following 8 octets of the lookup hint 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 lookup hint 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 lookup hint 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 lookup hint on an OpenPGP card device don't all contain the same value. If each of first 12 octets of the lookup hint does contain the same value, this 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 lookup hint, 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:¶