]> PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document updates the specification of existing media types, and specifies additional media types, for the identification of OpenPGP data in non-MIME contexts. 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 specifies media types for use in multipart MIME messages (), but these are not sufficient for use in other contexts, such as web-based APIs. Valid OpenPGP data formats that are not supported by the currently-specified media types include: non-ASCII-armored data non-MIME signed or encrypted messages Transferable Secret Keys We wish to define media types to cover all valid OpenPGP data formats, so that they can be accurately represented in applications that rely on media types for content identification, such as web-based APIs.

Conventions and Definitions The term "OpenPGP Certificate" is used in this document interchangeably with "OpenPGP Transferable Public Key", as defined in . 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.

Existing Media Types specifies the following media types: Type Extension Description application/pgp-encrypted (none) The "control part" of a multipart/encrypted OpenPGP message application/pgp-signature asc, sig. An ASCII-armored OpenPGP signature packet application/pgp-keys asc An ASCII-armored sequence of one or more OpenPGP Transferable Public Keys The application/pgp-encrypted media type does not directly represent an OpenPGP data format, but the plaintext "control part" of an enclosing multipart/encrypted MIME part -- the encrypted message part uses the application/octet-stream media type instead. It is therefore of little use outside the confines of a multipart/encrypted MIME part. The other two media types identify ASCII-armored OpenPGP data formats, and are in general use. For example, many keyservers serve OpenPGP certificates using an HTTP response with the content type application/pgp-keys.

Updates to Existing Media Types It is established (but currently unspecified) practice for web APIs to serve v4 detached revocation signatures () in the same packet sequence as OpenPGP certificates, e.g. in and . The specification of application/pgp-keys is hereby extended to allow zero or more v4 detached revocations to precede any certificates in the OpenPGP packet sequence.

New Media Types The following media types are hereby specified: Type Extension Description application/pgp-secret-keys asc An ASCII-armored sequence of one or more OpenPGP Transferable Secret Keys application/pgp-message asc An ASCII-armored OpenPGP message () As these are all ASCII-armored formats by default, they share the .asc file extension.

New Media Type Parameters OpenPGP does not require the use of ASCII armor. Encoding and decoding ASCII armor in binary-safe contexts (such as HTTP) is therefore wasteful. To accurately indicate the use of OpenPGP's native binary wire format, we specify optional parameters () for all the OpenPGP media types, with the exception of application/pgp-encrypted. OpenPGP media type parameters MUST NOT be used with the application/pgp-encrypted media type. Parameter Optional Default value Description armor yes true Whether the OpenPGP packet sequence is ASCII-armored The armor parameter has the following allowed values: Value Extension Description true asc, sig An armored OpenPGP packet sequence false pgp An un-armored OpenPGP packet sequence For OpenPGP media types, armor=false indicates that ASCII armor has NOT been applied to the binary wire format. The .asc and .pgp file extensions correspond the value of the armor parameter, but are otherwise shared between the various OpenPGP media types. To ensure backwards compatibility with existing implementations: the absence of an armor parameter implies armor=true. the exceptional use of the sig extension for an ASCII-armored detached signature is retained.

Guidance for the Future Specification of Media Type Suffixes No media type suffixes are currently specified for any OpenPGP media type, however future documents may do so. For example, one such document could specify an application/pgp-keys+json format where the packet sequence has been parsed into an abstract syntax tree that is then represented by JSON object structure. (This is not a purely theoretical question, as such a JSON format is already implemented by some applications, for example the keyserver.) Any suffixed media type uses the data encoding specified for the suffix. The armor parameter MUST NOT be used in combination with any suffixed OpenPGP media type, since ASCII-armor is only specified in relation to the native OpenPGP wire format.

Guidance for Implementers It is RECOMMENDED that new applications in binary-safe contexts, such as web APIs, use armor=false. ASCII-armor SHOULD continue to be used in 7-bit contexts, such as email. An explicit armor=true parameter SHOULD NOT be added to existing applications, to preserve backwards compatibility, but SHOULD be used in new applications.

Security Considerations The first octet of un-armored OpenPGP data always has the high bit set, therefore the 7-bit clean text of ASCII armor cannot be misinterpreted as the start of an un-armored OpenPGP packet sequence. The armor parameter is therefore highly indicative but not essential for correct parsing of an OpenPGP packet sequence.

IANA Considerations IANA is requested to register the following new templates in the "Media Types" registry, where ((THIS DOCUMENT)) should be replaced by the RFC number of this document: application/pgp-secret-keys:

application/pgp-message:

IANA is also requested to update the following existing templates in the "Media Types" registry, where ((THIS DOCUMENT)) should be replaced by the RFC number of this document: application/pgp-signature:

application/pgp-keys:

This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. 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. This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community. Jabberwocky Tech PGPKeys.EU This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. g10 Code GmbH This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key.

Acknowledgments The author would like to thank Daniel Huigens, Daniel Kahn Gillmor, Heiko Schäfer and Wiktor Kwapisiewicz for suggestions and discussions.