Subject: [COSE] RPK by value in COSE / EDHOC

From: John Mattsson <[email-masked]>
Date: Wed, 12 May 2021 13:15:46 +0000

Hi,

As stated in the agreed requirement document in LAKE weighted the initial focus of the LAKE WG shall be:

"RPK (by reference and value) and certificate by reference."

https://datatracker.ietf.org/doc/html/draft-ietf-lake-reqs

RPK by value has been requested by several industrial partners interested in using LAKE.

EDHOC completely relies on COSE header parameters to transport of identify credentials. I.e. 'kid', 'x5chain', 'x5bag', 'x5u', 'x5t', 'c5c', 'c5b', 'c5u', 'c5t'. It would be good if RPK by value work was done in COSE. Alternatively LAKE could specify the new COSE header parameter (as long as COSE agrees it should be done).

Two main options for PRK by value. COSE_Key or a slim down version of C509 without issuer signature. Both have some benefit and disadvantages.

- COSE_Key is available in COSE Implementations

- COSE_Key was not desgined for transport on the wire. But this can be fixed.

- COSE_Key lack header parameter for use by value

- EDHOC implementations will likely support C509, using both C509 and COSE_Key means using two completely different key formats. This means additional code and that key_ops / EKU needs to be registered twice.

- COSE_Key does not offer any additional functionality like validity, subject name. COSE_Key only supports very limited key_ops. Subject name is needed to align with SIGMA. Validity and KeyUsage seems useful also for PRK. 

- More of less same size on the wire.

Some examples of RPK with point compressions below:

COSE_Key
------------------------------

{
  1:  1,
 -1:  4,
 -2:  h'b1a3e89460e88d3a8d54211dc95f0b903ff205eb71912d6db8f4af980d2db83a',
 -3:  true,
}

C509
------------------------------

TBSCertificate = (
   c509CertificateType: int,
   validityNotBefore: Time,
   validityNotAfter: Time,
   subject: Name,
   subjectPublicKeyAlgorithm: AlgorithmIdentifier,
   subjectPublicKey: any,
   extensions: Extensions,
)

[
     2,
     h'01f50d',
     1577836800,
     1612224000,
     h'0123456789AB',
     1,
     h'02B1216AB96E5B3B3340F5BDF02E693F16213A04525ED44450B1019C2DFD3838AB',
     1
]

If COSE Agrees, I think there are three ways forward:

1. New draft in COSE WG defining header paramerer for COSE_Key by value
2. New c509CertificateType in draft-ietf-cose-cbor-encoded-cert
3. Define 1. or 2. in draft-ietf-lake-edhoc

---

From: John Mattsson <[email-masked]>
Date: Mon, 17 May 2021 11:21:33 +0000

Hi,

Thanks for the good discussion during the interim. Especially the pointers to RFC 7250, RFC 8392, and RFC  8747. Transfering CWTs in COSE / EDHOC was suggested back in 2016 by Jim Schad. I think our offline discussions was that this needed to be supported but then nobody ended up driving the use case. I definitly think CWT should be supported in COSE (and therefore in EDHOC). CWTs sovle a bit different use cases than certificates and are a bit more flexible. Both CWT and C509 can be used to transfer a "raw" public key. If transferring CWTs in COSE is supported, I am not sure that a more optimized format like RFC 7250 is needed at all (but somebody should calculate sizes). 

I made an issue and a PR on the EDHOC GitHub regarding this. The PR registers a new COSE header parameter to transfer CWTs in COSE.

https://github.com/lake-wg/edhoc/issues/115

https://github.com/lake-wg/edhoc/pull/116

Let's first discuss what should be specified, and later where and how. I will suggest that LAKE WG discuss CWT and PRK during the next interim if there is time.

Regarding the charter question brought up during the interim, I think CWT or RPK would fit nicely in:

"The COSE working group will deal with two types of documents going forward:

2. Documents which describe additional attributes for COSE."

There is however no work item related to 2.

Cheers,
John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Wednesday, 12 May 2021 at 15:15
To: "[email-masked]" <[email-masked]>
Subject: RPK by value in COSE / EDHOC

Hi,

COSE_Key

{
  1:  1,
 -1:  4,

C509

TBSCertificate = (

[
     2,
     h'01f50d',
     1577836800,
     1612224000,
     h'0123456789AB',
     1,