<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Felix,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Section 4 (Canonical Forms) of the BPSec draft (bpsec-27) explicitly requires Deterministically Encoded CBOR and zeroing reserved/unassigned bits as part of canonical forms. However, BPSec does allow specific security contexts to override/require their own canonicalization algorithms if that is something a context needs to do.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>BPSec security blocks themselves are required to use the same encodings as used when creating a canonical form (e.g., deterministically encoded cbor) as described in the second paragraph of section 3.6:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><pre><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>“</span><span style='color:black'>The fields of the ASB SHALL be as follows, listed in the order in which they must appear. The encoding of these fields MUST be in accordance with the canonical forms provided in <a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#section-4">Section 4</a>.”<o:p></o:p></span></pre><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>-Ed<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Edward J. Birrane, III, Ph.D. (he/him/his)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Chief Engineer, Space Constellation Networking<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Space Exploration Sector<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Johns Hopkins Applied Physics Laboratory<br>(W) 443-778-7423 / (C) 443-690-8272</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Felix.Flentge@esa.int <Felix.Flentge@esa.int> <br><b>Sent:</b> Thursday, November 18, 2021 10:17 AM<br><b>To:</b> Birrane, Edward J. <Edward.Birrane@jhuapl.edu><br><b>Cc:</b> kfall+rcs@kfall.com; sburleig.sb@gmail.com; sis-dtn@mailman.ccsds.org<br><b>Subject:</b> RE: [EXT] [Sis-dtn] Deterministic CBOR encoding<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Cool,</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>do we currently have any indefinite-length items in BPv7 / BPSEC besides the bundle itself? Maybe this exception is not needed,</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>(I have been planning to use indefinite-length arrays in the compressed reporting block as it could be more efficient in terms of size but I would be happy to go to definite-length).</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Regards,</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Felix</span> <br><br><br><br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>From: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Birrane, Edward J." <<a href="mailto:Edward.Birrane@jhuapl.edu">Edward.Birrane@jhuapl.edu</a>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>To: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>" <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>, "<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Cc: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>" <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>>, "<a href="mailto:kfall+rcs@kfall.com">kfall+rcs@kfall.com</a>" <<a href="mailto:kfall+rcs@kfall.com">kfall+rcs@kfall.com</a>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Date: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>18/11/2021 15:18</span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Subject: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>RE: [EXT] [Sis-dtn] Deterministic CBOR encoding</span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=2 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'>Felix,</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> </span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> I had almost this exact conversation with Scott Burleigh and Kevin Fall yesterday.</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> </span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> The approach to addressing this is to clarify what is meant by Canonical CBOR as part of AUTH48, with a statement of something like the following:</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> </span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>“the CBOR representations of the values of all fields in all blocks must conform to the Core Deterministic Encoding Requirements as specified in [RFC8949] except that indefinite-length items are not prohibited."<o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> </span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> The intent of the BPv7 spec is clearly to allow some indefinite length items, as the spec uses indefinite-length items, and the wording in Section 4.1 is meant to describe the encoding of fields within block otherwise. The exact wording will be figured out once we have the RFC-editor version of the text to review.</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> </span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'>-Ed</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> </span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#004080'>Edward J. Birrane, III, Ph.D. (he/him/his)</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#004080'>Chief Engineer, Space Constellation Networking</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#004080'>Space Exploration Sector</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#004080'>Johns Hopkins Applied Physics Laboratory<br>(W) 443-778-7423 / (C) 443-690-8272</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#004080'> </span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>> <b>On Behalf Of </b><a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a><b><br>Sent:</b> Thursday, November 18, 2021 7:02 AM<b><br>To:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><b><br>Subject:</b> [EXT] [Sis-dtn] Deterministic CBOR encoding</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Dear All,</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>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><b><span style='font-size:10.0pt;font-family:"Courier New"'><br>draft-ietf-dtn-bpbis-31.txt</span></b><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>:</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>We have:</span> <br><u><span style='color:blue'><br></span></u><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-31#section-4"><b><span style='font-size:10.0pt;font-family:"Courier New"'>4</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>. Bundle Format</span></b><span style='font-size:10.0pt;font-family:"Courier New"'><br></span><u><span style='color:blue'><br></span></u><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-31#section-4.1"><b><span style='font-size:10.0pt;font-family:"Courier New"'>4.1</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>. Bundle Structure</span></b><span style='font-size:10.0pt;font-family:"Courier New"'><br><br> <b>The format of bundles SHALL conform to the Concise Binary Object<br> Representation (CBOR [</b></span><a href="https://datatracker.ietf.org/doc/html/rfc8949"><b><span style='font-size:10.0pt;font-family:"Courier New"'>RFC8949</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>]).</span></b><span style='font-size:10.0pt;font-family:"Courier New"'><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><a href="https://datatracker.ietf.org/doc/html/rfc8949"><b><span style='font-size:10.0pt;font-family:"Courier New"'>RFC8949</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>].</span></b> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>There are two small issues here:</span> <span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>- 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> <span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>- RFC8949 does not really specify 'Canonical CBOR': <br>Section 4.2.3 contains the following note:</span> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Courier New"'> | <b>Although [</b></span><a href="https://datatracker.ietf.org/doc/html/rfc7049#section-3"><b><span style='font-size:10.0pt;font-family:"Courier New"'>RFC7049</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>] 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",</span></b><span style='font-size:10.0pt;font-family:"Courier New"'> while the length-first-ordered version of that could be<br> | called "Old Canonical CBOR".</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>and G.3:</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Courier New"'> For a single value in the data model, CBOR often provides multiple<br> encoding options. A new section (</span><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4"><span style='font-size:10.0pt;font-family:"Courier New"'>Section 4</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>) introduces the term<br> "preferred serialization" (</span><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.1"><span style='font-size:10.0pt;font-family:"Courier New"'>Section 4.1</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>) 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><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.2"><span style='font-size:10.0pt;font-family:"Courier New"'>Section 4.2</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>), which avoids terms "canonical" and<br> "canonicalization" from </span><a href="https://datatracker.ietf.org/doc/html/rfc7049#section-3"><span style='font-size:10.0pt;font-family:"Courier New"'>RFC 7049</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>. The suggestion of "Core<br> Deterministic Encoding Requirements" (</span><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.1"><span style='font-size:10.0pt;font-family:"Courier New"'>Section 4.2.1</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>) 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><a href="https://datatracker.ietf.org/doc/html/rfc7049#section-3"><span style='font-size:10.0pt;font-family:"Courier New"'>RFC 7049</span></a><span style='font-size:10.0pt;font-family:"Courier New"'> 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><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.3"><span style='font-size:10.0pt;font-family:"Courier New"'>Section 4.2.3</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>).</span><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>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><u><span style='color:blue'><br></span></u><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#section-4"><b><span style='font-size:10.0pt;font-family:"Courier New"'>4</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>. Canonical Forms</span></b><span style='font-size:10.0pt;font-family:"Courier New"'><br><br>[...]<br><br> The canonical form of the primary block is as specified in<br> [</span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#ref-I-D.ietf-dtn-bpbis"><span style='font-size:10.0pt;font-family:"Courier New"'>I-D.ietf-dtn-bpbis</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>] 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><a href="https://datatracker.ietf.org/doc/html/rfc8949"><b><span style='font-size:10.0pt;font-family:"Courier New"'>RFC8949</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>].</span></b><span style='font-size:10.0pt;font-family:"Courier New"'><br><br> All non-primary blocks share the same block structure and are<br> canonicalized as specified in [</span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#ref-I-D.ietf-dtn-bpbis"><span style='font-size:10.0pt;font-family:"Courier New"'>I-D.ietf-dtn-bpbis</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>] 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><a href="https://datatracker.ietf.org/doc/html/rfc8949"><b><span style='font-size:10.0pt;font-family:"Courier New"'>RFC8949</span></b></a><b><span style='font-size:10.0pt;font-family:"Courier New"'>].</span></b> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>(It would be even better if there would be an explicit reference to Section 4.2.1.) </span><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>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> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt;font-family:"Courier New"'>* Preferred serialization MUST be used. In particular, this means<br> that arguments (see </span><a href="https://datatracker.ietf.org/doc/html/rfc8949#section-3"><span style='font-size:10.0pt;font-family:"Courier New"'>Section 3</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>) <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><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>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><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>Regards,</span> <span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>Felix </span><br><br><b><i><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:gray'><br>Disclaimer</span></i></b> <i><span style='font-size:7.0pt;font-family:"Arial",sans-serif;color:gray'><br>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 (</span></i><a href="mailto:dpo@esa.int"><i><span style='font-size:7.0pt;font-family:"Arial",sans-serif'>dpo@esa.int</span></i></a><i><span style='font-size:7.0pt;font-family:"Arial",sans-serif;color:gray'>).</span></i><o:p></o:p></p></div></body></html>