Subject: [COSE] COSE IANA registrations in EDHOC (Was: [Lake] New Version Notification for draft-ietf-lake-edhoc-09.txt)

From: Göran Selander <[email-masked]>
Date: Tue, 24 Aug 2021 07:35:12 +0000

Combining the responses from Carsten and Michael, and including COSE.

> On 2021-08-23, 19:17, "Michael Richardson" <[email-masked]> wrote:
>
>    Göran Selander wrote:
>        > * The key identifier ‘kid’ is extended to also support CBOR ints,
>        > making ‘kid2’ introduced in -08 redundant. This change was based on
>        > feedback from the COSE WG [1]. One potential next step is to move all
>        > COSE-related IANA registrations from this draft to a separate COSE
>        > draft and make an informative reference.
>
>        >  [1] https://mailarchive.ietf.org/arch/msg/cose/qGngdte4s3SEZEKM-xBEoXYUgKc/
>
>    I understanding splitting the document so that it is easier to update,
>    but I think that the reference should be normative.
>
>    I think we want to publish the documents together.

> On 2021-08-23, 21:42, "Carsten Bormann" <[email-masked]> wrote:
>
>  > One potential next step is to move all COSE-related IANA registrations from this draft
> to a separate COSE draft and make an informative reference.
>
>    Why?
>

The registrations in question are in section 8.5 -  8.7 of draft-ietf-lake-edhoc-09: The extension of 'kid' to int (both as a reference and in the referenced object) and the registration of 'cwt' to signify that the value is a CWT or UCCS.

A few reasons have been mentioned for moving this from EDHOC to a COSE draft, I don't know what is most relevant, if anything:

* In case of 'kid', these registrations would make EDHOC an update of draft-ietf-cose-rfc8152bis-struct (RFC-to-be 9052). I don't know if LAKE or COSE wants that. 

* These registrations are independent of the base EDHOC protocol, but enables the use of CWT and UCCS as credentials, and more compact identification of credentials. Therefore they could instead be referenced from EDHOC. I don't see why the reference needs to be normative.

* These registrations belong to the COSE domain and may gain better awareness and reviews if put into a COSE draft.

Göran

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Aug 2021 10:04:54 +0200

I see.

So, you are saying, this will be a “using EDHOC in COSE” specification, still normative, but referenced from EDHOC as informative as EDHOC works without COSE.

Yes, it is always hard to position a “using X in Y” draft between the X and Y working groups — after all, the two ends of this draft need to fit X and Y, respectively.  If the EDHOC specification truly doesn’t need the contents of this specification, then I can see moving them into a COSE document.  But I think it is as expedient to keep them together in one document.  The only strong reason to split the document would be to avoid a long wait while COSE is deciding on some controversial content of the extracted spec.  Do we foresee such a delay?

Grüße, Carsten

> On 2021-08-24, at 09:35, Göran Selander <goran.selander=[email-masked]> wrote:
> 
> -- 
> Lake mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lake

---

From: Göran Selander <[email-masked]>
Date: Tue, 24 Aug 2021 11:43:42 +0000

> On 2021-08-24, 10:05, "Lake on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:
>
>    I see.
>
>    So, you are saying, this will be a “using EDHOC in COSE” specification, 

Well, others may also have use of the COSE header for CWT/UCCS, and the int value type of 'kid'.

>  still normative, but referenced from EDHOC as informative as 
>   EDHOC works without COSE.

Well, EDHOC is definitely dependent on COSE, but does not require these particular credentials or identifiers.

>   Yes, it is always hard to position a “using X in Y” draft between the X and Y working groups — after all, the two ends of this draft need 
>   to fit X and Y, respectively.  If the EDHOC specification truly doesn’t need the contents of this specification, then I can see moving them
>   into a COSE document.  But I think it is as expedient to keep them together in one document.  The only strong reason to split the 
>  document would be to avoid a long wait while COSE is deciding on some controversial content of the extracted spec.  Do we foresee such 
>  a delay?

Not that I am aware of. Previous discussion in COSE has not indicated that this is contentious. The main thing we haven't discussed is that EDHOC would be updating rfc8152bis-struct.

Göran

---

From: Marco Tiloca <[email-masked]>
Date: Tue, 24 Aug 2021 23:44:24 +0200

Hi all,

> Well, others may also have use of the COSE header for CWT/UCCS, and the int value type of 'kid'.

==>MT
Yes, the ACE KDC for group communication [1] and especially the ACE 
Group Manager for Group OSCORE [2] now use (the Labels of) COSE Header 
Parameters as values for the 'pub_key_enc' parameter.

This parameter indicates the format of public keys used in the group. 
The possible formats include also CWT/UCCS under pending registration; 
see for instance the paragraphs about 'pub_key_enc' in Sections 6.1 and 
6.4 of [2].

Best,
/Marco

[1] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/

[2] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/
<==

>      >>> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcose%2FqGngdte4s3SEZEKM-xBEoXYUgKc%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cfb94e5e14e9a419b9f1008d966f47a4b%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654022486332814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TVx5osodCud2uoLxWalRjnpX3fH%2BDexH0iXEhdYrsEw%3D&amp;reserved=0
>      >>
>      > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cfb94e5e14e9a419b9f1008d966f47a4b%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654022486332814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LAdEidnDbp7NLyMG1ZWXU2PHFUoIn9Im2%2Bg9vQa50KI%3D&amp;reserved=0
>
>      --
>      Lake mailing list
>      [email-masked]
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cfb94e5e14e9a419b9f1008d966f47a4b%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654022486332814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LAdEidnDbp7NLyMG1ZWXU2PHFUoIn9Im2%2Bg9vQa50KI%3D&amp;reserved=0
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Aug 2021 21:18:55 -0700

> Not that I am aware of. Previous discussion in COSE has not indicated that this is contentious. The main thing we haven't discussed is that EDHOC would be updating rfc8152bis-struct.

I think it would invite questions of charter scope if a document from LAKE
attempted to update rfc8152bis-struct; keeping that work in COSE seems
likely to have an easier path, process-wise.

-Ben