| Internet-Draft | PEM Label Registry | October 2026 |
| Bonnell & Stradling | Expires 15 April 2027 | [Page] |
RFC 7468 describes the textual encodings, commonly known as "PEM", of
several PKIX, PKCS, and CMS structures, each identified by a label such as
CERTIFICATE. No registry of these labels exists, which has led to
discoverability issues and inconsistent use. This document establishes an IANA registry
for PEM labels and defines the OCSP RESPONSE label.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://CBonnell.github.io/draft-bonnell-pem-label-registry/draft-bonnell-lamps-pem-label-registry.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bonnell-lamps-pem-label-registry/.¶
Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.¶
Source for this draft and an issue tracker can be found at https://github.com/CBonnell/draft-bonnell-pem-label-registry.¶
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 15 April 2027.¶
Copyright (c) 2026 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.¶
[RFC7468] defines the textual encoding of cryptographic structures in which
base64-encoded data is placed between encapsulation boundaries of the form
-----BEGIN label----- and -----END label-----. The label identifies the
format of the data carried in the base64 text.¶
[RFC7468] specifies a fixed set of labels, and other specifications have since defined or used additional labels. Without a registry, implementers have no authoritative place to find which labels are in use or which document defines the format of the encapsulated data, and specification authors have no way to avoid collisions.¶
This document creates the "PEM Labels" registry and populates it with labels previously defined in various documents. It also defines a label for OCSP responses (Section 3). It does not change the textual encoding itself.¶
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.¶
OCSP responses [RFC6960] are encoded using the OCSP RESPONSE label. The
encoded data MUST be a DER-encoded OCSPResponse as described in
Section 4.2.1 of [RFC6960].¶
Generators MUST use the OCSP RESPONSE label when encoding an OCSP response.
All other rules for generators and parsers in [RFC7468] apply.¶
This document only creates a registry and introduces no new security considerations. The security considerations of [RFC7468] continue to apply.¶
Registration of a label does not imply that the format it identifies, or any algorithm used with that format, is secure or recommended. The label is an unauthenticated hint, and the encapsulated data needs to be validated according to the specification of its format regardless of the label.¶
IANA is requested to create a new registry titled "PEM Labels". The registration procedure is Specification Required [RFC8126].¶
Each registration contains the following fields:¶
The label that appears in the encapsulation boundaries. It MUST conform to
the label ABNF production in Section 3 of [RFC7468].¶
The document that specifies the format of the data carried in the base64 text.¶
The document that defines the label and its use with the textual encoding.¶
The initial contents of the registry are:¶
| Label | Format Reference | Reference |
|---|---|---|
| CERTIFICATE | [RFC5280] | [RFC7468] |
| X509 CRL | [RFC5280] | [RFC7468] |
| CERTIFICATE REQUEST | [RFC2986] | [RFC7468] |
| PKCS7 | [RFC2315] | [RFC7468] |
| CMS | [RFC5652] | [RFC7468] |
| PRIVATE KEY | [RFC5208], [RFC5958] | [RFC7468] |
| ENCRYPTED PRIVATE KEY | [RFC5958] | [RFC7468] |
| ATTRIBUTE CERTIFICATE | [RFC5755] | [RFC7468] |
| PUBLIC KEY | [RFC5280] | [RFC7468] |
| EC PRIVATE KEY | [RFC5915] | [RFC5915] |
| PGP MESSAGE | [RFC9580] | [RFC9580] |
| PGP PUBLIC KEY BLOCK | [RFC9580] | [RFC9580] |
| PGP PRIVATE KEY BLOCK | [RFC9580] | [RFC9580] |
| PGP SIGNATURE | [RFC9580] | [RFC9580] |
| ECHCONFIG | [RFC9934] | [RFC9934] |
| ENCODED SMD | [RFC7848] | [RFC9361] |
| OCSP RESPONSE | [RFC6960] | RFC XXXX |
RFC Editor: please replace "RFC XXXX" with the RFC number assigned to this document and remove this note.¶
The designated experts are expected to verify that:¶
The label conforms to the syntax in Section 3 of [RFC7468] and does not differ from an existing registration only in case or whitespace.¶
The use of the label conforms to the encapsulation boundaries and base64
encoding defined in Section 3 of [RFC7468], rather than a similar but
distinct textual convention. For example, the SSH2 PUBLIC KEY label
defined by [RFC4716] uses an encapsulation boundary with a different
number of dashes than [RFC7468], and the ACME RESPONSE label defined
by [RFC8823] encloses base64url-encoded data rather than the base64
alphabet specified in Section 4 of [RFC4648]; neither is a suitable
candidate for registration as currently specified.¶
The referenced specification clearly identifies the format of the encapsulated data (for example, the ASN.1 type and its encoding).¶
A new label is warranted, rather than reuse of an existing label whose format already accommodates the data.¶
The experts may also approve registrations of labels already in widespread use, provided a stable specification describing the format is available.¶
TODO acknowledge.¶