[Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?

[Felix.Flentge at esa.int]

Well,

I think the point here is whether it is 'must' or 'MUST'.

Is there any intention to keep some flexibility for IETF DTN here or not?

It's an important point for (efficient) on-board implementations. CCSDS 
should be very clear on CBOR serialisation. So, I see four options

1) IETF has a MUST, CCSDS confirms this MUST
2) IETF has a 'must'--> CCSDS makes is a MUST
3) IETF has a MUST --> CCSDS decides to implement a different 
serialisation (to guarantee fixed block sizes independent from actual 
values)
4) IETF has a 'must'--> CCSDS decides to implement a different 
serialisation

Clearly, 3)  needs to avoided and I would hope that we do not need to go 
to 4) ( the initial feedback is that deterministic CBOR is ok for on-board 
implementations, TBC).
Ideally, we would have 1) but in order to avoid 3) we might want to stay 
with 1)

On the indefinite-length exception, I'm not sure. I think the requirement 
for deterministic CBOR is on the blocks/fields and not the entire bundle 
(which is currently the only indefinite length item).
So, we might allow indefinite-length also in blocks (which may lead to 
slightly more efficient encoding but might make decoding slightly more 
difficult). In this case, we might want to extend the deterministic CBOR 
requirement (with the exception) to the whole bundle.
Or we might not allow in-definite length for blocks/fields and state 
explicitly that this does not apply to the full bundle.

(I do hope, I have not been to confusing. It's still quite early for me.)

Regards,
Felix



From:   "Birrane, Edward J." <Edward.Birrane at jhuapl.edu>
To:     "Dr. Keith L Scott" <kscott at mitre.org>, "Scott Burleigh" 
<scott.c.burleigh at jpl.nasa.gov>
Cc:     "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Date:   01/12/2021 21:30
Subject:        Re: [Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for 
block field encoding?
Sent by:        "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>



I believe this is changed to deterministic CBOR with the exception the 
indefinite length items are not prohibited. 

Sent with BlackBerry Work
(www.blackberry.com)


From: Dr. Keith L Scott <kscott at mitre.org>
Date: Wednesday, Dec 01, 2021, 12:01 PM
To: Scott Burleigh <scott.c.burleigh at jpl.nasa.gov>, Birrane, Edward J. <
Edward.Birrane at jhuapl.edu>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?

APL external email warning: Verify sender kscott at mitre.org before clicking 
links or attachments
 
The draft-31 spec says:
 
Cryptographic verification of a block is possible only if the
   sequence of octets on which the verifying node computes its hash -
   the canonicalized representation of the block - is identical to the
   sequence of octets on which the hash declared for that block was
   computed.  To ensure that blocks are always in canonical
   representation when they are transmitted and received, the CBOR
   representations of the values of all fields in all blocks must
   conform to the rules for Canonical CBOR as specified in [RFC8949].
 
Note the non-capitalization of the MUST requirement.  Was that intended to 
be capitalized (and is it in the version that the RFC editor sent back)? 
What are folks thoughts on capitalizing it as part of AUTH48?
 
                                v/r,
 
                                --keith
 
 _______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211202/8ddce20d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211202/8ddce20d/attachment-0001.bin>