- From: Roman Danyliw via Datatracker <noreply@ietf.org>
- Date: Wed, 15 Mar 2023 14:30:13 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-client-cert-field@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, mnot@mnot.net
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-client-cert-field-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-field/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Loganaden Velvindron for the SECDIR review. ** Section 2.3 It MAY have a list of values or occur multiple times in a request. For header compression purposes, it might be advantageous to split lists into multiple instances. If the list is split into multiple headers, the order of the headers matters to say consistent with Section 4.4.2 of [TLS] (and the guidance in this section in cases where the chain is represented in a single header). Should this be explicitly stated? ** Section 2.4. Requests made over a TLS connection where the use of client certificate authentication was not negotiated MUST be sanitized by removing any and all occurrences of the Client-Cert and Client-Cert- Chain header fields Is this guidance for the TTRP on requests it got from the client? I’m trying to assess how this might work if there is a chain of proxies between the client and the origin.
Received on Wednesday, 15 March 2023 21:30:26 UTC