]> TurboLight Solutions, LLC

corey.bonnell@turbolightsolutions.com

Sectigo Ltd.

rob@sectigo.com

Security Limited Additional Mechanisms for PKIX and SMIME PEM textual encoding IANA registry 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. About This Document 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 Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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. 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 (). It does not change the textual encoding itself.

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.

Textual Encoding of OCSP Responses OCSP responses are encoded using the OCSP RESPONSE label. The encoded data MUST be a DER-encoded OCSPResponse as described in . Generators MUST use the OCSP RESPONSE label when encoding an OCSP response. All other rules for generators and parsers in apply.

Security Considerations This document only creates a registry and introduces no new security considerations. The security considerations of 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 Considerations IANA is requested to create a new registry titled "PEM Labels". The registration procedure is Specification Required . Each registration contains the following fields:

Label:

The label that appears in the encapsulation boundaries. It MUST conform to the label ABNF production in .

Format Reference:

The document that specifies the format of the data carried in the base64 text.

Reference:

The document that defines the label and its use with the textual encoding.

The initial contents of the registry are: Initial PEM Labels Registry Contents

Label	Format Reference	Reference
CERTIFICATE
X509 CRL
CERTIFICATE REQUEST
PKCS7
CMS
PRIVATE KEY	,
ENCRYPTED PRIVATE KEY
ATTRIBUTE CERTIFICATE
PUBLIC KEY
EC PRIVATE KEY
PGP MESSAGE
PGP PUBLIC KEY BLOCK
PGP PRIVATE KEY BLOCK
PGP SIGNATURE
ECHCONFIG
ENCODED SMD
OCSP RESPONSE		RFC XXXX

RFC Editor: please replace "RFC XXXX" with the RFC number assigned to this document and remove this note.

Guidance for Designated Experts The designated experts are expected to verify that:

• The label conforms to the syntax in 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 , rather than a similar but distinct textual convention. For example, the SSH2 PUBLIC KEY label defined by uses an encapsulation boundary with a different number of dashes than , and the ACME RESPONSE label defined by encloses base64url-encoded data rather than the base64 alphabet specified in ; 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.

References Normative References This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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. Informative References This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community. This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification. This document describes a syntax for private-key information. This memo provides information for the Internet community. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK] This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME. Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD). One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public. This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty. This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries, as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. 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"). Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, which can be built using different TLS libraries. This document specifies a standard file format for this purpose, similar to how RFC 7468 defines other Privacy-Enhanced Mail (PEM) file formats.

Acknowledgments TODO acknowledge.