Re: New Version Notification for draft-bdc-something-something-certificate-05.txt

[Justin Richer <[e-mail]>]

This is a simple draft, and I think it’s worth publishing. As a developer it’s a pain to deal with each different server implementation’s method of cramming a cert into the header, and in most cases it’s people following recipes from Stack Overflow to get it done. I have no delusions about an RFC fixing that variability over night, but it would be my hope that servers would adopt the standard version and make it easy to use (easier than copying from Stack Overflow, even).

It’s a small but consistent pain point, something that everyone has to solve in their own weird way. I think we can alleviate that pain.

 — Justin

> On Mar 23, 2021, at 3:27 PM, Brian Campbell <[e-mail]> wrote:
> 
> After a bit of a hiatus (largely due to some misunderstanding on my part around expectations and next steps), I've updated the 'Client-Cert' header draft.
> 
> The intended status of the draft has been changed to informational in hopes of better conveying the aspirational scope/goal of the document. Which is to describe existing practice and codify a simple variant thereof in order to hopefully nudge implementations towards more consistency and better, simpler out-of-the-box interoperability. 
> 
> 
> ---------- Forwarded message ---------
> From: <[e-mail] <mailto:[e-mail]>>
> Date: Tue, Mar 23, 2021 at 10:21 AM
> Subject: New Version Notification for draft-bdc-something-something-certificate-05.txt
> To: Brian Campbell <[e-mail] <mailto:[e-mail]>>
> 
> 
> 
> A new version of I-D, draft-bdc-something-something-certificate-05.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
> 
> Name:           draft-bdc-something-something-certificate
> Revision:       05
> Title:          Client-Cert HTTP Header: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications
> Document date:  2021-03-23
> Group:          Individual Submission
> Pages:          13
> URL:            https://www.ietf.org/archive/id/draft-bdc-something-something-certificate-05.txt <https://www.ietf.org/archive/id/draft-bdc-something-something-certificate-05.txt>
> Status:         https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ <https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>
> Html:           https://www.ietf.org/archive/id/draft-bdc-something-something-certificate-05.html <https://www.ietf.org/archive/id/draft-bdc-something-something-certificate-05.html>
> Htmlized:       https://tools.ietf.org/html/draft-bdc-something-something-certificate-05 <https://tools.ietf.org/html/draft-bdc-something-something-certificate-05>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-bdc-something-something-certificate-05 <https://www.ietf.org/rfcdiff?url2=draft-bdc-something-something-certificate-05>
> 
> Abstract:
>    This document defines the HTTP header field "Client-Cert" that allows
>    a TLS terminating reverse proxy to convey the client certificate of a
>    mutually-authenticated TLS connection to the origin server in a
>    common and predictable manner.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.