Hi, This change is complete:
https://www.iana.org/assignments/cwt thanks, Amanda On Thu Dec 05 18:36:04 2024, kmo...@amsl.com wrote: > Dear IANA, > > Please make the following update to the “CWT Confirmation Methods” > registry at <https://www.iana.org/assignments/cwt> to match the edited > document at <https://www.rfc-editor.org/authors/rfc9679-diff.html>. > > 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) > > Thanks in advance! > RFC Editor/kc > > > Begin forwarded message: > > > > From: Karen Moore <kmo...@amsl.com> > > Subject: Re: [AD] AUTH48: RFC-to-be 9679 <draft-ietf-cose-key- > > thumbprint-06> for your review > > Date: December 5, 2024 at 10:25:03 AM PST > > To: Paul Wouters <paul.wout...@aiven.io>, Hannes Tschofenig > > <hannes.tschofe...@gmx.net>, Orie Steele <orie@transmute.industries>, > > Isobe Kohei <isobeko...@gmail.com>, Hannes Tschofenig > > <hannes.tschofe...@gmail.com> > > Cc: Michael Jones <michael_b_jo...@hotmail.com>, RFC Editor <rfc- > > edi...@rfc-editor.org>, "cose-...@ietf.org" <cose-...@ietf.org>, Cose > > Chairs Wg <cose-cha...@ietf.org>, auth48archive <auth48archive@rfc- > > editor.org> > > > > Hi Paul and *Authors, > > > > Thank you for your quick reply. We have noted your approval on the > > AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9679). > > > > *Authors, please confirm if any final checks need to be performed > > prior to publication per this comment: > > > >> The sourcecode type should be set to cbor-diag. We should validate > >> these source code blocks once more at the very end, using CBOR.me or > >> similar. > > > > Note that we will ask IANA to update their registry per the recent > > update; we will inform you when complete. > > > > Best regards, > > RFC Editor/kc > > > >> On Dec 5, 2024, at 9:54 AM, Paul Wouters <paul.wout...@aiven.io> > >> wrote: > >> > >> I approve, > >> > >> Thanks everyone for working this out and catching it before the RFC > >> went out. > >> > >> Paul > >> > >> On Thu, Dec 5, 2024 at 12:45 PM Karen Moore <kmo...@amsl.com> wrote: > >> Hi Mike and *Paul (AD), > >> > >> Thanks for providing the updated XML file. The changes are now > >> reflected in our files. Hannes and Orie, we will assume your assent > >> to these changes unless we hear otherwise. > >> > >> *Paul, please review the following changes and let us know if you > >> approve (we updated item 3 and added item 4; see Mike’s explanation > >> for the new changes in the thread below). 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 [RFC7517], > >> are different even when the underlying cryptographic key material is > >> the same. > >> > >> This document does not register a JWT confirmation method [RFC7800] > >> for using "ckt" as a confirmation method for a JWT or a CWT > >> confirmation method [RFC8747] for using "jkt" as a confirmation > >> method for a CWT. > >> > >> ... > >> 4) Section 5.6 - please review the file for the changes to this > >> section. > >> > >> … > >> 5) 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 3:08 PM, Michael Jones > >>> <michael_b_jo...@hotmail.com> wrote: > >>> > >>> Folks, I hate to do this, but in reviewing the newly added section, > >>> I realized that it was incorrectly using the term "claim". In both > >>> RFC 7800 and RFC 8747, "cnf" is a claim, whereas the JWT and CWT > >>> confirmation members are referred to as "members" - not "claims". > >>> Then I realized there other places in the draft this the term > >>> "claim" was incorrectly used. > >>> > >>> The attached updated source file makes the needed corrections. For > >>> easier reviewing, a diff from the RFC Editor's source also follows. > >>> > >>> RFC Editor, please apply these edits and send out a new draft for > >>> review. > >>> > >>> Thanks, > >>> -- Mike (writing as a COSE chair) > >>> > >>> diff rfc9679.xml rfc9679_mbj.xml > >>> 46c46 > >>> < <date year="2024" month="October"/> > >>> --- > >>>> <date year="2024" month="December"/> > >>> 284,285c284,288 > >>> < 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. > >>> --- > >>>> This document does not register > >>>> a JWT confirmation method <xref target="RFC7800"/> > >>>> for using "ckt" as a confirmation method for a JWT > >>>> or a CWT confirmation method <xref target="RFC8747"/> > >>>> for using "jkt" as a confirmation method for a CWT. > >>> 293,294c296,297 > >>> < <t>The proof-of-possession key is identified using the > >>> "ckt" claim, > >>> < the COSE Key Thumbprint claim. This claim contains the value of > >>> --- > >>>> <t>The proof-of-possession key is identified using the "ckt" > >>>> member of > >>>> the CWT confirmation claim "cnf". This member contains the value > >>>> of > >>> 299c302 > >>> < claim. In this approach, the issuer of a CWT declares that the > >>> --- > >>>> member. In this approach, the issuer of a CWT declares that the > >>> 302c305 > >>> < of the key by including a "ckt" claim in the CWT.</t> > >>> --- > >>>> of the key by including a "ckt" CWT confirmation method member in > >>>> the CWT.</t> > >>> 304c307 > >>> < <t>The following example demonstrates the use of the > >>> "ckt" claim > >>> --- > >>>> <t>The following example demonstrates the use of the "ckt" member > >>> 319,320c322,323 > >>> < <t><xref target="IANA"/> registers the "ckt" claim and > >>> the confirmation method. > >>> < The "ckt" claim is expected to be used in the "cnf" claim.</t> > >>> --- > >>>> <t><xref target="IANA"/> registers the "ckt" CWT confirmation > >>>> method member. > >>>> The "ckt" member is used in the "cnf" claim.</t> > >>> 510a514 > >>>> <xi:include > >>>> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7800.xml%22/> > >> > >> > >>> On Dec 4, 2024, at 12:12 PM, Karen Moore <kmo...@amsl.com> wrote: > >>> > >>> 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- > >>>>> a...@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
