[auth48] [IANA #1361342] [IANA] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23> for your review

[David Dong via RT <[e-mail]>]

Hi Alanna,

These changes are complete:

-24 to 23	Standards Action

0		Reserved for success
1	tstr	Unspecified error

Please see:
https://www.iana.org/assignments/edhoc/

Best regards,

David Dong
IANA Services Sr. Specialist

On Fri Mar 15 16:36:39 2024, [e-mail] wrote:
> IANA,
> 
> Please make the following updates to the "EDHOC Error Codes” registry
> <https://www.iana.org/assignments/edhoc/edhoc.xhtml> to match what is
> in the document.
> 
> The diff file can be seen here: https://www.rfc-
> editor.org/authors/rfc9528-diff.html
> 
> 1) Please update the following values of the Description column as
> follows, i.e., update “Reserved” to be “Reserved for success” and
> change to lowercase "e” in “Error”.
> 
> OLD:
> ERR_CODE        ERR_INFO Type   Description
> 0                                                       Reserved
> 1                       tstr                            Unspecified
> Error
> 
> NEW:
> ERR_CODE        ERR_INFO Type   Description
> 0                                                       Reserved for
> success
> 1                       tstr                            Unspecified
> error
> 
> 2) Please update the following range in the Registration Procedures to
> expand it from “-20 to 23” to “-24 to 23”.
> 
> Old:
> -20 to 23  Standards Action
> 
> New:
> -24 to 23  Standards Action
> 
> Best regards,
> RFC Editor/ap
> 
> > On Mar 14, 2024, at 5:52 PM, Paul Wouters <[e-mail]>
> > wrote:
> >
> >
> >> On Mar 15, 2024, at 05:50, Alanna Paloma <[e-mail]> wrote:
> >>
> >> Hi Göran and Paul*,
> >>
> >> *Paul - Please review and approve of the following updates.
> >>
> >> - Section 3.4: added text
> >> - Section 3.5: added text
> >> - Section 3.5.2: added key word
> >> - Section 3.6: updated text
> >> - Section 6.3.1: added key word
> >> - Section 11.2: added reference
> >>
> >> These changes can be seen in this diff file:
> >> https://www.rfc-editor.org/authors/rfc9528-ad-diff.html
> >
> > Approved.
> >
> > Paul
> >
> >>
> >> Göran - We have incorporated your suggestions into the files. Please
> >> let us know if any further updates are needed
> >>
> >> The files have been posted here (please refresh):
> >> https://www.rfc-editor.org/authors/rfc9528.xml
> >> https://www.rfc-editor.org/authors/rfc9528.txt
> >> https://www.rfc-editor.org/authors/rfc9528.html
> >> https://www.rfc-editor.org/authors/rfc9528.pdf
> >>
> >> The relevant diff files have been posted here:
> >> https://www.rfc-editor.org/authors/rfc9528-diff.html (comprehensive
> >> diff)
> >> https://www.rfc-editor.org/authors/rfc9528-auth48diff.html (AUTH48
> >> changes)
> >> https://www.rfc-editor.org/authors/rfc9528-lastdiff.html (htmlwdiff
> >> diff between last version and this)
> >> https://www.rfc-editor.org/authors/rfc9528-lastrfcdiff.html (rfcdiff
> >> between last version and this)
> >>
> >> Thank you,
> >> RFC Editor/ap
> >>
> >>> On Mar 14, 2024, at 12:04 PM, Göran Selander
> >>> <[e-mail]> wrote:
> >>>
> >>> Hi Alanna, and all,  When I was checking the updates I found some
> >>> two more nits and a proposed change. I apologize for late input.
> >>> 3.6
> >>> ORIGINAL
> >>> IEEE CCM* mode
> >>> OLD
> >>> IEEE Counter with CBC-MAC (CCM)*
> >>> NEW
> >>> IEEE AES-CCM* mode of operation which is an extension of the CCM
> >>> mode, defined in [IEEE Std 802.15.4‐2015, Annex B].
> >>> GS: New reference needed.
> >>>  9.1.
> >>> ORIGINAL
> >>> EDHOC also adds selection of connection identifiers
> >>> OLD
> >>> EDHOC also adds a selection of connection identifiers
> >>> NEW
> >>> EDHOC also adds the selection of connection identifiers
> >>> Acknowledgments
> >>> OLD
> >>> intermediate draft versions of this document. We are especially
> >>> indebted …
> >>> NEW
> >>> intermediate draft versions of this document.
> >>> We are especially indebted …
> >>> GS: Please insert a new paragraph.
> >>>  Thanks!
> >>> Göran
> >>> From: Alanna Paloma <[e-mail]>
> >>> Date: Thursday, 14 March 2024 at 18:13
> >>> To: Göran Selander <[e-mail]>, Paul Wouters
> >>> <paul.wouters=[e-mail]>
> >>> Cc: Mališa Vučinić <[e-mail]>, John Mattsson
> >>> <[e-mail]>, Francesca Palombini
> >>> <[e-mail]>, Sandy Ginoza
> >>> <[e-mail]>, RFC Editor <[e-mail]>, lake-
> >>> [e-mail] <[e-mail]>, [e-mail]<lake-
> >>> [e-mail]>, [e-mail] <auth48archive@rfc-
> >>> editor.org>
> >>> Subject: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23>
> >>> for your review
> >>> Hi Göran and Paul*,
> >>>
> >>> *Paul - As the AD, the review and approve of the following updates.
> >>>
> >>> - Section 3.4: added text
> >>> - Section 3.5: added text
> >>> - Section 3.5.2: added key word
> >>> - Section 6.3.1: added key word
> >>>
> >>> These changes can be seen in this diff file:
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528-ad-
> >>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915827805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xcPOEsEeUuIspxGrvm6FjANullsyhtWKkzsHAELGvFk%3D&reserved=0
> >>>
> >>> Göran - Thank you for your reply. The files have been updated per
> >>> your suggestion, and we have noted your approval on the AUTH48
> >>> status page:
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915837351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c%2B1sUMVJVViyLit05hZgiYxXqICFsOkGxkN70QVWYU0%3D&reserved=0
> >>>
> >>> The files have been posted here (please refresh):
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915843983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vNjwGD3yDseST1TDWgZMPIyulNevLmloPm3JT1kRhqU%3D&reserved=0
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915849128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=U8M2iHLtxMPoqzjxIB4oQ1OpKF0uOzYlNhbvQcZEO2Q%3D&reserved=0
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915853501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nZuIOxGmKxg7r8cnCqgRim8%2BGKVe9%2FpqCwHMzMl6J9I%3D&reserved=0
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915857792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=U4SWxkbhB5F45U80FZNz%2FNxHCLZKTnkMER4rhbvi9Fw%3D&reserved=0
> >>>
> >>> The relevant diff files have been posted here:
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528-
> >>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915862059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ev6Ycb5d1daHl%2BVVgDQKiFkNBwXe7C9ocM8m249Ru0E%3D&reserved=0
> >>> (comprehensive diff)
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528-
> >>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915866331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HFKUS5DZDI4qteTJDpsDkp3e1XapYDTfOxbB6cFyc08%3D&reserved=0
> >>> (AUTH48 changes)
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528-
> >>> lastdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915870674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=se%2BdDwJtiqcvJkGnyNy6shx9GTFDAayRQo%2F2U4L5b8E%3D&reserved=0
> >>> (htmlwdiff diff between last version and this)
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>> editor.org%2Fauthors%2Frfc9528-
> >>> lastrfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915874925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VNgT0y06dOnkFZGfoBDN8ePnPv1%2FRE6uHeSXjL%2FOZy8%3D&reserved=0
> >>> (rfcdiff between last version and this)
> >>>
> >>> Once we have received Paul’s approval, we will ask IANA to update
> >>> their registry accordingly. After the IANA updates are complete, we
> >>> will move forward with the publication process.
> >>>
> >>> Thank you,
> >>> RFC Editor/ap
> >>>
> >>>>> On Mar 13, 2024, at 2:12 PM, Göran Selander
> >>>>> <[e-mail]> wrote:
> >>>>
> >>>> Hi again Alanna, and all
> >>>> Sorry for the spam. I learnt a better formulation in the proposed
> >>>> update to Section 6.3.1,  which is a minor change to the text
> >>>> previously proposed:
> >>>> NEW2
> >>>> After receiving SUITES_R, the Initiator can determine which cipher
> >>>> suite to select (if any) for the next EDHOC run with the
> >>>> Responder. The Initiator SHOULD remember which selected cipher
> >>>> suite to use until the next message_1 has been sent; otherwise,
> >>>> the Initiator and Responder will run into an infinite loop where
> >>>> the Initiator selects its most preferred cipher suite and the
> >>>> Responder sends an error with supported cipher suites.
> >>>> After a completed EDHOC session, the Initiator MAY remember the
> >>>> selected cipher suite to use in future EDHOC sessions with a
> >>>> particularthis Responder. Note that if the Initiator or Responder
> >>>> is updated with new cipher suite policies, any cached information
> >>>> may be outdated.
> >>>> In other words, compared to the previous proposal the NEW2 text
> >>>> is:
> >>>> NEW
> >>>> a particular
> >>>> NEW2
> >>>> this
> >>>> Thanks
> >>>> Göran
> >>>> From: Göran Selander <[e-mail]>
> >>>> Date: Wednesday, 13 March 2024 at 21:19
> >>>> To: Alanna Paloma <[e-mail]>, Mališa Vučinić
> >>>> <[e-mail]>, Paul Wouters
> >>>> <paul.wouters=[e-mail]>, John Mattsson
> >>>> <[e-mail]>, Francesca Palombini
> >>>> <[e-mail]>
> >>>> Cc: Sandy Ginoza <[e-mail]>, RFC Editor <rfc-editor@rfc-
> >>>> editor.org>, [e-mail] <[e-mail]>, lake-
> >>>> [e-mail] <[e-mail]>, auth48archive@rfc-
> >>>> editor.org <[e-mail]>
> >>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23> for
> >>>> your review
> >>>> Hi Alanna, and all,
> >>>> Here are some additional comments.
> >>>> General
> >>>> "CCS [RFC8392]" (multiple occurences)
> >>>> GS: Note that while CWT and CWT Claims Set are defined in RFC
> >>>> 8392, the abbreviation CCS is not. This is the reason why the
> >>>> original text always spells out CCS when making the reference the
> >>>> RFC 8392: "CWT Claims Set (CCS) [RFC8392]".  This is just for your
> >>>> information, no action is required unless you think it is an
> >>>> issue.
> >>>>  Abstract
> >>>> OLD
> >>>> lightweight authenticated Diffie-Hellman (DH) key exchange
> >>>> NEW
> >>>> lightweight authenticated Diffie-Hellman key exchange
> >>>> GS: While the expansion of COSE, CoAP and CBOR makes sense in the
> >>>> abstract, the abbreviation of Diffie-Hellman as DH makes less
> >>>> sense to me. The abbreviation is not needed to understand the
> >>>> abstract, and a person reading the abbreviation DH in the body of
> >>>> the document (which only occurs in the combination "static DH")
> >>>> would probably not look in the abstract for the definition. I
> >>>> propose to move this definition of DH to Section 1:
> >>>> 1.
> >>>> OLD
> >>>> static Diffie-Hellman public keys
> >>>> NEW
> >>>> static Diffie-Hellman (DH) public keys
> >>>> 1.1  OLD
> >>>> The IETF has acknowledged this problem by standardizing a range of
> >>>> lightweight protocols and enablers designed for the IoT, including
> >>>> the CoAP [RFC7252], CBOR [RFC8949], and Static Context Header
> >>>> Compression (SCHC) [RFC8724].
> >>>> NEW
> >>>> The IETF has acknowledged this problem by standardizing a range of
> >>>> lightweight protocols and enablers designed for the IoT, including
> >>>> CoAP [RFC7252], CBOR [RFC8949], and Static Context Header
> >>>> Compression (SCHC) [RFC8724].
> >>>> 2
> >>>> OLD
> >>>> In order to create a "full-fledged" protocol, some additional
> >>>> protocol elements are needed. EDHOC adds:
> >>>> NEW
> >>>> In order to create a "full-fledged" protocol, some additional
> >>>> protocol elements are needed. This specification adds:
> >>>>   GS: The old formulation gives the impression that new
> >>>> specifications (e.g. new methods) would not be EDHOC.
> >>>> ORIGINAL
> >>>> * selection of connection identifiers
> >>>> OLD
> >>>> * a selection of connection identifiers
> >>>> GS: To me this reads as "a set of connection identifier", whereas
> >>>> the original text is highlighting the selection capability of the
> >>>> protocol. Please revert to the original formulation with "*
> >>>> selection", or use "* the selection", or other formulation that
> >>>> highlights that that the protocol includes a selection procedure.
> >>>>  OLD
> >>>> To simplify for implementors, the use of CBOR and COSE in EDHOC is
> >>>> summarized in Appendix C.
> >>>> NEW
> >>>> To simplify for implementors, the use of CBOR, CDDL and COSE in
> >>>> EDHOC is summarized in Appendix C.
> >>>> 3.2
> >>>> OLD
> >>>> EDHOC supports authentication with signature or
> >>>> NEW
> >>>> EDHOC currently supports authentication with signature or
> >>>> GS: Support for PSK based authentication is in the new charter.
> >>>> 3.4
> >>>> OLD
> >>>> There is no maximum message size specified by the protocol; for
> >>>> example, this is dependent on the size of the authentication
> >>>> credentials (if they are transported, see Section 3.5).
> >>>> NEW
> >>>> There is no maximum message size specified by the protocol; for
> >>>> example, this is dependent on the size of the authentication
> >>>> credentials (if they are transported, see Section 3.5). The
> >>>> encryption of very large content in message_2 when using certain
> >>>> hash algorithms is described in [Appendix G].
> >>>> 3.5
> >>>> OLD
> >>>> EDHOC supports various settings for how the other endpoint's
> >>>> authentication (public) key may be transported, identified, and
> >>>> trusted.
> >>>> NEW
> >>>> EDHOC supports various settings for how the other endpoint's
> >>>> public key for authentication may be transported, identified, and
> >>>> trusted. We shall use the term "authentication key" to mean key
> >>>> used for authentication in general, or specifically, the public
> >>>> key, when there is no risk for confusion.
> >>>> GS: This replaces and expands on the explanation removed in the
> >>>> following change:
> >>>> 3.5.1
> >>>> OLD
> >>>> The authentication key (i.e., the public key used for
> >>>> authentication) MUST be a signature key or a static Diffie-Hellman
> >>>> key.
> >>>> NEW
> >>>> The authentication key MUST be a signature key or a static Diffie-
> >>>> Hellman key.
> >>>>  OLD
> >>>> Note that for most signature algorithms, the signature is
> >>>> determined by the signature algorithm and the authentication key
> >>>> algorithm together.
> >>>> NEW
> >>>> Note that for most signature algorithms, the signature is
> >>>> determined jointly by the signature algorithm and the
> >>>> authentication key algorithm.
> >>>> GS: Proposed rephrasing
> >>>> OLD
> >>>> For X.509 certificates, the authentication key is represented by a
> >>>> SubjectPublicKeyInfo field. For CWT and CCS (see Section 3.5.2),
> >>>> the authentication key is represented by a 'cnf' claim [RFC8747]
> >>>> containing a COSE_Key [RFC9052]. In EDHOC, a raw public key (RPK)
> >>>> is an authentication key encoded as a COSE_Key wrapped in a CCS.
> >>>> NEW
> >>>> For X.509 certificates, the authentication key is represented by a
> >>>> SubjectPublicKeyInfo field, which also contains information about
> >>>> authentication key algorithm. For CWT and CCS (see Section 3.5.2),
> >>>> the authentication key is represented by a 'cnf' claim [RFC8747]
> >>>> containing a COSE_Key [RFC9052], which contains information about
> >>>> authentication key algorithm. In EDHOC, a raw public key (RPK) is
> >>>> an authentication key encoded as a COSE_Key wrapped in a CCS, an
> >>>> example is given in [Figure 4].
> >>>> GS: This gives the reader more examples on authentication key
> >>>> /algorithm/.
> >>>> 3.5.2
> >>>> OLD
> >>>> The Initiator and Responder SHOULD use an available authentication
> >>>> credential (transported in EDHOC or otherwise provisioned) without
> >>>> re-encoding. If for some reason re-encoding of an authentication
> >>>> credential passed by reference may occur, then a potential common
> >>>> encoding for CBOR-based credentials is deterministically encoded
> >>>> CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949].
> >>>> Authentication credentials passed by value are used as is without
> >>>> re-encoding.
> >>>> NEW
> >>>> The Initiator and Responder SHOULD use an available authentication
> >>>> credential without re-encoding, i.e. an authentication credential
> >>>> transported in EDHOC by value, or otherwise provisioned, SHOULD be
> >>>> used as is. If for some reason re-encoding of an authentication
> >>>> credential passed by reference may occur, then a potential common
> >>>> encoding for CBOR-based credentials is deterministically encoded
> >>>> CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949].
> >>>> GS: Merge first and last sentences of this excerpt since they talk
> >>>> about the same thing.
> >>>>   OLD
> >>>> Naked COSE_Keys are thus dressed as CCS when used in EDHOC in its
> >>>> simplest form by prefixing the COSE_Key with 0xA108A101 (a map
> >>>> with a 'cnf' claim).
> >>>> NEW
> >>>> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in its
> >>>> simplest form by prefixing the COSE_Key with 0xA108A101 (a map
> >>>> with a 'cnf' claim).
> >>>> GS: I added a comma to clarify that the end of the sentence is an
> >>>> example.
> >>>> 3.6
> >>>> OLD
> >>>> Just like in (D)TLS 1.3 [RFC8446] [RFC9147] and IKEv2 [RFC7296], a
> >>>> signature in COSE is determined by the signature algorithm and the
> >>>> authentication key algorithm together; see Section 3.5.1.
> >>>> NEW
> >>>> Just like in (D)TLS 1.3 [RFC8446] [RFC9147] and IKEv2 [RFC7296], a
> >>>> signature in COSE is determined jointly by the signature algorithm
> >>>> and the authentication key algorithm; see Section 3.5.1.
> >>>> GS: Proposed rephrasing.
> >>>>  OLD
> >>>> Cipher suites 0-3, based on AES-CCM, are intended for constrained
> >>>> IoT where a message overhead is a very important factor.
> >>>> NEW
> >>>> Cipher suites 0-3, based on AES-CCM, are intended for constrained
> >>>> IoT where message overhead is a very important factor.
> >>>> GS: "message overhead" refers to a property such as "delay",
> >>>> "latency", etc. where it doesn't make sense here to use indefinite
> >>>> article. Please revert to the original formulation without "a".
> >>>>   4.1.1.1
> >>>> OLD
> >>>> Example: Assuming the use of SHA-256, the extract phase of the Key
> >>>> Derivation Function (HKDF) produces PRK_2e as follows:
> >>>> NEW
> >>>> Example: Assuming the use of SHA-256, the extract phase of the key
> >>>> derivation function is HKDF-Extract, which produces PRK_2e as
> >>>> follows:
> >>>> GS: More details to the example.
> >>>> 5.2.1
> >>>> ORIGINAL
> >>>> C_I - variable-length connection identifier
> >>>> OLD
> >>>> C_I is the variable-length connection identifier
> >>>> NEW
> >>>> C_I is a variable-length connection identifier
> >>>> GS: "the" gives the impression that it is unique. Similarly:
> >>>> ORIGINAL
> >>>> EAD_1 - external authorization data
> >>>> OLD
> >>>> EAD_1 is the external authorization data
> >>>> NEW
> >>>> EAD_1 is external authorization data
> >>>> 5.2.2
> >>>> ORIGINAL
> >>>> if the Initiator previously received from the Responder an error
> >>>> message with error code 2 containing SUITES_R (see Section 6.3)
> >>>> indicating cipher suites supported by the Responder,
> >>>> OLD
> >>>> if the Initiator previously received from the Responder has an
> >>>> error message with error code 2 containing SUITES_R (see Section
> >>>> 6.3) indicating cipher suites supported by the Responder,
> >>>> GS: There is something wrong with this sentence, I can't parse it
> >>>> with the added "has". Did you intend to change the original into:
> >>>> "if the Initiator *has* previously received from the Responder an
> >>>> error message ..."? Either that, or revert to original, or other
> >>>> formulation where it is clear that this is a conditional statement
> >>>> about the Initiator having received an error message.
> >>>> 5.3.2
> >>>> ORIGINAL
> >>>> ID_CRED_R - identifier to facilitate the retrieval of CRED_R
> >>>> OLD
> >>>> ID_CRED_R is the identifier to facilitate the retrieval of CRED_R
> >>>> NEW
> >>>> ID_CRED_R is an identifier to facilitate the retrieval of CRED_R
> >>>> GS: "the" gives the impression that it is unique. Similarly:
> >>>> OLD
> >>>> CRED_R is the CBOR item containing
> >>>> NEW
> >>>> CRED_R is a CBOR item containing
> >>>> OLD
> >>>> EAD_2 is the external authorization data
> >>>> NEW
> >>>> OLD
> >>>> EAD_2 is external authorization data
> >>>>  5.4.2
> >>>> OLD
> >>>> ID_CRED_I is the identifier to facilitate the retrieval of CRED_I
> >>>> NEW
> >>>> ID_CRED_I is an identifier to facilitate the retrieval of CRED_I
> >>>> OLD
> >>>> CRED_I is the CBOR item containing
> >>>> NEW
> >>>> CRED_I is a CBOR item containing
> >>>> OLD
> >>>> EAD_3 is the external authorization data
> >>>> NEW
> >>>> OLD
> >>>> EAD_3 is external authorization data
> >>>> 5.5.2
> >>>> OLD
> >>>> EAD_4 is the external authorization data
> >>>> NEW
> >>>> OLD
> >>>> EAD_4 is external authorization data
> >>>> 6.
> >>>> OLD
> >>>> ERR_INFO is the error information
> >>>> NEW
> >>>> ERR_INFO is error information
> >>>> 6.3.1
> >>>> OLD
> >>>> After receiving SUITES_R, the Initiator can determine which cipher
> >>>> suite to select (if any) for the next EDHOC run with the
> >>>> Responder.
> >>>> The Initiator needs to remember which selected cipher suite to use
> >>>> until the next message_1 has been sent; otherwise, the Initiator
> >>>> and Responder will run into an infinite loop where the Initiator
> >>>> selects its most preferred cipher suite and the Responder sends an
> >>>> error with supported cipher suites. After a completed EDHOC
> >>>> session, the Initiator MAY remember the selected cipher suite to
> >>>> use in future EDHOC sessions. Note that if the Initiator or
> >>>> Responder is updated with new cipher suite policies, any cached
> >>>> information may be outdated.
> >>>> NEW
> >>>> After receiving SUITES_R, the Initiator can determine which cipher
> >>>> suite to select (if any) for the next EDHOC run with the
> >>>> Responder. The Initiator SHOULD remember which selected cipher
> >>>> suite to use until the next message_1 has been sent; otherwise,
> >>>> the Initiator and Responder will run into an infinite loop where
> >>>> the Initiator selects its most preferred cipher suite and the
> >>>> Responder sends an error with supported cipher suites.
> >>>> After a completed EDHOC session, the Initiator MAY remember the
> >>>> selected cipher suite to use in future EDHOC sessions with a
> >>>> particular Responder. Note that if the Initiator or Responder is
> >>>> updated with new cipher suite policies, any cached information may
> >>>> be outdated.
> >>>> GS: Propose to reverting to the SHOULD from the original text.
> >>>> Please note the change in paragraph break, emphasizing the
> >>>> different actions in the different message processing phases.
> >>>> 9.1
> >>>> ORIGINAL
> >>>> EDHOC also adds selection of connection identifiers and downgrade
> >>>> protected negotiation of cryptographic parameters
> >>>> OLD
> >>>> EDHOC also adds selection of connection identifiers and downgrades
> >>>> protected negotiation of cryptographic parameters
> >>>> NEW
> >>>> EDHOC also adds selection of connection identifiers and downgrade-
> >>>> protected negotiation of cryptographic parameters
> >>>> GS: This refers to protecting the negotiation against downgrade of
> >>>> cryptographic parameters.
> >>>> 9.5
> >>>> OLD
> >>>> Note that even if ead_value is encrypted outside of EDHOC, the
> >>>> ead_labels in EAD_1 is revealed to passive attackers and the
> >>>> ead_labels in EAD_2 is revealed to active attackers.
> >>>> NEW
> >>>> Note that even if ead_value is encrypted outside of EDHOC, the
> >>>> ead_labels in EAD_1 are revealed to passive attackers and the
> >>>> ead_labels in EAD_2 are revealed to active attackers.
> >>>> 10.5  OLD
> >>>> Table 11: Registration procedures for EDHOC EAD Labels
> >>>> NEW
> >>>> Table 11: Registration Procedures for EDHOC EAD Labels
> >>>>  10.11
> >>>> "Expert reviewers should take into consideration the following
> >>>> points:
> >>>> - - -
> >>>> "
> >>>> ORIGINAL
> >>>> Even for "Expert Review" specifications are recommended.
> >>>> OLD
> >>>> The fact that even "Expert Review" specifications are recommended.
> >>>> NEW
> >>>> It is recommended to have a specification even if the registration
> >>>> procedure is "Expert Review".
> >>>> GS: Proposed rephrasing.
> >>>> OLD
> >>>> When specifications are not provided for a request where Expert
> >>>> Review is the assignment policy, the description provided needs to
> >>>> have sufficient information to verify the code points above.
> >>>> NEW
> >>>> When specifications are not provided for a request where Expert
> >>>> Review is the assignment policy, the description provided needs to
> >>>> have sufficient information to verify the code points as above.
> >>>>   Appendix G
> >>>> ORIGINAL with SHA-256 as EDHOC hash algorithm
> >>>> OLD
> >>>> with SHA-256 as an EDHOC hash algorithm
> >>>> NEW
> >>>> with SHA-256 as the EDHOC hash algorithm
> >>>> GS: The EDHOC hash algorithm is determined by the cipher suite so
> >>>> it is fixed in this example.
> >>>>   Acknowledgements
> >>>> ORIGINAL
> >>>> We are especially indebted to the late Jim Schaad for his
> >>>> continuous reviewing and implementation of early versions of this
> >>>> and other drafts.
> >>>> OLD
> >>>> We are especially indebted to the late Jim Schaad for his
> >>>> continuous reviewing and implementation of early draft versions of
> >>>> this document.
> >>>> NEW
> >>>> We are especially indebted to the late Jim Schaad for his
> >>>> continuous review and implementation of draft versions of this
> >>>> document, as well as his work on other technologies such as COSE
> >>>> and OSCORE without which EDHOC would not have been.
> >>>> GS: As the original formulation indicates our gratitude extends
> >>>> beyond this document.
> >>>> With these changes, I approve publication.
> >>>> Thanks,
> >>>> Göran
> >>>> From: Alanna Paloma <[e-mail]>
> >>>> Date: Tuesday, 12 March 2024 at 17:23
> >>>> To: Göran Selander <[e-mail]>, Mališa Vučinić
> >>>> <[e-mail]>, Paul Wouters
> >>>> <paul.wouters=[e-mail]>, John Mattsson
> >>>> <[e-mail]>, Francesca Palombini
> >>>> <[e-mail]>
> >>>> Cc: Sandy Ginoza <[e-mail]>, RFC Editor <rfc-editor@rfc-
> >>>> editor.org>, [e-mail] <[e-mail]>, lake-
> >>>> [e-mail] <[e-mail]>, auth48archive@rfc-
> >>>> editor.org <[e-mail]>
> >>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23> for
> >>>> your review
> >>>> Authors and Paul*,
> >>>>
> >>>> Thank you for your replies. We have updated the text per Mališa’s
> >>>> suggestion and inserted the now assigned IANA values.
> >>>>
> >>>> The files have been posted here (please refresh):
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915879280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UX5yQ156vTwY2ZXcmmhjYJylIUv%2FVFWOpX1iBSXJZaE%3D&reserved=0
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915883962%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XKlCLbn5KO0gFOK4ulscZchJQp64lXql4l6kxHtqMl8%3D&reserved=0
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915889439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UxtA%2BX4BkxhuMJozdNBKFu6Zk15l2amS5jf0XlRvRL0%3D&reserved=0
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915894203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rnXY6%2F8aOslmmR0Y%2BEseLE55mR%2FeorKHQ6VtY%2B%2FR%2F6g%3D&reserved=0
> >>>>
> >>>> The relevant diff files have been posted here:
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528-
> >>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915898532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cueH%2BU43pWM0%2FwpO%2BdRO9zYkfNd4MqcJfBCWs9Oaqhg%3D&reserved=0
> >>>> (comprehensive diff)
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528-
> >>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915902829%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ev%2FbYAdLO4J%2FapfE2T8X6qhRYxa9wQtvvSWPsLTMmDo%3D&reserved=0
> >>>> (AUTH48 changes)
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528-
> >>>> lastdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915907199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k%2Bq3MRtlkm8UyYvHTmXPepx7ULfFTpGG6oEMrgBEXgI%3D&reserved=0
> >>>> (htmlwdiff diff between last version and this)
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauthors%2Frfc9528-
> >>>> lastrfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915912252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KB0aw8n341HE15HWhbElVd7nzdZ3FzlU7%2BMtFPcTaEQ%3D&reserved=0
> >>>> (rfcdiff between last version and this)
> >>>>
> >>>> *Paul’s approval has been noted on the AUTH48 status page:
> >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915916595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Nxsn9kkg1wmi8WrgzlOZasozJrgd31Zqgnh%2F7faGgyw%3D&reserved=0
> >>>>
> >>>> Once we have received approvals from Göran and Francesca, we will
> >>>> move this document forward in the publication process.
> >>>>
> >>>> Thank you,
> >>>> RFC Editor/ap
> >>>>
> >>>>> On Mar 12, 2024, at 7:21 AM, Göran Selander
> >>>>> <[e-mail]> wrote:
> >>>>>
> >>>>> Hi Mališa, and all,
> >>>>> The authors are fine with the text.
> >>>>> Thanks,
> >>>>> Göran
> >>>>> From: Mališa Vučinić <[e-mail]>
> >>>>> Date: Monday, 11 March 2024 at 22:26
> >>>>> To: Göran Selander <[e-mail]>
> >>>>> Cc: John Mattsson <[e-mail]>, Paul Wouters
> >>>>> <paul.wouters=[e-mail]>, Alanna Paloma
> >>>>> <[e-mail]>, Francesca Palombini
> >>>>> <[e-mail]>, Sandy Ginoza
> >>>>> <[e-mail]>, RFC Editor <[e-mail]>, lake-
> >>>>> [e-mail] <[e-mail]>, [e-mail]<lake-
> >>>>> [e-mail]>, [e-mail]
> >>>>> <[e-mail]>
> >>>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-
> >>>>> edhoc-23> for your review
> >>>>> Hi all,
> >>>>> It seems that we have consensus, including Paul, on the following
> >>>>> text, without the addition of the new references.
> >>>>> NEW:
> >>>>> Note that the security properties depend on the type of context
> >>>>> and the number of KeyUpdate iterations.
> >>>>> @Authors and Paul: please confirm whether this is OK by you.
> >>>>> Mališa
> >>>>> —————————
> >>>>> Mališa Vučinić
> >>>>> Research Scientist, Inria
> >>>>> Co-chair, IETF LAKE
> >>>>>
> >>>>>
> >>>>> On Mar 10, 2024, at 09:08, Göran Selander
> >>>>> <[e-mail]> wrote:
> >>>>>  Hi Paul and all,
> >>>>> I understand the issue how it is perceived that John adds these
> >>>>> references in AUTH48.
> >>>>> However, this was discussed in the latest LAKE WG interim meeting
> >>>>> on Feb 13, where John did propose to add  these pointers in the
> >>>>> security considerations.
> >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-
> >>>>> interim-2024-lake-01-
> >>>>> 202402131400%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915920870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BVnQXznbwpZ8BBr2n5rf6S4MmScKp1mqfOW5ba1gR70%3D&reserved=0
> >>>>> “JPM: Will mail TLS group, and MLS, and QUIC, and CoRE, once
> >>>>> published. It's in pre-print. No immediate action needed, small
> >>>>> seccons is way to go
> >>>>> SF: Might be interesting, before we do seccons, to know what
> >>>>> people think in the TLS/QUIC context.
> >>>>> JPM: Can just point to those in seccons, would be uncontroversial
> >>>>> addition.
> >>>>> SF: Maybe also text into MT's draft.”
> >>>>> My recollection is, and the “also” in the last quoted line
> >>>>> indicates, that Stephen in the end didn’t disagree with the
> >>>>> proposal (please speak up if I’m wrong). No other proposal on
> >>>>> this topic has been noted.
> >>>>> So it seems to me that the WG has agreed to this, or at least not
> >>>>> disagreed to add security considerations, which of course can be
> >>>>> done with or without references.
> >>>>> As John writes, this is a minor remark, the priority is to not
> >>>>> delay publication.
> >>>>> And in any case, since one of the papers is quite recent and not
> >>>>> yet reviewed, we should not draw any definitive conclusion based
> >>>>> on that. But to formulate a concern / caveat related to the use
> >>>>> of the key update mechanism seems prudent, given the inputs we
> >>>>> have today.
> >>>>> John’s proposed text:
> >>>>> Note that the security properties depends on the type of context
> >>>>> and the number of KeyUpdate iterations [1][2].
> >>>>> NEW1:
> >>>>> Recent results indicate that the security properties may depend
> >>>>> on the type of context and the number of KeyUpdate iterations
> >>>>> iterations.
> >>>>> However, this may be too inspecific to guide the reader. Making a
> >>>>> reference to a paper would have been the obvious thing to do in
> >>>>> this security consideration, had it not been for  the author of
> >>>>> the paper also being an author of the draft. I think NEW1 is
> >>>>> sufficiently vague, and in combination with that it has been
> >>>>> discussed at a WG meeting, to allow the inclusion of the
> >>>>> references:
> >>>>> NEW2:
> >>>>> Recent results indicate that the security properties may depend
> >>>>> on the type of context and the number of KeyUpdate iterations
> >>>>> iterations [1][2].
> >>>>> Göran
> >>>>> From: John Mattsson <[e-mail]>
> >>>>> Date: Saturday, 9 March 2024 at 17:48
> >>>>> To: Paul Wouters <paul.wouters=[e-mail]>, Alanna
> >>>>> Paloma <[e-mail]>, Göran Selander
> >>>>> <[e-mail]>
> >>>>> Cc: Francesca Palombini <[e-mail]>, Sandy
> >>>>> Ginoza <[e-mail]>, RFC Editor <rfc-editor@rfc-
> >>>>> editor.org>, [e-mail] <[e-mail]>, lake-
> >>>>> [e-mail] <[e-mail]>,
> >>>>> [e-mail]<[e-mail]>,
> >>>>> [e-mail] <[e-mail]>
> >>>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-
> >>>>> edhoc-23> for your review
> >>>>>> I do not approve of a single author adding two new references
> >>>>>> citing himself to the document in AUTH48, without a confirmation
> >>>>>> of >the WG.
> >>>>> That sounds reasonable. Göran or Francesca, can you suggest
> >>>>> something (as long as it does not delay publication). You are not
> >>>>> authors of the referenced papers. Göran, I got the feeling you
> >>>>> wanted more changes than I suggested.  I think it would be good
> >>>>> to give some information to the reader in RFC 9528. The first
> >>>>> reference is peer reviewed, it shows that the number of
> >>>>> iterations matters. The second is not peer reviewed yet and shows
> >>>>> that the type of context matters.
> >>>>> I don’t think the statement  “Note that the security properties
> >>>>> depends on the type of context and the number of KeyUpdate
> >>>>> iterations.” should be controversial. I avoided any detailed text
> >>>>> that could be controversial.
> >>>>>
> >>>>> One option could be to just skip the references. I really don’t
> >>>>> need citations. But there are no other references to cite as far
> >>>>> as I know. MLS and KUDOS use different types of context but does
> >>>>> not say why. KUDOS likely added the random context for other
> >>>>> reasons. MLS very likely added a counter for the reason to avoid
> >>>>> short repetitive cycles. That is a very standard approach in
> >>>>> cryptographic design.
> >>>>>
> >>>>> An earlier version of the EDHOC document had the excellent text:
> >>>>> “The EDHOC-KeyUpdate takes a nonce as input to guarantee that
> >>>>> there are no short cycles.  The Initiator and the Responder need
> >>>>> to agree on the nonce, which can e.g., be a counter or a random
> >>>>> number.”
> >>>>> My main priority is to publish the RFC. Companies that have
> >>>>> already deployed EDHOC is eager for that. KeyUpdate is not so
> >>>>> important, I don’t think anybody is planning on using it and the
> >>>>> WG considered to completely remove it. If needed just skip any
> >>>>> futher changes to the KeyUpdate section.
> >>>>> Cheers,
> >>>>> John
> >>>>> From: Paul Wouters <paul.wouters=[e-mail]>
> >>>>> Date: Saturday, 9 March 2024 at 16:18
> >>>>> To: Alanna Paloma <[e-mail]>
> >>>>> Cc: John Mattsson <[e-mail]>, Francesca
> >>>>> Palombini <[e-mail]>, Sandy Ginoza
> >>>>> <[e-mail]>, RFC Editor <[e-mail]>, Göran
> >>>>> Selander <[e-mail]>, [e-mail] <lake-
> >>>>> [e-mail]>, [e-mail] <[e-mail]>,
> >>>>> [e-mail]<[e-mail]>,
> >>>>> [e-mail] <[e-mail]>
> >>>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-
> >>>>> edhoc-23> for your review
> >>>>> Hi,
> >>>>>
> >>>>> I do not approve of a single author adding two new references
> >>>>> citing himself to the document in AUTH48, without a confirmation
> >>>>> of the WG.
> >>>>>
> >>>>> The other changes are fine.
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>> Sent using a virtual keyboard on a phone
> >>>>>
> >>>>>> On Mar 8, 2024, at 17:59, Alanna Paloma <[e-mail]>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi John and Paul*,
> >>>>>>
> >>>>>> *Paul - As the AD, please review and approve of the following
> >>>>>> updates:
> >>>>>>
> >>>>>> - Section 1.2: added text
> >>>>>> - Section 6.3.1: updated text
> >>>>>> - Appendix H: added text
> >>>>>>
> >>>>>> John - Thank you for your reply. We have updated the files per
> >>>>>> your request. Please see our notes below.
> >>>>>>
> >>>>>> Additionally, your approval on the AUTH48 status page. We assume
> >>>>>> assent to changes from your coauthors unless we hear otherwise.
> >>>>>>
> >>>>>>> OLD:
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     | ERR_CODE | ERR_INFO Type | Description
> >>>>>>> |
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     |        0 |               | Reserved
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        1 | tstr          | Unspecified error
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        2 | suites        | Wrong selected cipher suite
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        3 | true          | Unknown credential referenced
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |       23 |               | Reserved
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>> NEW:
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     | ERR_CODE | ERR_INFO Type | Description
> >>>>>>> |
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     |        0 |               | Reserved for success
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        1 | tstr          | Unspecified error
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        2 | suites        | Wrong selected cipher suite
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        3 | true          | Unknown credential referenced
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |       23 |               | Reserved
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>> (I think it is good to differentiate the 0 reserved from the 23
> >>>>>>> reserved)
> >>>>>>
> >>>>>> ) Please note that this is not how it appears in the IANA
> >>>>>> registry. Based on your reply, we have updated the document to
> >>>>>> "Reserved for success" and will send a separate mail to request
> >>>>>> that IANA update the registry
> >>>>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fedhoc%2Fedhoc.xhtml%23edhoc-
> >>>>>> error-
> >>>>>> codes&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915925133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=T8msrDujpbrdiIQZdFgUZpwC0iCF8AVZseJlJYTyBMU%3D&reserved=0)
> >>>>>> accordingly.
> >>>>>>
> >>>>>>> John: Unclear to me why only one of the rows has a reference to
> >>>>>>> 9528.
> >>>>>>> Feels like it should be none or all.
> >>>>>>>       +-------------+------------------------------+-----------
> >>>>>>> +
> >>>>>>>      | 2-22        | Unassigned                   |           |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>>      | 23          | Reserved                     | RFC 9528  |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>>      | 24-32767    | Unassigned                   |           |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>>      | 32768-65535 | Reserved for Private Use     |           |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>
> >>>>>> ) This table matches how it appears in the IANA registry
> >>>>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fedhoc%2Fedhoc.xhtml%23edhoc-
> >>>>>> exporter-
> >>>>>> labels&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915929275%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c5ZrK4%2Bbjare9f8V1HOLtpaVLStK1CfRmRA9NTyXiCA%3D&reserved=0)
> >>>>>> Typically, IANA registries do not list a reference for
> >>>>>> unassigned values.
> >>>>>>
> >>>>>>> OLD:
> >>>>>>> | 3     | Array: 30,     | AES-CCM-16-128-128,         | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | -16, 16, 1,    | SHA-256, 16, P-256, ES256,  |
> >>>>>>> |
> >>>>>>> |       | -7, 10, -16    | AES-CCM-16-64-128, SHA-256  |
> >>>>>>> |
> >>>>>>> +-------+----------------+-----------------------------
> >>>>>>> +-----------+
> >>>>>>> | 4     | Array: 24,     | ChaCha20/Poly1305, SHA-256, | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | -16, 16, 4,    | 16, X25519, EdDSA,          |
> >>>>>>> |
> >>>>>>> |       | -8, 24, -16    | ChaCha20/Poly1305, SHA-256  |
> >>>>>>> |
> >>>>>>> NEW:
> >>>>>>> | 3     | 30, -16, 16,   | AES-CCM-16-128-128,         | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | 1, -7, 10, -16 | SHA-256, 16, P-256, ES256,  |
> >>>>>>> |
> >>>>>>> |       |                | AES-CCM-16-64-128, SHA-256  |
> >>>>>>> |
> >>>>>>> +-------+----------------+-----------------------------
> >>>>>>> +-----------+
> >>>>>>> | 4     | 24, -16, 16,   | ChaCha20/Poly1305, SHA-256, | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | 4, -8, 24, -16 | 16, X25519, EdDSA,          |
> >>>>>>> |
> >>>>>>> |       |                | ChaCha20/Poly1305, SHA-256  |
> >>>>>>> |
> >>>>>>> (To align with the other rows)
> >>>>>>> -----------
> >>>>>>
> >>>>>> ) This has been udpated as requested (to remove "Array:"), which
> >>>>>> matches the IANA registry. Our mistake for not catching that
> >>>>>> earlier.
> >>>>>>
> >>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
> >>>>>>> respectively:
> >>>>>>>    -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R and
> >>>>>>>    -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R,
> >>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
> >>>>>>> respectively:
> >>>>>>>    -  ID_CRED_x = { 35 : uri }, for x = I or R, and
> >>>>>>>    -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
> >>>>>>> John: TDB3 and TDB4 still exist in Appendix C.3
> >>>>>>
> >>>>>> ) Once the values have been confirmed by the COSE chairs, we
> >>>>>> will insert them into the document.
> >>>>>>
> >>>>>>> OLD:
> >>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
> >>>>>>> binding of
> >>>>>>> the updated PRK_out to some event that triggered the key
> >>>>>>> update.  The
> >>>>>>> Initiator and Responder need to agree on the context, which
> >>>>>>> can,
> >>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
> >>>>>>> provide
> >>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
> >>>>>>> PRK_exporter and old application keys) must be deleted as soon
> >>>>>>> as
> >>>>>>> they are not needed.  When to delete the old keys and how to
> >>>>>>> verify
> >>>>>>> that they are not needed is up to the application.
> >>>>>>> NEW
> >>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
> >>>>>>> binding of
> >>>>>>> the updated PRK_out to some event that triggered the key
> >>>>>>> update.  The
> >>>>>>> Initiator and Responder need to agree on the context, which
> >>>>>>> can,
> >>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
> >>>>>>> provide
> >>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
> >>>>>>> PRK_exporter and old application keys) must be deleted as soon
> >>>>>>> as
> >>>>>>> they are not needed.  When to delete the old keys and how to
> >>>>>>> verify
> >>>>>>> that they are not needed is up to the application. Note that
> >>>>>>> the
> >>>>>>> security properties depends on the type of context and the
> >>>>>>> number
> >>>>>>> of KeyUpdate iterations [1][2].
> >>>>>>> [1]
> >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
> >>>>>>> 501d5122-313273af-454445555731-
> >>>>>>> dc22bfcd594b44db%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
> >>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2023%252F913&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915933841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BE4e6hzn94jtfMhBhNh0z1DcpNVWnph4sHvUrtoNUA4%3D&reserved=0
> >>>>>>> [2]
> >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
> >>>>>>> 501d5122-313273af-454445555731-
> >>>>>>> 238b27209f91355d%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
> >>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2024%252F220&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915940176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fsIhY4Mv7eV9uYjxpDO6ItfrM6LuwLxt4dhPEgfTuIk%3D&reserved=0
> >>>>>>
> >>>>>> ) As this document does not use numbered references, we have
> >>>>>> added the following reference entries to the Informative
> >>>>>> References sections.
> >>>>>>
> >>>>>> [PreußMattsson23]
> >>>>>>                  Preuß Mattsson, J., "Hidden Stream Ciphers and
> >>>>>> TMTO
> >>>>>>                  Attacks on TLS 1.3, DTLS 1.3, QUIC, and
> >>>>>> Signal”,
> >>>>>>                 DOI 10.1007/978-981-99-7563-1_12, December 2023,
> >>>>>>                 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
> >>>>>> 501d5122-313273af-454445555731-
> >>>>>> dc22bfcd594b44db%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
> >>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2023%252F913&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915944717%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fRHQ3gKoAzG%2BMtj%2BrEeiNoAOnnjrAwE5yaNPfO%2B94DE%3D&reserved=0>.
> >>>>>>
> >>>>>> [PreußMattsson24]
> >>>>>>                  Preuß Mattsson, J., "Security of Symmetric
> >>>>>> Ratchets and
> >>>>>>                  Key Chains - Implications for Protocols like
> >>>>>> TLS 1.3,
> >>>>>>                  Signal, and PQ3", February 2024,
> >>>>>>                  <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
> >>>>>> 501d5122-313273af-454445555731-
> >>>>>> 238b27209f91355d%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
> >>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2024%252F220&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915949360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FaH06DsKIgtR4KDJt5c9aFNgQJVbiVFgzk%2F5Rbggo9I%3D&reserved=0>.
> >>>>>> ...
> >>>>>> The files have been posted here (please refresh):
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915953752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZVFubgX5o9sjfyACfi9y9mDp7bhdaTu9wP3fbhjCY%2Bk%3D&reserved=0
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915958099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=D6o3SspNLav2JCHgVwQh9X8Q5S%2BlWOlTmU%2BJh54XHqM%3D&reserved=0
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915962386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1vMDqbMeJZoNbUqJ8xfFM8nCnNI2uklM%2BL67MWSUwsk%3D&reserved=0
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915966592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=I5i8O1V74ogYeg%2F0fvZpf3Sft5%2F3PP%2FJn%2FyDksn6qz4%3D&reserved=0
> >>>>>>
> >>>>>> The relevant diff files have been posted here:
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915970818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=F90HfllY5OfaykHupAdFIVDfsrTXSwC2U9bceHvz1oI%3D&reserved=0
> >>>>>> (comprehensive diff)
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915975078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=63E0VIfVV1ZIDfOxzkOOdI1VPmXEkTaMQPKr4HmM2iQ%3D&reserved=0
> >>>>>> (AUTH48 changes)
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>> lastdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915979294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8U%2BqAuKPhzz9uKaktor0jc1qd7DO6KHmqfClIRZOFWQ%3D&reserved=0
> >>>>>> (htmlwdiff diff between last version and this)
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>> lastrfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915983513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=utML07TG4g6QstzcSOerRA9zjHzw%2BHmW5Fl7gUKVC7g%3D&reserved=0
> >>>>>> (rfcdiff between last version and this)
> >>>>>>
> >>>>>> For the AUTH48 status of this document, please see:
> >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915987708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2HlFleo7fBcPUmDgx8X9AVTr%2BdZLE6WiLRrKo2vidHQ%3D&reserved=0
> >>>>>>
> >>>>>> Thank you,
> >>>>>> RFC Editor/ap
> >>>>>>
> >>>>>>> On Mar 8, 2024, at 6:10 AM, John Mattsson
> >>>>>>> <john.mattsson=[e-mail]> wrote:
> >>>>>>>
> >>>>>>> Dear RFC Editor,I have reviewed the whole document in detail. I
> >>>>>>> have the suggestions below:
> >>>>>>> I approve publication.
> >>>>>>> -----------
> >>>>>>> OLD: ERR_CODE is sn error code encoded as an integer.
> >>>>>>> NEW: ERR_CODE is an error code encoded as an integer.
> >>>>>>> -----------
> >>>>>>> OLD: Based on the cryptographic algorithms requirements
> >>>>>>> NEW: Based on the cryptographic algorithm requirements
> >>>>>>> -----------
> >>>>>>> OLD:Any dependencies on security applications with previously
> >>>>>>> registered EAD items needs to be documented
> >>>>>>> NEW:Any dependencies on security applications with previously
> >>>>>>> registered EAD items need to be documented
> >>>>>>> -----------
> >>>>>>> OLD: high performance algorithms
> >>>>>>> NEW: high-performance algorithms
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>>  Examples of EDHOC message sizes are shown in Table 1, which
> >>>>>>> use
> >>>>>>> different kinds of authentication keys and COSE header
> >>>>>>> parameters for
> >>>>>>> identification, i.e., static Diffie-Hellman keys or signature
> >>>>>>> keys,
> >>>>>>> either in CWT/CCS [RFC8392] identified by a key identifier
> >>>>>>> using
> >>>>>>> 'kid' [RFC9052] or in X.509 certificates identified by a hash
> >>>>>>> value
> >>>>>>> using 'x5t' [RFC9360]. As a comparison, in the case of RPK
> >>>>>>> NEW:
> >>>>>>> Examples of EDHOC message sizes are shown in Table 1, which use
> >>>>>>> different kinds of authentication keys and COSE header
> >>>>>>> parameters for
> >>>>>>> identification, i.e., static Diffie-Hellman keys or signature
> >>>>>>> keys,
> >>>>>>> either in CWT/CCS [RFC8392] identified by a key identifier
> >>>>>>> using
> >>>>>>> 'kid' [RFC9052] or in X.509 certificates identified by a hash
> >>>>>>> value
> >>>>>>> using 'x5t' [RFC9360]. EDHOC always uses ephemeral-ephemeral
> >>>>>>> key exchange.
> >>>>>>> As a comparison, in the case of RPK
> >>>>>>> (clarification to avoid misunderstanding such as the secdir
> >>>>>>> review)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> SIGn-and-MAc (SIGMA) is a family of theoretical protocols with
> >>>>>>> a
> >>>>>>> large number of variants [SIGMA].
> >>>>>>> NEW:
> >>>>>>> SIGn-and-MAc (SIGMA) is a family of theoretical protocols with
> >>>>>>> a
> >>>>>>> number of variants [SIGMA].
> >>>>>>> (large number is maybe overstating it)
> >>>>>>> -----------
> >>>>>>> OLD: passed by the value are used as is without re-encoding.
> >>>>>>> NEW: passed by value are used as is without re-encoding.
> >>>>>>> ("by value" is the standard term used in other parts of the
> >>>>>>> document.)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> EDHOC since the authentication credentials are integrity
> >>>>>>> protected.
> >>>>>>> NEW:
> >>>>>>> EDHOC since the authentication credentials are integrity
> >>>>>>> protected
> >>>>>>> by the Signature_or_MAC field.
> >>>>>>> (Clarification. The paragraph also talks about that the
> >>>>>>> credential is transported to the endpoints)
> >>>>>>> -----------
> >>>>>>> OLD: (when with public key cryptography)
> >>>>>>> NEW: (when used with public key cryptography)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     | ERR_CODE | ERR_INFO Type | Description
> >>>>>>> |
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     |        0 |               | Reserved
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        1 | tstr          | Unspecified error
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        2 | suites        | Wrong selected cipher suite
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        3 | true          | Unknown credential referenced
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |       23 |               | Reserved
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>> NEW:
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     | ERR_CODE | ERR_INFO Type | Description
> >>>>>>> |
> >>>>>>>     +==========+===============+===============================+
> >>>>>>>     |        0 |               | Reserved for success
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        1 | tstr          | Unspecified error
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        2 | suites        | Wrong selected cipher suite
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |        3 | true          | Unknown credential referenced
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>>     |       23 |               | Reserved
> >>>>>>> |
> >>>>>>>     +----------+---------------+-------------------------------
> >>>>>>> +
> >>>>>>> (I think it is good to differentiate the 0 reserved from the 23
> >>>>>>> reserved)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> If the Initiator intends to contact the Responder in the
> >>>>>>> future, the
> >>>>>>> Initiator SHOULD remember which selected cipher suite to use
> >>>>>>> until
> >>>>>>> the next message_1 has been sent; otherwise, the Initiator and
> >>>>>>> Responder will likely run into an infinite loop where the
> >>>>>>> Initiator
> >>>>>>> selects its most preferred cipher suite and the Responder sends
> >>>>>>> an
> >>>>>>> error with supported cipher suites.  After a completed EDHOC
> >>>>>>> session,
> >>>>>>> the Initiator MAY remember the selected cipher suite to use in
> >>>>>>> future
> >>>>>>> EDHOC sessions.
> >>>>>>> NEW:
> >>>>>>> The Initiator need to remember which selected cipher suite to
> >>>>>>> use until
> >>>>>>> the next message_1 has been sent; otherwise, the Initiator and
> >>>>>>> Responder will run into an infinite loop where the Initiator
> >>>>>>> selects its most preferred cipher suite and the Responder sends
> >>>>>>> an
> >>>>>>> error with supported cipher suites.  After a completed EDHOC
> >>>>>>> session,
> >>>>>>> the Initiator MAY remember the selected cipher suite to use in
> >>>>>>> future
> >>>>>>> EDHOC sessions.
> >>>>>>> (I think this paragraph is quite confusing and needs to be
> >>>>>>> improved.)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> The same authentication credential MAY be used for both the
> >>>>>>> Initiator
> >>>>>>> and Responder roles.  As noted in Section 12 of [RFC9052], the
> >>>>>>> use of
> >>>>>>> a single key for multiple algorithms is strongly discouraged
> >>>>>>> unless
> >>>>>>> proven secure by a dedicated cryptographic analysis.  In
> >>>>>>> particular,
> >>>>>>> this recommendation applies to using the same private key for
> >>>>>>> static
> >>>>>>> Diffie-Hellman authentication and digital signature
> >>>>>>> authentication.
> >>>>>>> A preliminary conjecture is that a minor change to EDHOC may be
> >>>>>>> sufficient to fit the analysis of a secure shared signature and
> >>>>>>> ECDH
> >>>>>>> key usage in [Degabriele11] and [Thormarker21].
> >>>>>>> NEW:
> >>>>>>> The same authentication credential MAY be used for both the
> >>>>>>> Initiator
> >>>>>>> and Responder roles.  As noted in Section 12 of [RFC9052], the
> >>>>>>> use of
> >>>>>>> a single key for multiple algorithms is strongly discouraged
> >>>>>>> unless
> >>>>>>> proven secure by a dedicated cryptographic analysis.  In
> >>>>>>> particular,
> >>>>>>> this recommendation applies to using the same private key for
> >>>>>>> static
> >>>>>>> Diffie-Hellman authentication and digital signature
> >>>>>>> authentication.
> >>>>>>> A preliminary conjecture is that a minor change to EDHOC may be
> >>>>>>> sufficient to fit the analysis of a secure shared signature and
> >>>>>>> ECDH
> >>>>>>> key usage in [Degabriele11] and [Thormarker21]. Note that
> >>>>>>> Section
> >>>>>>> 5.6.3.2 of [SP-800-56A] allows a key agreement key pair to be
> >>>>>>> used
> >>>>>>> with a signature algorithm in certificate requests.
> >>>>>>> (I think the added piece of information is very important for
> >>>>>>> users
> >>>>>>> of the document. Otherwise they might get the idea that this
> >>>>>>> cannot be
> >>>>>>> done. The new sentence just notes that NIST allows this.)
> >>>>>>> -----------
> >>>>>>> OLD: [DET-ECC-SIGS]
> >>>>>>> OLD: [HEDGED-ECC-SIGS]
> >>>>>>> (The CFRG draft has changes name. Also DET-ECC-SIGS gives the
> >>>>>>> wrong idea.)
> >>>>>>> -----------
> >>>>>>> John: Unclear to me why only one of the rows has a reference to
> >>>>>>> 9528.
> >>>>>>> Feels like it should be none or all.
> >>>>>>>       +-------------+------------------------------+-----------
> >>>>>>> +
> >>>>>>>      | 2-22        | Unassigned                   |           |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>>      | 23          | Reserved                     | RFC 9528  |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>>      | 24-32767    | Unassigned                   |           |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>>      | 32768-65535 | Reserved for Private Use     |           |
> >>>>>>>      +-------------+------------------------------+-----------+
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> | 3     | Array: 30,     | AES-CCM-16-128-128,         | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | -16, 16, 1,    | SHA-256, 16, P-256, ES256,  |
> >>>>>>> |
> >>>>>>> |       | -7, 10, -16    | AES-CCM-16-64-128, SHA-256  |
> >>>>>>> |
> >>>>>>> +-------+----------------+-----------------------------
> >>>>>>> +-----------+
> >>>>>>> | 4     | Array: 24,     | ChaCha20/Poly1305, SHA-256, | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | -16, 16, 4,    | 16, X25519, EdDSA,          |
> >>>>>>> |
> >>>>>>> |       | -8, 24, -16    | ChaCha20/Poly1305, SHA-256  |
> >>>>>>> |
> >>>>>>> NEW:
> >>>>>>> | 3     | 30, -16, 16,   | AES-CCM-16-128-128,         | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | 1, -7, 10, -16 | SHA-256, 16, P-256, ES256,  |
> >>>>>>> |
> >>>>>>> |       |                | AES-CCM-16-64-128, SHA-256  |
> >>>>>>> |
> >>>>>>> +-------+----------------+-----------------------------
> >>>>>>> +-----------+
> >>>>>>> | 4     | 24, -16, 16,   | ChaCha20/Poly1305, SHA-256, | RFC
> >>>>>>> 9528  |
> >>>>>>> |       | 4, -8, 24, -16 | 16, X25519, EdDSA,          |
> >>>>>>> |
> >>>>>>> |       |                | ChaCha20/Poly1305, SHA-256  |
> >>>>>>> |
> >>>>>>> (To align with the other rows)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> [SP-800-108]
> >>>>>>>            Chen, L., "Recommendation for Key Derivation Using
> >>>>>>>            Pseudorandom Functions", NIST Special Publication
> >>>>>>> 800-108
> >>>>>>>            Revision 1, DOI 10.6028/NIST.SP.800-108r1, August
> >>>>>>> 2022,
> >>>>>>>            <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.6028%2FNIST.SP.800-
> >>>>>>> 108r1&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915991941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1%2Fk6%2FnEC4KoCyUUmX3fWwYDps1gRNm3zhUAwssWiibw%3D&reserved=0>.
> >>>>>>> NEW:
> >>>>>>> [SP-800-108]
> >>>>>>>            Chen, L., "Recommendation for Key Derivation Using
> >>>>>>>            Pseudorandom Functions", NIST Special Publication
> >>>>>>> 800-108
> >>>>>>>            Revision 1, DOI 10.6028/NIST.SP.800-108r1-upd1,
> >>>>>>> August 2022,
> >>>>>>>            <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.6028%2FNIST.SP.800-
> >>>>>>> 108r1-
> >>>>>>> upd1&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915996135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k06%2F3D0DWNBAG2qLhHRyGGlOhSqS2UJKFMo%2FCHuSMg8%3D&reserved=0>.
> >>>>>>> (NIST has done a very minor update to the SP)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> A full validation according to Section 5.6.2.3.3 of
> >>>>>>> [SP-800-56A] can be achieved by also checking that 0 ≤ x < p
> >>>>>>> and that
> >>>>>>> y^2 ≡ x^3 + a ⋅ x + b (mod p).
> >>>>>>> NEW:
> >>>>>>> A full validation according to Section 5.6.2.3.3 of
> >>>>>>> [SP-800-56A] is done by also checking that 0 ≤ x < p and that
> >>>>>>> y^2 ≡ x^3 + a ⋅ x + b (mod p).
> >>>>>>> (Comment from Scott in TLS WG that the original text makes it
> >>>>>>> unclear
> >>>>>>> if validation needs to be done)
> >>>>>>> -----------
> >>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
> >>>>>>> respectively:
> >>>>>>>    -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R and
> >>>>>>>    -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R,
> >>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
> >>>>>>> respectively:
> >>>>>>>    -  ID_CRED_x = { 35 : uri }, for x = I or R, and
> >>>>>>>    -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
> >>>>>>> John: TDB3 and TDB4 still exist in Appendix C.3
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> When EDHOC_KeyUpdate is called, a new PRK_out is calculated as
> >>>>>>> a
> >>>>>>> "hash" of the old PRK_out using the EDHOC_Expand function as
> >>>>>>> illustrated by the following pseudocode.  The change of PRK_out
> >>>>>>> causes a change to PRK_exporter, which enables the derivation
> >>>>>>> of new
> >>>>>>> application keys superseding the old ones, using
> >>>>>>> EDHOC_Exporter; see
> >>>>>>> Section 4.2.1.
> >>>>>>> NEW:
> >>>>>>> When EDHOC_KeyUpdate is called, a new PRK_out is calculated as
> >>>>>>> the output of the EDHOC_Expand function with the old PRK_out as
> >>>>>>> input. The change of PRK_out causes a change to PRK_exporter,
> >>>>>>> which enables the derivation of new application keys
> >>>>>>> superseding
> >>>>>>> the old ones, using EDHOC_Exporter; see Section 4.2.1. The
> >>>>>>> process is illustrated by the following pseudocode.
> >>>>>>> (I think it is good to remove "hash" as that that has the worst
> >>>>>>> security properties. Also I think it is good to have the
> >>>>>>> pseudocode
> >>>>>>> sentence last in the paragraph.)
> >>>>>>> -----------
> >>>>>>> OLD:
> >>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
> >>>>>>> binding of
> >>>>>>> the updated PRK_out to some event that triggered the key
> >>>>>>> update.  The
> >>>>>>> Initiator and Responder need to agree on the context, which
> >>>>>>> can,
> >>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
> >>>>>>> provide
> >>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
> >>>>>>> PRK_exporter and old application keys) must be deleted as soon
> >>>>>>> as
> >>>>>>> they are not needed.  When to delete the old keys and how to
> >>>>>>> verify
> >>>>>>> that they are not needed is up to the application.
> >>>>>>> NEW
> >>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
> >>>>>>> binding of
> >>>>>>> the updated PRK_out to some event that triggered the key
> >>>>>>> update.  The
> >>>>>>> Initiator and Responder need to agree on the context, which
> >>>>>>> can,
> >>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
> >>>>>>> provide
> >>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
> >>>>>>> PRK_exporter and old application keys) must be deleted as soon
> >>>>>>> as
> >>>>>>> they are not needed.  When to delete the old keys and how to
> >>>>>>> verify
> >>>>>>> that they are not needed is up to the application. Note that
> >>>>>>> the
> >>>>>>> security properties depends on the type of context and the
> >>>>>>> number
> >>>>>>> of KeyUpdate iterations [1][2].
> >>>>>>> [1]
> >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
> >>>>>>> 501d5122-313273af-454445555731-
> >>>>>>> dc22bfcd594b44db%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
> >>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2023%252F913&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916000226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f4%2B6ktMoCXI8AewtMalTEIK%2FU%2BcpLTnXDrz0QWwzb7E%3D&reserved=0
> >>>>>>> [2]
> >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
> >>>>>>> 501d5122-313273af-454445555731-
> >>>>>>> 238b27209f91355d%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
> >>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2024%252F220&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916004531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8B%2FMpkqSVLpt453glAzQ753XiYWCGdLXVr9Pp8C%2Bf5c%3D&reserved=0
> >>>>>>> -----------
> >>>>>>> Cheers,
> >>>>>>> John Preuß Mattsson
> >>>>>>> From: Francesca Palombini
> >>>>>>> <francesca.palombini=[e-mail]>
> >>>>>>> Date: Friday, 8 March 2024 at 08:43
> >>>>>>> To: Sandy Ginoza <[e-mail]>
> >>>>>>> Cc: John Mattsson <[e-mail]>, RFC Editor
> >>>>>>> <[e-mail]>, Göran Selander
> >>>>>>> <[e-mail]>, [e-mail] <lake-
> >>>>>>> [e-mail]>, [e-mail] <[e-mail]>,
> >>>>>>> [e-mail]
> >>>>>>> <[e-mail]>,[e-mail]
> >>>>>>> <[e-mail]>, auth48archive@rfc-
> >>>>>>> editor.org<[e-mail]>
> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23>
> >>>>>>> for your review
> >>>>>>> Hi Sandy!
> >>>>>>> (with my author’s hat on only, of course) I understand, thank
> >>>>>>> you for the heads up. I am reviewing RFC 7120 and realize we
> >>>>>>> missed one step, we requested the AD and IANA for early
> >>>>>>> allocation, but missed the COSE chairs. My co-authors are also
> >>>>>>> authors of the COSE draft, and they believe it to be stable
> >>>>>>> enough, so does the IANA expert who has reviewed the
> >>>>>>> registration. But of course we welcome feedback from the
> >>>>>>> chairs.
> >>>>>>> Thank you for keeping us updated,
> >>>>>>> Francesca
> >>>>>>> From: Sandy Ginoza <[e-mail]>
> >>>>>>> Date: Thursday, 7 March 2024 at 23:37
> >>>>>>> To: Francesca Palombini <[e-mail]>
> >>>>>>> Cc: John Mattsson
> >>>>>>> <john.mattsson=[e-mail]>, RFC Editor <rfc-
> >>>>>>> [e-mail]>, Göran Selander
> >>>>>>> <[e-mail]>, [e-mail] <lake-
> >>>>>>> [e-mail]>, [e-mail] <[e-mail]>,
> >>>>>>> [e-mail]<[e-mail]>,
> >>>>>>> [e-mail] <[e-mail]>,
> >>>>>>> [e-mail] <[e-mail]>
> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23>
> >>>>>>> for your review
> >>>>>>> Hi Francesca, Authors,
> >>>>>>>
> >>>>>>> We generally try to avoid including TBDs and IANA assignments
> >>>>>>> for documents that have yet to be published because things may
> >>>>>>> change before the defining document is approved for
> >>>>>>> publication.  In this case, the state of draft-ietf-cose-cbor-
> >>>>>>> encoded-cert appears to be I-D exists, which seems to imply
> >>>>>>> it’s not yet stable.
> >>>>>>>
> >>>>>>> Note that we just received mail from IANA asking us to
> >>>>>>> temporarily delay updating these values because there is an
> >>>>>>> issue they are discussing with the WG Chairs.  Note that we
> >>>>>>> have reverted the values to TBDs per IANA’s request.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Sandy
> >>>>>>>
> >>>>>>>>> On Mar 7, 2024, at 12:16 PM, Alanna Paloma <[e-mail]>
> >>>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Francesca,
> >>>>>>>>
> >>>>>>>> Thank you for the update. We have updated the files with the
> >>>>>>>> new values.
> >>>>>>>>
> >>>>>>>> The files have been posted here (please refresh):
> >>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916008891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=aQGcqH7HmlabFMb8mzFsIGNGr184Hn9pab2DmBl8mGQ%3D&reserved=0
> >>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916013210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hnTO%2F%2FxCXxea6gNtzOAGG7TBjPqK%2FpBvUwd41noy75E%3D&reserved=0
> >>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916017397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=w1zaZ5GrzJ08%2F%2BclyF22yaoWYcmzCaYATTPRlB4UEbQ%3D&reserved=0
> >>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916021573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xRyM%2BxW6y1cE1OSkN%2FO252ncsccH6lsQ3Ae3w5E0waY%3D&reserved=0
> >>>>>>>>
> >>>>>>>> The relevant diff files have been posted here:
> >>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916025743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mnwZ%2B9l%2BSnEf%2FKjRQj3uirSxBVxIdxcGE9VBggTGdVY%3D&reserved=0
> >>>>>>>> (comprehensive diff)
> >>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916029927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B7Y1W%2FEQtjLthNOUmhRZEc2bw5bxTZ%2FFWR6IpMn5GXk%3D&reserved=0
> >>>>>>>> (AUTH48 changes)
> >>>>>>>>
> >>>>>>>> Thank you,
> >>>>>>>> RFC Editor/ap
> >>>>>>>>
> >>>>>>>>> On Mar 7, 2024, at 11:50 AM, Francesca Palombini
> >>>>>>>>> <[e-mail]> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi Alanna,
> >>>>>>>>> The values were just assigned today, thanks to Paul and IANA,
> >>>>>>>>> so we don’t need to have TBDs anymore but we can replace them
> >>>>>>>>> with the actual values. We can make the following change:
> >>>>>>>>> OLD:
> >>>>>>>>> Different header parameters to identify X.509 or C509
> >>>>>>>>> certificates by
> >>>>>>>>> reference are defined in [RFC9360] and
> >>>>>>>>> [I-D.ietf-cose-cbor-encoded-cert]:
> >>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>   -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
> >>>>>>>>>   -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;
> >>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>   -  ID_CRED_x = { 35 : uri }, for x = I or R,
> >>>>>>>>>   -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
> >>>>>>>>> NEW:
> >>>>>>>>> Different header parameters to identify X.509 or C509
> >>>>>>>>> certificates by
> >>>>>>>>> reference are defined in [RFC9360] and
> >>>>>>>>> [I-D.ietf-cose-cbor-encoded-cert]:
> >>>>>>>>>
> >>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { 22 : COSE_CertHash }, for x = I or R;
> >>>>>>>>>
> >>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { 35 : uri }, for x = I or R,
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { 23 : uri }, for x = I or R.
> >>>>>>>>> Thanks,
> >>>>>>>>> Francesca
> >>>>>>>>> From: Alanna Paloma <[e-mail]>
> >>>>>>>>> Date: Thursday, 7 March 2024 at 20:27
> >>>>>>>>> To: John Mattsson
> >>>>>>>>> <john.mattsson=[e-mail]>
> >>>>>>>>> Cc: [e-mail] <[e-mail]>,
> >>>>>>>>> Göran Selander <[e-mail]>, Francesca
> >>>>>>>>> Palombini <[e-mail]>, lake-
> >>>>>>>>> [e-mail] <[e-mail]>, [e-mail] <lake-
> >>>>>>>>> [e-mail]>, [e-mail]
> >>>>>>>>> <[e-mail]>,
> >>>>>>>>> [e-mail]<[e-mail]>,
> >>>>>>>>> [e-mail] <[e-mail]>
> >>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-
> >>>>>>>>> 23> for your review
> >>>>>>>>> Hi John,
> >>>>>>>>>
> >>>>>>>>> Thank you for your reply.  The files have been updated. We
> >>>>>>>>> have one follow-up question.
> >>>>>>>>>
> >>>>>>>>> RFCs are typically not published if they contain unassigned
> >>>>>>>>> values. So, to avoid the use of unassigned values (TBD3 and
> >>>>>>>>> TBD4), may those lines in the examples in Appendix C.3 be
> >>>>>>>>> removed? Or, can they be replaced with different examples
> >>>>>>>>> that use existing values?
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> Different header parameters to identify X.509 or C509
> >>>>>>>>> certificates by
> >>>>>>>>> reference are defined in [RFC9360] and
> >>>>>>>>> [I-D.ietf-cose-cbor-encoded-cert]:
> >>>>>>>>>
> >>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;
> >>>>>>>>>
> >>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { 35 : uri }, for x = I or R,
> >>>>>>>>>
> >>>>>>>>> -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
> >>>>>>>>>
> >>>>>>>>> Perhaps:
> >>>>>>>>> Different header parameters to identify X.509 or C509
> >>>>>>>>> certificates by
> >>>>>>>>> reference are defined in [RFC9360] and [C509-CERTS]:
> >>>>>>>>>
> >>>>>>>>> * by a hash value with the 'x5t' or 'c5t' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>
> >>>>>>>>> - ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
> >>>>>>>>>
> >>>>>>>>> * or by a URI with the 'x5u' or 'c5u' parameters,
> >>>>>>>>> respectively:
> >>>>>>>>>
> >>>>>>>>> - ID_CRED_x = { 35 : uri }, for x = I or R.
> >>>>>>>>>
> >>>>>>>>> ...
> >>>>>>>>> The files have been posted here (please refresh):
> >>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916034226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4LnLNTtpzqqFBIBpa7ZoVPRjwmVaDD4Nz2ugW0pw5Zg%3D&reserved=0
> >>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916038447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=S9RSVo%2FAFbFCX02eF88vPtTaYUTLSOatUdlI3xMSXvQ%3D&reserved=0
> >>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916042604%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tffX3NOhyzfn7hYzdyaK%2Fy%2FJHUoeO90BUmhT5u74%2BgY%3D&reserved=0
> >>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916046710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IT3bbQ2TvedAbq7cCr%2FEO4aljEC%2FtrrwdqSecD3pxuQ%3D&reserved=0
> >>>>>>>>>
> >>>>>>>>> The relevant diff files have been posted here:
> >>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916050874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NsYJz7seopPmghmqMsdKb%2FNwQtGzs8O89xfblQJQULU%3D&reserved=0
> >>>>>>>>> (comprehensive diff)
> >>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916055002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Hs8hMRTG%2BbJNNTb%2FfdiKJ%2BJdrtn0eWkuDdv69yTx148%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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916059250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c%2FmEgyyBE7%2BEiHv3oF0%2B026WPUabLc57Z6SJnh4nkQc%3D&reserved=0
> >>>>>>>>>
> >>>>>>>>> Thank you,
> >>>>>>>>> RFC Editor/ap
> >>>>>>>>>
> >>>>>>>>>> On Mar 5, 2024, at 5:50 AM, John Mattsson
> >>>>>>>>>> <john.mattsson=[e-mail]> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Dear RFC Editor,
> >>>>>>>>>> See answers to the questions inline.
> >>>>>>>>>> Cheers,
> >>>>>>>>>> John Preuß Mattsson
> >>>>>>>>>> From: [e-mail] <[e-mail]>
> >>>>>>>>>> Date: Friday, 1 March 2024 at 03:02
> >>>>>>>>>> To: Göran Selander <[e-mail]>, John
> >>>>>>>>>> Mattsson <[e-mail]>, Francesca Palombini
> >>>>>>>>>> <[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 9528 <draft-ietf-lake-edhoc-
> >>>>>>>>>> 23> 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
> >>>>>>>>>> onhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fsearch&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916063470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zRICB9uq5TqAXxYfSVmnwwSYWdDOmZdZenm0NlupoZg%3D&reserved=0.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> AKE, LAKE, COSE, OSCORE, lightweight authenticated key
> >>>>>>>>>> exchange, constrained node networks, IoT security
> >>>>>>>>>>
> >>>>>>>>>> 2) <!--[rfced] FYI, each instance where SVG was used to
> >>>>>>>>>> create a table,
> >>>>>>>>>> we have changed to use the table element. For example, see
> >>>>>>>>>> the
> >>>>>>>>>> current Table 1, Table 2, etc. The remaining SVG is used for
> >>>>>>>>>> diagrams,
> >>>>>>>>>> as intended. Please review that the tables appear correctly.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> Table 2 is not correct :
> >>>>>>>>>> OLD: | 1 | Static DH Key      | Signature Key      |
> >>>>>>>>>> NEW: | 1 | Signature Key      | Static DH Key      |
> >>>>>>>>>> Table 7 should have the following row to be consistant with
> >>>>>>>>>> the other tables.
> >>>>>>>>>> | -24 to -21 | Private Use. |
> >>>>>>>>>>
> >>>>>>>>>> 3) <!--[rfced] The SVG figures in Sections 2, 3.1, and 6.3.2
> >>>>>>>>>> and
> >>>>>>>>>> Appendices A.2.1, A.2.2, I.1, and I.2 have width and height
> >>>>>>>>>> specified,
> >>>>>>>>>> which will make the artwork not scale. Please consider
> >>>>>>>>>> whether
> >>>>>>>>>> scaling should be enabled. Scaling will allow the figure to
> >>>>>>>>>> be
> >>>>>>>>>> resized when it is viewed on a mobile device; however, there
> >>>>>>>>>> may be aesthetic trade-offs (e.g., image may appear too
> >>>>>>>>>> large
> >>>>>>>>>> on a desktop screen or different figures may scale
> >>>>>>>>>> differently
> >>>>>>>>>> based on their relative sizes). Please review the HTML and
> >>>>>>>>>> PDF
> >>>>>>>>>> outputs and let us know how to proceed.
> >>>>>>>>>>
> >>>>>>>>>> For comparison (to see how they look without the height and
> >>>>>>>>>> width
> >>>>>>>>>> attributes), please see
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Ftest9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916067659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=d2e%2BDMZiG73rYIPX7%2Fnb%2Fmv9d9l%2FtSCM7LvGr3yHEMg%3D&reserved=0
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Ftest9529.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916072011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4xfbPZFcWELbChAM5bYHyJQXTzqcugsUoM5FRlja9EU%3D&reserved=0
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> John: OK
> >>>>>>>>>>
> >>>>>>>>>> 4) <!-- [rfced] Please review whether the note below should
> >>>>>>>>>> be in
> >>>>>>>>>> the <aside> element. It is defined as "a container for
> >>>>>>>>>> content
> >>>>>>>>>> that is semantically less important or tangential to the
> >>>>>>>>>> content
> >>>>>>>>>> that surrounds it"
> >>>>>>>>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Fen%2Frfcxml-
> >>>>>>>>>> vocabulary%23aside&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916076312%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5Hf4Vh8lZpBQjuhMEUa%2BCADTxMqHGhXbT1qAQhkd8i4%3D&reserved=0).
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> Implementation Note: When implementing the byte string
> >>>>>>>>>> identifier
> >>>>>>>>>> representation, it can in some programming languages help to
> >>>>>>>>>> define a
> >>>>>>>>>> new type, or other data structure, which (in its user facing
> >>>>>>>>>> API)
> >>>>>>>>>> behaves like a byte string, but when serializing to CBOR
> >>>>>>>>>> produces a
> >>>>>>>>>> CBOR byte string or a CBOR integer depending on its value.
> >>>>>>>>>>        -->
> >>>>>>>>>>
> >>>>>>>>>> John: Fine to put in <aside>
> >>>>>>>>>>
> >>>>>>>>>> 5) <!--[rfced] We see the following author-inserted comment
> >>>>>>>>>> in the XML
> >>>>>>>>>> file for this document. We are unsure if this has been
> >>>>>>>>>> resolved.
> >>>>>>>>>> Please review and let us know if it can be deleted or if it
> >>>>>>>>>> needs to
> >>>>>>>>>> be addressed.
> >>>>>>>>>>
> >>>>>>>>>> <!- A diagram of the EDHOC key schedule can be found in
> >>>>>>>>>> Figure 2 of
> >>>>>>>>>> {{Vucinic22}}. TBD: Rewrite the diagram ->
> >>>>>>>>>>
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> John: Delete the comment.
> >>>>>>>>>>
> >>>>>>>>>> 6) <!--[rfced] Per usage elsewhere in the document, should
> >>>>>>>>>> "message 3" and
> >>>>>>>>>> "message 2" be updated to "message_3" and "message_2",
> >>>>>>>>>> respectively?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> For example, PRK_3e2m is involved in the encryption of
> >>>>>>>>>> message 3 and in calculating the MAC of message 2.
> >>>>>>>>>>   -->
> >>>>>>>>>>
> >>>>>>>>>> John: The Original text is correct and should not be
> >>>>>>>>>> changed.
> >>>>>>>>>>
> >>>>>>>>>> 7) <!--[rfced] We note that RFC 9053 does not contain a
> >>>>>>>>>> Section 4.4. We
> >>>>>>>>>> have updated this to Section 4.4 of RFC 9052 (which is
> >>>>>>>>>> "Signing and
> >>>>>>>>>> Verification Process"). Please review.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>>   If the
> >>>>>>>>>>   Responder authenticates with a signature key (method
> >>>>>>>>>> equals 0 or
> >>>>>>>>>>   2), then Signature_or_MAC_2 is the 'signature' field of a
> >>>>>>>>>>   COSE_Sign1 object, computed as specified in Section 4.4 of
> >>>>>>>>>>   [RFC9053] using the signature algorithm of the selected
> >>>>>>>>>> cipher
> >>>>>>>>>>   suite, the private authentication key of the Responder,
> >>>>>>>>>> and the
> >>>>>>>>>>   following parameters as input (see Appendix C.3 for an
> >>>>>>>>>> overview of
> >>>>>>>>>>   COSE and Appendix C.1 for notation):
> >>>>>>>>>>      -->
> >>>>>>>>>>
> >>>>>>>>>> John: Thanks. Your change to RFC 9052 is correct.
> >>>>>>>>>>
> >>>>>>>>>> 8) <!--[rfced] We are having difficulty understanding "in
> >>>>>>>>>> this section
> >>>>>>>>>> exemplified with CoAP" in the following sentence. May we
> >>>>>>>>>> update the
> >>>>>>>>>> text as suggested below?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> EDHOC by default assumes that message duplication is handled
> >>>>>>>>>> by the
> >>>>>>>>>> transport, in this section exemplified with CoAP, see
> >>>>>>>>>> Appendix A.2.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> By default, EDHOC assumes that message duplication is
> >>>>>>>>>> handled by the
> >>>>>>>>>> transport (which is exemplified by CoAP in this section);
> >>>>>>>>>> see
> >>>>>>>>>> Appendix A.2.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> John: Yes, please update the text.
> >>>>>>>>>>
> >>>>>>>>>> 9) <!--[rfced] To improve clarity, may we rephrase this
> >>>>>>>>>> sentence as follows?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> By including the authentication credentials in the
> >>>>>>>>>> transcript hash, EDHOC protects against Duplicate Signature
> >>>>>>>>>> Key
> >>>>>>>>>> Selection (DSKS)-like identity mis-binding attack that the
> >>>>>>>>>> MAC-then-
> >>>>>>>>>> Sign variant of SIGMA-I is otherwise vulnerable to.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> By including the authentication credentials in the
> >>>>>>>>>> transcript hash, EDHOC protects against an identity
> >>>>>>>>>> misbinding
> >>>>>>>>>> attack like the Duplicate Signature Key Selection (DSKS)
> >>>>>>>>>> that the
> >>>>>>>>>> MAC-then-Sign variant of SIGMA-I is otherwise vulnerable to.
> >>>>>>>>>>    -->
> >>>>>>>>>>
> >>>>>>>>>> John: Yes, please rephrase the text.
> >>>>>>>>>>
> >>>>>>>>>> 10) <!--[rfced] Regarding usage of "IND-CCA":
> >>>>>>>>>> a) How should the expansion be updated? Specifically,
> >>>>>>>>>> "indistinguishability under chosen ciphertext" or
> >>>>>>>>>> "indistinguishability under adaptive chosen ciphertext
> >>>>>>>>>> attack"
> >>>>>>>>>> (as it appears in RFCs 9172 and 9180) or otherwise?
> >>>>>>>>>>
> >>>>>>>>>> John: indistinguishability under adaptive chosen ciphertext
> >>>>>>>>>> attack (IND-CCA2)
> >>>>>>>>>>
> >>>>>>>>>> b) Should it be "IND-CCA2"? (We see zero instances of "IND-
> >>>>>>>>>> CCA"
> >>>>>>>>>> in RFCs.) Please review how it should be used in the second
> >>>>>>>>>> sentence.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> HKDF-Expand is not often used as a stream cipher
> >>>>>>>>>> as it is slow on long messages, and most applications
> >>>>>>>>>> require both
> >>>>>>>>>> confidentiality with indistinguishability under chosen
> >>>>>>>>>> ciphertext
> >>>>>>>>>> (IND-CCA) as well as integrity protection.  For the
> >>>>>>>>>> encryption of
> >>>>>>>>>> message_2, any speed difference is negligible, IND-CCA does
> >>>>>>>>>> not
> >>>>>>>>>> increase security, ...
> >>>>>>>>>>
> >>>>>>>>>> Perhaps (if "IND-CCA2" is accurate):
> >>>>>>>>>> HKDF-Expand is not often used as a stream cipher
> >>>>>>>>>> as it is slow on long messages, and most applications
> >>>>>>>>>> require both
> >>>>>>>>>> confidentiality with indistinguishability under adaptive
> >>>>>>>>>> chosen
> >>>>>>>>>> ciphertext attack (IND-CCA2) as well as integrity
> >>>>>>>>>> protection. For the
> >>>>>>>>>> encryption of message_2, any speed difference is negligible,
> >>>>>>>>>> IND-CCA2
> >>>>>>>>>> does not increase security, ...
> >>>>>>>>>> -->    John: We are fine with changing to IND-CCA2.
> >>>>>>>>>>
> >>>>>>>>>> 11) <!-- [rfced] Tables 5, 6, 7, 8, 9, and 11 do not have
> >>>>>>>>>> titles. Please
> >>>>>>>>>> review, and provide titles for the untitled tables if
> >>>>>>>>>> desired. -->
> >>>>>>>>>>
> >>>>>>>>>> John: Here are suggested labels:
> >>>>>>>>>> Table 5: Registration Procedures for EDHOC Exporter Labels
> >>>>>>>>>> Table 6: EDHOC Cipher Suites
> >>>>>>>>>> Table 7: Registration Procedures for EDHOC Cipher Suites
> >>>>>>>>>> Table 8: Registration Procedures for EDHOC Method Types
> >>>>>>>>>> Table 9: Registration Procedures for EDHOC Error Codes
> >>>>>>>>>> Table 10: EDHOC EAD Labels
> >>>>>>>>>> Table 11: Registration procedures for EDHOC EAD Labels
> >>>>>>>>>>
> >>>>>>>>>> 12) <!--[rfced] We note that draft-selander-lake-authz-03
> >>>>>>>>>> has been replaced
> >>>>>>>>>> by draft-ietf-lake-authz. Should this reference be updated?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> [I-D.selander-lake-authz]
> >>>>>>>>>>           Selander, G., Mattsson, J. P., Vučinić, M.,
> >>>>>>>>>> Richardson,
> >>>>>>>>>>           M., and A. Schellenbaum, "Lightweight
> >>>>>>>>>> Authorization using
> >>>>>>>>>>           Ephemeral Diffie-Hellman Over COSE", Work in
> >>>>>>>>>> Progress,
> >>>>>>>>>>           Internet-Draft, draft-selander-lake-authz-03, 7
> >>>>>>>>>> July 2023,
> >>>>>>>>>>           <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-
> >>>>>>>>>> selander-
> >>>>>>>>>> &data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916080385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nAOfMj94UnB2ZVRA8oCDUzzZxaF%2Fta%2FCwnfKywi7HF8%3D&reserved=0
> >>>>>>>>>>           lake-authz-03>.
> >>>>>>>>>>            -->
> >>>>>>>>>>
> >>>>>>>>>> John: Yes, please update to draft-ietf-lake-authz.
> >>>>>>>>>>
> >>>>>>>>>> 13) <!--[rfced] Section 4.3 of RFC 9052 does not mention
> >>>>>>>>>> "COSE_Sign1".
> >>>>>>>>>> We have updated the citation as follows. Please let us know
> >>>>>>>>>> of any
> >>>>>>>>>> objections.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> *  Signatures in message_2 of method 0 and 2, and in
> >>>>>>>>>> message_3 of
> >>>>>>>>>>   method 0 and 1, consist of a subset of the single signer
> >>>>>>>>>> data
> >>>>>>>>>>   object COSE_Sign1, which is described in Sections 4.2-4.4
> >>>>>>>>>> of
> >>>>>>>>>>   [RFC9052].
> >>>>>>>>>>
> >>>>>>>>>> Current:
> >>>>>>>>>> *  Signatures in message_2 of method 0 and 2, and in
> >>>>>>>>>> message_3 of
> >>>>>>>>>>   method 0 and 1, consist of a subset of the single signer
> >>>>>>>>>> data
> >>>>>>>>>>   object COSE_Sign1, which is described in Sections 4.2 and
> >>>>>>>>>> 4.4 of
> >>>>>>>>>>     [RFC9052].
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> John: That is good.
> >>>>>>>>>>
> >>>>>>>>>> 14) <!--[rfced] In Appendix C.3, what should replace TBD3
> >>>>>>>>>> and TBD4?
> >>>>>>>>>> Those placeholders were not used in the IANA Considerations.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>>   -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;
> >>>>>>>>>> [...]
> >>>>>>>>>>   -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> John: Hi, TBD3 and TBD4 will be registered by draft-ietf-
> >>>>>>>>>> cose-cbor-encoded-cert in the future. We suggest the
> >>>>>>>>>> following change. We do not want to wait until C509-CERTS is
> >>>>>>>>>> published. This is just an example.
> >>>>>>>>>> OLD:
> >>>>>>>>>> When ID_CRED_x does not contain the actual credential, it
> >>>>>>>>>> may be very short, e.g., if the endpoints have agreed to use
> >>>>>>>>>> a key identifier parameter 'kid':
> >>>>>>>>>> NEW:
> >>>>>>>>>> TBD3 and TBD4 are to be assigned by [C509-CERTS].
> >>>>>>>>>> When ID_CRED_x does not contain the actual credential, it
> >>>>>>>>>> may be very short, e.g., if the endpoints have agreed to use
> >>>>>>>>>> a key identifier parameter 'kid':
> >>>>>>>>>> Otherwise the other option (we don't want) is to wait for
> >>>>>>>>>> C509-CERTS to be done - I expect that RFC Editor will tell
> >>>>>>>>>> us as much if we ask them how to handle.
> >>>>>>>>>>
> >>>>>>>>>> 15) <!--[rfced] Figures 12 and 13 do not have titles, unlike
> >>>>>>>>>> Figures 1-11.
> >>>>>>>>>> Please review, and provide titles for those two figures if
> >>>>>>>>>> desired.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> Here are suggested labels:
> >>>>>>>>>>
> >>>>>>>>>> Figure 12: Initiator State Machine
> >>>>>>>>>> Figure 13: Responder State Machine
> >>>>>>>>>>
> >>>>>>>>>> 16) <!--[rfced] Acronyms
> >>>>>>>>>>
> >>>>>>>>>> a) 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.
> >>>>>>>>>>
> >>>>>>>>>> IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH)
> >>>>>>>>>> Authentication and Key Agreement (AKA)
> >>>>>>>>>> CBC-MAC (CCM)
> >>>>>>>>>> Extensible Authentication Protocol Tunneled Transport Layer
> >>>>>>>>>> Security (EAP-TTLS)
> >>>>>>>>>> Elliptic Curve Diffie-Hellman (ECDH)
> >>>>>>>>>> Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
> >>>>>>>>>> Elliptic Curve Digital Signature Algorithm (ECDSA)
> >>>>>>>>>> Edwards-curve Digital Signature Algorithm (EdDSA)
> >>>>>>>>>> Hashed Message Authentication Code (HMAC)
> >>>>>>>>>> Internet Key Exchange Protocol Version 2 (IKEv2)
> >>>>>>>>>> JSON Object Signing and Encryption (JOSE)
> >>>>>>>>>> Key Derivation Function (KDF)
> >>>>>>>>>> Lightweight Authenticated Key Exchange (LAKE)
> >>>>>>>>>> Online Certificate Status Protocol (OSCP)
> >>>>>>>>>> Octet Key Pair (OKP)
> >>>>>>>>>> Pseudorandom Function (PRF)
> >>>>>>>>>> Standards for Efficient Cryptography Group (SECG)
> >>>>>>>>>>
> >>>>>>>>>> John: CCM should be “Counter with CBC-MAC (CCM)”, see RFC
> >>>>>>>>>> 3610.
> >>>>>>>>>>
> >>>>>>>>>> b) FYI, we have updated the expansion of AEAD from
> >>>>>>>>>> "authenticated
> >>>>>>>>>> encryption with additional data" to "Authenticated
> >>>>>>>>>> Encryption with
> >>>>>>>>>> Associated Data". Please let us know if this is not correct.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> John: That is fine.
> >>>>>>>>>>
> >>>>>>>>>> 17) <!-- [rfced] Please review the "Inclusive Language"
> >>>>>>>>>> portion of the online
> >>>>>>>>>> Style Guide
> >>>>>>>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916084529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1RAfjYOKYHppTcYfOHhWKrQ1maEo4hr0OMh2b36%2FfTY%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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Ffaq%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916089229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZhogC9AlzxjJu%2BDdfVDSef%2BkRt%2BVdiLf9R0ZxVC6WdQ%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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-
> >>>>>>>>>> info%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916095475%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=78VrWIgPNwLXm6mvTMubL0rQkFyKiutRk47TL93LsoQ%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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-
> >>>>>>>>>> vocabulary&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916099818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=T%2FIRGzCLSoItipMEQ8rkq9DmZuNvonXtVj6YRcVE3aM%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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-
> >>>>>>>>>> announce%2Fyb6lpIGh-
> >>>>>>>>>> 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916103959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sX41Xd7exnQANKdi%2BG6SeKRYt72mngahplDdPteulYI%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> *  The archive itself:
> >>>>>>>>>>    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916108201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PqGit0fo2LE7KOm8ZK9r3REK5mqAs91RqjdmH%2FnXVNM%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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916112063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lQq8mnS0nAab%2BpNg1sw5YzuZUK4OmzuPzKFdzH7F5oE%3D&reserved=0
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916116319%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GG%2Fe6nXKd7KuxdknHKkoecoecoPiBAYrITJgPzmdxHE%3D&reserved=0
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916120511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ibAN7KI%2BrOgpzcT2omQDiqKIXrS%2BTNz92IemDQP8Rog%3D&reserved=0
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916124781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TTMxgiB13BBzzDilfYzEX1ad6MBenQliAtLhAQ8X%2FPc%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> Diff file of the text:
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916129006%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pMMhMP7vPK8MrCl6eAK8HCyzsd0x1SNl1Ki%2BSJmma24%3D&reserved=0
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>>>>>> rfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916133329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2dTFJ%2BQbWI7qzbrwq6c80jieqS9xNABIiHzNCL2LD9g%3D&reserved=0
> >>>>>>>>>> (side by side)
> >>>>>>>>>>
> >>>>>>>>>> Diff of the XML:
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
> >>>>>>>>>> xmldiff1.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916137793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AYyglRyVJ%2BUnk7rIqYnxpCnWncz8STlsIBgymZ54x00%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Tracking progress
> >>>>>>>>>> -----------------
> >>>>>>>>>>
> >>>>>>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
> >>>>>>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916142260%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FzIFZ65CYuuwZTbiikGotR8mdAB9CxjL2GxHlk9haNI%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> Please let us know if you have any questions.
> >>>>>>>>>>
> >>>>>>>>>> Thank you for your cooperation,
> >>>>>>>>>>
> >>>>>>>>>> RFC Editor
> >>>>>>>>>>
> >>>>>>>>>> --------------------------------------
> >>>>>>>>>> RFC9528 (draft-ietf-lake-edhoc-23)
> >>>>>>>>>>
> >>>>>>>>>> Title            : Ephemeral Diffie-Hellman Over COSE
> >>>>>>>>>> (EDHOC)
> >>>>>>>>>> Author(s)        : G. Selander, J. Mattsson, F. Palombini
> >>>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>
> >