Thanks for the work on the draft and sorry for the slow response. I read through the draft carefully today and in general the edits look good but I noticed a possible bug.
In the IANA consideration section we say that the ckt confirmation method maps to the jkt JWT configuration method. I double-checked RFC 9449, which defines the jkt, and it defines the computation as follows: " The value of the jkt member MUST be the base64url encoding of the JWK SHA-256 Thumbprint. " In draft-ietf-cose-key-thumbprint-06 we define the ckt thumbprint as the hash of the deterministic encoding of the COSE_Key structure. So, the question to me is whether we can even map the ckt to the jkt since the underlying structure that is hashed is different: JWK vs. COSE_Key structure. For that reason I believe it would be more correct to change the IANA consideration section by omitting the JWT Confirmation Method Name. Here is the proposed change: From: Confirmation Method Name: ckt Confirmation Method Description: COSE Key SHA-256 Thumbprint JWT Confirmation Method Name: jkt To: Confirmation Method Name: ckt Confirmation Method Description: COSE Key SHA-256 Thumbprint JWT Confirmation Method Name: Do you agree with me? Sorry for noticing this issue only now. Ciao Hannes > Betreff: AUTH48: RFC-to-be 9679 <draft-ietf-cose-key-thumbprint-06> for > your review > Datum: Mon, 21 Oct 2024 14:30:59 -0700 (PDT) > Von: rfc-edi...@rfc-editor.org > An: isobeko...@gmail.com, hannes.tschofe...@gmx.net, > orie@transmute.industries > Kopie (CC): rfc-edi...@rfc-editor.org, cose-...@ietf.org, > cose-cha...@ietf.org, michael_b_jo...@hotmail.com, paul.wout...@aiven.io, > auth48archive@rfc-editor.org > > *****IMPORTANT***** > > Updated 2024/10/21 > > 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 XML 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> > <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 XML 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 XML 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 > -------------------------- > > 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/rfc9679.xml > https://www.rfc-editor.org/authors/rfc9679.html > https://www.rfc-editor.org/authors/rfc9679.pdf > https://www.rfc-editor.org/authors/rfc9679.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9679-diff.html > https://www.rfc-editor.org/authors/rfc9679-rfcdiff.html (side by side) > > Diff of the XML: https://www.rfc-editor.org/authors/rfc9679-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9679 > > Please let us know if you have any questions. > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9679 (draft-ietf-cose-key-thumbprint-06) > > Title : CBOR Object Signing and Encryption (COSE) Key Thumbprint > Author(s) : K. Isobe, H. Tschofenig, O. Steele > WG Chair(s) : Matthew A. Miller, Ivaylo Petrov, Michael B. Jones > > Area Director(s) : Deb Cooley, Paul Wouters > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
