RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 7468, "Textual Encodings of PKIX, PKCS, and CMS Structures", April 2015

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4508
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Sean Leonard
Date Reported: 2015-10-20
Verifier Name: Stephen Farrell
Date Verified: 2016-06-10

Section 3 says:

  preeb      = "-----BEGIN " label "-----" ; unlike [RFC1421] (A)BNF,
                                           ; eol is not required (but
  posteb     = "-----END " label "-----"   ; see [RFC1421], Section 4.4)

It should say:

  preeb      = "-----" %x42.45.47.49.4E " " label "-----" 

  posteb     = "-----" %x45.4E.44 " " label"-----"
                         ; unlike [RFC1421] (A)BNF, eol is not required
                         ; (but see [RFC1421], Section 4.4)

OR:

  preeb      = %s"-----BEGIN " label "-----" ; unlike [RFC1421] (A)BNF,
                                             ; eol is not required (but
  posteb     = %s"-----END " label "-----"   ; see [RFC1421],
                                             ; Section 4.4)

...with reference to RFC 7405.

Notes:

The encapsulation boundaries are case-sensitive, including (especially) the BEGIN and END characters. Nearly all implementations enforce the case sensitivity of BEGIN and END on input, and all surveyed implementations output all-caps.

Status: Reported (1)

RFC 7468, "Textual Encodings of PKIX, PKCS, and CMS Structures", April 2015

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 7697
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Stefan Brüns
Date Reported: 2023-11-10

Section 5.3 says:

   This section does not disturb the official application/pkix-cert
   registration [RFC2585] in any way (which states that "each '.cer'
   file contains exactly one certificate, encoded in DER format"), but
   merely articulates a widespread, de facto alternative.

It should say:

   This section does not disturb the official application/pkix-cert
   registration [RFC2585] in any way (which states that "each '.cer'
   file contains exactly one certificate, encoded in DER format").
   
   PEM encoded certificates should use the application/pkix-cert+pem
   IANA registration. This distinguishes it from plain DER encoded data
   and also denotes it uses an encoding following syntax and semantics
   of the application/pem media type.  

Notes:

The current statement allows two possible interpretations:

1. As PEM wraps DER format, a PEM encoded certificate is also DER encoded. Thus application/pkix-cert is the correct media type also for PEM encoded certificates.

2. "Exactly one certificate in DER format" precludes any additional encoding, e.g. PEM. Thus application/pkix-cert is not valid for PEM encoded certificates.

In case 2 is the correct interpretation, a distinct media type for PEM encoded data should be registered with IANA. This media type should be used as a structured syntax type for all PEM wrapped key and certificate types. E.g.:

- application/pem
- application/pkix-cert+pem
- application/x-x509-ca-cert+pem

The latter two would be an amendment to RFC 2585 and and RFC 8894 respectively.

The "+pem" suffix used conforms to RFC 6838 "structured syntax".

OpenPGP ascii armor (RFC 4880) and SSH public key (RFC 4716) are *not* subtypes of PEM.

Report New Errata



Advanced Search