Re: [COSE] [Ace] draft-raza-ace-cbor-certificates-04.txt

[Göran Selander <[e-mail]>]

Hi Laurence,

(Copying both ACE and COSE pending further notice about right mail list.)

Comments inline.

From: COSE <[e-mail]> on behalf of Laurence Lundblade <[e-mail]>
Date: Friday, 24 April 2020 at 20:58
To: Joel Höglund <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [COSE] [Ace] draft-raza-ace-cbor-certificates-04.txt


On Apr 24, 2020, at 5:01 AM, Joel Höglund <[e-mail]<mailto:[e-mail]>> wrote:

> But of most interest to me is whether the COSE was considered as the
> signing format for native CBOR certs. If COSE is used, then this looks
> almost identical to CWT and may be a native CBOR cert is a variant of
> a CWT? … …

Our starting point has been to stay close to the original X.509 format while minimizing size. A COSE encoding would re-add some format overhead (close to 10% for the provided example certificate). But if a COSE encoding would help making the format accepted and used, it can definitely be further discussed.

Once again, thank you for your comments!

Hi Joel,

I’m just focusing on the native CBOR cert here.

[GS] Thanks for showing interest!

The overhead for COSE_Sign1 to encode the algorithm ID, key id (optional), payload, and signature is tiny and is fixed. If you assume each of these (IDs, payload, sig) already have to be a CBOR-encoded integer or string, then the overhead is probably less than ten bytes total, maybe even less than five for the COSE structure that groups them.

In your example A.3, I don’t see how the to-be-signed bytes are identified. Some solution, probably using bstr wrapping is needed. COSE solves with no more overhead than necessary.  (You don’t need this in example A.2, because you reconstruct the X.509 ASN.1/DER which does identify the to-be-signed bytes).

I’m not sure where you got the 10% number, but it seems high. Also, the COSE overhead is fixed, not proportional to the size of the certificate.

[GS] I think Joel is making a rough estimate of the size of a CBOR certificate to that of a COSE_Sign1 of a CWT.

To go on a little more, in the ASN.1 world, X.509 certs didn’t use CMS structure for signing which meant they couldn’t share implementations. Seems like X.509 and CMS were developed separately. Also, CMS isn’t that compact.

However, COSE_Sign1 is very compact and efficient. If it could be used for a native CBOR cert format, then COSE code can be re used. In use cases like signed SW updates and secured boot that use certificate chains, both the certificate chain and the signed SW updates would use the COSE format and share for verifying signatures.

[GS] The rationale for native CBOR certificates is to reuse the same encoding as in the compression scheme defined for RFC 7925, but signing the CBOR instead of signing the uncompressed data. This provides a roadmap with minimal changes when moving from compressed to native CBOR certificates.

I agree with you that the overhead of COSE_Sign1 or CWT is not major and these points are open for discussion. The more important question is where this should be standardized. The compression scheme is now included in the new draft charter for COSE:
https://github.com/cose-wg/Charter/blob/master/Charter.md
The charter is currently not explicitly supporting native CBOR certificates. If you think it should, in some variant, then this is a good time to raise your voice.

Göran