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 <[email protected]> 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 _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
