]>

heiko.schaefer@posteo.de

openpgp Internet-Draft This document describes an approach for storing a shortened fingerprint-based lookup hint 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 lookup based on OpenPGP fingerprints. This document outlines an approach for how to use such fields on hardware devices, when the field size is too constrained for the length of modern fingerprints. For example, the "OpenPGP card" specification defines a 20 octet "fingerprint" field for each secret key packet stored on the card (see page 23 in , under the tag "C5"). These fields were sized for OpenPGP version 4 fingerprints (based on SHA-1 hashes). However, modern OpenPGP version 6 component keys (as specified in ) use 32 octet (SHA-256) fingerprints, which cannot be directly stored in a 20 octet field. This document describes an approach for using size-constrained lookup fields to refer to OpenPGP component keys with longer fingerprint sizes.

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.

Goals This draft describes a scheme for using the widely available OpenPGP card devices for OpenPGP version 6 (or later) keys. The scheme may be applied analogously for other types of hardware security device that have comparable constraints.

Encoding a key lookup hint on the device To store a fingerprint-based lookup key on a hardware device when the target field is shorter than the fingerprint, instead of the full fingerprint, applications should store the concatenation of: A marker that specifies the key packet's version. The leftmost octets of the full fingerprint.

Encoding version 6 (or later) fingerprints on OpenPGP card devices OpenPGP card devices that implement version 3.4.1 (or earlier) offer a 20 octet lookup field for each key that is stored on the hardware device. Note that this field an OpenPGP smart cards is named "fingerprint", for historical reasons. With OpenPGP version 4 keys, the size of the fields on the device matches the length of the OpenPGP fingerprint. However, OpenPGP version 6 keys use 32 octet fingerprints, so it is not possible to store these fingerprints on the card in full. When importing a version 6 (or later) OpenPGP key onto an OpenPGP card device, applications should instead store 20 octets of lookup hint, concatenating the following two parts: 12 octets of version marker, consisting of 12 copies of the version octet. For a version v6 key, each octet contains the value 0x06. The leftmost 8 octets of the full fingerprint.

Example The full version 6 fingerprint of the primary key of the Transferable Secret Key in is cb186c4f0609a697e4d52dfa6c722b0c1f1e27c18a56708f6525ec27bad9acc9. When uploading this component key to an OpenPGP card device, the lookup hint on the card should be set to 060606060606060606060606cb186c4f0609a697.

Some version 4 fingerprints become unusable on constrained card devices Because the scheme outlined here limits itself to using a pre-existing data field (which can legitimately contain any possible value), and uses this field to encode additional information, the scheme necessarily involves a tradeoff. Concretely, the chosen tradeoff is: Version 4 key packets with a fingerprint that starts with 12 octets of the same value (e.g. 12 octets of 0x06) become unusable when following the guidance in this text, because they are interpreted as key packets with a different version. That is, to allow explicit encoding of key version other than 4, a (small) portion of the fingerprint namespace gets effectively blocked off. This text considers the blocked part of the namespace sufficiently small that it is disregarded in the remainder of the document. Concretely, the fraction of the v4 fingerprint namespace that becomes unusable with this scheme is 1 : 2^88 (any value in which the first 12 octets all have the same content).

Security Considerations

Shorter identifiers have a higher risk of collisions This text proposes use of (effectively) an 8 octet identifier to recognize a key on an OpenPGP card, instead of previously a 20 octet identifier. This raises the question if there are any risks associated with that shortened identifier. There are at least two classes of conceivable risks: Accidental occurrence of a duplicate identifier in a user's context. Attackers who intentionally cause a duplicate identifier to be present in a user's context. It is important to keep in mind that the lookup hints stored on an OpenPGP card device only exist within the user's own local computing environment. They are only visible locally, for example when the user plugs in a USB device that implements the OpenPGP card application. These lookup hints are never visible in more global namespaces.

Accidental occurrence of duplicate lookup hints on cards It is exceedingly unlikely that the 8 octet prefix of an OpenPGP fingerprint has an accidental collision with a second card-backed component key, within any user's local environment.

