Let's add a section to the document, before the section on relationship to certificate thumbprints.
5.5 Relationship to JSON Web Key Thumbprints The ckt of a cose key, and jkt of a json web key are different, even when underlying cryptographic key material is the same. This document does not register a JWT claim for using ckt as a confirmation method for a JWT, or a CWT claim for using jkt as a confirmation method for a CWT. On Mon, Dec 2, 2024, 6:26 PM Orie Steele <orie@transmute.industries> wrote: > I agree, let's just stick with the simple (none) solution. > > Hannes can you approve or suggest changes to the clarifying text that > makes it clear this is not an oversight? > > Mike, do you object to that clarifying text assuming we take you change to > the IANA considerations section? > > OS > > On Mon, Dec 2, 2024, 5:56 PM Michael Jones <michael_b_jo...@hotmail.com> > wrote: > >> I’m either fine with Orie’s proposed change to the registration wording >> or the following one: >> >> >> >> 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: (none) >> >> For the record, I’m not OK trying to add a ckt JWT “cnf” method as an >> AUTH48 action (despite me appreciating Orie’s discussion of the >> possibility). >> >> >> >> Cheers, >> >> -- Mike >> >> >> >> *From:* Orie Steele <orie@transmute.industries> >> *Sent:* Monday, December 2, 2024 2:55 PM >> *To:* Hannes Tschofenig <hannes.tschofe...@gmail.com> >> *Cc:* Hannes Tschofenig <hannes.tschofe...@gmx.net>; RFC Editor < >> rfc-edi...@rfc-editor.org>; Isobe Kohei <isobeko...@gmail.com>; >> cose-...@ietf.org; Cose Chairs Wg <cose-cha...@ietf.org>; Michael Jones < >> michael_b_jo...@hotmail.com>; Paul Wouters <paul.wout...@aiven.io>; >> auth48archive@rfc-editor.org >> *Subject:* Re: AUTH48: RFC-to-be 9679 >> <draft-ietf-cose-key-thumbprint-06> for your review >> >> >> >> This is indeed a bug, for extra assurance that it is a problem: >> >> How would you use a ckt to verify a JWT that was using "cnf"? >> >> Here is a more complete fix for the bug: >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint-06#section-5.3 >> >> Note that the ckt of a cose key, and jkt of a json web key are different, >> even when underlying cryptographic key material is the same. >> >> ckt is a binary string and jkt is always a base64url string encoded as >> described in section 6.1 of RFC9449. >> To use a ckt claim inside a JWT, the ckt claim value MUST be base64url >> encoded. >> The example provided in section 6.1 of RFC9449 is modified to distinguish >> confirmation with a CKT instead of JKT: >> { >> "sub":"some...@example.com", >> "iss":"https://server.example.com";, >> "nbf":1562262611, >> "exp":1562266216, >> "cnf": { >> "ckt":"SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w" >> } >> } >> >> I used the same base64url encoded thumbprint the draft already used for >> extra clarity. >> >> ckt would also need to be added here: >> https://www.iana.org/assignments/jwt/jwt.xhtml#confirmation-methods >> >> This kind of change might need to be taken to the relevant lists for >> review... and maybe another WGLC. >> >> ... we could leave the "ckt" in JWT cnf registration to another document, >> but I think at a minimum we need something added to section 5.3 to the >> effect of: >> >> Note that the ckt of a cose key, and jkt of a json web key are different, >> even when underlying cryptographic key material is the same. >> ckt is a binary string and jkt is always a base64url string encoded as >> described in section 6.1 of RFC9449. >> >> ^ If we are comfortable with this change alone, we still have a problem >> with the registration template: >> https://www.rfc-editor.org/rfc/rfc8747.html#name-registration-template >> >> """ >> CWT claims should normally have a corresponding JWT claim. If a >> corresponding JWT claim would not make sense, the designated experts can >> choose to accept registrations for which the JWT Claim Name is listed as >> "N/A". >> """ >> >> The logical JWT claim is "ckt"... not "jkt"... so N/A... does not make >> sense... and leaving it blank also does not make sense. >> >> There is also the x5t claim which sets the precedent that ckt is for cose >> key, jkt is for json web key, and x5t is for x.509 certs. >> >> I propose: >> >> 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: Not assigned by RFCXXXX ( not to be >> confused with x5t or jkt ) >> >> >> OS >> >> >> >> On Mon, Dec 2, 2024 at 4:14 PM Hannes Tschofenig < >> hannes.tschofe...@gmail.com> wrote: >> >> 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 >> >> >> >> >> -- >> >> >> >> >> *ORIE STEELE *Chief Technology Officer >> www.transmute.industries >> >> <https://transmute.industries/> >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
