Hi David, Thank you for your reply. Your approval has been noted: https://www.rfc-editor.org/auth48/rfc9729
We await Jonathan’s approval of the content. Best regards, RFC Editor/ap > On Feb 9, 2025, at 7:56 AM, David Oliver <da...@guardianproject.info> wrote: > > Wonderful. You have my approval on the recent updates on RFC9729. > > David M. Oliver | da...@guardianproject.info | https://guardianproject.info | > @davidmoliver | +1 970 368 2366 > > > On Wed, Feb 5, 2025 at 12:49 PM Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > Hi David, > > Thank you for your reply. We have updated the files with your additional > tweaks and noted your approval on the AUTH48 status page: > https://www.rfc-editor.org/auth48/rfc9729 > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9729.md > > https://www.rfc-editor.org/authors/rfc9729-diff.html (comprehensive text > diff) > https://www.rfc-editor.org/authors/rfc9729-auth48diff.html (AUTH48 text diff) > > (Note: We have adjusted the wrapping to now have a width of 80.) > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html (comprehensive md > diff) > https://www.rfc-editor.org/authors/rfc9729-mdauth48diff.html (AUTH48 md diff) > https://www.rfc-editor.org/authors/rfc9729-mdlastdiff.html (last version to > this one) > > We will now await approvals of the content from David M. Oliver and Jonathan > Hoyland. > > Best regards, > RFC Editor/ap > > > > On Feb 4, 2025, at 4:08 PM, David Schinazi <dschinazi.i...@gmail.com> wrote: > > > > Thanks Alanna! > > > > I went through the document in detail, and I think the changes look great. > > I made three small tweaks to your version, and uploaded them here: > > https://github.com/httpwg/http-extensions/commit/03cd6dc3b6588b30a40ce74f59843ed96a15555c > > > > Apart from that, I think this is good to go. > > > > Doing the review in markdown made it incredibly seamless. I have a couple > > incredibly minor points about the markdown diff: > > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html > > > > 1) it points out a change in the lines surrounding diagrams/sourcecode > > blocks: it says that "~~" was changed to "~~~" even though both versions > > contain "~~~". > > 2) it seems to be set to a column width of 78. That causes a few lines to > > wrap for documents where we use a width of 80 (which I think is the > > default?). > > > > Thanks! > > David > > > > On Tue, Feb 4, 2025 at 1:53 PM Alanna Paloma <apal...@staff.rfc-editor.org> > > wrote: > > Hi David, > > > > Thank you for your reply. We have updated as requested. > > > > > 4) <!-- [rfced] We see that the capitalization of "Key ID" is > > > inconsistent. Please let how we should update it. > > > --> > > > > > > I think the inconsistency is intentional: "key ID" refers to the concept, > > > whereas "Key ID" refers to the eponymous field in the Key Exporter > > > Context structure. Does that work or do you think it reduces clarity? > > > > ) Thank you for clarifying. The reasoning makes sense, and it should be > > clear enough from the context within the document. We have left the > > capitalization as is. > > > > > > The updated files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9729.md > > > > https://www.rfc-editor.org/authors/rfc9729-diff.html (comprehensive text > > diff) > > https://www.rfc-editor.org/authors/rfc9729-auth48diff.html (AUTH48 text > > diff) > > > > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html (comprehensive > > md diff side-by-side) > > https://www.rfc-editor.org/authors/rfc9729-mdauth48diff.html (AUTH48 md > > diff side-by-side) > > > > > > Please review the document carefully and contact us with any further > > updates you may have. Note that we do not make changes once a document is > > published as an RFC. > > > > We will await approvals from each author of the content in the markdown > > prior to converting the markdown to RFCXML and asking each authors to > > review and approve the final files. > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9729 > > > > Thank you, > > RFC Editor/ap > > > > > On Feb 3, 2025, at 7:43 PM, David Schinazi <dschinazi.i...@gmail.com> > > > wrote: > > > > > > Hi RFC Editor(s), > > > > > > First off, I really wanted to thank you for doing this AUTH48 in markdown > > > - it's a huge life improvement :-) > > > > > > Please find answers to your questions inline below. Let me know when > > > you've incorporated those and I'll do a full pass of the document as soon > > > as I can in the next few days. > > > > > > Thanks, > > > David > > > > > > On Fri, Jan 31, 2025 at 12:18 PM <rfc-edi...@rfc-editor.org> wrote: > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > > > necessary) the following questions, which are also in the XML file. > > > > > > 1) <!-- [rfced] FYI, we have added the following sentence to Section 1.1 > > > ("Conventions and Definitions") in order to include a citation for RFC > > > 8792 in the text. Please let us know of any objections. > > > > > > Current: > > > Various examples in this document contain long lines that may be > > > folded, > > > as described in [RFC8792]. > > > --> > > > > > > Sounds good. > > > > > > 2) <!--[rfced] Throughout the text, "Concealed HTTP authentication > > > scheme" and "Concealed authentication scheme" appear to be used > > > inconsistently. Please review these occurrences and let us know if/how > > > they be made consistent. Some examples are listed here: > > > > > > Original: > > > When a client wishes to use the Concealed HTTP authentication scheme > > > with a request, it SHALL compute the authentication proof using a TLS > > > keying material exporter with the following parameters: > > > ... > > > If a frontend is configured to check the Concealed authentication > > > scheme, it will parse the Authorization (or Proxy-Authorization) > > > header field. > > > --> > > > > > > I think that the defining statement at the start of section 2 > > > <<This document defines the "Concealed" HTTP authentication scheme.>> > > > should include "HTTP" to be extra clear when defining it. I'm happy for > > > all other uses to be consistent. > > > So maybe we make them all <<Concealed HTTP authentication scheme>>? > > > > > > 3) <!-- [rfced] Please review sourcecode types within the markdown file, > > > and let us know if they should be set and/or have been set correctly. > > > > > > The current list of preferred values for sourcecode types is available at > > > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > > > If the current list does not contain an applicable type, feel free to > > > suggest additions for consideration. Note that it is also acceptable > > > to leave the sourcecode type not set. > > > --> > > > > > > They look correct to me. It might be useful to define a new type for the > > > QUIC presentation format given how common it's becoming (since we have > > > one for the TLS presentation format), but for this document those can > > > stay empty since it doesn't exist yet. > > > > > > 4) <!-- [rfced] We see that the capitalization of "Key ID" is > > > inconsistent. Please let how we should update it. > > > --> > > > > > > I think the inconsistency is intentional: "key ID" refers to the concept, > > > whereas "Key ID" refers to the eponymous field in the Key Exporter > > > Context structure. Does that work or do you think it reduces clarity? > > > > > > 5) <!--[rfced] As "Signature Algorithm" is being used in a general way > > > and not as a field name, may we make it lowercase in this sentence? > > > > > > Original: > > > The encoding of the public key is determined by the Signature > > > Algorithm in use as follows: > > > > > > Perhaps: > > > The encoding of the public key is determined by the signature > > > algorithm in use as follows: > > > --> > > > > > > Agreed, that one's not the field name so lowercase makes sense. > > > > > > 6) <!--[rfced] For clarity, may we update "which" to "that" here? It > > > depends on the intended meaning, as noted below. > > > > > > Original: > > > The public key is an RSAPublicKey structure > > > [PKCS1] encoded in DER [X.690]. BER encodings which are not DER > > > MUST be rejected. > > > > > > Perhaps (restrictive "that", meaning some BER encodings): > > > The public key is an RSAPublicKey structure > > > [PKCS1] encoded in DER [X.690]. BER encodings that are not DER > > > MUST be rejected. > > > > > > Or (nonrestrictive "which", meaning all BER encodings): > > > The public key is an RSAPublicKey structure > > > [PKCS1] encoded in DER [X.690]. BER encodings, which are not DER, > > > MUST be rejected. > > > --> > > > > > > You're correct, let's use "that" here. Some BER encodings are DER, and > > > those are valid and must not be rejected. > > > > > > 7) <!-- [rfced] We having difficulty parsing the following sentence. > > > Does the key ID authenticate or does the client? > > > > > > Current: > > > For example, the key ID "basement" authenticating using Ed25519 > > > [ED25519] could produce the following header field > > > > > > Perhaps: > > > For example, a client authenticating with the key ID "basement" > > > and using Ed25519 [ED25519] could produce the following header > > > field > > > --> > > > > > > You're correct that the key ID doesn't authenticate. However, > > > "authenticate" is somewhat annoying as a verb in that the concept of "the > > > client is proving to the server that it is who it says it is" can be said > > > as "the server authenticated the client" or "the client authenticated to > > > the server" - and not everyone agrees that they're both valid. How about > > > we sidestep the issue with something like this: > > > <<For example, a client using the key ID "basement" and the signature > > > algorithm Ed25519 [ED25519] could produce the following header field:>> > > > > > > 8) <!-- [rfced] RFC 8941 has been obsoleted by RFC 9651. May we replace > > > RFC 8941 with RFC 9651? > > > --> > > > > > > Yes, please. > > > > > > 9) <!-- [rfced] Please review the "Inclusive Language" portion of the > > > online Style Guide > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let > > > us know if any changes are needed. Updates of this nature typically > > > result in more precise language, which is helpful for readers. > > > --> > > > > > > I didn't find any instances of non inclusive language, but let me know if > > > you noticed any. > > > > > > 10) <!--[rfced] References. May we add the following URL to this > > > reference for the ease of the reader? > > > > > > https://www.itu.int/rec/T-REC-X.690 > > > > > > Current: > > > > > > [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: > > > Specification of Basic Encoding Rules (BER), Canonical > > > Encoding Rules (CER) and Distinguished Encoding Rules > > > (DER)", ITU-T Recommendation X690, ISO/IEC 8825-1:2021, > > > February 2021. > > > --> > > > > > > Sounds good. > > > > > > Thank you. > > > > > > RFC Editor/ap/jm > > > > > > > > > On 1/31/25 2:14 PM, rfc-edi...@rfc-editor.org wrote: > > > *****IMPORTANT***** > > > > > > Updated 2025/01/31 > > > > > > RFC Author(s): > > > -------------- > > > > > > Instructions for Completing AUTH48 > > > > > > Your document has now entered AUTH48. Once it has been reviewed and > > > approved by you and all coauthors, it will be published as an RFC. > > > If an author is no longer available, there are several remedies > > > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > > > You and you coauthors are responsible for engaging other parties > > > (e.g., Contributors or Working Group) as necessary before providing > > > your approval. > > > > > > Planning your review > > > --------------------- > > > > > > Please review the following aspects of your document: > > > > > > * RFC Editor questions > > > > > > Please review and resolve any questions raised by the RFC Editor > > > that have been included in the .md file as comments marked as > > > follows: > > > > > > <!-- [rfced] ... --> > > > > > > These questions will also be sent in a subsequent email. > > > > > > * Changes submitted by coauthors > > > > > > Please ensure that you review any changes submitted by your > > > coauthors. We assume that if you do not speak up that you > > > agree to changes submitted by your coauthors. > > > > > > * Content > > > > > > Please review the full content of the document, as this cannot > > > change once the RFC is published. Please pay particular attention to: > > > - IANA considerations updates (if applicable) > > > - contact information > > > - references > > > > > > * Copyright notices and legends > > > > > > Please review the copyright notice and legends as defined in > > > RFC 5378 and the Trust Legal Provisions > > > (TLP – https://trustee.ietf.org/license-info). > > > > > > * Semantic markup > > > > > > Please review the markup in the XML file to ensure that elements of > > > content are correctly tagged. For example, ensure that <sourcecode> > > > and <artwork> are set correctly. See details at > > > <https://authors.ietf.org/rfcxml-vocabulary>. > > > > > > * Formatted output > > > > > > Please review the PDF, HTML, and TXT files to ensure that the > > > formatted output, as generated from the markup in the XML file, is > > > reasonable. Please note that the TXT will have formatting > > > limitations compared to the PDF and HTML. > > > > > > > > > Submitting changes > > > ------------------ > > > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > > > the parties CCed on this message need to see your changes. The parties > > > include: > > > > > > * your coauthors > > > > > > * rfc-edi...@rfc-editor.org (the RPC team) > > > > > > * other document participants, depending on the stream (e.g., > > > IETF Stream participants are your working group chairs, the > > > responsible ADs, and the document shepherd). > > > > > > * auth48archive@rfc-editor.org, which is a new archival mailing list > > > to preserve AUTH48 conversations; it is not an active discussion > > > list: > > > > > > * More info: > > > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > > > * The archive itself: > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > > > * Note: If only absolutely necessary, you may temporarily opt out > > > of the archiving of messages (e.g., to discuss a sensitive > > > matter). > > > If needed, please add a note at the top of the message that you > > > have dropped the address. When the discussion is concluded, > > > auth48archive@rfc-editor.org will be re-added to the CC list and > > > its addition will be noted at the top of the message. > > > > > > You may submit your changes in one of two ways: > > > > > > An update to the provided .md file > > > — OR — > > > An explicit list of changes in this format > > > > > > Section # (or indicate Global) > > > > > > OLD: > > > old text > > > > > > NEW: > > > new text > > > > > > You do not need to reply with both an updated file and an explicit > > > list of changes, as either form is sufficient. > > > > > > We will ask a stream manager to review and approve any changes that seem > > > beyond editorial in nature, e.g., addition of new text, deletion of text, > > > and technical changes. Information about stream managers can be found in > > > the FAQ. Editorial changes do not require approval from a stream manager. > > > > > > > > > Approving for publication > > > -------------------------- > > > > > > This document is being edited in kramdown-rfc markdown. Once the content > > > is approved, the markdown will be converted to RFCXML and formatted as an > > > RFC. You will be asked to review and approve the XML and output formats. > > > Your final approval means you approve both the content and format. > > > > > > To approve your RFC for publication, please reply to this email stating > > > that you approve this RFC for publication. Please use ‘REPLY ALL’, > > > as all the parties CCed on this message need to see your approval. > > > > > > > > > Files > > > ----- > > > > > > The files are available here: > > > https://www.rfc-editor.org/authors/rfc9729.md > > > https://www.rfc-editor.org/authors/rfc9729.html > > > https://www.rfc-editor.org/authors/rfc9729.pdf > > > https://www.rfc-editor.org/authors/rfc9729.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9729-diff.html > > > https://www.rfc-editor.org/authors/rfc9729-rfcdiff.html (side by side) > > > > > > Diff of the markdown: > > > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9729 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9729 (draft-ietf-httpbis-unprompted-auth-12) > > > > > > Title : The Concealed HTTP Authentication Scheme > > > Author(s) : D. Schinazi, D. Oliver, J. Hoyland > > > WG Chair(s) : Mark Nottingham, Tommy Pauly > > > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini > > > > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
