OpenPGP key identifiers for legacy hardware devices
draft-hko-openpgp-identifiers-for-legacy-devices-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Heiko Schaefer | ||
| Last updated | 2026-08-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hko-openpgp-identifiers-for-legacy-devices-03
openpgp H. Schäfer
Internet-Draft 27 August 2026
Intended status: Informational
Expires: 28 February 2027
OpenPGP key identifiers for legacy hardware devices
draft-hko-openpgp-identifiers-for-legacy-devices-03
Abstract
This document describes an approach for storing a fingerprint-based
identifier for an OpenPGP key packet on a hardware security device
that has a size-constrained identifier field.
About This Document
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.
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."
This Internet-Draft will expire on 28 February 2027.
Schäfer Expires 28 February 2027 [Page 1]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Encoding an identifier for an OpenPGP key . . . . . . . . . . 5
4.1. Encoding for a v4 OpenPGP key packet . . . . . . . . . . 5
4.2. Encoding for a post-v4 OpenPGP key packet . . . . . . . . 6
4.3. Example: Identifier for a version 6 OpenPGP key packet . 6
5. Purposes of the identifier field . . . . . . . . . . . . . . 6
5.1. Detect if key material is associated with an OpenPGP key
packet . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Detect the OpenPGP key packet version . . . . . . . . . . 7
5.3. Identification of an OpenPGP key packet stored on a
device . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Validate reconstruction of an OpenPGP key packet from a
device . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Finding a hardware device that matches a given OpenPGP
public key packet . . . . . . . . . . . . . . . . . . . . 8
6.2. Determining the full OpenPGP fingerprint (and key packet
details) without relying on external data . . . . . . . . 9
6.3. Finding the OpenPGP certificate that corresponds to a
hardware-backed key . . . . . . . . . . . . . . . . . . . 10
6.3.1. Lookup in a local key store by fingerprint prefix . . 10
6.3.2. Lookup by full fingerprint (e.g. from a public key
server) . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. Collision risk for identifiers . . . . . . . . . . . . . 11
7.1.1. Accidental occurrence of duplicate identifiers . . . 11
7.1.2. Duplicate identifiers caused by an attacker . . . . . 12
8. Additional considerations . . . . . . . . . . . . . . . . . . 13
Schäfer Expires 28 February 2027 [Page 2]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
8.1. Some version 4 fingerprint values are overloaded by this
identifier scheme . . . . . . . . . . . . . . . . . . . . 13
8.2. Handling (seeming) inconsistencies of on-device data . . 14
8.2.1. Case 1: The key material is not associated with an
OpenPGP key packet . . . . . . . . . . . . . . . . . 14
8.2.2. Case 2: The application can't interpret the identifier
because it lacks knowledge . . . . . . . . . . . . . 14
8.2.3. Case 3: The application understands the key flavor, can
validate all public key data against additional
information about the OpenPGP key packet, but the
identifier field doesn't match the expected value . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Alternative designs considered . . . . . . . . . . . 16
A.1. 20 octet prefix of fingerprint . . . . . . . . . . . . . 16
A.2. Key packet version only . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Document History . . . . . . . . . . . . . . . . . . . . . . . . 17
Substantive Changes from
draft-hko-openpgp-identifiers-for-legacy-devices-02 to
draft-hko-openpgp-identifiers-for-legacy-devices-03 . . 17
Substantive Changes from
draft-hko-openpgp-identifiers-for-legacy-devices-01 to
draft-hko-openpgp-identifiers-for-legacy-devices-02 . . 17
Substantive Changes from
draft-hko-openpgp-identifiers-for-legacy-devices-00 to
draft-hko-openpgp-identifiers-for-legacy-devices-01 . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Private key material for an OpenPGP component key may be stored on a
hardware security device (also see
[I-D.dkg-openpgp-external-secrets]). Some such devices offer an
informational data field for key identification.
Many currently available hardware devices that target use with
OpenPGP keys offer a 20 octet identifier field for this purpose
(originally designed to store an OpenPGP v4 fingerprint).
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"). This field
was designed to match the size of an OpenPGP version 4 fingerprint
(based on a SHA-1 hash digest). Note that the field's name is
"fingerprint", based on its original intended use.
Schäfer Expires 28 February 2027 [Page 3]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
This document describes an interoperable scheme for using such a
size-constrained identifier field to refer to an OpenPGP component
key 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,
an OpenPGP version 6 key packet uses a 32 octet SHA-256
fingerprint (see Section 5.5.4.3 of [RFC9580]).
1.1. Requirements Language
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.
1.2. Terminology
* "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.
2. Scope
This document describes an interoperable scheme for using a class of
widely available hardware security devices (such as the "OpenPGP
card" family of devices) for an OpenPGP key packet with version > 4.
This scheme may be applied to handle an OpenPGP key packet on a
hardware security device that has an informational key identification
field with size fixed to 20 octets. The scheme MUST NOT be applied
in any other context, without a specification that describes why the
scheme is appropriate for that context.
Schäfer Expires 28 February 2027 [Page 4]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
As additional informational background, this document outlines
current practices for handling OpenPGP v4 keys on such devices, and
how these practices interact with the scheme described in this
document.
3. Motivation
For the last decades, widely available hardware security devices have
typically stored a full v4 key fingerprint as identifier when
uploading an OpenPGP v4 key packet. While this fingerprint
information is not required to perform cryptographic operations, it
is useful for various purposes (more on this in Section 5).
Since the identifier field on many existing devices is size-limited
to exactly 20 octets, a full modern fingerprint can not be stored in
it. Separately, the key packet version can also not be stored
explicitly on most of these devices.
This document describes an approach for storing an identifier for a
modern OpenPGP key (with version > 4) on existing hardware. The
identifier scheme matches the properties of existing practice for v4
keys as closely as possible, given the constraints of existing
hardware devices.
4. Encoding an identifier for an OpenPGP key
This document describes a 20-octet-sized identifier that represents
an OpenPGP key packet. This identifier can be stored on a hardware
device with a field of that fixed length.
4.1. Encoding for a v4 OpenPGP key packet
The fingerprint for a v4 key packet has historically been stored
verbatim on a device with a 20 octet identifier field.
This document notes this existing practice, and specifies that a v4
key packet should continue to be handled in this way, going forward.
However, note that this existing use of the identifier field
interacts with this document, which outlines a separate scheme for
using the same field for any key with version > 4 (more on this in
Section 8.1).
Existing practice for storing and identifying a v4 key packet needs
to be taken into account by implementers. Even an implementation
that doesn't support v4 keys needs to be able to gracefully handle an
identifier field that contains a verbatim v4 fingerprint.
Schäfer Expires 28 February 2027 [Page 5]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
4.2. Encoding for a post-v4 OpenPGP key packet
To store a fingerprint-based key identifier on a hardware device for
an OpenPGP key with version > 4, instead of the full fingerprint, an
application should store the concatenation of:
* A "version marker" that specifies the key packet's version.
* A prefix of the full fingerprint.
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, an application
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 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
subset of the v4 fingerprint namespace. Some legitimate v4
fingerprints will be interpreted as post-v4 identifiers, under this
scheme (more on this in Section 8.1). With this in mind, the size of
the version marker is intentionally large, so that the fraction of
the v4 fingerprint namespace that it overlaps with is small.
4.3. Example: Identifier for a version 6 OpenPGP key packet
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.
5. Purposes of the identifier field
The identifier value stored on a hardware device can serve some or
all of the following purposes.
Schäfer Expires 28 February 2027 [Page 6]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
5.1. Detect if key material is associated with an OpenPGP key packet
Goal: An application can detect if key material on a hardware device
is associated with an OpenPGP key packet.
Context: Bare key material on a hardware device may be associated
with different protocols. Even on an "OpenPGP card" device, some
users may store cryptographic key material that is associated with
another (non-OpenPGP) protocol.
This detection is currently possible for a v4 OpenPGP key by testing
if the v4 fingerprint stored on the device corresponds to the public
key material and associated metadata stored on the device.
This scheme extends this property to version > 4.
5.2. Detect the OpenPGP key packet version
Goal: A user or application can easily detect the OpenPGP key packet
version of a key on a hardware device.
By default, version 4 is assumed, for historical reasons.
This scheme explicitly encodes the key packet version in the
identifier, for key packet version > 4.
5.3. Identification of an OpenPGP key packet stored on a device
Goal: A user or application can easily compare an identifier stored
on a hardware device with a fingerprint that is known to them.
By default, the identifier field is assumed to contain a version 4
OpenPGP fingerprint, stored verbatim.
For key version > 4, this scheme stores an 8 octet fingerprint prefix
in the identifier field. This fingerprint prefix can be visually
inspected by a user, or processed by an application for various
purposes (more on these in Section 6).
5.4. Validate reconstruction of an OpenPGP key packet from a device
Goal: An application 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.
Schäfer Expires 28 February 2027 [Page 7]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
This positive confirmation validates all parameters of a key packet,
including the public key material, version number, creation time,
algorithm id, and additional elliptic curve or KDF parameters, if
applicable.
Validation of a reconstructed key packet is possible both for version
4 and version > 4, with the scheme described here.
Note that with this validation, an application can detect when it
fails to interpret the intended usage of key material on a device
correctly. Incorrect interpretation can for example occur when:
* There are two different OpenPGP key packet forms that a given set
of on-device key data could be associated with.
* An application is only aware of one of those possible forms.
If an application is not aware that two candidate key packet forms
exists, it can neither detect the ambiguity, nor resolve it
correctly. That is, without an additional signal, an application can
not detect if on-device data is associated with an OpenPGP key packet
form that it doesn't know of.
The identifier scheme in this document allows robust detection of
this case.
When detecting that the identifier on a device doesn't match the
expected identifier for a key packet reconstruction, an application
must not use the key material on the card. This prevents using key
material in an unintended way, with potentially confusing outcomes
for the user, or possible security implications.
6. Use cases
6.1. Finding a hardware device that matches a given OpenPGP public key
packet
When using the identifier scheme outlined in this document, an
application can determine if a hardware device contains key material
that corresponds to a given OpenPGP key packet, as follows:
1. Given an OpenPGP key packet, the application determines that
component key's full fingerprint.
2. If the key packet is version > 4, the application considers only
the leftmost 8 octets of the full fingerprint (for key packet
version 4, the fingerprint is compared verbatim, and step 3 is
skipped).
Schäfer Expires 28 February 2027 [Page 8]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
3. The application then checks that:
* The first 12 octets of the identifier on the card conform to
the "version marker" format described in Section 4.2, and that
the version octet in the marker matches the key packet.
* The following 8 octets of the identifier on the card
correspond to the leftmost 8 octets of the fingerprint.
4. If a key on a device matches this identifier convention, the
application assumes that it contains the expected key material.
6.2. Determining the full OpenPGP fingerprint (and key packet details)
without relying on external data
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, consider an OpenPGP card device that has been
initialized following the scheme outlined in this document, that
stores a version 6 OpenPGP key packet. The identifier field then
only contains 8 octets of the fingerprint prefix. Without additional
context, it is not possible to perform a keyserver lookup with this
information:
A privacy-preserving public key server doesn't allow lookup of a
version 6 key 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:
1. For the on-device key, the application obtains the following
information from the device:
* The basic algorithm setting (e.g. RSA, ECDH) and parameters
(e.g. the OID, for ECC key material).
* The key version (e.g. 0x06), if the first 12 octets of the
identifier conform to the "version marker" format defined in
Section 4.2.
* 8 octets of fingerprint prefix, from the identifier field.
* The (4 octet) key creation timestamp.
Schäfer Expires 28 February 2027 [Page 9]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
* The public key parameters of the key.
2. 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 an ECDH key packet).
Usually, this search space will be small, often it contains just
one candidate.
3. 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.
4. The full OpenPGP fingerprint is calculated for each of the
candidate public key packets.
5. For a key packet with version > 4, if the fingerprint of a
candidate public key packet matches the 8 octet fingerprint
prefix in the identifier, the application assumes that this
candidate public key packet corresponds to the key slot in
question.
6. 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).
6.3. Finding the OpenPGP certificate that corresponds to a hardware-
backed key
With the scheme outlined in this document, 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.
6.3.1. Lookup in a local key store by fingerprint prefix
If an application has access to a set of candidate certificates,
locally, it may be able to search them by the 8 octet fingerprint
prefix from the device. Depending on the application, such a local
lookup may be efficient and acceptable.
Schäfer Expires 28 February 2027 [Page 10]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
However, an application should consider if collisions of the 8 octet
fingerprint prefix are a concern in the expected threat model of
their users.
Collisions should not normally be an issue if the lookup is performed
on a set of curated certificates that the user has explicitly
associated with themself.
6.3.2. Lookup by full fingerprint (e.g. from a public key server)
In order to perform a certificate lookup by fingerprint, an
application can perform the "determining the full OpenPGP
fingerprint" procedure (as described in Section 6.2), and then
perform a network lookup based on the confirmed fingerprint, e.g.
from a public key server.
7. Security Considerations
7.1. Collision risk for identifiers
This document describes 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:
1. Accidental occurrence of a duplicate identifier in a user's
context.
2. An attacker who intentionally causes a duplicate identifier to be
present in a user's context.
It is important to keep in mind that an identifier stored on a
hardware security device only exists within the user's local
computing environment. It is only visible locally, when a user plugs
in, for example, a USB device that implements the "OpenPGP card"
application.
7.1.1. Accidental occurrence of duplicate identifiers
Accidental collision of 8 octet fingerprint prefixes between multiple
hardware-backed OpenPGP component keys in a user's local environment
is exceedingly unlikely.
Schäfer Expires 28 February 2027 [Page 11]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
And even if a collision were to occur, it could be detected and
resolved safely by an application, e.g. by reconstructing the full
key packet and checking the complete fingerprint for each hardware-
backed key.
7.1.2. Duplicate identifiers caused by an attacker
Note that this case only arises if an attacker introduces a hardware
security device 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 if this document - 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 this case.
* Assuming an "honest" device (which truthfully reports the public
key parameters that correspond to the private key stored on the
device): If an application checks for consistency between 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.
- But in any case, 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 of 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 used by 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
document does not attempt to mitigate risks associated with
adversarial devices.
Schäfer Expires 28 February 2027 [Page 12]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
(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 are important to consider, underhandedly
replacing a user's private key material is not a typical attack
scenario.)
8. Additional considerations
8.1. Some version 4 fingerprint values are overloaded by this
identifier scheme
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 necessarily involves a tradeoff. The chosen tradeoff is:
The identifier for a version 4 key packets with a fingerprint that
starts with 12 octets that match the "version marker" format
specified in Section 4.2 becomes ambiguous. Such an identifier would
(erroneously) be interpreted to refer to a key packet with a
different version.
In other words, to allow explicit encoding of key versions > 4, a
(small) portion of the identifier namespace gets reserved for special
handling, thereby rendering that fraction v4 fingerprint namespace
unusable.
Concretely, the fraction of the v4 fingerprint namespace that becomes
unusable with this scheme is 1 : 2^88 (any identifier value in which
the first 11 octets are all zero). This document considers the
blocked part of the namespace sufficiently small that it is
disregarded in the remainder of the document.
(Note though that an application could in theory recognize and
correctly handle OpenPGP v4 keys with fingerprints that start with
what looks like a version marker segment, by reconstructing and
validating a reconstruction of that shape of key packet. However,
the added complexity of such special case handling would not be well-
spent. This document does not recommend implementing handling that
case.)
Schäfer Expires 28 February 2027 [Page 13]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
8.2. Handling (seeming) inconsistencies of on-device data
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.
Note that this is the case for the long-established use of v4 OpenPGP
keys on hardware devices, and analogously the case for the scheme
outlined in this document.
Such inconsistencies may have different underlying root causes.
These are discussed in the following.
8.2.1. Case 1: The key material is not associated with an OpenPGP key
packet
Some key material stored on hardware devices (including on "OpenPGP
card" devices) is not linked to an OpenPGP key packet.
Such keys don't have a consistent OpenPGP identifier set on the
device. This fact is unchanged by this document.
8.2.2. Case 2: The application can't interpret the identifier because
it lacks knowledge
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.
When an application cannot find an internally consistent
interpretation of the on-device data as an OpenPGP key packet, 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 any data on the device without user confirmation.
If appropriate from a UX perspective, it may inform the user about
the issue.
Schäfer Expires 28 February 2027 [Page 14]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
8.2.3. Case 3: The application understands the key flavor, can validate
all public key data against additional information about the
OpenPGP key packet, but the identifier field doesn't match the
expected value
In this case, the application has access to a key on a hardware
security device, as well as to a complete representation of the
associated OpenPGP key packet (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 format 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.
9. IANA Considerations
This document does not require any action from IANA.
10. References
10.1. Normative References
[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/info/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/info/rfc8174>.
[RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/info/rfc9580>.
10.2. Informative References
[I-D.dkg-openpgp-external-secrets]
Gillmor, D. K. and H. Schaefer, "OpenPGP External Secret
Keys", Work in Progress, Internet-Draft, draft-dkg-
Schäfer Expires 28 February 2027 [Page 15]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
openpgp-external-secrets-03, 22 July 2026,
<https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-
external-secrets-03>.
[OPENPGP-SMARTCARD]
Pietig, A., "Functional Specification of the OpenPGP
application on ISO Smart Card Operating Systems, Version
3.4.1", 18 March 2020, <https://gnupg.org/ftp/specs/
OpenPGP-smart-card-application-3.4.1.pdf>.
Appendix A. Alternative designs considered
The option space for encoding a 20 octet identifier for a key packet
is large. The following substantively different design options were
considered:
A.1. 20 octet prefix of fingerprint
One alternative design would 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, an application 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 be practically viable, but it has at least one
downside compared to the scheme described in this document:
The version number is not encoded explicitly. This is not in itself
a reason to reject the approach. However, there is no known upside
that counterbalances this downside.
A.2. Key packet version only
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).
Schäfer Expires 28 February 2027 [Page 16]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
This scheme is sufficient for performing cryptographic operations,
under normal circumstances. The scheme has the advantage that the
data on the device cannot be internally inconsistent.
However, this scheme does not allow an application to reason about
the key material on a device, in the absence of an externally
available copy of the OpenPGP key packet data:
* An application can not conclusively detect if the on-device key is
intended for use in an OpenPGP context, without additional
information.
* An application can not deduce the shape of the associated OpenPGP
key packet, without additional information.
Acknowledgements
The following people have contributed to this document in various
ways, offering reviews, suggestions, corrections, and implementation
notes:
* Andrew Gallagher
* Daniel Huigens
* Daniel Kahn Gillmor
* Paul Schaub
* Simo Sorce
* Simon Josefsson
* Werner Koch
Document History
Substantive Changes from draft-hko-openpgp-identifiers-for-legacy-
devices-02 to draft-hko-openpgp-identifiers-for-legacy-devices-03
* Editorial and structural changes only
Substantive Changes from draft-hko-openpgp-identifiers-for-legacy-
devices-01 to draft-hko-openpgp-identifiers-for-legacy-devices-02
* Further elaborate the purpose of the identifier
Schäfer Expires 28 February 2027 [Page 17]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
* Add guidance for dealing with (seemingly) inconsistent identifier
values
* Add some more context about the status quo of handling v4 keys on
hardware devices
* Edits for clarity
Substantive Changes from draft-hko-openpgp-identifiers-for-legacy-
devices-00 to draft-hko-openpgp-identifiers-for-legacy-devices-01
* Change the version marker from 12 octets of <version> to 11 octets
of 0x00 and one octet of <version>
* Add an explicit description of the identifier field's purpose(s)
Author's Address
Heiko Schäfer
Email: heiko.schaefer@posteo.de
Schäfer Expires 28 February 2027 [Page 18]