Found 2 records.

Status: Reported (2)

RFC 8879, "TLS Certificate Compression", December 2020

Errata ID: 8753
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Benjamin
Date Reported: 2026-02-11

Section 4 says:

   uncompressed_length:  The length of the Certificate message once it
      is uncompressed.  If, after decompression, the specified length
      does not match the actual length, the party receiving the invalid
      message MUST abort the connection with the "bad_certificate"
      alert.  The presence of this field allows the receiver to
      preallocate the buffer for the uncompressed Certificate message
      and enforce limits on the message size before performing
      decompression.

   compressed_certificate_message:  The result of applying the indicated
      compression algorithm to the encoded Certificate message that
      would have been sent if certificate compression was not in use.
      The compression algorithm defines how the bytes in the
      compressed_certificate_message field are converted into the
      Certificate message.

It should say:

   uncompressed_length:  The length of the Certificate message once it
      is uncompressed.  This is the length of the encoded Certificate
      structure, without a four-byte handshake header.  If, after
      decompression, the specified length does not match the actual
      length, the party receiving the invalid message MUST abort the
      connection with the "bad_certificate" alert.  The presence of this
      field allows the receiver to preallocate the buffer for the
      uncompressed Certificate message and enforce limits on the message
      size before performing decompression.

   compressed_certificate_message:  The result of applying the indicated
      compression algorithm to the encoded Certificate message that
      would have been sent if certificate compression was not in use.
      The compression algorithm defines how the bytes in the
      compressed_certificate_message field are converted into the
      Certificate message.  The input to the compression algorithm is
      the encoded Certificate structure, without a four-byte handshake
      header.

Notes:

We're often a bit sloppy about whether a "Certificate message" means the literal bytes of the Certificate structure, or also the four-byte header when wrapped in a Handshake structure. Since this is important for interop, explicitly say which we mean. Skimming BoringSSL, NSS, and OpenSSL, we all took this interpretation. This interpretation is also the marginally more size-efficient one.

Errata ID: 8738
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kazu Yamamoto
Date Reported: 2026-02-04

Section 5 says:

After decompression, the Certificate message MUST be processed as if
it were encoded without being compressed. This way, the parsing and
the verification have the same security properties as they would have
in TLS normally.

It should say:

After decompression, the Certificate message MUST be processed as if
it were encoded without being compressed, with the exception of the
handshake transcript. The CompressedCertificate message is hashed into
the handshake transcript (Section 4.4.3 of [RFC8446]) in place of a
Certificate message.

Notes:

The corrected text is suggested by Martin Thomson.

Report New Errata