]>

heiko.schaefer@posteo.de

openpgp Internet-Draft 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. Status information for this document may be found at . Discussion of this document takes place on the OpenPGP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Private key material for an OpenPGP component key may be stored on a hardware security device (also see ). 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 , 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. 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 ).

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 when, and only when, they appear in all capitals, as shown here.

Terminology "Transferable Secret Key" or just "TSK" refers to an OpenPGP Transferable Secret Key (see ). "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.

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. 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.

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 ). 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.

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.

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 ). 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.

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 ). 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.

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 is cb186c4f0609a697e4d52dfa6c722b0c1f1e27c18a56708f6525ec27bad9acc9. When uploading this component key to e.g. an OpenPGP card device, the identifier on the card should be set to 000000000000000000000006cb186c4f0609a697.

Purposes of the identifier field The identifier value stored on a hardware device can serve some or all of the following purposes.

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.

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.

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 ).

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. 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.

Use cases

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: Given an OpenPGP key packet, the application determines that component key's full fingerprint. 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). The application then checks that: The first 12 octets of the identifier on the card conform to the "version marker" format described in , 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. If a key on a device matches this identifier convention, the application assumes that it contains the expected key material.

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: 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 . 8 octets of fingerprint prefix, from the identifier field. The (4 octet) key creation timestamp. The public key parameters of the key. From this information, the application can construct a set of candidate OpenPGP public key packets, by iterating over all key packet properties that are unspecified on the card (for example, the set of plausible KDF parameters for an ECDH key packet). Usually, this search space will be small, often it contains just one candidate. The key packet version may be assumed to be 0x04, if the first 12 octets of the identifier on an OpenPGP card device don't conform to the "version marker" format. If the first 12 octets of the identifier do conform to the "version marker" format, the encoded version value is taken as the key packet's version number. The full OpenPGP fingerprint is calculated for each of the candidate public key packets. For 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. 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).

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.

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. 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.

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 ), and then perform a network lookup based on the confirmed fingerprint, e.g. from a public key server.

Security Considerations

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: Accidental occurrence of a duplicate identifier in a user's context. 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.

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. 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.

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. (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.)

Additional considerations

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 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.)

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.

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.

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.

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.

IANA Considerations This document does not require any action from IANA.

This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. American Civil Liberties Union This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored externally, for example on a hardware device or other comparable subsystem.

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:

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 , 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.

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 , 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, 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 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)