Textual Encodings of PKIX, PKCS, and CMS Structures
Extracted elements (29)
DER encoding is strongly preferred over BER for certificates, CRLs, certification requests, and attribute certificates because: (1) digital signatures are computed over the DER encoding; (2) cryptographic hashes for identification use DER; and (3) DER uses definite-length form, allowing parsers to anticipate memory usage upfront. CMS is an exception since indefinite-length encoding enables one-pass streaming generation.
The label 'X509 CRL' was standardized for CRLs rather than the historically used 'CRL' because 'CRL' is not commonly used today and many popular tools do not understand it, whereas 'X509 CRL' is already widely deployed.
Unlike legacy PEM encoding, OpenPGP ASCII armor, and OpenSSH key file format, textual encoding does NOT define or permit headers alongside the data. Generators SHOULD NOT emit any empty spacing between the pre-encapsulation boundary and the base64 data, though the area exists as a PEM throwback.
Extant parsers diverge considerably on whitespace handling. Most ignore blanks at ends of lines; blanks at the beginnings of lines or in the middle of base64-encoded data are far less compatible. The laxest parsers are not line-oriented at all and accept any mixture of whitespace outside encapsulation boundaries.
Files MAY contain multiple textual encoding instances, for example when a file contains several certificates. Whether the instances are ordered or unordered depends on the context. Many tools emit explanatory text before BEGIN and after END lines for PKIX certificates.
The file extension '.crt' SHOULD be used for the textual encoding of a certificate to promote interoperability and separate DER encodings from textual encodings, but many tools still default to '.cer' for this textual encoding despite the official RFC 2585 registration of '.cer' for DER-format certificates.
Generators conforming to this document MUST generate 'CERTIFICATE' labels and MUST NOT generate 'X509 CERTIFICATE' or 'X.509 CERTIFICATE' labels. Parsers SHOULD NOT treat those legacy labels as equivalent to 'CERTIFICATE'.
Generators MUST generate 'CERTIFICATE REQUEST' labels. Parsers MAY treat 'NEW CERTIFICATE REQUEST' as equivalent to 'CERTIFICATE REQUEST' for backwards compatibility.
Generators MUST generate 'X509 CRL' labels and MUST NOT generate 'CRL' labels. Parsers SHOULD NOT treat 'CRL' as equivalent to 'X509 CRL'.
Generators MUST NOT generate the 'CERTIFICATE CHAIN' label, and parsers SHOULD NOT treat it as equivalent to 'PKCS7'. Implementations SHOULD NOT generate PKCS #7 when CMS is an alternative.
Generators MUST put the same label on the '-----END ' line as the corresponding '-----BEGIN ' line. Parsers MAY disregard a label mismatch in the post-encapsulation boundary instead of signaling an error.
Generators MUST wrap base64-encoded lines so that each line consists of exactly 64 characters except for the final line, and MUST NOT emit extraneous whitespace.
Implementations SHOULD generate CMS when it is an alternative to PKCS #7, promoting interoperability and forwards-compatibility.
New implementations SHOULD emit the strict textual encoding format (Figure 3), which requires exactly 64-character base64 lines, a strict final line, and newlines immediately after encapsulation boundaries.
Parsers MUST NOT malfunction when processing data appearing before the encapsulation boundaries, SHOULD ignore whitespace and other non-base64 characters, and MUST handle different newline conventions (CRLF, CR, or LF).
Attribute Certificates use the label 'ATTRIBUTE CERTIFICATE' and the encoded data MUST be a BER (DER strongly preferred) encoded ASN.1 AttributeCertificate structure as described in RFC 5755.
Certificate Revocation Lists use the label 'X509 CRL' and the encoded data MUST be a BER (DER strongly preferred) encoded ASN.1 CertificateList structure as described in RFC 5280 Section 5.
Cryptographic Message Syntax structures use the label 'CMS' and the encoded data MUST be a BER-encoded ASN.1 ContentInfo structure as described in RFC 5652. CMS is the IETF successor to PKCS #7.
Encrypted PKCS #8 structures (EncryptedPrivateKeyInfo) use the label 'ENCRYPTED PRIVATE KEY' and MUST be a BER (DER preferred) encoded ASN.1 EncryptedPrivateKeyInfo structure per RFC 5208 and RFC 5958.
Labels are formally case-sensitive, uppercase, and comprised of zero or more printable characters (excluding hyphen-minus). Labels must not contain consecutive spaces or hyphen-minuses, nor spaces or hyphen-minuses at either end. The label type implies the encoded data follows the specified ASN.1 syntax.
PKCS #10 Certification Requests use the label 'CERTIFICATE REQUEST' and the encoded data MUST be a BER (DER strongly preferred) encoded ASN.1 CertificationRequest structure as described in RFC 2986.
PKCS #7 Cryptographic Message Syntax structures use the label 'PKCS7' and the encoded data MUST be a BER-encoded ASN.1 ContentInfo structure as described in RFC 2315.
Public-key certificates use the label 'CERTIFICATE' and the encoded data MUST be a BER (DER strongly preferred) encoded ASN.1 Certificate structure as described in RFC 5280 Section 4.
Subject Public Key Info structures use the label 'PUBLIC KEY' and the encoded data MUST be a BER (DER preferred) encoded ASN.1 SubjectPublicKeyInfo structure as described in RFC 5280 Section 4.1.2.7.
Unencrypted PKCS #8 Private Key Info structures (PrivateKeyInfo / OneAsymmetricKey) use the label 'PRIVATE KEY' and MUST be a BER (DER preferred) encoded ASN.1 PrivateKeyInfo or OneAsymmetricKey structure per RFC 5208 / RFC 5958.
Data in this format often originates from untrusted sources; parsers must be prepared to handle unexpected data without causing security vulnerabilities. A conforming parser MAY interpret contents as another label type but must be aware of resulting security implications.
This document does not define canonical encodings, so implementations relying on canonical representation or fingerprinting must be aware of multiple ambiguity sources: text vs. binary encoding, multiple treated-as-equivalent labels, whitespace variations, and non-base64 characters. These ambiguities create opportunities for side channels; if canonical encoding is needed, the data must be decoded and re-encoded as DER.
Textual encoding consists of a pre-encapsulation boundary line '-----BEGIN <label>-----', followed by base64-encoded data (per RFC 4648 Section 4), followed by a post-encapsulation boundary line '-----END <label>-----'. There is exactly one space between 'BEGIN'/'END' and the label, and exactly five hyphen-minus characters on each side.
The strict ABNF (Figure 3) requires a pre-encapsulation boundary followed by a newline, then full 64-base64char lines each terminated by eol, a final line with up to 64 chars and optional padding, and a post-encapsulation boundary followed by a newline. New implementations SHOULD emit this strict format.