Thanks for the edits. It looks good to me with the additional edits Orie proposed in his recent email.
On Wed, Dec 4, 2024 at 4:27 PM Orie Steele <orie@transmute.industries> wrote: > Thank you! > > "cose key" should be "COSE Key", > > We could add "COSE Key as described in Section 7 of RFC9052" and "JSON Web > Key, as described in Section 4 of RFC7517" > > If the citations are helpful... This is a style nit. > > I approve of the changes. > > On Tue, Dec 3, 2024 at 3:48 PM Karen Moore <kmo...@amsl.com> wrote: > >> Authors, >> >> Thank you for the discussion and suggested changes. Our files now >> reflect the updates below (see < >> https://www.rfc-editor.org/authors/rfc9679-lastrfcdiff.html> for a >> snapshot of the changes). Please review and let us know if these changes >> are agreeable or if any further updates are needed. We will then ask the AD >> to approve them. >> >> 1) Section 5.3 >> >> OLD: >> Any party in possession of a key that is represented as a COSE Key can >> use the COSE Key Thumbprint. >> >> NEW: >> The only prerequisites are that the COSE_Key representation >> of the key be defined and the party creating the COSE Key Thumbprint >> be in possession of the necessary key material. >> >> ... >> 2) Addition of New Section. Note that we made “json web key” uppercase >> for consistency. >> >> NEW: >> 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. >> >> ... >> 3) Section 8 >> >> OLD: >> Confirmation Method Name: ckt >> Confirmation Method Description: COSE Key SHA-256 Thumbprint >> JWT Confirmation Method Name: jkt >> >> NEW: >> Confirmation Method Name: ckt >> Confirmation Method Description: COSE Key SHA-256 Thumbprint >> JWT Confirmation Method Name: (none) >> >> >> —FILES (please refresh)— >> >> The updated XML file is here: >> https://www.rfc-editor.org/authors/rfc9679.xml >> >> The updated output files are here: >> https://www.rfc-editor.org/authors/rfc9679.txt >> https://www.rfc-editor.org/authors/rfc9679.pdf >> https://www.rfc-editor.org/authors/rfc9679.html >> >> This diff file shows all changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9679-auth48diff.html >> >> These diff files show only changes made during the last edit round: >> https://www.rfc-editor.org/authors/rfc9679-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9679-lastrfcdiff.html >> >> This diff file shows all changes made to date: >> https://www.rfc-editor.org/authors/rfc9679-diff.html >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9679 >> >> Thank you, >> RFC Editor/kc >> >> > On Dec 3, 2024, at 7:55 AM, Hannes Tschofenig < >> hannes.tschofe...@gmail.com> wrote: >> > >> > Thanks for the insightful comment, Orie. I agree with your proposed >> edits for the IANA consideration section and the extra text before the >> section on relationship to certificate thumbprints. >> > >> > I am also fine with the additional text Mike proposed. >> > >> > It is indeed too late to add new functionality at this point in time. >> > >> > Ciao >> > Hannes >> > >> > >> > On Tue, Dec 3, 2024 at 3:13 AM Michael Jones < >> michael_b_jo...@hotmail.com> wrote: >> > I support adding the section that Orie proposed. >> > >> > >> > >> > However in reviewing related text, I unfortunately found a problem. >> Reading >> https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint-06#section-5.3, >> it differs from https://www.rfc-editor.org/rfc/rfc7638#section-3.5 in a >> counterproductive and overly restrictive way. Please change: >> > >> > >> > >> > Any party in possession of a key that is represented as a COSE Key can >> > >> > use the COSE Key Thumbprint. >> > >> > >> > >> > to: >> > >> > >> > >> > The only prerequisites are that the COSE_Key representation >> > >> > of the key be defined and the party creating the COSE Key Thumbprint >> > >> > be in possession of the necessary key material. >> > >> > >> > >> > That way it will be more actionable and will parallel the corresponding >> RFC 7638 text. >> > >> > >> > >> > Thanks >> all, >> > >> > -- Mike >> > >> > >> > >> > From: Orie Steele <orie@transmute.industries> >> > Sent: Monday, December 2, 2024 5:55 PM >> > To: Michael Jones <michael_b_jo...@hotmail.com> >> > Cc: Hannes Tschofenig <hannes.tschofe...@gmail.com>; 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>; Paul Wouters <paul.wout...@aiven.io>; >> auth48archive <auth48archive@rfc-editor.org> >> > Subject: Re: AUTH48: RFC-to-be 9679 <draft-ietf-cose-key-thumbprint-06> >> for your review >> > >> > >> > >> > 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>. >> > >> > * 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 >> > >> >> > > -- > > > 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
