[TLS] [Technical Errata Reported] RFC8879 (8753)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC8879,
"TLS Certificate Compression".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8753

--------------------------------------
Type: Technical
Reported by: David Benjamin <[e-mail]>

Section: 4

Original Text
-------------
   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.

Corrected Text
--------------
   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.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8879 (draft-ietf-tls-certificate-compression-10)
--------------------------------------
Title               : TLS Certificate Compression
Publication Date    : December 2020
Author(s)           : A. Ghedini, V. Vasiliev
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Stream              : IETF
Verifying Party     : IESG