Change:
Hellman key.  The authentication key algorithm needs to be compatible with the method and the cipher suite.  The authentication key algorithm needs to be compatible with the EDHOC key exchange <del> algorithm when static Diffie-Hellman authentication is used and </del> <ins> algorithm when static Diffie-Hellman authentication is used, and </ins> compatible with the EDHOC signature algorithm when signature authentication is used.

Discussion:
This PR addresses and as well as parts of and . I also thought is was good to point out that AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with the IEEE CCM* mode.I also corrected the sentence "wrapped in a bstr" that Carsten pointed out during the interim.
Looks ready to merge
Duplicated text in 3.5.2. and 3.6: "The authentication key algorithm needs to be compatible with the EDHOC key exchange algorithm when static Diffie-Hellman authentication is used, and compatible with the EDHOC signature algorithm when signature authentication is used."
Is it relevant to have post-quantum cipher suites see URL
EDHOC already supports PQC signatures in the form of LMS. Any PQC signatures added to COSE will also be supported by EDHOC. For Key Exchange it is a bit more complex. Supporting KEMs will likely require some changes. The conslusion in the requirement document was that: "PAKE, post-quantum and "hybrid" (simultaneously more than one) key exchange is out of scope, but may be supported in a later version."
We also looked into if EDHOC with ECC should be moved to KEMs to be able to (more or less) automatically support PQC Kems, but the resulting protocol would have been more heavy as some properties of ECC could not be used in a strict KEM design. I think both PAKEs and KEMs would require new methods. Each PAKE might require its own method while all KEMs could likely be supported together. Unclear if 3x PQX KEM is better than 1 PQC KEM and 2 PQC Signatures, that requires some analysis.
Maybe we looked a bit to much on the Static DH mode when KEM was discussed last. Mehtod 0 will automatically work with PQC KEMs. GX is the public key and GY is an key encapsulation / ciphertext. We should likely describe that in the text. Good that you brought this up again NAME This would not be a technical change at all for method 0. The other methods would not work for general KEMs.

Although I'm not convinced all aspects of "PQ" can be solved in EDHOC timeframe, I still think it makes sense to put this in the document already.
My current plan would be to point out that the Key Exchange in method 0 is already following the KEM interface and can be replaced by any KEM including PQC KEMs. Might also be good to point out that method works with any signature algorithm including the PQC signature algorithm LMS that COSE has already specified.
NAME that for raising the issue earlier in NAME and NAME please review the new PR Method 0 is well-prepared for PQC algorithms, you can just replace the current KEM and Signature algorithms with PQC algorithms. Many of the PQC algorithms are very fast. Note that using PQC algorithms significantly increases the message sizes. Signatures, public keys, and encapsulations would be around 800 bytes instead of the current 32-64 bytes.
Does it make sense to specify a suite?
Regarding increased size, it does not meet the charter objective/fragmentation limit of 6TiSCH, but it still fits the MTU 6lowpan and may be a price to pay to reach PQC. Can the OSCORE re-keying proposals also meet PQC requirements? If so, and a "relatively expensive" key-exchange can be done very infrequently - the overhead is less of an issue.
Not right now I think. I think EDHOC needs to wait until COSE has registered PQC Key exchange algorithms. Which will probable happen after NIST standards. I don't think combining LMS signatures with ECC key exchange makes sense. NIST stated that round 3 will end close to the end of 2021. Draft standards will be available 2022-2023 and final standards hopefully 2024. NSA has stated that will update their CNSA suite at the end of NIST round 3. I think that makes a lot of sense for US TOP SECRET that requires protection for maybe 50-100 years. For many other use cases I think the quantum threat might bw a bit exagerated. It is unclear if CRQC will ever be built. If the number of qubits double every 18 months like transistor based chips did it will take 25-30 years.

