]>

heiko.schaefer@posteo.de

openpgp Internet-Draft This document describes an approach for storing a shortened fingerprint-based identifier for OpenPGP private key material on hardware security devices. 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 OpenPGP component keys may be stored on hardware security devices (also see ). 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 , 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. 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 ).

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

Security Considerations

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: Accidental occurrence of a duplicate identifier in a user's context. Attackers who intentionally cause a duplicate identifier to be present in a user's context. It is important to keep in mind that the identifiers stored on 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.

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.

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

Use cases

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: Given an OpenPGP key packet, the application determines that component key's full fingerprint. If the key packet is newer than version 4, the application considers only the leftmost 8 octets of the full fingerprint. 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. If a key on the 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, 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. 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). 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. 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. 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 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. 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 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.

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.

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.

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 involves a tradeoff. Concretely, the chosen tradeoff is: 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.

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.

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.

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.

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.

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. Some substantively different design options that were considered follow:

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 , the identifier on a hardware device would be set to cb186c4f0609a697e4d52dfa6c722b0c1f1e27c1 (truncated from the full fingerprint cb186c4f0609a697e4d52dfa6c722b0c1f1e27c18a56708f6525ec27bad9acc9). 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.

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