OpenPGP Extensions for Device Certificates

OpenPGP defines a standard, compact format for, among other things, sharing keys and signature certificates. Unfortunately the specification is user-focused, assuming that there are people sitting at the ends and creating and managing those keys. New use cases have come up where that is not the case and the endpoint for these keys are devices, not users. Yet we still want to be able to certify these device keys. Since the publication of RFC 4880, new use cases have emerged that don't fit into the existing standard models. For example, the Internet of Things have introduced devices that need to certify device-level encryption keys but cannot self-certify and have no user associated. This draft suggests extensions to RFC 4880 that enable those use cases and make it easier to have device certificates using OpenPGP.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

RFC 4880 section 12.1 defines a v4 Public Key Format as a sequence of packets starting with a Primary Key and then a sequence of packets and subpackets that add Revocations, User IDs, and Signatures. The description in RFC 4880 requires a User ID. Implementors of this specification can loosen that requirement such that an augmented V4 device certificate looks like the following sequence (no longer requiring a User ID packet):

Note that RFC 4880 section 11.1 defines this same sequence in text for transferable public keys. Implementors of this specification can change that definition from "One or more User ID packets" to "Zero or more User ID packets". Moreover, one more relaxation from section 12.1. RFC 4880 states that "In a V4 key, the primary key MUST be a key capable of certification." Implementors of this specification can loosen that restriction as well, such that in V4 augmented key, the primary key MAY be a key capable of certification. A primary key capable of making signatures SHOULD be accompanied by either a certification signature (on a User ID or User Attribute) or a signature directly on the key. Implementations MUST accept encryption-only primary keys without a signature. It also MUST allow importing any key accompanied either by a certification signature or a signature on itself. It MAY accept signature-capable primary keys without an accompanying signature.

Section 5.12 of RFC 4880 defines the User Attribute Packet which can be used in lieu of a User ID Packet. Whereas the User ID Packet only allows a single UTF-8 string content, the User Attribute Packet allows the addition of multiple attributes in subtype packets. Unfortunately RFC 4880 only defined a single Attribute Subpacket, the Image Attribute. This means that you need two signatures if you want to have an ID and an image. To solve that problem for device certificates we define a new User Attribute Subpacket, the User ID Attribute Subpacket, type #[IANA -- assignment TBD1]. A User ID Attribute subpacket, just like a User ID packet, consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 mail name-addr, but there are no restrictions on its content. For devices, it may be the device identifier. The packet length in the header specifies the length of the User ID. Note that RFC 4880 already allows a User Attribute packet anywhere a User ID packet can be used. See RFC 4880 section 5.2.3.19 (Primary User ID) for more information on self-signatures over these kinds of packets. Any signature on a User Attribute packet covers all subpackets. Implementations MAY decide to trust the User ID Subpacket.

OpenPGP defines a signature notation data packet that allows implementors and users to add extra data to signatures. RFC 4880 defined a registry for a global namespace and requires using name@dom.ain domain-name notations otherwise. Many of the devices targeted by this specification have limited storage capability, so it behooves an implementor to limit the extraneous storage. These notations can be important when you have a third-party device certification. That third party might want to add extra data about the device to its signature certification. In order to keep the certificate smaller we define a set of notations that MAY be used when signing a device certificate.

The "manu" notation is a string that declares the device manufacturer's name. The certifier key is asserting this string (which may or may not be related to the User ID of the certifier's key).

This notation defines the product make. It is a free form string.

This notation defines the product model name/number. It is a free form string.

This notation contains the product identifier. It is a free form string.

This notation defines the product version number (which could be a release number, year, or some other identifier to differentiate different versions of the same make/model). It is a free form string.

This notation defines the product lot number (which is an indicator of the batch of product). It is a free form string.

This notation defines the quantity of items in this package. It is a decimal integer representation with no punctuation, e.g. "10", "1000", "10000", etc.