Regarding increased size, it does not meet the charter objective/fragmentation limit of 6TiSCH, but it still fits the MTU 6lowpan and may be a price to pay to reach PQC. COSE/EDHOC will definitly have PQC algorithms in a few years. A big US company asked for a CNSA compliant suite which was added. CNSA will be updated to PQC is just a few months, but I think EDHOC should wait for COSE when it comes to PQC. >Can the OSCORE re-keying proposals also meet PQC requirements? If so, and a "relatively expensive" key-exchange can be done very infrequently - the overhead is less of an issue. Basically any symmetric construction will be PQC. The current It is unclear if CRQC breaking RSA will ever be built. If such CRQC are ever built, it would take millions of such CRQC hundreds of years to break AES-128. SHA-256 is more quantum resistant then AES-128 and HMAC-SHA-256 is more resistant than SHA-256. NIST currently draft documents label AES-128 and SHA-256 as quantum resistant which make a lot of sense to me. The EDHOC Key-Update use HMAC-SHA-256 and the OSOCRE key update use HKDF-SHA-256. They would both be highly resistant to quantum computers.
is now merged into master. Any further comments?
It looks good to me, and i appreciate the progress moving forward.
All good from my side too. Thanks!
Several things in the document is not specification but rather clarification of how COSE works. The additon of this and the integration in the main body was requested by several implementors. It should be more clearly marked that these parts just explain COSE and does not define anything. If soemthing would be wrong. The COSE specification apply. E.g.
The explanations of COSE are moved to C.3 in PR .
The IANA section currectly specified that CWT can be sent tagged or untagged while UCCS can only be sent untagged. That is probably not how it should be.
Only untagged: Untagged or tagged: Only tagged
Tagged add bytes that are not required.

The COSE header parameter alredady gives this information. Except that I don't have a strong opinion between allowing both and only allowing untagged. Note that this is mostly a COSE question, rather than LAKE
The UCCS tag numer has not been assigned yet. URL
If I understand correctly, there is no need to integrity-protect also the possible CBOR tags. Then, I'd propose to generally admit both tagged and untagged objects. However, possible CBOR tags must be stripped away when building CRED_X --- Relates to URL
If I understand correctly, there is no need to integrity-protect also the possible CBOR tags. There is no need, but if used in the protected header as in EDHOC they will be integrity protected. That however not a problem as the protected header_map is sent on the wire, so both parties will have the same formatting.
Thanks Marco. My understandanding of the the current suggestion from Marco is: COSE: The COSE header parameters for CWT and ECCS allow bot tagged and untagged and do not enforce any specific order in the map. EDHOC: When CWT and UCCS is used in EDHOC, then CRED_x is the untagged CWT or UCCS sorted in lexigraphical order as defined by deterministic CBOR. That works for me.
Do CWT and UCCS need several header parameter each similar to x5u x5t x5chain x5bag?
New name (kcwt/kccs) and description: 4910a42f
NAME commented in the interim on "wrapped in a bstr" needs to be clarified.
NAME Is this following minor change (in ) sufficient, or do we need to provide more details? OLD When the authentication credential is a X.509 certificate, CREDx SHALL be the end-entity DER encoded certificate wrapped in a bstr {{I-D.ietf-cose-x509}}. NEW When the authentication credential is an X.509 certificate, CREDx SHALL be the end-entity DER encoded certificate, encoded as a bstr {{I-D.ietf-cose-x509}}.
Do you have a nested encoding step or is this just a byte string with the encoded X.509 certificate?
As this is referring to the end-entity certificate I would say the latter.

NAME
Or in other words, we need to make sure we don't use terminology that implies nested encoding steps in cases where we simply have a plain data item in the CBOR. In CBOR diagnostic, if 'foo' is the encoded foreign data: 'foo' Inside the overall encoded data item: > Inside the overall encoded data item:
As I read it "end-entity DER encoded certificate, encoded as a bstr" indicates a "plain" CBOR encoding of the non-CBOR X.509 certificate data. Any objection / disagreement to this definition / interpretation?