Hi Deb and Paul, We are unable to verify this erratum that the submitter marked as editorial, so we changed the Type to “Technical”. As Stream Approver, please review and set the Status and Type accordingly (see the definitions at https://www.rfc-editor.org/errata-definitions/).
You may review the report at: https://www.rfc-editor.org/errata/eid8795. Information on how to verify errata reports can be found at: https://www.rfc-editor.org/how-to-verify/. Further information on errata can be found at: https://www.rfc-editor.org/errata.php. Thank you, Madison Church RFC Production Center > On Mar 2, 2026, at 10:44 AM, RFC Errata System <[email protected]> > wrote: > > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8795 > > -------------------------------------- > Type: Editorial > Reported by: Loïc Ferreira <[email protected]> > > Section: 4.6.2 > > Original Text > ------------- > A client that receives a CertificateRequest message without having sent the > "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert. > > Corrected Text > -------------- > A client that receives a CertificateRequest message encrypted with the > server_application_traffic_secret_N without having sent the > "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert. > > Notes > ----- > This sentence is to be understood in the context of a possible post-handshake > authentication. During a main handshake, a CertificateRequest message > (encrypted with the server_handshake_traffic_secret) may be sent by the > server (without need for the client to send a "post_handshake_auth" > extension). > > 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. > > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > 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]
