Re: [Cbor] [COSE] CBOR magic number, file format and tags

My choice would be to parallel what is done for COSE, CWT and most other CBOR protocols I’ve seen:

1) Make the compressed CBOR certs an array instead of a sequence for all use. This makes it one byte bigger, but it makes it work just like the other CBOR protocols that have been defined. I see the use of CBOR sequence here as an outlier, somewhat confusing and burdensome. It is burdensome because you can’t just drop them into other CBOR protocols and because a tag for it has to be special. As far as I can tell the only reason this is a sequence and not an an array is to save the one byte. 

2) Assign a tag that indicates compressed CBOR cert and use it just like the tags for COSE and CWT or any other protocol with an identifying tag. Or said another way, most CBOR protocols have an identifying tag. Compressed CBOR certs should have one too.

3) When you put it in a file, use the 55799 magic number to indicate it is CBOR and then the compressed CBOR cert tag to indicate it is a compressed CBOR cert. If the tag number was 48 then the first bytes of the file would be:

d9 d9 f7 d8 30 8b … 

You could take d9 d9 f7 d8 30 to be the magic number for a compressed CBOR cert. The 8b is to open the array for step 1) above. When you want to put the compressed CBOR cert into a protocol message field that needs no tagging you can just exclude those five bytes. When you take it out of a protocol message and put it in a file, you add those five bytes.

This mechanism would work for CWTs and COSEs in files too.  Similarly a COSE_Sign1 CWT in a file would be:

d9 d9 f7 d8 3d d2 84

This is three nested tags 55799(61(18(…))), a COSE_Sign1 in a CWT in a 55799. You can treat d9 d9 f7 d8 3d d2 the magic number.

Or take d9 d9 f7, the 55799 tag, to be the magic number indicating CBOR causing a general CBOR dispatcher to be started. That dispatcher looks for a second tag. Based on a second tag it dispatched to the handler for the compressed cert, the CWT, the COSE, the CoSWID, the UCCS...

LL

> On Jan 23, 2021, at 5:07 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> 
> 
>> On 2021-01-23, at 04:14, Dale R. Worley <worley@ariadne.com> wrote:
>> 
>> Here's an alternative.  It is aligned with the magic number tag of CBOR
>> itself (55799) and the CBOR way of doing things.  Specifically, reserve
>> a large range of tags (such as 55800 to 65000, or 100000 to 109999) for
>> use as magic numbers; the CBOR object has the appropriate magic number
>> tag applied to that, and optionally, the CBOR magic number tag 55799
>> applied to that.  That can leave the generic CBOR magic number visible
>> at the start of the file, immediately followed by the bytes of the
>> specific magic number for the object type.
> 
> Right.  Something like this would probably make sense as an alternative to the primary approach proposed, which is based on CBOR sequences.  If you want to keep the magic-numbered file a single data item, this is the way to go.
> 
> Two issues:
> 
> — This should probably be a 1+4-byte tag.  The range you mention leads to a zero byte in the magic number.  Not sure if that is a bug or a feature.  (It is also way too small.)
> 
> — As I mentioned before, we don’t have a good way to assign a purpose to a range and then let IANA do the allocation within the range.
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor