Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT

[Jim Schaad <[e-mail]>]

 

 

From: CBOR <[e-mail]> On Behalf Of Brendan Moran
Sent: Tuesday, July 28, 2020 8:25 AM
To: [e-mail]
Subject: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT

 

I think that packed CBOR is a feature that’s very much needed. In fact, there’s a similar feature in SUIT. I’d rather get rid of SUIT’s deduplication system and use packed CBOR instead, but the timing may not work out. 

 

I’d like to reiterate some of things that were said in the discussion during the cbor meeting, and add some additional points.

 

The current encoding of #6.6([]) is not friendly to stream processing, nor to pull parsers. It is easier for this style of parser to have a dictionary first, followed by the rump. We could arrange to resolve this by replacing the rump in its entirety with a shared object reference, and encoding the actual rump as a shared object. This allows a pull parser to directly jump to the dictionary. If the “rump” is placed as the last shared object, a stream processor can use this abstraction to ensure that the rump is encountered only once the dictionary is received. So, this “concern” may be a no-op and may just require an implementation hint for addressing pull parsers.

 

 

SUIT has some peculiar requirements that might be relevant to the design of packed CBOR:

 

1. SUIT manifests would absolutely benefit from a mechanism to compress CBOR sequences. SUIT’s basic building block is arrays that are effectively multi-maps. Some of these multi-maps contain similar sequences of objects. It would be beneficial to be able to deduplicate the identical parts. 

 

2. SUIT would benefit from nested packed CBOR items. SUIT features elements that can be detached from each other in much the same way as COSE supports detached payloads. A SUIT envelope contains a manifest and zero or more severable (detached) elements. It would be preferable for packing to work like this: any element or sequence that appears at least once in the manifest and two or more times in the union of manifest and severable elements, should be placed in the dictionary for the manifest. Any element or sequence that appears two or more times in a severable element, but not in the manifest, should be placed in the severable element’s dictionary.

 

I believe that a suit-specific cbor packer could achieve this mechanism if nested packed CBOR data items were supported. SUIT does not appear to require more than a 





3. I suspect that SUIT would also benefit from domain-specific pre-shared dictionaries. I’d like to see some way of defining canonical dictionary merging: Are dictionaries concatenated? In which order are they concatenated? How should a domain-specific pre-shared dictionary be included in a signed context? By digest?

 

[Brendan] One of the questions that I have is the order of compressing and applying security operations.  If you are using a pull parser do you think it is going to be easier (we can talk about more secure later) to do the hashing on the compressed or uncompressed version.  This could be an even harder question to ask with the use of an external dictionary.  There is one potential benefit w/ COSE in that the hash of the dictionary could be included as external data.

 

Jim

 

 

 

Best Regards,

Brendan

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.