]> PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document specifies a method for ensuring the integrity of file metadata when signed using 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 Due to a design oversight in an early version of PGP, the literal data metadata (file type, file name, and file timestamp) were not covered by any integrity-protection mechanisms. That omission has persisted through subsequent OpenPGP specifications, up to and including . This document introduces the missing integrity check by adopting and extending the "Literal Data Meta Hash" subpacket from , section 5.2.3.33.

Conventions and Definitions 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.

Literal Data Meta subpacket This subpacket MAY be used to protect the metadata of a Literal Data Packet. It is only useful when located in the hashed-subpackets area of a v4 (or later) signature over a Literal Data Packet, and so it SHOULD NOT appear elsewhere. The packet SHOULD be marked as critical. The metadata is always of the same form as it appears in the Literal Data Packet (type 11, section 5.9), i.e.: A one-octet field that describes how the data is formatted. File name as a string (one-octet length, followed by a file name). A four-octet number that indicates a date associated with the literal data. The first octet of the subpacket contents indicates the encoding of the subpacket. A value of 0 indicates Hashed encoding, and a value of 1 indicates Verbatim encoding. The remaining octets of the subpacket are encoding-dependent.

Literal Data Meta (Hashed) The remainder of the packet contains a 32 octet fixed-length hash value. The hash is computed over the metadata as specified above, using SHA-256 . When an implementation is validating a signature containing a Literal Data Meta (Hashed) subpacket in its hashed-subpackets area, it MUST re-create the hash from the metadata section of the Literal Data packet that is signed over. If the calculated hash value does not match the one in the subpacket, the signature MUST be deemed as invalid.

Literal Data Meta (Verbatim) The remainder of the packet contains a verbatim copy of the metadata as specified above. When an implementation has successfully validated a signature containing a Literal Data Meta (Verbatim) subpacket in its hashed-subpackets area, the metadata section of the Literal Data Packet that is signed over MUST be replaced with the copy from the Literal Data Meta subpacket.

Security Considerations A signature containing a Literal Data Meta (Verbatim) subpacket can be round-tripped via detached-signature format without loss of integrity. A signature containing a Literal Data Meta (Hashed) subpacket does not have this property, because the metadata cannot be regenerated from the hash and is therefore lost on conversion to a detached signature. It is therefore RECOMMENDED that implementations generate Literal Data Hash subpackets using the Verbatim encoding.

IANA Considerations This document requests that the following entry be added to the OpenPGP Signature Subpacket registry: Type Name Specification 40 Literal Data Meta This document

National Institute of Standards and Technology, U.S. Department of Commerce 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. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK] 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.

Acknowledgments The author would like to thank Werner Koch for his earlier work on the Literal Data Meta Hash subpacket.