]> PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document updates the specification of User Attribute Packets and Subpackets in OpenPGP. The latest revision of this draft can be found at . 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 . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction User Attributes are a much-maligned and often-abused feature of OpenPGP. Currently their only specified use is to contain images, however it is known that some implementations use the Private and Experimental User Attribute Subpacket range for various internal purposes. In this document, we simplify the specification of User Attribute packets and subpackets, and use them to implement currently-missing functionality in OpenPGP.

Conventions and Definitions The term "OpenPGP Certificate" is used in this document interchangeably with "OpenPGP Transferable Public Key", as defined in . The term "Component key" is used in this document to mean either a primary key or subkey. 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.

User Attribute Subpackets User Attribute Packets are simple containers for one or more User Attribute Subpackets. These subpackets are wire-format compatible with Signature Subpackets, but the only currently defined type is the Image Attribute Subpacket type. As a result, a User Attribute Packet is currently only used to contain an Image Attribute Subpacket.

User Attribute Subpacket Categories By analogy with the categorisation of Signature Subpacket Types in , we categorise User Attribute Subpacket Types into:

General Subpackets These may be included in any User Attribute packet, and define properties of the packet itself. Unless otherwise specified, a User Attribute Packet SHOULD NOT contain more than one of each type of General subpacket.

Attribute Value Subpackets These carry the non-metadata content of the User Attribute. Unless otherwise specified, a User Attribute Packet SHOULD NOT contain more than one Attribute Value subpacket. A User Attribute Packet MUST NOT contain subpackets of more than one type of Attribute Value subpacket.

Image Attribute Subpacket The Image Attribute Subpacket (Type 1, Attribute Value category) has some unusual features, and is wildly over-specified: The image header has a little-endian length field, uniquely for OpenPGP. It has a version octet that represents an entire registry but with only one version specified. It has an encoding format octet that represents an entire registry with only one value specified. The v1 image header has a further 12 octets of unused fields. The Image Attribute Subpacket has been abused to store large amounts of data on the OpenPGP keyservers, and as a result most modern keyservers refuse to handle any User Attribute packets. Further, we wish to minimise the quantity of human-readable information in the OpenPGP wire format. If a key owner wishes to publish an image, this is more appropriately handled at the application layer. The use of Image Attribute subpackets is therefore deprecated: Code point 1 in the User Attribute Subpacket Registry should be updated to "Image Attribute Subpacket (deprecated)", with a category of "Attribute Value". No further Image Attribute versions or encoding formats will be supported; the values of both these fields are hereby fixed at 1. The OpenPGP Image Attribute Versions and OpenPGP Image Attribute Encoding Formats registries should be deleted. A User Attribute packet MUST NOT contain more than one Image Attribute subpacket.

Attribute Creation Time Subpacket We define an Attribute Creation Time subpacket (Type 2, General category) that identifies the time before which the User Attribute packet is not valid. It contains a four-octet timestamp in seconds since midnight, 1st January 1970. It is bitwise-identical to the Signature Creation Time Signature Subpacket (), and performs the same function as the "creation time" field in a Public Key or Public Subkey packet (). A User Attribute packet MUST NOT contain more than one Attribute Creation Time subpacket.

Attribute URI Subpacket We define an Attribute URI Subpacket (Type 8 (TBC), Attribute Value category) that identifies the resource being claimed by the key owner. It performs a similar function to the User ID packet, but in a strictly machine-readable URI format. For example, an email address would be represented as "mailto:user@example.com". A certificate MAY include both a User ID containing an email address, and a User Attribute with an Attribute URI subpacket representing the same email address. If a receiving implementation supports the Attribute URI subpacket, it SHOULD be used in preference to the User ID packet. If an implementation intends to certify the email address component of an RFC822-ish User ID, but not the real name or comment components, it SHOULD instead certify a User Attribute with an Attribute URI subpacket containing the mailto: URI of the email address. indicates that a User ID packet is not necessary in a v4 or v6 certificate (this differs from previous versions of the OpenPGP specification). However, since legacy implementations will not in general understand the Attribute URI subpacket, it is RECOMMENDED that a v4 certificate includes a User ID packet corresponding to each Attribute URI subpacket. A User Attribute packet MUST NOT contain more than one Attribute URI subpacket.

Notation Data Subpacket The Notation Data Subpacket (Type 20, General category) from the Signature Subpacket Types registry is duplicated into the User Attribute Subpacket registry, with the same wire format (). A User Attribute Packet MAY contain one or more Notation Data subpackets. Notation names share the same namespaces and semantics as signature notations. Notation names in the user namespace MAY be present in User Attributes. Notation names in the IANA namespace MUST NOT be present in User Attributes unless specified for that purpose.

Embedded Signature Subpacket The Embedded Signature Subpacket (Type 32, Attribute Value category) from the Signature Subpacket Types registry is duplicated into the User Attribute Subpacket registry, with the same wire format (). A User Attribute Packet MAY contain one or more Embedded Signature subpackets. These can be used by an implementation that wishes to distribute signatures that would not otherwise be valid in a certificate. Unless otherwise specified, all such embedded signature packets MUST be made by a component key of the current certificate. We update the following signature types to be "embeddable" (see ), and specify their use in User Attributes:

