OpenPGP key identifiers for legacy hardware devices
draft-hko-openpgp-identifiers-for-legacy-devices-02
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Heiko Schaefer | ||
| Last updated | 2026-08-24 (Latest revision 2026-08-12) | ||
| RFC stream | (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-02
openpgp H. Schäfer
Internet-Draft 24 August 2026
Intended status: Informational
Expires: 25 February 2027
OpenPGP key identifiers for legacy hardware devices
draft-hko-openpgp-identifiers-for-legacy-devices-02
Abstract
This document describes an approach for storing a shortened
fingerprint-based identifier for OpenPGP private key material on
hardware security devices.
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 25 February 2027.
Schäfer Expires 25 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. Purposes of the identifier field . . . . . . . . . . . . . . 5
4.1. Detect if key material is associated with an OpenPGP key
packet . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Detect the OpenPGP key packet version . . . . . . . . . . 5
4.3. Identification of OpenPGP key packets stored on
devices . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Validate reconstruction of OpenPGP key packets from a
device . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Encoding identifiers for OpenPGP keys . . . . . . . . . . . . 6
5.1. Encoding for v4 OpenPGP key packets . . . . . . . . . . . 7
5.2. Encoding for post-v4 OpenPGP key packets . . . . . . . . 7
5.3. Example: Identifier for a version 6 OpenPGP key packet . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Collision risk for identifiers . . . . . . . . . . . . . 8
6.1.1. Accidental occurrence of duplicate identifiers . . . 8
6.1.2. Attackers causing occurrence of duplicate identifiers
between devices . . . . . . . . . . . . . . . . . . . 9
7. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Finding a hardware device that matches a given OpenPGP
public key packet . . . . . . . . . . . . . . . . . . . . 10
7.2. Determining the full OpenPGP fingerprint (and key packet
details) without relying on external data . . . . . . . . 10
7.3. Finding the OpenPGP certificate that corresponds to a
hardware-backed key . . . . . . . . . . . . . . . . . . . 12
7.3.1. Lookup in a local key store by fingerprint prefix . . 12
7.3.2. Lookup by full fingerprint (e.g. from a public key
server) . . . . . . . . . . . . . . . . . . . . . . . 12
Schäfer Expires 25 February 2027 [Page 2]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
8. Additional considerations . . . . . . . . . . . . . . . . . . 12
8.1. Some version 4 fingerprint values are overloaded by this
identifier scheme . . . . . . . . . . . . . . . . . . . . 12
8.2. Handling (seeming) inconsistencies of on-device data . . 13
8.2.1. Case 1: The key material is not associated with an
OpenPGP key packet . . . . . . . . . . . . . . . . . 13
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 . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Alternative designs considered . . . . . . . . . . . 15
A.1. 20 octet prefix of fingerprint . . . . . . . . . . . . . 15
A.2. Key packet version only . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Document History . . . . . . . . . . . . . . . . . . . . . . . . 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 . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
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.
Schäfer Expires 25 February 2027 [Page 3]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
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]).
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 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.
Schäfer Expires 25 February 2027 [Page 4]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
3. Motivation
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.
4. Purposes of the identifier field
The identifier value stored on hardware devices can serve some or all
of the following purposes.
4.1. Detect if key material is associated with an OpenPGP key packet
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.
4.2. Detect the OpenPGP key packet version
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.
Schäfer Expires 25 February 2027 [Page 5]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
4.3. Identification of OpenPGP key packets stored on devices
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).
4.4. Validate reconstruction of OpenPGP key packets from a device
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.
5. Encoding identifiers for OpenPGP keys
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.
Schäfer Expires 25 February 2027 [Page 6]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
5.1. Encoding for v4 OpenPGP key packets
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.
5.2. Encoding for post-v4 OpenPGP key packets
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:
* 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, 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.
Schäfer Expires 25 February 2027 [Page 7]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
5.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.
6. Security Considerations
6.1. Collision risk for identifiers
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:
1. Accidental occurrence of a duplicate identifier in a user's
context.
2. 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.
6.1.1. Accidental occurrence of duplicate identifiers
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.
Schäfer Expires 25 February 2027 [Page 8]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
6.1.2. Attackers causing occurrence of duplicate identifiers between
devices
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.
Schäfer Expires 25 February 2027 [Page 9]
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 that are important to consider,
underhandedly replacing a user's private key material is not a
typical attack scenario.)
7. Use cases
7.1. Finding a hardware device that matches a given OpenPGP public key
packet
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:
1. Given an OpenPGP key packet, the application determines that
component key's full fingerprint.
2. If the key packet is newer than version 4, the application
considers only the leftmost 8 octets of the full fingerprint.
3. The application then checks that:
* The first 12 octets of the identifier on the card conform to
the "version marker" format described above.
* The following 8 octets of the identifier on the card
correspond to the leftmost 8 octets of the fingerprint.
4. If a key on the device matches this identifier convention, the
application assumes that it contains the expected key material.
7.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, 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.
Schäfer Expires 25 February 2027 [Page 10]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
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).
* 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.
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 ECDH key packets).
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 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.
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).
Schäfer Expires 25 February 2027 [Page 11]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
7.3. Finding the OpenPGP certificate that corresponds to a hardware-
backed key
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.
7.3.1. Lookup in a local key store by fingerprint prefix
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.
7.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 above), and then perform a
network lookup based on the confirmed fingerprint, e.g. from public
key servers.
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 involves a tradeoff. Concretely, the chosen tradeoff is:
Schäfer Expires 25 February 2027 [Page 12]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
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.
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.
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.
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 won't have a consistent OpenPGP identifier set on the
device. This fact is unchanged by this draft.
Schäfer Expires 25 February 2027 [Page 13]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
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.
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.
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
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.
9. IANA Considerations
This document does not require any action from IANA.
10. References
10.1. Normative References
Schäfer Expires 25 February 2027 [Page 14]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
[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-
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. Some substantively different design options that were
considered follow:
A.1. 20 octet prefix of fingerprint
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).
Schäfer Expires 25 February 2027 [Page 15]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
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.
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).
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:
* Applications could not conclusively detect if the on-device key is
intended for use in an OpenPGP context, without additional
information.
* Applications could not deduce the shape of the associated key
packet, without additional information.
Acknowledgements
The following people have contributed in various ways to this draft,
offering reviews, suggestions, corrections, and implementation notes:
* Andrew Gallagher
* Daniel Huigens
* Daniel Kahn Gillmor
* Paul Schaub
* Simo Sorce
* Simon Josefsson
Schäfer Expires 25 February 2027 [Page 16]
Internet-Draft OpenPGP identifiers for legacy devices August 2026
* Werner Koch
Document History
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
* 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 25 February 2027 [Page 17]