From bda89000aab9fb44dfe5578f72efeff260bfeb7f Mon Sep 17 00:00:00 2001 From: Brian Campbell Date: Tue, 27 Jun 2023 11:43:15 -0600 Subject: [PATCH] Fix '*** overwriting RFC9113' messages to fix ##2495 --- draft-ietf-httpbis-client-cert-field.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-httpbis-client-cert-field.md b/draft-ietf-httpbis-client-cert-field.md index 2aa2b1390..40692ca5f 100644 --- a/draft-ietf-httpbis-client-cert-field.md +++ b/draft-ietf-httpbis-client-cert-field.md @@ -136,10 +136,10 @@ such a connection. In contemporary versions of TLS {{?TLS=RFC8446}} CertificateVerify messages during the handshake and for the server to verify the CertificateVerify and Finished messages. -HTTP/2 restricts TLS 1.2 renegotiation ({{Section 9.2.1 of ?RFC9113}}) and -prohibits TLS 1.3 post-handshake authentication ({{Section 9.2.3 of ?RFC9113}}). However, they are +HTTP/2 restricts TLS 1.2 renegotiation ({{Section 9.2.1 of RFC9113}}) and +prohibits TLS 1.3 post-handshake authentication ({{Section 9.2.3 of RFC9113}}). However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 -{{?RFC9112}} where the server decides whether to request a client certificate +{{RFC9112}} where the server decides whether to request a client certificate based on the HTTP request. HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually authenticated and thus suitable for the mechanisms described in this @@ -294,8 +294,8 @@ an HTTP 431 (Request Header Fields Too Large) status code per {{Section 5 of ?RF Due to the typical size of the field values containing certificate data, recipients may need to be configured to allow for a larger maximum header size. An intermediary generating client certificate header fields on connections that allow -for advertising the maximum acceptable header size (e.g., HTTP/2 {{?RFC9113}} -or HTTP/3 {{?RFC9114}}) should account for the additional size of the header +for advertising the maximum acceptable header size (e.g., HTTP/2 {{RFC9113}} +or HTTP/3 {{RFC9114}}) should account for the additional size of the header of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. @@ -344,7 +344,7 @@ TTRP and backend or origin server, for example, might be authenticated in some way with the insertion and consumption of the `Client-Cert` and `Client-Cert-Chain` header fields occurring only on that connection. -{{Appendix B.3 of ?I-D.ietf-httpbis-message-signatures}} gives one example of +{{Appendix B.3 of I-D.ietf-httpbis-message-signatures}} gives one example of this with an application of HTTP Message Signatures. Alternatively, the network topology might dictate a private network such that the backend application is only able to accept