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

[Francesca Palombini <[e-mail]>]

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 <[e-mail]>, Göran Selander <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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://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)
>
> 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]>, [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
>> 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://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)
>>
>> 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://www.rfc-editor.org/auth48/rfc9528
>>
>> 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://www.rfc-editor.org/search. -->
>>>
>>> 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://www.rfc-editor.org/authors/test9528.html
>>> https://www.rfc-editor.org/authors/test9529.pdf
>>> -->
>>>
>>> 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://authors.ietf.org/en/rfcxml-vocabulary#aside).
>>>
>>> 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://datatracker.ietf.org/doc/html/draft-selander-
>>>              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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>> 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://www.rfc-editor.org/faq/).
>>>
>>> You and you coauthors are responsible for engaging other parties
>>> (e.g., Contributors or Working Group) as necessary before providing
>>> your approval.
>>>
>>> Planning your review
>>> ---------------------
>>>
>>> Please review the following aspects of your document:
>>>
>>> *  RFC Editor questions
>>>
>>>  Please review and resolve any questions raised by the RFC Editor
>>>  that have been included in the XML file as comments marked as
>>>  follows:
>>>
>>>  <!-- [rfced] ... -->
>>>
>>>  These questions will also be sent in a subsequent email.
>>>
>>> *  Changes submitted by coauthors
>>>
>>>  Please ensure that you review any changes submitted by your
>>>  coauthors.  We assume that if you do not speak up that you
>>>  agree to changes submitted by your coauthors.
>>>
>>> *  Content
>>>
>>>  Please review the full content of the document, as this cannot
>>>  change once the RFC is published.  Please pay particular attention to:
>>>  - IANA considerations updates (if applicable)
>>>  - contact information
>>>  - references
>>>
>>> *  Copyright notices and legends
>>>
>>>  Please review the copyright notice and legends as defined in
>>>  RFC 5378 and the Trust Legal Provisions
>>>  (TLP – https://trustee.ietf.org/license-info/).
>>>
>>> *  Semantic markup
>>>
>>>  Please review the markup in the XML file to ensure that elements of
>>>  content are correctly tagged.  For example, ensure that <sourcecode>
>>>  and <artwork> are set correctly.  See details at
>>>  <https://authors.ietf.org/rfcxml-vocabulary>.
>>>
>>> *  Formatted output
>>>
>>>  Please review the PDF, HTML, and TXT files to ensure that the
>>>  formatted output, as generated from the markup in the XML file, is
>>>  reasonable.  Please note that the TXT will have formatting
>>>  limitations compared to the PDF and HTML.
>>>
>>>
>>> Submitting changes
>>> ------------------
>>>
>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>>> the parties CCed on this message need to see your changes. The parties
>>> include:
>>>
>>>  *  your coauthors
>>>
>>>  *  [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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>
>>>    *  The archive itself:
>>>       https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>
>>>    *  Note: If only absolutely necessary, you may temporarily opt out
>>>       of the archiving of messages (e.g., to discuss a sensitive matter).
>>>       If needed, please add a note at the top of the message that you
>>>       have dropped the address. When the discussion is concluded,
>>>       [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://www.rfc-editor.org/authors/rfc9528.xml
>>>  https://www.rfc-editor.org/authors/rfc9528.html
>>>  https://www.rfc-editor.org/authors/rfc9528.pdf
>>>  https://www.rfc-editor.org/authors/rfc9528.txt
>>>
>>> Diff file of the text:
>>>  https://www.rfc-editor.org/authors/rfc9528-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9528-rfcdiff.html (side by side)
>>>
>>> Diff of the XML:
>>>  https://www.rfc-editor.org/authors/rfc9528-xmldiff1.html
>>>
>>>
>>> Tracking progress
>>> -----------------
>>>
>>> The details of the AUTH48 status of your document are here:
>>>  https://www.rfc-editor.org/auth48/rfc9528
>>>
>>> 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.
>
>