Re: [auth48] [EXT] [AD] AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09> for your review

[Paul Wouters <[e-mail]>]

On Wed, Mar 13, 2024 at 11:44 AM Alanna Paloma <[e-mail]> wrote:

> Hi Marco and Marek,
>
> Thank you for your replies. The files have been updated accordingly, and
> we’ve noted Marek’s approval on the AUTH48 status page:
> https://www.rfc-editor.org/auth48/rfc9529
>
> Once we’ve received Paul’s approval, we will move this document forward in
> the publication process.
>

I approve the changes.

Paul


> ...
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9529.xml
> https://www.rfc-editor.org/authors/rfc9529.txt
> https://www.rfc-editor.org/authors/rfc9529.html
> https://www.rfc-editor.org/authors/rfc9529.pdf
>
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9529-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9529-auth48diff.html (AUTH48
> changes)
> https://www.rfc-editor.org/authors/rfc9529-lastdiff.html (htmlwdiff diff
> between last version and this)
> https://www.rfc-editor.org/authors/rfc9529-lastrfcdiff.html (rfcdiff
> between last version and this)
>
> Thank you,
> RFC Editor/ap
>
> > On Mar 12, 2024, at 3:22 PM, Serafin, Marek <[e-mail]>
> wrote:
> >
> > Dear RFC Editor,  I also approve the publication of this document.
> >  Thanks,
> >  Marek Serafin
> >   From: Mališa Vučinić <[e-mail]>
> > Date: Monday, 11 March 2024 at 15:24
> > To: Göran Selander <[e-mail]>
> > Cc: Marco Tiloca <[e-mail]>, Alanna Paloma <[e-mail]>,
> John Mattsson <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, Serafin, Marek <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, Stephen Farrell <[e-mail]>,
> [e-mail] <[e-mail]>
> > Subject: [EXT] Re: [AD] AUTH48: RFC-to-be 9529
> <draft-ietf-lake-traces-09> for your review
> > CAUTION: This email is external. Do not click links or attachments that
> are unexpected or from unknown senders. If unsure, click the Report
> Phishing Button in Outlook.
> > Dear RFC Editor,  I approve the publication of this document.
> >  Thanks,
> > Mališa
> >
> >
> > On Mar 11, 2024, at 09:39, Göran Selander <[e-mail]>
> wrote:
> >  Hi,
> >  I reviewed Marco’s changes and they all look fine to me, some good
> catches.  Two remarks:
> >
> >     • I don’t think upper or lower case for hex strings matters.
> >
> >     • The text between the printouts in 2.7 and 3.9 could be verbatim
> the same, which they aren’t even after Marco’s  good changes, but that
> doesn’t matter either.
> >  Thanks,
> > Göran
> >  From: Marco Tiloca <[e-mail]>
> > Date: Sunday, 10 March 2024 at 19:48
> > To: Alanna Paloma <[e-mail]>, Göran Selander <
> [e-mail]>, John Mattsson <[e-mail]>
> > Cc: [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> > Subject: Re: [AD] AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09> for
> your review
> > Dear RFC Editor,
> >
> > I have reviewed the document, including the changes following John's and
> Göran's review.
> >
> > Please see below some comments from my side.
> >
> > Besides that, I approve this publication.
> >
> > Thanks,
> > /Marco
> >
> >
> > * Section 2.1
> >
> > OLD:
> > Connection identifier chosen by Initiator
> >
> >
> > NEW:
> > Connection identifier chosen by the Initiator
> >
> >
> > (2 instances)
> >
> > --------------------
> >
> > * Section 2.2
> >
> > To be consistent with the use of "represented by" in Sections 2.1, 3.1,
> 3.3, and 3.4:
> >
> > OLD:
> > The Responder selects its connection identifier C_R to be the byte
> string 0x18, which is encoded as h'18' = 0x4118 since it is not represented
> as a 1-byte CBOR int:
> >
> >
> > NEW:
> > The Responder selects its connection identifier C_R to be the byte
> string 0x18, which is encoded as h'18' = 0x4118 since it is not represented
> by a 1-byte CBOR int:
> >
> > --------------------
> >
> > * Section 2.2
> >
> > OLD:
> > Connection identifier chosen by Responder
> >
> >
> > NEW:
> > Connection identifier chosen by the Responder
> >
> >
> > (2 instances)
> >
> > --------------------
> >
> > * Section 2.4
> >
> > OLD:
> >     = HKDF-Expand( PRK_4x3m, info, key_length )
> >
> >
> > NEW:
> >     = HKDF-Expand( PRK_4e3m, info, key_length )
> >
> > --------------------
> >
> > * Section 2.4
> >
> > OLD:
> >      = HKDF-Expand( PRK_4x3m, info, iv_length )
> >
> >
> > NEW:
> >      = HKDF-Expand( PRK_4e3m, info, iv_length )
> >
> > --------------------
> >
> > * Section 2.5
> >
> > To be consistent with the definition in Section 4.2.1 of RFC 9528:
> >
> > OLD:
> > EDHOC_Exporter( label, context, length )
> > = EDHOC_KDF( PRK_exporter, label, context, length )
> >
> >
> > NEW:
> > EDHOC_Exporter( exporter_label, context, length )
> > = EDHOC_KDF( PRK_exporter, exporter_label, context, length )
> >
> > --------------------
> >
> > * Section 2.6
> >
> > OLD:
> > = HKDF-Expand( PRK_4x3m, info, oscore_salt_length )
> >
> >
> > NEW:
> > = HKDF-Expand( PRK_exporter, info, oscore_salt_length )
> >
> > --------------------
> >
> > * Section 2.7
> >
> > OLD:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c
> >
> > where info for KeyUpdate is:
> >
> >
> > NEW:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c
> >
> > context for KeyUpdate (CBOR Data Item) (17 bytes)
> > 50 d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c
> >
> > where info for KeyUpdate is:
> >
> > --------------------
> >
> > * Section 2.7
> >
> > OLD:
> > where info and key_length are unchanged as in Section 2.6.
> >
> >
> > NEW:
> > where info and oscore_key_length are unchanged as in Section 2.6.
> >
> > --------------------
> >
> > * Section 2.7
> >
> > OLD:
> > OSCORE Master Salt = HKDF-Expand( PRK_exporter, info, salt_length )
> >
> > where info and salt_length are unchanged as in Section 2.6.
> >
> >
> > NEW:
> > OSCORE Master Salt = HKDF-Expand( PRK_exporter, info, oscore_salt_length
> )
> >
> > where info and oscore_salt_length are unchanged as in Section 2.6.
> >
> > --------------------
> >
> > * Section 3.1
> >
> > OLD:
> > Connection identifier chosen by Initiator
> >
> >
> > NEW:
> > Connection identifier chosen by the Initiator
> >
> >
> > (2 instances)
> >
> > --------------------
> >
> > * Section 3.3
> >
> > OLD:
> > Connection identifier chosen by Initiator
> >
> >
> > NEW:
> > Connection identifier chosen by the Initiator
> >
> >
> > (2 instances)
> >
> > --------------------
> >
> > * Section 3.4
> >
> > OLD:
> > Connection identifier chosen by Responder
> >
> >
> > NEW:
> > Connection identifier chosen by the Responder
> >
> >
> > (2 instances)
> >
> > --------------------
> >
> > * Section 3.4
> >
> > For consistency with using lowercase letters in hexadecimal notation:
> >
> > OLD:
> > {                                              /CCS/
> >   2 : "example.edu",                           /sub/
> >   8 : {                                        /cnf/
> >     1 : {                                      /COSE_Key/
> >       1 : 2,                                   /kty/
> >       2 : h'32',                               /kid/
> >      -1 : 1,                                   /crv/
> >      -2 : h'BBC34960526EA4D32E940CAD2A234148
> >             DDC21791A12AFBCBAC93622046DD44F0', /x/
> >      -3 : h'4519E257236B2A0CE2023F0931F1F386
> >             CA7AFDA64FCDE0108C224C51EABF6072'  /y/
> >     }
> >   }
> > }
> >
> >
> > NEW:
> > {                                              /CCS/
> >   2 : "example.edu",                           /sub/
> >   8 : {                                        /cnf/
> >     1 : {                                      /COSE_Key/
> >       1 : 2,                                   /kty/
> >       2 : h'32',                               /kid/
> >      -1 : 1,                                   /crv/
> >      -2 : h'bbc34960526ea4d32e940cad2a234148
> >             ddc21791a12afbcbac93622046dd44f0', /x/
> >      -3 : h'4519e257236b2a0ce2023f0931f1f386
> >             ca7afda64fcde0108c224c51eabf6072'  /y/
> >     }
> >   }
> > }
> >
> > --------------------
> >
> > * Section 3.5
> >
> > For consistency with using lowercase letters in hexadecimal notation:
> >
> > OLD:
> > {                                              /CCS/
> >   2 : "42-50-31-FF-EF-37-32-39",               /sub/
> >   8 : {                                        /cnf/
> >     1 : {                                      /COSE_Key/
> >       1 : 2,                                   /kty/
> >       2 : h'2b',                               /kid/
> >      -1 : 1,                                   /crv/
> >      -2 : h'AC75E9ECE3E50BFC8ED6039988952240
> >             5C47BF16DF96660A41298CB4307F7EB6'  /x/
> >      -3 : h'6E5DE611388A4B8A8211334AC7D37ECB
> >             52A387D257E6DB3C2A93DF21FF3AFFC8'  /y/
> >     }
> >   }
> > }
> >
> >
> > NEW:
> > {                                              /CCS/
> >   2 : "42-50-31-FF-EF-37-32-39",               /sub/
> >   8 : {                                        /cnf/
> >     1 : {                                      /COSE_Key/
> >       1 : 2,                                   /kty/
> >       2 : h'2b',                               /kid/
> >      -1 : 1,                                   /crv/
> >      -2 : h'ac75e9ece3e50bfc8ed6039988952240
> >             5c47bf16df96660a41298cb4307f7eb6'  /x/
> >      -3 : h'6e5de611388a4b8a8211334ac7d37ecb
> >             52a387d257e6db3c2a93df21ff3affc8'  /y/
> >     }
> >   }
> > }
> >
> > --------------------
> >
> > * Section 3.7
> >
> > To be consistent with the definition in Section 4.2.1 of RFC 9528:
> >
> > OLD:
> > EDHOC_Exporter( label, context, length )
> > = EDHOC_KDF( PRK_exporter, label, context, length )
> >
> >
> > NEW:
> > EDHOC_Exporter( exporter_label, context, length )
> > = EDHOC_KDF( PRK_exporter, exporter_label, context, length )
> >
> > --------------------
> >
> > * Section 3.9
> >
> > OLD:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea
> >
> > and where info for the KeyUpdate is:
> >
> > context for KeyUpdate (CBOR Data Item) (17 bytes)
> > 50 a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea
> >
> > and where info for the key update is:
> >
> >
> > NEW:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea
> >
> > context for KeyUpdate (CBOR Data Item) (17 bytes)
> > 50 a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea
> >
> > and where info for the key update is:
> >
> > --------------------
> >
> > * Section 3.9
> >
> > OLD:
> > where info and key_length are unchanged as in Section 2.6.
> >
> >
> > NEW:
> > where info and oscore_key_length are unchanged as in Section 3.8.
> >
> > --------------------
> >
> > * Section 3.9
> >
> > OLD:
> > OSCORE Master Salt = HKDF-Expand( PRK_exporter, info, salt_length )
> >
> > where info and salt_length are unchanged as in Section 2.6.
> >
> >
> > NEW:
> > OSCORE Master Salt = HKDF-Expand( PRK_exporter, info, oscore_salt_length
> )
> >
> > where info and oscore_salt_length are unchanged as in Section 3.8.
> >
> > --------------------
> >
> > * Section 4
> >
> > OLD:
> > This is just a small set of examples of different reasons a message
> might be invalid. The same types of invalidities applies to other fields
> and messages as well.
> >
> >
> > NEW:
> > This is just a small set of examples of different reasons for which a
> message might be invalid. The same types of invalidities apply to other
> fields and messages as well.
> >
> > --------------------
> >
> > * Section 4.2.3
> >
> > To be consistent with "The x-coordinate in G_X is invalid ..." used in
> Section 4.2.2:
> >
> > OLD:
> > The x-coordinate in (G_X) is invalid as it does not correspond to a
> point on the P-256 curve.
> >
> >
> > NEW:
> > The x-coordinate in G_X is invalid as it does not correspond to a point
> on the P-256 curve.
> >
> > --------------------
> >
> > * Section 4.3.2
> >
> > OLD:
> > The element SUITES_I = [6, 2] is incorrectly encoded as an
> indefinite-length array. The correct encoding is the definite-length array
> 82 06 02 according to Section 4.2.1 of [RFC8949], which is referenced in
> Section 5.2.2 of [RFC9528].
> >
> >
> > NEW:
> > The element SUITES_I = [6, 2] is incorrectly encoded as an
> indefinite-length array. The correct encoding is the definite-length array
> 82 06 02 according to Section 4.2.1 of [RFC8949], which is referenced in
> Section 3.1 of [RFC9528].
> >
> >
> > (in Section 5.2.2 of RFC 9528, there is no reference to Section 4.2.1 of
> RFC 8949; that reference is instead provided in Section 3.1 of RFC 9528,
> which sets the general expectation on using deterministically encoded CBOR)
> >
> > --------------------
> >
> > * Section "Acknowledgments"
> >
> > To ensure that people are listed in alphabetical order by last name,
> Rikard Höglund and Stefan Hristozov should be swapped:
> >
> > OLD:
> > The authors want to thank all people verifying EDHOC test vectors and/or
> contributing to the interoperability testing, including: Christian Amsüss,
> Timothy Claeys, Rikard Höglund, Stefan Hristozov, Christos Koulamas,
> Francesca Palombini, Lidia Pocero, Peter van der Stok, and Michel Veillette.
> >
> >
> > NEW:
> > The authors want to thank all people verifying EDHOC test vectors and/or
> contributing to the interoperability testing, including: Christian Amsüss,
> Timothy Claeys, Stefan Hristozov, Rikard Höglund, Christos Koulamas,
> Francesca Palombini, Lidia Pocero, Peter van der Stok, and Michel Veillette.
> >
> > --------------------
> >
> > * Section "Authors' Addresses"
> >
> > Please update my contact information as follows:
> >
> > OLD:
> > Marco Tiloca
> > RISE
> > Sweden
> > Email: [e-mail]
> >
> >
> > NEW:
> > Marco Tiloca
> > RISE AB
> > Isafjordsgatan 22
> > 164 40 Kista
> > Sweden
> > Email: [e-mail]
> >
> > On 2024-03-08 23:59, Alanna Paloma wrote:
> > [You don't often get email from [e-mail]. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi Göran and John,
> >
> > Thank you for your replies. We have updated the files per your requests.
> Your approvals have been noted on the AUTH48 status page. We assume assent
> to changes from your coauthors unless we hear otherwise.
> >
> > The files have been posted here (please refresh):
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.xml&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191189309%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zuJ5kQsEzlRv%2BCHoKxKjMlTkVJyur3mS98iDrjUGNaY%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.txt&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191197701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=m7iKpHXTMZH5YLN8rEQhD0cT2nd79RXG%2BK8g%2BaR7O50%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191203471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B3ok5hBIbR5LYuoKIhHGFnI1uLmjcvH%2F4h9oaaYvobg%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.pdf&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191207686%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1N6ECFTNl1H%2FVhQowaSjeNb6fcSZqWuqSx7FvMbp7ds%3D&reserved=0
> >
> > The relevant diff files have been posted here:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-diff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191211753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2F9Y%2FGtDHx5qoSsn23ZAohureR1AkXMyJwuvXewxVZB4%3D&reserved=0
> (comprehensive diff)
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-auth48diff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191215778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=To5SysjL1z6Q63a4brCTGBpaogq8SF191lfaTu9G2bM%3D&reserved=0
> (AUTH48 changes)
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-lastdiff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191219776%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=J14XAK07VQbFzoMVC9AZvSzI9a4oAovguTumpjhYtZw%3D&reserved=0
> (htmlwdiff diff between last version and this)
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-lastrfcdiff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191223790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wyA6C3oceIvgY1zq%2B74BRQkBbQB0DO7f7eiANRfGtqU%3D&reserved=0
> (rfcdiff between last version and this)
> >
> > For the AUTH48 status of this document, please see:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9529&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191227807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6kap4ZmedQGTvP8eWNDgrOXPzZf1KJMMHr%2BIuHYOYwI%3D&reserved=0
> >
> > Thank you,
> > RFC Editor/ap
> >
> > On Mar 8, 2024, at 7:47 AM, Göran Selander <[e-mail]>
> wrote:
> >
> > Hi,
> > I have reviewed the XML file provided by John in the mail below.
> > Here are some minor editorial changes:
> > Section 2.2
> > OLD
> > Message to be signed 2 (CBOR Data Item) (341 bytes)
> > NEW
> > Message to be signed in message_2 (CBOR Data Item) (341 bytes)
> >   Section 2.3
> > OLD
> > Message to be signed 3 (CBOR Data Item) (341 bytes)
> > NEW
> > Message to be signed in message_3 (CBOR Data Item) (341 bytes)
> >   Section 4.1.4
> > OLD
> > The third element (G_X) is incorrectly encoded as a text string. The
> correct encoding is a byte string according to Section 5.2.1 of [RFC9528].
> > NEW
> > The third element of message_1 (G_X) is incorrectly encoded as a text
> string. The correct encoding is a byte string according to Section 5.2.1 of
> [RFC9528].
> > Section 4.15
> > OLD
> > The CBOR sequence has an incorrect number of elements. The correct
> number of elements in the CBOR sequence is 1 according to Section 5.3.1 of
> [RFC9528].
> > NEW
> > The CBOR sequence in message_2 has an incorrect number of elements. The
> correct number of elements in the CBOR sequence is 1 according to Section
> 5.3.1 of [RFC9528].
> >   I approve publication.
> > Göran
> > From: John Mattsson <[e-mail]>
> > Date: Thursday, 7 March 2024 at 22:29
> > To: Alanna Paloma <[e-mail]>, [e-mail] <
> [e-mail]>
> > Cc: [e-mail] <[e-mail]>, Göran
> Selander <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> > Subject: Re: [AD] Re: AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09>
> for your review
> > Thanks Alanna,
> >
> > Attached is an XML file with minor editorial formatting chances:
> >
> > - 0, 1, or 2 spaces indent were used in the diagnostic notation.
> > I aligned everything to 2 spaces, this aligns with RFC 9528
> > - One line of hexadecimal numbers where too long.
> > - Inconsistent use of space around arguments in functions like
> HKDF-Expand()
> > - Removed one remaining double =
> > - Removed a tab character that cause an extra empty line.
> > - Aligned use of end comma in diagnostic notation. Removed one comma.
> > - Aligned use of comma after equation before where. Removed several.
> > I approve publication.
> >
> > Cheers,
> > John Preuß Mattsson
> > From: Alanna Paloma <[e-mail]>
> > Date: Thursday, 7 March 2024 at 20:28
> > To: John Mattsson <[e-mail]>, [e-mail] <
> [e-mail]>
> > Cc: [e-mail] <[e-mail]>, Göran
> Selander <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> > Subject: [AD] Re: AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09> for
> your review
> > Hi John and Paul*,
> >
> > *Paul - As the AD, please review and approve of the following updates:
> >
> > -Section 1.1: deleted text
> > -Section 2.7: updated text
> > -Sections 3.4 and 3.5: added text
> > -Section 3.9: added and updated text
> > -Sections 4.1.2-4.1.7: updated text
> >
> > The changes can be seen in the following diff:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-ad-diff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191231790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rkjVg18gQVPWaJdmoFs1%2F%2Bc4WVJuOq0X88KWovAKltY%3D&reserved=0
> >
> > John - Thank you for your replies.  We have updated as requested.
> >
> > OLD:
> > When the protocol transporting EDHOC messages does not inherently
> provide correlation across all messages, like Constrained Application
> Protocol (CoAP) [RFC7252], then
> > NEW:
> > When the protocol transporting EDHOC messages does not inherently
> provide correlation across all messages, then
> > (It is incorrect that CoAP inherently provide correlation across all
> messages)
> >
> > FYI: As the citation to RFC 7252 has been removed and it is not cited
> anywhere else in the document, we have removed its corresponding reference
> entry from the Informative References section.
> >
> > ...
> > The files have been posted here (please refresh):
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.xml&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191235866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=w02jIC1%2F81YCkYGP490FY5zl5iHXGDBidh5hI6amOvk%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.txt&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191239794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Iw8Tanc%2BI2cw2H%2Bamo%2FkFQUt2Ni5DGqJ15%2Bndt0fhAs%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191243866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XvisvePbCY%2BR9%2FR4BWsfe7Quq7eGu%2Bx73mmWyvEXjBU%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.pdf&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191248105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XnPoarbVQpOxjYVXnbog1WMdq7If9WSJcWpjVR%2B3IZs%3D&reserved=0
> >
> > The relevant diff files have been posted here:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-diff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191252080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=MOuVSW4UKOR2EU4NXvR%2FjPBOHI69Kq1bZvY1vFP88Ss%3D&reserved=0
> (comprehensive diff)
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-auth48diff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191256046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lvfTwug7F20CSI3wyI6t%2FPx%2Fl%2F8i3c60LYxQ4x3b1gM%3D&reserved=0
> (AUTH48 changes)
> >
> > Please review the document carefully and contact us with any further
> updates you may have.  Note that we do not make changes once a document is
> published as an RFC.
> >
> > We will await approvals from each party listed on the AUTH48 status page
> below prior to moving this document forward in the publication process.
> >
> > For the AUTH48 status of this document, please see:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9529&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191260047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=iIeLmsHUYy%2B5gvVS50V4gvbWQmUEtPEVjdZ%2BMoUNevc%3D&reserved=0
> >
> > Thank you,
> > RFC Editor/ap
> >
> > On Mar 7, 2024, at 8:01 AM, John Mattsson <john.mattsson=
> [e-mail]> wrote:
> >
> > Hi,
> > I have reviewed the whole document in detail. I have the following
> suggestions:
> > ------------------
> > OLD:This document contains some example
> > NEW:This document contains example
> > ------------------
> > OLD:
> > When the protocol transporting EDHOC messages does not inherently
> provide correlation across all messages, like Constrained Application
> Protocol (CoAP) [RFC7252], then
> > NEW:
> > When the protocol transporting EDHOC messages does not inherently
> provide correlation across all messages, then
> > (It is incorrect that CoAP inherently provide correlation across all
> messages)
> > ------------------
> > OLD: Authentication with Signatures, X.509 Certificates Identified by
> 'x5t'
> > NEW: Authentication with Signatures, X.509 Identified by 'x5t'
> > (To fit on one line and align with Section 3 title)
> > ------------------
> > OLD:
> > MAC_2 is computed through EDHOC_Expand() using the EDHOC hash
> >    algorithm (see Section 4.1.2 of [RFC9528]):
> >     [
> >    MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2)
> >     where
> >      info = ( 2, context_2, mac_length_2 )
> > NEW:
> > MAC_2 is computed through EDHOC_Expand() using the EDHOC hash
> >    algorithm (see Section 4.1.2 of [RFC9528]):
> >     MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2)
> >     where
> >     info = ( 2, context_2, mac_length_2 )
> > ------------------
> > OLD:
> > where
> >      info = ( 6, context_3, mac_length_3 )
> > NEW:
> > where
> >     info = ( 6, context_3, mac_length_3 )
> > ------------------
> > OLD: Crypto-Related Errors
> > NEW: Cryptography-Related Errors
> > ------------------
> > OLD:
> > K_4   = EDHOC_KDF( PRK_4e3m, 8, TH_4, key_length )
> >       = HKDF-Expand( PRK_4e3m, info, key_length )
> > NEW:
> > K_4 = EDHOC_KDF( PRK_4e3m, 8, TH_4, key_length )
> >     = HKDF-Expand( PRK_4e3m, info, key_length )
> > Same thing with
> > SALT_3e2m  =
> > SALT_4e3m  =
> > ------------------
> > OLD:
> > PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
> >               = HKDF-Expand( PRK_out, info,  hash_length )
> > NEW:
> > PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
> >              = HKDF-Expand( PRK_out, info,  hash_length )
> > ------------------
> > OLD:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c
> > context for KeyUpdate (CBOR Data Item) (17 bytes)
> > 50 d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c
> > where info for key update is:
> > info =
> > (
> > 11,
> > h'd6be169602b8bceaa01158fdb820890c',
> > 32
> > )
> > NEW:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c
> > where info for KeyUpdate is:
> > info =
> > (
> > 11,
> > h'd6be169602b8bceaa01158fdb820890c',
> > 32
> > )
> > info for KeyUpdate (CBOR Sequence) (20 bytes)
> > 0b 50 d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c 18 20
> > ------------------
> > OLD:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea
> > context for KeyUpdate (CBOR Data Item) (17 bytes)
> > 50 a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea
> > and where info for the key update is:
> > info =3.7
> > (
> > 11,
> > h'a01158fdb820890cd6be169602b8bcea',
> > 32
> > )
> > NEW:
> > context for KeyUpdate (Raw Value) (16 bytes)
> > a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea
> > and where info for the KeyUpdate is:
> > info =
> > (
> > 11,
> > h'a01158fdb820890cd6be169602b8bcea',
> > 32
> > )
> > info for KeyUpdate (CBOR Sequence) (20 bytes)
> > 0b 50 a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea 18 20
> > ------------------
> >
> > Cheers,
> > John Preuß Mattsson
> > From: John Mattsson <[e-mail]>
> > Date: Tuesday, 5 March 2024 at 13:41
> > To: [e-mail] <[e-mail]>, Göran
> Selander <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> > Cc: [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> > Subject: Re: AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09> for your
> review
> > Dear RFC Editor,
> > See answers to the questions inline.
> > Cheers,
> > John Prueß Mattsson
> > From: [e-mail] <[e-mail]>
> > Date: Friday, 1 March 2024 at 03:03
> > To: Göran Selander <[e-mail]>, John Mattsson <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> > Cc: [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> > Subject: Re: AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09> for your
> review
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> >
> > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the
> > title) for use on
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191264036%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QnyTsWJAD2izZ9vw5whpH22QuB5ds8b4wXVsI8FEqDg%3D&reserved=0.
> -->
> > John: test vector, lightweight, authenticated key exchange, LAKE, AKE
> >
> > 2) <!--[rfced] FYI, to match usage in [RFC9528], we have updated
> > "static-ephemeral" to "ephemeral-static" for consistency. Please let us
> > know if this is not accurate.
> >
> > Original:
> >    The endpoints use NIST P-256 [SP-800-186] for
> >    both ephemeral-ephemeral and static-ephemeral Diffie-Hellman key
> >    exchange.
> >
> > Current:
> >    The endpoints use NIST P-256 [SP-800-186] for
> >    both ephemeral-ephemeral and ephemeral-static Diffie-Hellman key
> >    exchange.
> > -->
> >
> > John: That is great.
> >
> > 3) <!--[rfced] The following lines are not complete sentences. Please
> > review and let us know if/how they should be updated.
> >
> > Original (Section 3.4):
> >    The Responder's static Diffie-Hellman P-256 key pair:
> >
> > Original (Section 3.5):
> >    The Initiator's static Diffie-Hellman P-256 key pair:
> > -->
> >
> > OLD: The Responder's static Diffie-Hellman P-256 key pair:
> > NEW: The Responder's static Diffie-Hellman P-256 key pair consist of a
> private key and a public key.
> > OLD: The Initiator's static Diffie-Hellman P-256 key pair:
> > NEW: The Initiator's static Diffie-Hellman P-256 key pair consist of a
> private key and a public key.
> >
> > 4) <!--[rfced] In Sections 2.2, 2.5, 3.4, 3.5, 3.7, and 3.9, it seems
> there
> > are extraneous equals signs. Please review. For example, should the
> > second equals sign on the PRK_exporter line and PRK_out line
> > be removed (see c and d below)?
> >
> > a) Original:
> >    PRK_2e = EDHOC_Extract( salt, G_XY ) =
> >           = HMAC-SHA-256( salt, G_XY )
> >
> > Perhaps:
> >    PRK_2e = EDHOC_Extract( salt, G_XY )
> >           = HMAC-SHA-256( salt, G_XY )
> >
> > b) Original: (appears in Sections 2.2 and 3.4)
> >
> >    KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length ) =
> >                = HKDF-Expand( PRK_2e, info, plaintext_length )
> >
> > Perhaps:
> >    KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length )
> >                = HKDF-Expand( PRK_2e, info, plaintext_length )
> >
> > c) Original: (appears in 3.7 and 3.9)
> >
> > PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
> >              = HKDF-Expand( PRK_out, info,  hash_length )
> >
> > Perhaps:
> > PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length )
> >              = HKDF-Expand( PRK_out, info,  hash_length )
> >
> >
> > d) Original: (appears in 2.5 and 3.7)
> >
> > PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length ) =
> >         = HKDF-Expand( PRK_4e3m, info,  hash_length )
> >
> > Perhaps:
> > PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length )
> >         = HKDF-Expand( PRK_4e3m, info,  hash_length )
> >
> >
> > e) Original:
> >    OSCORE Master Secret =
> >    = HKDF-Expand(PRK_exporter, info, oscore_key_length)
> >
> > Perhaps:
> >   OSCORE Master Secret
> >   = HKDF-Expand(PRK_exporter, info, oscore_key_length)
> >
> > f) See more examples in Section 3.5: SALT_4e3m and PRK_4e3m
> > -->
> >
> > John: Yes, please remove all the extraneous equals signs on the upper
> line.
> >
> > 5) <!--[rfced] The first lines of Sections 4.1.1-4.1.7, 4.2.1-4.2.6,
> 4.3.1,
> > and 4.3.2 are not complete sentences. Please review these instances and
> > let us know how they  may be updated.
> > -->
> > OLD: Invalid encoding of message_1 as array.
> > NEW: message_1 is incorrectly encoded as a CBOR array.
> > OLD: Invalid encoding 41 0e of C_I = 0x0e.
> > NEW: The connection identifier C_I = 0x0e is incorrectly encoded as the
> CBOR byte string 41 0e.
> > OLD: Invalid array encoding 81 02 of SUITES_I = 2
> > NEW: The element SUITES_I = 2 is incorrectly encoded as the CBOR array
> 81 02.
> > OLD: Invalid type of the third element (G_X). NEW: The third element
> (G_X) is incorrectly encoded as a text string.  OLD: Invalid number of
> elements in the CBOR sequence.
> > NEW: The CBOR sequence has an incorrect number of elements.
> > OLD: Invalid encoding a1 04 42 32 10 of ID_CRED_R in PLAINTEXT_2.
> > NEW: The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the
> map a1 04 42 32 10.
> > OLD: Invalid encoding 41 32 of ID_CRED_R in PLAINTEXT_2.
> > NEW: The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the
> byte string 41 32.
> > OLD: Invalid length of the third element (G_X).
> > NEW: The third element (G_X) has an invalid length.
> > OLD: Invalid x-coordinate in G_X as x ≥ p.
> > NEW: The x-coordinate in G_X is invalid as x ≥ p.
> > OLD: Invalid x-coordinate in (G_X) not corresponding to a point on the
> P-256 curve.
> > NEW: The x-coordinate in (G_X) is invalid as it does not correspond to a
> point on the P-256 curve.
> > OLD: Curve25519 point of low order which fails the check for all-zero
> output according to Section 9.2 of [RFC9528].
> > NEW: The Curve25519 point is invalid as it is of low order and fails the
> check for all-zero output according to Section 9.2 of [RFC9528].
> > OLD: Invalid length of third element (Signature_or_MAC_2).
> > NEW: The third element (Signature_or_MAC_2) has an invalid length.
> > OLD: Invalid encoding of third element (G_X).
> > NEW: The third element (G_X) is incorrectly encoded.
> > OLD: Invalid 16-bit encoding 19 00 03 of METHOD = 3.
> > NEW: The element METHOD = 3 is incorrectly encoded as an 16-bit integer.
> > OLD: Invalid indefinite-length array encoding 9F 06 02 FF of SUITES_I =
> [6, 2]. NEW: The element SUITES_I = [6, 2] is incorrectly encoded as an
> indefinite-length array.
> >
> > 6) <!--[rfced] Citations
> >
> > a) Section 4.1.2 - "0e" is not mentioned in Section 3.3.2 of RFC 9528.
> > (Please refer to
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191268034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sgDpUtBSVLxkWyYAEon1x1gMWXYywFiCUGAQ4H2meuk%3D&reserved=0
> or
> > the other formats.) Please review and let us know if/how the citation
> > may be updated.
> >
> > Original:
> >    Correct encoding is 0e
> >    according to Section 3.3.2 of [I-D.ietf-lake-edhoc].
> > NEW: The correct encoding is the integer 0e  according to Section 3.3.2
> of [RFC9528].
> >
> > b) Section 4.1.3 - "02" is not mentioned in Section 5.2.2 of RFC 9528.
> > Please review and let us know if/how the citation may be updated.
> >
> > Original:
> >    Correct encoding is 02
> >    according to Section 5.2.2 of [I-D.ietf-lake-edhoc].
> > NEW: The correct encoding is the integer 02 according to Section 5.2.2
> of [RFC9528].
> >
> > c) Section 4.1.5 - "correct number of elements" is not mentioned in
> > Section 5.3.1 of RFC 9528. Please review and let us know if/how this
> > citation may be updated.
> >
> > Original:
> >    Correct number of
> >    elements is 1 according to Section 5.3.1 of [I-D.ietf-lake-edhoc].
> > NEW: The  correct number of elements in the CBOR sequence is 1 according
> to Section 5.3.1 of [RFC9528].
> >
> > d) Section 4.2.2 - "x < p" is not mentioned in Section 9.2 of RFC 9528.
> > Please let us know if/how this citation may be updated.
> >
> > Original:
> >    Requirement that x < p
> >    according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
> >    of [SP-800-56A].
> > NEW: It is required that x < p according to Section 5.6.2.3 of
> [SP-800-56A], which is referenced in Section 9.2 of [RFC9528].
> >
> > e) Section 4.2.3 - "y^2 ≡ x^3 + a ⋅ x + b (mod p)" is not mentioned in
> > Section 9.2 of RFC 9528. Please let us know if/how this citation may be
> > updated.
> >
> > Original:
> >    Requirement that y^2 ≡ x^3 + a ⋅ x + b (mod p)
> >    according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
> >    of [SP-800-56A].
> > NEW: It is required that y^2 ≡ x^3 + a ⋅ x + b (mod p) according to
> Section 5.6.2.3 of [SP-800-56A], which is referenced in Section 9.2 of
> [RFC9528].
> >
> > f) Section 4.2.6 - "leading zeros" is not mentioned in Section 3.7 of
> > RFC 9528. Please review and let us know if/how this citation may be
> > updated.
> >
> > Original:
> >    Correct encoding is with
> >    leading zeros according to Section 3.7 of [I-D.ietf-lake-edhoc] and
> >    Section 7.1.1 of [RFC9053].
> > NEW: The correct encoding is with leading-zero octets according to
> Section 7.1.1 of [RFC9053], which is referenced in Section 3.7 of [RFC9528].
> >
> > g) Section 4.3.2 - "82 06 02" is not mentioned in Section 5.2.2 of RFC
> 9528.
> > Please review and let us know if/how this citation may be updated.
> >
> > Original:
> >    Correct encoding is 82 06 02 according to Section 5.2.2 of
> >    [I-D.ietf-lake-edhoc].
> > -->  NEW: The correct encoding is the definite-length array 82 06 02
> according to Section 4.2.1 of[RFC8949], which is referenced in Section
> 5.2.2 of [RFC9528].
> >
> > 7) <!--[rfced] The first paragraphs of Sections 4.2.2  and 4.2.3 are
> made up of
> > incomplete sentences. Please review and let us know how they may be
> updated.
> >
> > Original (Section 4.2.2):
> >    Invalid x-coordinate in G_X as x ≥ p.  Requirement that x < p
> >    according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
> >    of [SP-800-56A].
> >
> > Original (Section 4.2.3):
> >    Invalid x-coordinate in (G_X) not corresponding to a point on the
> >    P-256 curve.  Requirement that y^2 ≡ x^3 + a ⋅ x + b (mod p)
> >    according to Section 9.2 of [RFC9528] and Section 5.6.2.3
> >    of [SP-800-56A].
> > -->
> >
> > NEW: The x-coordinate in G_X is invalid as x ≥ p. It is required that x
> < p according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
> of [SP-800-56A].
> > NEW: The x-coordinate in (G_X) is invalid as it does not correspond to a
> point on the P-256 curve. It is required that y^2 ≡ x^3 + a ⋅ x + b (mod p)
> according to Section 9.2 of [RFC9528] and Section 5.6.2.3 of [SP-800-56A].
> >
> > 8) <!--[rfced] To improve readability, may we update this sentence as
> follows?
> >
> > Original:
> >    Correct is the
> >    deterministic encoding 03 according to Section 3.1 of
> >    [I-D.ietf-lake-edhoc] and Section 4.2.1 of [RFC8949], which states
> >    that the arguments for integers, lengths in major types 2 through 5,
> >    and tags are required to be as short as possible.
> >
> > Perhaps:
> >    The deterministic encoding 03 is correct according to Section 3.1 of
> >    [RFC9528] and Section 4.2.1 of [RFC8949], which states that the
> >    arguments for integers, lengths in major types 2 through 5, and tags
> >    are required to be as short as possible.
> > -->
> >
> > John: Fine
> >
> > 9) <!--[rfced] FYI, we have moved one name in order to alphabetize
> > the names in the Acknowledgments because that seemed to have been
> > your intention. Please let us know if you prefer otherwise.
> > -->
> > John: Fine
> >
> > 10) <!-- [rfced] FYI - We have added expansions for the following
> abbreviations
> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> > expansion in the document carefully to ensure correctness.
> >
> > Authenticated Encryption with Associated Data (AEAD)
> > Concise Binary Object Representation (CBOR)
> > Constrained Application Protocol (CoAP)
> > CBOR Object Signing and Encryption (COSE)
> > Diffie-Hellman (DH)
> > Elliptic Curve Diffie-Hellman (ECDH)
> > Edwards-curve Digital Signature Algorithm (EdDSA)
> > Message Authentication Code (MAC)
> > Object Security for Constrained RESTful Environments (OSCORE)
> > -->
> >
> > John: Good
> >
> > 11) <!-- [rfced] Please review the "Inclusive Language" portion of the
> > online Style Guide
> > <
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191272061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TcMi2r18OayRoQKjW00Mais5pNZ1XOPri45egHBpJgs%3D&reserved=0
> >
> > and let us know if any changes are needed.
> >
> > For example, please consider whether "master" should be updated.
> > -->
> >
> > John: We have reviewed the “Inclusive Language” portion. “master” cannot
> be updated as it is the term used in RFC 8613.
> >
> > Thank you.
> >
> > RFC Editor/ap/ar
> >
> >
> > On Feb 29, 2024, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2024/02/29
> >
> > 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191276108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=99D2NM3IrOJd4lGokYCxNpXYErd7fxhXPaEeHTXAny4%3D&reserved=0
> ).
> >
> > 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191280002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=N6SgFgHgxPYEUpuvifHQbgxOnRgLcbBhTmbmNQa6sH0%3D&reserved=0
> ).
> >
> > *  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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191283790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AsxtplpRTKNrGv8RlpondijhsO1qHT02cJtBxqfzyZ0%3D&reserved=0
> >.
> >
> > *  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
> >
> >   *  [e-mail] (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).
> >
> >   *  [e-mail], which is a new archival mailing list
> >      to preserve AUTH48 conversations; it is not an active discussion
> >      list:
> >
> >     *  More info:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191287555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Y35093WvArRnHSIHySO%2BdRAqpxWpVs21GJk3PFRzFI4%3D&reserved=0
> >
> >     *  The archive itself:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191291494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yrlULXvu6f84rSpHs2IWJbcU78qK0zhVrVdh%2FeqQTLY%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,
> >        [e-mail] 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.xml&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191295037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=llyj506fq0dMTBlxnm56m4KsOv4KxM04oNlAjAgotcw%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191299066%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dDqCNR9gpNbtzFpBDgyYOVlETTemIQIe2LFMXIiA32o%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.pdf&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191302974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HbBR%2FzZjmiCoOgbIbOXO8CFZok3Z800wbPmFa43xKG0%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529.txt&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191306994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Xr6u7nUcy%2FRy4Q3H0%2BHwmwIeVmO3TLOgJAz3pu%2BLUJU%3D&reserved=0
> >
> > Diff file of the text:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-diff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191310894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=0LrtKHW%2FAwRC67KW91%2FrqsbduSvMl71Vvmyat2IaO80%3D&reserved=0
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-rfcdiff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191314831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tQT8loNb%2BE2%2F8FyCdfQW1MElsWXw8gBaIVzo7UGj8oI%3D&reserved=0
> (side by side)
> >
> > Diff of the XML:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9529-xmldiff1.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191318786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rSTmilChz160LE5ZFOhW9nFkmODY5CTlkXeMmR%2BNGUE%3D&reserved=0
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9529&data=05%7C02%7Cmarco.tiloca%40ri.se%7C75aedc9f2a0f4166d10c08dc3fc3720f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638455356191323104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k0iEnYKu0d0AsG2iyYfv2NnCG%2BL4CcS8wuxYgfuFD98%3D&reserved=0
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9529 (draft-ietf-lake-traces-09)
> >
> > Title            : Traces of EDHOC
> > Author(s)        : G. Selander, J. Mattsson, M. Serafin, M. Tiloca, M.
> Vučinić
> > WG Chair(s)      : Mališa Vučinić, Stephen Farrell
> > Area Director(s) : Roman Danyliw, Paul Wouters
> >
> > John: My last name is fine in the document but here it is chopped in
> half. My last name is “Preuß Mattsson” including the white space.
> >
> >
> >  --
> > Marco Tiloca
> > Ph.D., Senior Researcher
> >
> > Phone: [phone]
> >
> > RISE Research Institutes of Sweden AB
> > Box 1263
> > 164 29 Kista (Sweden)
> >
> > Division: Digital Systems
> > Department: Computer Science
> > Unit: Cybersecurity
> >
> > https://www.ri.se
>
>