<span style=" font-size:10pt;font-family:sans-serif">Dear All,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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.</span>
<br>
<br><span style=" font-size:10pt;font-family:Courier New"><b>draft-ietf-dtn-bpbis-31.txt</b></span><span style=" font-size:10pt;font-family:sans-serif">:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">We have:</span>
<br>
<br><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-31#section-4"><tt><span style=" font-size:10pt;color:blue"><b><u>4</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>.
Bundle Format</b><br>
<br>
</span></tt><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-31#section-4.1"><tt><span style=" font-size:10pt;color:blue"><b><u>4.1</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>.
Bundle Structure</b><br>
<br>
<b>The format of bundles SHALL conform to the Concise Binary Object<br>
Representation (CBOR [</b></span></tt><a href=https://datatracker.ietf.org/doc/html/rfc8949><tt><span style=" font-size:10pt;color:blue"><b><u>RFC8949</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>]).</b><br>
<br>
Cryptographic verification of a block is possible only if the<br>
sequence of octets on which the verifying node computes its hash
-<br>
the canonicalized representation of the block - is identical to
the<br>
sequence of octets on which the hash declared for that block was<br>
computed. <b>To ensure that blocks are always in canonical<br>
representation when they are transmitted and received, the CBOR<br>
representations of the values of all fields in all blocks must<br>
conform to the rules for Canonical CBOR as specified in [</b></span></tt><a href=https://datatracker.ietf.org/doc/html/rfc8949><tt><span style=" font-size:10pt;color:blue"><b><u>RFC8949</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>].</b></span></tt>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif"> There are
two small issues here:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- 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).</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- RFC8949 does
not really specify 'Canonical CBOR': </span>
<br><span style=" font-size:10pt;font-family:sans-serif">Section 4.2.3
contains the following note:</span>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><tt><span style=" font-size:10pt">
| <b>Although [</b></span></tt><a href="https://datatracker.ietf.org/doc/html/rfc7049#section-3"><tt><span style=" font-size:10pt;color:blue"><b><u>RFC7049</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>]
used the term "Canonical CBOR" for its form<br>
| of requirements on deterministic encoding,
this document avoids<br>
| this term because "canonicalization"
is often associated with<br>
| specific uses of deterministic encoding only.
The terms are<br>
| essentially interchangeable, however, and
the set of core<br>
| requirements in this document could also be
called "Canonical<br>
| CBOR",</b> while the length-first-ordered
version of that could be<br>
| called "Old Canonical CBOR".</span></tt></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">and
G.3:</span></p>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><tt><span style=" font-size:10pt">
For a single value in the data model, CBOR often provides multiple<br>
encoding options. A new section (</span></tt><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4"><tt><span style=" font-size:10pt;color:blue"><u>Section
4</u></span></tt></a><tt><span style=" font-size:10pt">) introduces the
term<br>
"preferred serialization" (</span></tt><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.1"><tt><span style=" font-size:10pt;color:blue"><u>Section
4.1</u></span></tt></a><tt><span style=" font-size:10pt">) and defines it
for various<br>
kinds of data items. On the basis of this terminology, the
section<br>
then discusses how a CBOR-based protocol can define "deterministic<br>
encoding" (</span></tt><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.2"><tt><span style=" font-size:10pt;color:blue"><u>Section
4.2</u></span></tt></a><tt><span style=" font-size:10pt">), which avoids
terms "canonical" and<br>
"canonicalization" from </span></tt><a href="https://datatracker.ietf.org/doc/html/rfc7049#section-3"><tt><span style=" font-size:10pt;color:blue"><u>RFC
7049</u></span></tt></a><tt><span style=" font-size:10pt">. The suggestion
of "Core<br>
Deterministic Encoding Requirements" (</span></tt><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.1"><tt><span style=" font-size:10pt;color:blue"><u>Section
4.2.1</u></span></tt></a><tt><span style=" font-size:10pt">) enables generic<br>
support for such protocol-defined encoding requirements. This<br>
document further eases the implementation of deterministic encoding<br>
by simplifying the map ordering suggested in </span></tt><a href="https://datatracker.ietf.org/doc/html/rfc7049#section-3"><tt><span style=" font-size:10pt;color:blue"><u>RFC
7049</u></span></tt></a><tt><span style=" font-size:10pt"> to a simple<br>
lexicographic ordering of encoded keys. A description of
the older<br>
suggestion is kept as an alternative, now termed "length-first
map<br>
key ordering" (</span></tt><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.3"><tt><span style=" font-size:10pt;color:blue"><u>Section
4.2.3</u></span></tt></a><tt><span style=" font-size:10pt">).</span></tt></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<br><span style=" font-size:10pt;font-family:sans-serif"> 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:
</span>
<br><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#section-4"><tt><span style=" font-size:10pt;color:blue"><b><u>4</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>.
Canonical Forms</b><br>
<br>
[...]<br>
<br>
The canonical form of the primary block is as specified in<br>
[</span></tt><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#ref-I-D.ietf-dtn-bpbis"><tt><span style=" font-size:10pt;color:blue"><u>I-D.ietf-dtn-bpbis</u></span></tt></a><tt><span style=" font-size:10pt">]
with the following constraint.<br>
<br>
o <b>CBOR values from the primary block MUST be canonicalized
using the<br>
rules for Deterministically Encoded CBOR, as specified
in<br>
[</b></span></tt><a href=https://datatracker.ietf.org/doc/html/rfc8949><tt><span style=" font-size:10pt;color:blue"><b><u>RFC8949</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>].</b><br>
<br>
All non-primary blocks share the same block structure and are<br>
canonicalized as specified in [</span></tt><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#ref-I-D.ietf-dtn-bpbis"><tt><span style=" font-size:10pt;color:blue"><u>I-D.ietf-dtn-bpbis</u></span></tt></a><tt><span style=" font-size:10pt">]
with the following<br>
constraints.<br>
<br>
o <b>CBOR values from the non-primary block MUST be canonicalized
using<br>
the rules for Deterministically Encoded CBOR, as specified
in<br>
[</b></span></tt><a href=https://datatracker.ietf.org/doc/html/rfc8949><tt><span style=" font-size:10pt;color:blue"><b><u>RFC8949</u></b></span></tt></a><tt><span style=" font-size:10pt"><b>].</b></span></tt>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">(It would be even
better if there would be an explicit reference to Section 4.2.1.) </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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:</span>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><tt><span style=" font-size:10pt">*
Preferred serialization MUST be used. In particular, this means<br>
that arguments (see </span></tt><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-3"><tt><span style=" font-size:10pt;color:blue"><u>Section
3</u></span></tt></a><tt><span style=" font-size:10pt">) <b>for integers,
lengths in major<br>
types 2 through 5, and tags MUST be as short as possible</b>,
for<br>
instance:<br>
[...]<br>
<br>
* <b>Indefinite-length items MUST NOT appear</b>. They
can be encoded as<br>
definite-length items instead.<br>
<br>
* The keys in every map MUST be sorted in the bytewise lexicographic<br>
order of their deterministic encodings. [...]</span></tt></p>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Regards,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Felix </span><tt><span style=" font-size:10pt"><b><br>
</b></span></tt>
<br>
<br><span style=" font-size:9pt;color:#808080;font-family:Arial"><b><i>Disclaimer</i></b></span>
<br><span style=" font-size:7pt;color:#808080;font-family:Arial"><i>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@esa.int).</i></span>