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/>
-----Original Message-----
From: Karen Moore <kmo...@amsl.com>
Sent: Wednesday, December 4, 2024 12:14 PM
To: Hannes Tschofenig <hannes.tschofe...@gmail.com>; Paul Wouters
<paul.wout...@aiven.io>; Hannes Tschofenig <hannes.tschofe...@gmx.net>; Isobe
Kohei <isobeko...@gmail.com>; Orie Steele <orie@transmute.industries>; Michael
Jones <michael_b_jo...@hotmail.com>
Cc: RFC Editor <rfc-edi...@rfc-editor.org>; cose-...@ietf.org; Cose Chairs Wg
<cose-cha...@ietf.org>; auth48archive <auth48archive@rfc-editor.org>
Subject: Re: AUTH48: RFC-to-be 9679 <draft-ietf-cose-key-thumbprint-06> for
your review
Hello Hannes,
We have noted your approval of the document on the AUTH48 status page
(https://www.rfc-editor.org/auth48/rfc9679).
We now await approval from Paul.
Best regards,
RFC Editor/kc
> On Dec 4, 2024, at 12:11 PM, Hannes Tschofenig <hannes.tschofe...@gmail.com>
> wrote:
>
> 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.r/
> fc-editor.org%2Fauthors%2Frfc9679.xml&data=05%7C02%7C%7Cffec038f21264c
> 9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638689
> 400647996515%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=bzWmdHu1SIdScl4DvOiEyfTd%2F8yGCnR4jeEj1sK1Rnk%3D&reserved=0
>
> The updated output files are here:
>
> https://www.r/
> fc-editor.org%2Fauthors%2Frfc9679.txt&data=05%7C02%7C%7Cffec038f21264c
> 9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638689
> 400648016060%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=MWn7grAtZbRscMA87kc8jXdej2zWbTqhbuSjHlqypJI%3D&reserved=0
>
> https://www.r/
> fc-editor.org%2Fauthors%2Frfc9679.pdf&data=05%7C02%7C%7Cffec038f21264c
> 9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638689
> 400648035295%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=tWjwnqfIS6zEEf6iwa5xFQjbL8b%2F%2FEDJNHhqb%2B5nZvw%3D&reserved
> =0
>
> https://www.r/
> fc-editor.org%2Fauthors%2Frfc9679.html&data=05%7C02%7C%7Cffec038f21264
> c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63868
> 9400648050919%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> %7C&sdata=lXM13vx00Wd0CfBgOIyyf5KKoSlalZitAFfoKBepf30%3D&reserved=0
>
> This diff file shows all changes made during AUTH48:
>
> https://www.r/
> fc-editor.org%2Fauthors%2Frfc9679-auth48diff.html&data=05%7C02%7C%7Cff
> ec038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%
> 7C0%7C638689400648064937%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3
> D%7C0%7C%7C%7C&sdata=0NZU01lPTAdCqLYDPA2Z1oNKTTq9ERRZ8YgPeL9vZJI%3D&re
> served=0
>
> These diff files show only changes made during the last edit round:
>
> https://www.r/
> fc-editor.org%2Fauthors%2Frfc9679-lastdiff.html&data=05%7C02%7C%7Cffec
> 038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C
> 0%7C638689400648078454%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=4TNQbumUEeRnloq87gXGMK%2Bx6oYnY%2FHEsYAmSnFwHEc%3D&
> reserved=0
>
> https://www.r/
> fc-editor.org%2Fauthors%2Frfc9679-lastrfcdiff.html&data=05%7C02%7C%7Cf
> fec038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1
> %7C0%7C638689400648092307%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=BXUsNh1kjpgH%2FsyUGhIbzR3e17Qn2poKGyN8XGDwokQ%3D
> &reserved=0
>
> This diff file shows all changes made to date:
>
> https://www.r/
> fc-editor.org%2Fauthors%2Frfc9679-diff.html&data=05%7C02%7C%7Cffec038f
> 21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C
> 638689400648105827%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%
> 7C%7C%7C&sdata=b%2BgABW%2BoOFSvz1BXmJGkQo0ZwfzdzmwcjXRvoJYVW1o%3D&rese
> rved=0
>
> For the AUTH48 status of this document, please see:
>
> https://www.r/
> fc-editor.org%2Fauth48%2Frfc9679&data=05%7C02%7C%7Cffec038f21264c9983c
> d08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63868940064
> 8118882%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> ata=NSSl5drmtVNahxxJRIi64i%2FGrLUQmmvQ3JKATE%2Byw5M%3D&reserved=0
>
> 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://dat/
> > atracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-key-thumbprint-06%2
> > 3section-5.3&data=05%7C02%7C%7Cffec038f21264c9983cd08dd14a03c85%7C84
> > df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638689400648167196%7CUnknow
> > n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX
> > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7GJO0q8u
> > JxSVFlSLdsuzpTAsD%2B8q0MttHOmZgMiqt5M%3D&reserved=0
> >
> > 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%2Fassignments%2Fjwt%2Fjwt.xhtml%23confirmation-methods&dat
> > a=05%7C02%7C%7Cffec038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb4
> > 35aaaaaaaaaaaa%7C1%7C0%7C638689400648192834%7CUnknown%7CTWFpbGZsb3d8
> > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=E%2FuHxvQHDkL91qUvdn9V%2
> > Fiv%2BFpxNOo6Rlu1%2FVPDoB%2Fc%3D&reserved=0
> >
> > 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%2Frfc%2Frfc8747.html%23name-registration-template&da
> > ta=05%7C02%7C%7Cffec038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb
> > 435aaaaaaaaaaaa%7C1%7C0%7C638689400648207569%7CUnknown%7CTWFpbGZsb3d
> > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Zj7JoUzqivSAAho1RH96bUW
> > SyjoKTii9If1wARZrurI%3D&reserved=0
> >
> > """
> > 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://mai/
> > larchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIA
> > e6P8O4Zc&data=05%7C02%7C%7Cffec038f21264c9983cd08dd14a03c85%7C84df9e
> > 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638689400648277324%7CUnknown%7C
> > TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QsmVXUToHM9L
> > GhDlqmlc93MbNMwhIkVimBA6yDRp0VQ%3D&reserved=0
> > * The archive itself:
> > https://mai/
> > larchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7C
> > %7Cffec038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaa
> > aa%7C1%7C0%7C638689400648292565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h
> > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> > IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9JjfOtR82MrA6d25M4JqN8zhFofbLYySXX4O
> > yQiX3%2Fc%3D&reserved=0
> >
> > * 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%2Fauthors%2Frfc9679.xml&data=05%7C02%7C%7Cffec038f21
> > 264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C
> > 638689400648309932%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> > 7C0%7C%7C%7C&sdata=JQjyIvBMPXkftvVXeZDiZnbm9wTLayJW6SH9u%2Fc%2FMOE%3
> > D&reserved=0
> > https://www/
> > .rfc-editor.org%2Fauthors%2Frfc9679.html&data=05%7C02%7C%7Cffec038f2
> > 1264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7
> > C638689400648327455%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
> > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> > %7C0%7C%7C%7C&sdata=WLL5FVGsJynRmj191VO20UFrO47yZwEL%2BDVTS66Hu6g%3D
> > &reserved=0
> > https://www/
> > .rfc-editor.org%2Fauthors%2Frfc9679.pdf&data=05%7C02%7C%7Cffec038f21
> > 264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C
> > 638689400648345419%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> > 7C0%7C%7C%7C&sdata=nQSv83kDF8l6wWd30%2B6UmhAFKtgwZ37eeGHXK3xJ8ck%3D&
> > reserved=0
> > https://www/
> > .rfc-editor.org%2Fauthors%2Frfc9679.txt&data=05%7C02%7C%7Cffec038f21
> > 264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C
> > 638689400648362433%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> > 7C0%7C%7C%7C&sdata=RFPj4fNYkfhGZw25PPl%2FGMF4JJ5ztGgymDO4lY%2Bg4ZQ%3
> > D&reserved=0
> >
> > Diff file of the text:
> > https://www/
> > .rfc-editor.org%2Fauthors%2Frfc9679-diff.html&data=05%7C02%7C%7Cffec
> > 038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%
> > 7C0%7C638689400648378700%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> > 3D%3D%7C0%7C%7C%7C&sdata=ZmyL2kWaxX2ls0KY9YErddGbrprSJMKS%2FMDLTu3cJ
> > BA%3D&reserved=0
> > https://www/
> > .rfc-editor.org%2Fauthors%2Frfc9679-rfcdiff.html&data=05%7C02%7C%7Cf
> > fec038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7
> > C1%7C0%7C638689400648397152%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> > fQ%3D%3D%7C0%7C%7C%7C&sdata=nwtix1KYYNYJKt%2Fun8NpCSg4%2BGmImmbqRIYf
> > vUrLDQM%3D&reserved=0 (side by side)
> >
> > Diff of the XML:
> > https://www/
> > .rfc-editor.org%2Fauthors%2Frfc9679-xmldiff1.html&data=05%7C02%7C%7C
> > ffec038f21264c9983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%
> > 7C1%7C0%7C638689400648414007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
> > yfQ%3D%3D%7C0%7C%7C%7C&sdata=FrWTUDwi%2B3qEMOqubvSIB7EG1eKRdUUZIQUWQ
> > nzdw3M%3D&reserved=0
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> > https://www/
> > .rfc-editor.org%2Fauth48%2Frfc9679&data=05%7C02%7C%7Cffec038f21264c9
> > 983cd08dd14a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63868
> > 9400648430300%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi
> > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> > C%7C%7C&sdata=iH3O7S1AhYR57Ehi94B7o0AElOPdOycSDhEukSlW8Cw%3D&reserve
> > d=0
> >
> > 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
> > http://www/.
> > transmute.industries%2F&data=05%7C02%7C%7Cffec038f21264c9983cd08dd14
> > a03c85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6386894006484454
> > 01%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM
> > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda
> > ta=KT2Gb0P%2BJJcz57WLJFuZHnKWXbk0%2FWx6g5sLOJRNyqg%3D&reserved=0
> >
>
>
>
> --
>
> ORIE STEELE
> Chief Technology Officer
> http://www.tr/
> ansmute.industries%2F&data=05%7C02%7C%7Cffec038f21264c9983cd08dd14a03c
> 85%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638689400648460614%7CU
> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiO
> iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QaEVRvL
> hRvhznAhoPQKi94%2BFfgMGESmF2aW%2FYHcHZm4%3D&reserved=0
>
rfc9679_mbj.xml
Description: rfc9679_mbj.xml
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
