[Sis-dtn] Deterministic CBOR encoding

[Felix.Flentge at esa.int]

Dear All,

I have spend some time this morning to understand the requirements we get 
for the BPv7 CBOR encoding from draft-ietf-dtn-bpbis-31.txt, RFC 8949, and 
draft-ietf-dtn-bpsec-27 (actually, I have been worried about a potential 
issue with the current BPv7 spec; now I think it is probably ok). Anyway, 
this is my understanding of the current situation. Please let me know 
whether you share it or not.

draft-ietf-dtn-bpbis-31.txt:

We have:

4. Bundle Format

4.1. Bundle Structure

   The format of bundles SHALL conform to the Concise Binary Object
   Representation (CBOR [RFC8949]).

   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].

 There are two small issues here:
- Only the first statement is a real requirement for BPv7, the 'must' in 
the last sentence is not capitalised meaning it is not normative (AFAIK).
- RFC8949 does not really specify 'Canonical CBOR': 
Section 4.2.3 contains the following note:

      |  Although [RFC7049] used the term "Canonical CBOR" for its form
      |  of requirements on deterministic encoding, this document avoids
      |  this term because "canonicalization" is often associated with
      |  specific uses of deterministic encoding only.  The terms are
      |  essentially interchangeable, however, and the set of core
      |  requirements in this document could also be called "Canonical
      |  CBOR", while the length-first-ordered version of that could be
      |  called "Old Canonical CBOR".
and G.3:

   For a single value in the data model, CBOR often provides multiple
   encoding options.  A new section (Section 4) introduces the term
   "preferred serialization" (Section 4.1) and defines it for various
   kinds of data items.  On the basis of this terminology, the section
   then discusses how a CBOR-based protocol can define "deterministic
   encoding" (Section 4.2), which avoids terms "canonical" and
   "canonicalization" from RFC 7049.  The suggestion of "Core
   Deterministic Encoding Requirements" (Section 4.2.1) enables generic
   support for such protocol-defined encoding requirements.  This
   document further eases the implementation of deterministic encoding
   by simplifying the map ordering suggested in RFC 7049 to a simple
   lexicographic ordering of encoded keys.  A description of the older
   suggestion is kept as an alternative, now termed "length-first map
   key ordering" (Section 4.2.3).

 Anyway, for our purposes we probably can understand 'rules for Canonical 
CBOR' as the Core Deterministic Requirements in Section 4.2.1 (at least as 
long as we don't use maps, see 4.2.3). This view would be supported by 
draft-ietf-dtn-bpsec-27: 
4.  Canonical Forms

  [...]

   The canonical form of the primary block is as specified in
   [I-D.ietf-dtn-bpbis] with the following constraint.

   o  CBOR values from the primary block MUST be canonicalized using the
      rules for Deterministically Encoded CBOR, as specified in
      [RFC8949].

   All non-primary blocks share the same block structure and are
   canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following
   constraints.

   o  CBOR values from the non-primary block MUST be canonicalized using
      the rules for Deterministically Encoded CBOR, as specified in
      [RFC8949].

(It would be even better if there would be an explicit reference to 
Section 4.2.1.) 

So, for CCSDS the main questions seems to be whether we are happy enough 
with the core deterministic requirements in RFC8949, Section 4.2.1, 
basically:

*  Preferred serialization MUST be used.  In particular, this means
      that arguments (see Section 3) for integers, lengths in major
      types 2 through 5, and tags MUST be as short as possible, for
      instance:
[...]

   *  Indefinite-length items MUST NOT appear.  They can be encoded as
      definite-length items instead.

   *  The keys in every map MUST be sorted in the bytewise lexicographic
      order of their deterministic encodings. [...]

We are not using maps (currently; and may want to avoid in the future) and 
shall not use indefinite-length items in (extension) blocks (the whole 
indefinite length bundle array should be ok). I would suggest that we 
consult with more hardware-oriented people whether the '... as short as 
possible ...' requirements would be a problem. If not, I would suggest 
that we explicitly require Deterministically Encoded CBOR according to 
RFC8949, 4.2.1. Otherwise, we might have to define something more 
CCSDS-specific (and would risk loosing interoperability with other 
implementations, in particular, regarding bundle security).

Regards,
Felix 


Disclaimer
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or protected content. Any unauthorised 
disclosure, use, retention or dissemination is prohibited. If you have 
received this e-mail in error, please notify the sender immediately. ESA 
applies appropriate organisational measures to protect personal data, in 
case of data privacy queries, please contact the ESA Data Protection 
Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211118/e5679b47/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/20211118/e5679b47/attachment-0001.bin>