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



_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to