Certification Revocation Signature An Embedded Signature Subpacket MAY contain a Certification Revocation signature (Type 0x30):

Certification Revocation Signature Over a Third-Party Certificate The key holder might not trust that a third party will distribute certification revocations over their (possibly fraudulent) certificate . The key holder MAY instead distribute the revocation signature in their own certificate using an Embedded Signature subpacket of a User Attribute packet. (( TODO: can we identify the third party certificate in the revocation sig? ))

Certification Revocation Self-Signature If the key holder wishes to delete a User ID or User Attribute from their own certificate using a redacting revocation signature , they cannot append the revocation signature to the redacted User ID or User Attribute packet, because the redacted packet is no longer part of the certificate packet sequence. In order to distribute the revocation signature, it MAY be included in an Embedded Signature subpacket of a separate User Attribute packet. The revocation signature can be validated by a receiving implementation that already has a copy of the redacted User ID or User Attribute.

User Attribute Subpacket Grammar A User Attribute packet SHOULD contain exactly one Attribute Creation Time subpacket. It SHOULD contain at most one subpacket of each other subpacket type in the General category. It MUST NOT contain subpackets of more than one type in the Attribute Value category. A receiving implementation MUST disregard the entire User Attribute packet if a User Attribute packet contains an unknown subpacket, or if it contains subpackets of more than one type in the Attribute Value category.

Time Evolution of User Attributes There has historically been no easy way to create a Certification signature at an arbitrary time that supersedes an earlier one but retains the same starting validity date. Therefore, many implementations maintain a copy of all Certification signatures to ensure that historical signatures can be validated after a superseding certification is made. Some implementations have also attempted to work around this by backdating signature creation timestamps, which has implications for signature ordering. We are prevented from using the time evolution semantics described in for Certification signatures over User IDs, because User IDs have no intrinsic creation date. It is instead RECOMMENDED that v6 (and higher) certificates use User Attributes that contain an Attribute Creation Time subpacket. Certification signatures over a User Attribute with an Attribute Creation Time subpacket ({attribute-creation-time-subpacket}) can therefore have similar time evolution semantics as binding signatures, with the Attribute Creation Time subpacket performing the role of the (Sub)key Creation Time field. Certification signatures SHOULD NOT contain Key Expiration Time subpackets, and any such subpackets MUST be ignored. The validity of a Certification signature over a User Attribute extends from the User Attribute Creation Time until the signature's expiration time. If the most recent Certification signature has no Signature Expiration Time subpacket, then the certification does not expire. A Certification signature is temporally valid if its creation time is no earlier than the creation times of all of the primary key that made it, and the primary key and User Attribute that it is made over. Unlike a Key Binding self-signature, a Certification self-signature is not valid if the primary key has been hard-revoked, even for historical purposes. The creation time of a Certification signature over a User Attribute is used only for ordering, not for calculation of User Attribute validity. A third-party Certification signature over a User Attribute thereby retrospectively validates the User Attribute from the User Attribute Creation Time, if it exists. If a user does not believe that such a User Attribute has always been valid, they should not certify it.

Security Considerations The use of an Attribute URI subpacket instead of a User ID packet should increase overall security, as it has a stricter format that simplifies parsing. The deprecation of Image Attribute subpackets should increase both security and reliability, by removing a significant abuse vector. Distribution of third-party revocations in the certificate of the signer should be more reliable than existing methods, thereby increasing overall trust in the certification process.

IANA Considerations IANA is requested to perform the following tasks: Delete the OpenPGP Image Attribute Versions and OpenPGP Image Attribute Encoding Format registries. Add a column to the OpenPGP User Attribute Subpacket Types Registry, called "Category". Update the contents of the OpenPGP User Attribute Subpacket Types Registry to read: Type Name Category Reference 1 Image Attribute (Deprecated) Attr Value 2 Attribute Creation Time General 8(TBC) Attribute URI Attr Value 20 Notation Data General 32 Embedded Signature Attr Value Update the following entry in the OpenPGP Signature Types Registry to read: ID Name Embeddable Reference 0x30 Certification Revocation Signature Yes ,

Guidelines for Management of the User Attribute Subpacket Types Registry We have allocated code points in the User Attribute Subpacket Types registry that permit wire-format and semantics compatibility between User Attribute subpackets and Signature subpackets. Code points 1 and 8 are reserved in the Signature Subpacket Types registry, and code points 2, 10 and 32 represent subpacket types that are compatible in wire format and semantics. While not strictly required, it is RECOMMENDED that code points should be allocated so as to minimise semantics and wire format incompatibility between the two Subpacket Type registries. Signature subpacket code points outside of the General or Attribute Value categories SHOULD NOT be shared with the User Attribute registry.

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. PGPKeys.EU This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. ACLU Cryptographic revocation is a hard problem. OpenPGP's revocation mechanisms are imperfect, not fully understood, and not as widely implemented as they could be. Additionally, some historical OpenPGP revocation mechanisms simply do not work in certain contexts. This document provides clarifying guidance on how OpenPGP revocation works, documents outstanding problems, and introduces a new mechanism for delegated revocations that improves on previous mechanism.

Acknowledgments The author would like to thank Heiko Schäfer for discussions.