Hi Orie and *Paul (AD), We have updated the text with your additional suggested edits; the changes are now reflected in our files (links below). We now await approvals from Hannes and Paul.
*Paul, please review the following changes and let us know if you approve. The updates can also be viewed here: https://www.rfc-editor.org/authors/rfc9679-auth48diff.html. 1) Section 5.1 OLD: The COSE Key Thumbprint is a digest of the essential parameters required to represent the key as a COSE Key, rather than any additional data that might accompany the key. NEW: The COSE Key Thumbprint is a digest of the ordered essential parameters needed to represent a COSE Key, with all other parameters excluded. ... 2) 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. … 3) Addition of Section 5.5 NEW: 5.5 Relationship to JSON Web Key Thumbprints The ckt of a COSE Key, as described in Section 7 of [RFC9052], and the jkt of a JSON Web Key, as described in Section 4 of RFC 7517, are different even when the 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. … 4) 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 4, 2024, at 7:26 AM, 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 > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
