Media Types for OpenPGP

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 February 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[RFC3156] specifies media types for use in multipart MIME messages ([RFC1847]), 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.¶

2. Conventions and Definitions

The term "OpenPGP Certificate" is used in this document interchangeably with "OpenPGP Transferable Public Key", as defined in Section 10.1 of [RFC9580].¶

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Existing Media Types

[RFC3156] specifies the following media types:¶

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.¶

4. New Media Types

The following media types are hereby specified:¶

As these are all ASCII-armored formats by default, they share the .asc file extension.¶

5. 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 (Section 5 of [RFC2045]) 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.¶

The armor parameter has the following allowed values:¶

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.¶

6. 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 [Hockeypuck] 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.¶

7. 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.¶

8. 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.¶

9. 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:¶

MIME media type name: application
MIME subtype name: pgp-secret-keys
Required parameters: none
Optional parameters: armor

Encoding considerations:

   The content of this media type consists of 7bit text if the `armor` parameter does not have the value `false`.

Security considerations:

   See RFC 9580 Section 13.

Interoperability considerations: none

Published specification:

   RFC9580 and ((THIS DOCUMENT)).

Additional information:

   Magic number(s): none
   File extension(s): asc, pgp
   Macintosh File Type Code(s): none

Person & email address to contact for further information:

   Andrew Gallagher
   Email: andrewg&andrewg.com

Intended usage: common

Author/Change controller:

   Andrew Gallagher
   Email: andrewg&andrewg.com

• application/pgp-message:¶

MIME media type name: application
MIME subtype name: pgp-message
Required parameters: none
Optional parameters: armor

Encoding considerations:

   The content of this media type consists of 7bit text if the `armor` parameter does not have the value `false`.

Security considerations:

   See RFC 9580 Section 13.

Interoperability considerations: none

Published specification:

   RFC 9580 and ((THIS DOCUMENT)).

Additional information:

   Magic number(s): none
   File extension(s): asc, pgp
   Macintosh File Type Code(s): none

Person & email address to contact for further information:

   Andrew Gallagher
   Email: andrewg&andrewg.com

Intended usage: common

Author/Change controller:

   Andrew Gallagher
   Email: andrewg&andrewg.com

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:¶

MIME media type name: application
MIME subtype name: pgp-signature
Required parameters: none
Optional parameters: armor

Encoding considerations:

   The content of this media type consists of 7bit text if the `armor` parameter does not have the value `false`.

Security considerations:

   See RFC 9580 Section 13.

Interoperability considerations: none

Published specification:

   RFC9580, RFC 3156, and ((THIS DOCUMENT)).

Additional information:

   Magic number(s): none
   File extension(s): asc, sig, pgp
   Macintosh File Type Code(s): pgDS

Person & email address to contact for further information:

   Andrew Gallagher
   Email: andrewg&andrewg.com

Intended usage: common

Author/Change controller:

   Andrew Gallagher
   Email: andrewg&andrewg.com

• application/pgp-keys:¶

MIME media type name: application
MIME subtype name: pgp-keys
Required parameters: none
Optional parameters: armor

Encoding considerations:

   The content of this media type consists of 7bit text if the `armor` parameter does not have the value `false`.

Security considerations:

   See RFC 9580 Section 13.

Interoperability considerations: none

Published specification:

   RFC 9580, RFC 3156, and ((THIS DOCUMENT)).

Additional information:

   Magic number(s): none
   File extension(s): asc, pgp
   Macintosh File Type Code(s): none

Person & email address to contact for further information:

   Andrew Gallagher
   Email: andrewg&andrewg.com

Intended usage: common

Author/Change controller:

   Andrew Gallagher
   Email: andrewg&andrewg.com

Appendix A. Acknowledgments

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

Author's Address