The "loc" and 'dest' notations declare a GeoLocation as defined by RFC 5870 but without the leading "geo:" header. For example, if you had a GeoLocation URI of "geo:13.4125,103.8667" you would encode that in these notations as "13.4125,103.8667". The 'loc' notation is meant to encode the geo location where the signature was made. The 'dest' notation is meant to encode the geo location where the device is "destined" (i.e., a "destination" for the device).

A 'hash' notation is a means to include external data in the contents of a signature without including the data itself. This is done by hashing the external data separately and then including the data's name and hash in the signature via this notation. This is useful, for example, to have an external "manifest," "image," or other data that might not be vital to the signature itself but still needs to be protected and authenticated without requiring a second signature. The 'hash' notation has the following structure: A single byte specifying the length of the name of the hashed data A UTF-8 string of the name of the hashed data A single byte specifying the hash algorithm (see RFC 4880 section 9.4) The binary hash output of the hashed data using the specified algorithm. (The length of this data is implicit based on the algorithm specified). Due to its nature a 'hash' notation is not human readable and MUST NOT be marked as such when used.

A big thank you to Werner Koch, David Shaw, Jon Callas, Daniel Nagy, and David Leon Gil for their input on the concepts and text of this document.

This document requests IANA to register several items within the OpenPGP parameters (or the "name space" in the terminology of ) created by .

This specification asks IANA to register a PGP User Attribute Type: Value Attribute Reference TBD1 User ID This Doc

This specification asks IANA to register a set of OpenPGP Signature Notation Data Subpacket Types defined in . The following table is a summary of the requested registrations. Allowed Values Name Type Reference Any String manu Manufacturer Name This doc Any String make Product Make This doc Any String model Product Model This doc Any String prodid Product ID This doc Any String pvers Product Version This doc Any String lot Product Lot Number This doc Decimal Integer String qty Package Quantity This doc A geo: URI without the "geo:" loc Current Geo-location Latitude/Longitude This doc A geo: URI without the "geo:" dest Destination Geo-location Latitude/Longitude This doc Hash Notation data hash The Hash of external data This doc

The Security Considerations of apply. OpenPGP was designed with security in mind, with many smart, intelligent people spending a lot of time thinking about the ramifications of their decisions. Removing the requirement for self-certifying User ID (and User Attribute) packets on a key means that someone could surreptitiously add an unwanted ID to a key and sign it. If enough "trusted" people sign that surreptitious identity then other people might believe it. The attack could wind up sending encrypted mail destined for alice to some other target, bob, because someone added "alice" to bob's key without bob's consent. In the case of device certificates the device itself does not have any consent. It is given an identity by the device manufacturer and the manufacturer can insert that ID on the device certificate, signing it with the manufacturer's key. If another people wants to label the device by another name, they can do so. There is no harm in multiple IDs, because the verification is all done based on who has signed those IDs. When a key can self-sign, it is still suggested to self-certify IDs, even if it no longer required by this modification to OpenPGP. This at least signals to recipients of keys that yes, the owner of this key asserts that this identity belongs to herself. Note, however, that mallet could still assert that he is 'alice' and could even self-certify that. So the attack is not truly different. Moreover, in the case of device certificates, it's more the manufacturer than the device that wants to assert an identity (even if the device could self-certify). There is no signaling whether a key is using this new, looser-requirement key format. An attacker could therefore just remove the self-signature off a published key. However one would hope that wide publication would result in another copy still having that signature and it being returned quickly. However, the lack of signaling also means that a user with an application following RFC 4880 directly would see a key following this specification as "broken" and may not accept it. On a different note, including the "geo" notation could leak information about where a signer is located. However it is just an assertion (albeit a signed assertion) so there is no verifiable truth to the location information released. Similarly, all the rest of the signature notations are pure assertions, so they should be taken with the trustworthiness of the signer. Combining the User ID with the User Attribute means that an ID and image would not be separable. For a person this is probably not good, but for a device it's unlikely the image will change so it makes sense to combine the ID and image into a single signed packet with a single signature.