Attackers causing occurrence of duplicate lookup hints on cards First, it is unclear under which circumstances an attacker benefits from causing a target keyholder to use a different private key than the one they intend to use. While there might be attacks that are important to consider, underhandedly replacing a user's private keys is not a typical attack scenario. Given that, this scheme does not add much new attack surface for an attacker who underhandedly replaces a user's OpenPGP card: When using an "honest" OpenPGP card device in an attack, it remains non-trivial for an attacker to generate a malicious key pair that shares the 64 bit prefix with the user's key, even if the user relies solely on that identifier to ensure that they are using the correct private key material (however, the user's application is not constrained to checking only the lookup hint field on the card. It can easily also check that the full public key parameters, as reported by the card, correspond to the expected component key). However, self-reported information from a hardware device cannot be relied on, if the device itself is malicious. A custom "fake" hardware device could report fingerprints and public key material that do not legitimately correspond to the private key material that the card uses. This draft does not attempt to mitigate the risks associated with adversarial devices.

Usability Considerations

Finding a hardware device that matches a given OpenPGP public key packet When using the method outlined in this text, applications can determine if an OpenPGP card contains the expected key material, as follows: Given an OpenPGP key packet, the application determines that component key's full fingerprint. If the fingerprint length exceeds 20 octets, the application considers only the leftmost 8 octets of the full fingerprint. The application then checks that a) The first 12 octets of the lookup hint on the card each correspond to the key packet version. b) The following 8 octets of the lookup hint on the card correspond to the leftmost 8 octets of the fingerprint. If the key slot on the card matches this convention, the application assumes that it contains the expected key material.

Finding the OpenPGP certificate that corresponds to a shortened OpenPGP card lookup hint With the scheme outlined in this text, given a key slot on an OpenPGP card device, some additional work may be needed to find the associated OpenPGP certificate: Because the lookup hint field on the device only contains the first 8 octets of the full fingerprint, not all certificate lookup methods are directly applicable.

Lookup in a key store that allows searches by fingerprint prefix If an application has access to a set of certificates, locally, it can search them by (8 octet) fingerprint prefix. Depending on the application, it may be sufficient and acceptable to perform such a local key search. However, applications should consider if collisions of the 8 octet fingerprint prefix are a concern in the expected threat model of their users.

Determining the full OpenPGP fingerprint without relying on external data In other contexts, it may be necessary to determine the full OpenPGP fingerprint of the key packet on an OpenPGP card device, without relying on any data that is external to the OpenPGP card device. For example, given an OpenPGP card device, without any additional context, it is not possible to perform a keyserver lookup based on the lookup hint field alone: Privacy-preserving public key servers do not allow lookup of version 6 keys by 8 octet fingerprint prefix. To perform a lookup on such a keyserver, the full 32 octet fingerprint is needed. To obtain the full fingerprint of a non-v4 key that is stored on an OpenPGP card device, applications can use the following method: For each key stored on an OpenPGP card device, applications obtain the following information from the device: The basic algorithm setting (e.g. RSA, ECDH). The key version (e.g. 0x06), if the first 12 octets of the lookup hint have a uniform value. 8 octets of prefix of the OpenPGP fingerprint. 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). The key packet version may be assumed to be 0x04, if the first 12 octets of the lookup hint on an OpenPGP card device don't all contain the same value. If each of first 12 octets of the lookup hint does contain the same value, this value is taken as the key packet's version number. The full OpenPGP fingerprint is calculated for each of these candidate public key packets. For key packets with a version greater than 4, if the fingerprint of a candidate public key packet matches the 8 octet fingerprint prefix in the lookup hint, then the application may assume that this candidate public key packet corresponds to the key slot in question. The full OpenPGP fingerprint for that public key packet can now be used for any purpose (e.g. for certificate lookup on a privacy-preserving key server).

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.

Design Choices An alternative design could encode the first octets of the full fingerprint on the card, matching the length of the field on the constrained device, without an explicit version marker. With this approach, applications would for example store the first 20 octets of a version 6 fingerprint on an OpenPGP card device. This approach would also be practically viable. However, it would be in more tension with the guidance in ().

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

Document History