rfc9277.original.xml   rfc9277.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.8 (Ruby 3.1.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-cbor-file-magic-12" number="9277" category="std" consensus="true" submissi
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft onType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
-ietf-cbor-file-magic-12" category="std" consensus="true" submissionType="IETF"
tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.3 --> <!-- xml2rfc v2v3 conversion 3.12.3 -->
<front> <front>
<title abbrev="cbor-file-magic">On storing CBOR encoded items on stable stor
age</title> <title abbrev="cbor-file-magic">On Stable Storage for Items in Concise Binar
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-file-magic-12"/> y Object Representation (CBOR)</title>
<seriesInfo name="RFC" value="9277"/>
<author initials="M." surname="Richardson" fullname="Michael Richardson"> <author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization> <organization>Sandelman Software Works</organization>
<address> <address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
</address> </address>
</author> </author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>D-28359 Bremen</city> <city>D-28359 Bremen</city>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2022" month="May" day="05"/> <date year="2022" month="August"/>
<area>Internet</area> <area>art</area>
<workgroup>CBOR Working Group</workgroup> <workgroup>cbor</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>magic number</keyword>
<keyword>file identification</keyword>
<abstract> <abstract>
<t>This document defines a stored ("file") format for CBOR data items that
is friendly to common file type recognition systems such as the Unix file(1) com <t>This document defines a stored ("file") format for Concise Binary
mand.</t> Object Representation (CBOR) data items
that is friendly to common systems that recognize file types, such
as the Unix file(1) command.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/"/>.
</t>
<t>
Discussion of this document takes place on the
cbor Working Group mailing list (<eref target="mailto:cbor@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/cbor/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/cbor-wg/cbor-magic-number"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Since very early in computing, operating systems have sought ways to ma rk which files could be processed by which programs. <t>Since very early in computing, operating systems have sought ways to ma rk which files could be processed by which programs.
In Unix, everything is a stream of bytes; identifying the contents of a stream o f bytes became a heuristic activity.</t> In Unix, everything is a stream of bytes; identifying the contents of a stream o f bytes became a heuristic activity.</t>
<t>For instance, the Unix file(1) command, which has existed since 1973 <x <t>For instance, the Unix file(1) command, which has existed since 1973 <x
ref target="file"/>, has for decades been able to identify many file formats bas ref target="FILE"/>, has been able to identify many file formats based upon the
ed upon the contents of the file.</t> contents of the file for decades.</t>
<t>Many systems (Linux, macOS, Windows) will select the correct applicatio <t>Many systems (Linux, macOS, Windows) will select the correct applicatio
n based upon the file contents, if the system can not determine it by other mean n based upon the file contents if the system cannot determine it by other means.
s. For instance, in classical Mac OS, a resource fork was maintained
For instance, in classical MacOS, a resource fork was maintained
separately from the file data that included file type information; separately from the file data that included file type information;
this way, the OS ideally never needed to know anything about the file this way, the OS ideally never needed to know anything about the file
data contents to determine the media type.</t> data contents to determine the media type.</t>
<t>Many other systems do this by file extensions. <t>Many other systems do this by using file extensions.
Many common web servers derive the media-type information from file extensions.< Many common Web servers derive the media-type information from file extensions.<
/t> /t>
<t>Having a media type associated with the file contents can avoid some <t>Having a media type associated with the file contents can avoid some
of the brittleness of this approach. of the brittleness of this approach.
When files become disconnected from their type information, such as when attempt When files become disconnected from their type information, such as when attempt
ing to do forensics on a damaged system, then being able to identify the type of ing to do forensics on a damaged system, being able to identify the type of info
information that is stored in file can become very important.</t> rmation stored in a file can become very important.</t>
<t>A common way to identify the type of a file from its contents is to <t> A common way to identify the type of a file from its contents is to
place a "magic number" at the start of the file contents <xref target="MAGIC"/>. place a "magic number" at the start of the file contents <xref target="MAGIC"/
It is noted that in the media type registration template <xref target="RFC6838"/ >. In
>, a magic number is asked for, if available, as is a file extension.</t> the media type registration template <xref target="RFC6838"/>, a
<t>A challenge for the file(1) command is often that it can be confused by magic number is asked for, if available, as is a file extension.
the encoding vs. the content. </t>
For instance, an Android "apk" (as used to transfer and store an application) ma
y be identified as a ZIP file. <t>A challenge for the file(1) command is often that it can be confused
Additionally, both OpenOffice and MSOffice files are ZIP files of XML files, and by recognizing the overall encoding but not the content being encoded.
may also be identified as a ZIP file.</t> For instance, an Android APK (as used to transfer and store an application) may
be
identified as a ZIP file. Additionally, both OpenOffice and MSOffice files are Z
IP files
of XML files; the identification may stop at identifying them as ZIP files.
</t>
<t>As CBOR becomes a more and more common encoding for a wide variety of a rtifacts, identifying them as just "CBOR" is probably not sufficient. <t>As CBOR becomes a more and more common encoding for a wide variety of a rtifacts, identifying them as just "CBOR" is probably not sufficient.
This document provides a way to encode a magic number into the beginning of a CB OR format file. This document provides a way to encode a magic number into the beginning of a CB OR format file.
As a CBOR format may use a single CBOR data item or a CBOR sequence of As a CBOR format may use a single CBOR data item or a CBOR sequence of
data items <xref target="RFC8742"/>, data items <xref target="RFC8742"/>,
two possible methods of enveloping data are presented; a CBOR Protocol designer will specify one. two possible methods of enveloping data are presented; a CBOR Protocol designer will specify one.
(A CBOR Protocol is a specification which uses CBOR as its encoding.)</t> (A CBOR Protocol is a specification that uses CBOR as its encoding.)</t>
<t>This document also gives advice to designers of CBOR Protocols on <t>This document also gives advice to designers of CBOR Protocols on
choosing one of these mechanisms for identifying their contents. choosing one of these mechanisms for identifying their contents.
This advice is informative.</t> This advice is informative.</t>
<t>A third method is also proposed by which this CBOR format prepended tag
is used to identify non-CBOR files. <t>A third method is also proposed by which a CBOR format tag is prepended
This third method has been placed in <xref target="headers"/> because it is not to identify non-CBOR files.
Further information on this method appears in <xref target="headers"/> because i
t is not
about identifying media types containing CBOR-encoded data items. about identifying media types containing CBOR-encoded data items.
This includes a simple way to derive a magic number to content-formats This includes a simple way to derive a magic number for
as defined by <xref target="RFC7252"/>, even if not in CBOR form.</t> content-formats as defined in <xref target="RFC7252"/>, even if the file is
not in CBOR form.
</t>
<t>Examples of CBOR Protocols currently under development include Concise <t>Examples of CBOR Protocols currently under development include Concise
Software Identification Tags (CoSWID, <xref target="I-D.ietf-sacm-coswid"/>) and Software Identification Tags <xref target="I-D.ietf-sacm-coswid"/> and
Entity Attestation Tokens (EAT, <xref target="I-D.ietf-rats-eat"/>). Entity Attestation Tokens <xref target="I-D.ietf-rats-eat"/>.
COSE itself <xref target="RFC8152"/> is considered infrastructure. CBOR Object Signing and Encryption (COSE) itself <xref target="RFC8152"/> is con
The encoding of public keys in CBOR as described in <xref target="I-D.ietf-cose- sidered infrastructure.
cbor-encoded-cert"/> as <em>C509</em> would benefit from being an identified CBO The encoding of public keys in CBOR as <em>C509</em> as described in <xref targe
R Protocol.</t> t="I-D.ietf-cose-cbor-encoded-cert"/> would benefit from being an identified CBO
<t>A major inspiration for this document is observing the disarray in cert R Protocol.</t>
ain
ASN.1 based systems where most files are PEM encoded; these are then all identif <!-- [rfced] Text updated as shown below based on your reply. We used "confound
ied by the extension "pem", confusing public keys, private keys, certificate req s" instead of "confuses". Please let us know if any changes are desired.
uests, and S/MIME content.</t>
Maybe:
A major inspiration for this document is observing the disarray in
certain ASN.1 based systems where most files are PEM encoded;
these files are all identified by the
extension "pem", which confounds public keys, private keys,
certificate requests, and S/MIME content.
Maybe confound or commingle?
-->
<t>A major inspiration for this document is observing the disarray in
certain ASN.1-based systems where most files are Privacy-Enhanced Mail (PEM) enc
oded;
these files are all identified by the
extension "pem", which confounds public keys, private keys,
certificate requests, and S/MIME content.</t>
<t>While the envelopes defined in this specification add information to ho w data conforming to CBOR Protocols are stored in files, there is no requirement that either type of envelope be transferred on the wire. <t>While the envelopes defined in this specification add information to ho w data conforming to CBOR Protocols are stored in files, there is no requirement that either type of envelope be transferred on the wire.
However, there are some protocols which may benefit from having such a magic num ber on the wire if they are presently using a different (legacy) encoding scheme . However, there are some protocols that may benefit from having such a magic numb er on the wire if they are presently using a different (legacy) encoding scheme.
The presence of the identifiable magic sequence can be used to signal The presence of the identifiable magic sequence can be used to signal
that a CBOR Protocol is being used as opposed to a legacy scheme.</t> that a CBOR Protocol is being used as opposed to a legacy scheme.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>Byte is a synonym for octet. <t>Byte is a synonym for octet.
The term "byte string" refers to the data item defined in <xref target="STD94"/> .</t> The term "byte string" refers to the data item defined in <xref target="RFC8949" />.</t>
<t>The term "file" is understood to stand in a general way for a stored <t>The term "file" is understood to stand in a general way for a stored
representation that is somewhat detached from the original context of representation that is somewhat detached from the original context of
usage of that representation; its usage in this document encompasses usage of that representation; its usage in this document encompasses
similar units of storage that may have different identification similar units of storage that may have different identification
schemes such as partitions or media blocks.</t> schemes such as partitions or media blocks.</t>
<t>The term "diagnostic notation" refers to the human-readable notation <t>The term "diagnostic notation" refers to the human-readable notation
for CBOR data items defined in <xref section="8" sectionFormat="of" target="STD9 for CBOR data items defined in <xref target="RFC8949" section="8" sectionFormat=
4"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>.</t> "of"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>.</t>
<t>The term CDDL (Concise Data Definition Language) refers to the <t>The term "CDDL" (Concise Data Definition Language) refers to the
language defined in <xref target="RFC8610"/>.</t> language defined in <xref target="RFC8610"/>.</t>
<t>The function TN(ct) is defined in <xref target="ct-tags"/>.</t> <t>The function TN(ct) is defined in <xref target="ct-tags"/>.</t>
</section> </section>
<section anchor="requirements-for-a-magic-number"> <section anchor="requirements-for-a-magic-number">
<name>Requirements for a Magic Number</name> <name>Requirements for a Magic Number</name>
<t>A magic number is ideally a fingerprint that is unique to a specific <t>Ideally, a magic number is a fingerprint that is unique to a specific
CBOR protocol, present in the first few (small multiple of 4) bytes of the file, CBOR Protocol, is present in the first few (small multiple of 4) bytes of the f
which does not change when the contents change, and does not depend upon the len ile and does not change when the contents change, and does not depend upon the l
gth of the file.</t> ength of the file.</t>
<t>Less ideal solutions have a pattern that needs to be matched, but in which some bytes need to be ignored. <t>Less ideal solutions have a pattern that needs to be matched, but in which some bytes need to be ignored.
While the Unix file(1) command can be told to ignore certain bytes, this can lea d to ambiguities.</t> While the Unix file(1) command can be told to ignore certain bytes, this can lea d to ambiguities.</t>
</section> </section>
</section> </section>
<section anchor="protocol"> <section anchor="protocol">
<name>Protocol</name> <name>Protocol</name>
<t>This Section presents two enveloping methods. <t>This section presents two enveloping methods.
Both use CBOR Tags in a way that results in a deterministic first 8 to 12 bytes. Both use CBOR tags in a way that results in a deterministic first 8 to 12 bytes.
Which one is to be used The Protocol designer determines which one to use; see <xref target="advice"/> f
is up to the CBOR Protocol designer to determine; see <xref target="advice"/> fo or
r
some guidance.</t> some guidance.</t>
<section anchor="spectag"> <section anchor="spectag">
<name>The CBOR Protocol Specific Tag</name> <name>The CBOR-Protocol-Specific Tag</name>
<t>In both enveloping methods, <t>In both enveloping methods,
CBOR Protocol designers need to obtain a CBOR tag for each kind of object that t hey might store in files. CBOR Protocol designers need to obtain a CBOR tag for each kind of object that t hey might store in files.
As there are more than 4 billion available 4-byte tags, there should be little i ssue in allocating a few to each available CBOR Protocol.</t> As there are more than 4 billion available 4-byte tags, there should be little i ssue in allocating a few to each available CBOR Protocol.</t>
<t>The IANA policy for 4-byte CBOR Tags is First Come First Served, so a <t>The IANA policy for 4-byte CBOR tags is First Come First Served <xref
ll that is required is a simple interaction (e.g., via web or email) with IANA, target="RFC8126" format="default"/> so only a simple interaction (e.g., via Web
having filled in the small template provided in <xref section="9.2" sectionForma or email) with IANA is required. The interaction includes filling in the small
t="of" target="STD94"/>. template provided in <xref target="RFC8949" section="9.2" sectionFormat="of"/>.
In the template, it is suggested to include a reference to this In the template, a reference to this
specification (RFC XXXX) alongside the Description of specification (RFC 9277) alongside the Description of
semantics. <cref anchor="XXXX">(Note to RFC Editor: Please replace all occurrenc semantics is suggested.</t>
es of "RFC
XXXX" with the RFC number of the present specification and remove
this note.)</cref></t>
<t>Allocation of the CBOR tag needs to be initiated by the designer of t he CBOR <t>Allocation of the CBOR tag needs to be initiated by the designer of t he CBOR
Protocol, who can provide a proposed tag number. Protocol, who can provide a proposed tag number.
In order to be in the four-byte range, and so that there are no In order to be in the 4-byte range, and so that there are no
leading zero bytes in the four-byte encoding of the tag number, the leading zero bytes in the 4-byte encoding of the tag number, the
value needs to be in the range 0x01000000 (decimal value needs to be in the range 0x01000000 (decimal
16777216) to 0xFFFFFFFF (decimal 4294967295) inclusive. 16777216) to 0xFFFFFFFF (decimal 4294967295) inclusive.
It is further suggested to avoid values that have an embedded zero byte in It is further suggested to avoid values that have an embedded zero byte in
the four bytes of their binary representation (such as 0x12003456), as the 4 bytes of their binary representation (such as 0x12003456), as
these may confuse implementations that treat the magic number as a C string.</t> these may confuse implementations that treat the magic number as a C string.</t>
<t>The use of a sequence of four US-ASCII <xref target="RFC20"/> codes w
hich are mnemonic to the <t>The use of a sequence of four ASCII <xref target="RFC0020"/> codes wh
ich are mnemonic to the
protocol is encouraged, but not required (there may be reasons to protocol is encouraged, but not required (there may be reasons to
encode other information into the tag; see <xref target="ct-tags"/> for an examp le). encode other information into the tag; see <xref target="ct-tags"/> for an examp le).
For instance, <xref target="openswan"/> uses "OPSN" which translates to the tag For instance, <xref target="openswan"/> uses "OPSN", which translates to the tag
number 1330664270 registered for it.</t> number 1330664270 registered for it.</t>
<t>For CBOR data items that form a representation that is
described by a CoAP Content-Format Number (<xref section="12.3" sectionFormat="o <t>In <xref target="IANA.CORE-PARAMETERS"/>, the Constrained Application
f" target="RFC7252"/>, Protocol (CoAP) defines the "CoAP Content-Formats" registry to assign Content-F
Registry ormat Numbers (<xref
<xref section="CoAP Content-Formats" relative="#content-formats" sectionFormat=" section="12.3" sectionFormat="of" target="RFC7252"/>) to Content Types in a spec
bare" target="IANA.core-parameters"/> ific Content Coding.
of <xref target="IANA.core-parameters"/>), For CBOR data items that form a representation that is already described by such
a tag number has pro-actively been allocated in <xref target="iana-ct-tags"/> (s a Content-Format
ee <xref target="ct-tags"/> Number, a tag number has proactively been allocated
for details and examples).</t> in <xref target="iana-ct-tags"/> (see <xref target="ct-tags"/> for details and e
xamples).
</t>
</section> </section>
<section anchor="wrapped"> <section anchor="wrapped">
<name>Enveloping Method: CBOR Tag Wrapped</name> <name>Enveloping Method: CBOR Tag Wrapped</name>
<t>The CBOR Tag Wrapped method is appropriate for use with CBOR protocol s that encode a single CBOR data item. <t>The CBOR Tag Wrapped method is appropriate for use with CBOR Protocol s that encode a single CBOR data item.
This data item is enveloped into two nested tags:</t> This data item is enveloped into two nested tags:</t>
<t>The outer tag is a Self-described CBOR tag, 55799, as
described in <xref section="3.4.6" sectionFormat="of" target="STD94"/>.</t> <t>The outer tag is a self-described CBOR tag, 55799, as
described in <xref target="RFC8949" sectionFormat="of" section="3.4.6"/>.</t>
<t>The tag content of the outer tag is a second CBOR tag whose tag numbe r has <t>The tag content of the outer tag is a second CBOR tag whose tag numbe r has
been allocated to describe the specific Protocol involved, as been allocated to describe the specific Protocol involved, as
discussed in <xref target="spectag"/>. discussed in <xref target="spectag"/>.
The tag content of this inner tag is the single CBOR data item.</t> The tag content of this inner tag is the single CBOR data item.</t>
<t>This method wraps the CBOR data item as CBOR tags usually do. <t>This method wraps the CBOR data item as CBOR tags usually do.
Applications that need to send the stored CBOR data item across a Applications that need to send the stored CBOR data item across a
constrained network may wish to remove the two tags if the type is constrained network may wish to remove the two tags if the type is
understood from the protocol context, e.g., from a CoAP Content-Format understood from the protocol context, e.g., from a CoAP Content-Format
Option (<xref section="5.10.3" sectionFormat="of" target="RFC7252"/>). Option (<xref section="5.10.3" sectionFormat="of" target="RFC7252"/>).
A CBOR Protocol specification may therefore pick the specific cases Therefore, a CBOR Protocol specification may pick the specific cases
where the CBOR Tag Wrapped enveloping method is to be used. where the CBOR Tag Wrapped enveloping method is to be used.
For instance, it might specify its use for storing the representation For instance, it might specify its use for storing the representation
in a local file or for Web access, but not within protocol messages that in a local file or for Web access, but not within protocol messages that
already provide the necessary context.</t> already provide the necessary context.</t>
<section anchor="tag-wrap-example"> <section anchor="tag-wrap-example">
<name>Example</name> <name>Example</name>
<t>To construct an example without registering a new tag, we use the <t>To construct an example without registering a new tag, we use
Content-Format number registered in <xref target="RFC8428"/> for the Content-Format ID assigned for <tt>application/senml+cbor</tt> (112) <xref t
<tt>application/senml+cbor</tt> (as per Registry <xref section="Content-Formats" arget="RFC8428"/>
relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/ of the "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETERS"/>).</
> of <xref target="IANA.core-parameters"/>), t>
the number 112.</t>
<t>Using the technique described in <xref target="ct-tags"/>, this tra nslates into the <t>Using the technique described in <xref target="ct-tags"/>, this tra nslates into the
tag TN(112) = 1668546929.</t> tag TN(112) = 1668546929.</t>
<t>With this tag, the SenML-CBOR pack <tt>[{0: "current", 6: 3, 2: 1.5 }]</tt> would be enveloped as (in diagnostic notation):</t> <t>With this tag, the SenML-CBOR pack <tt>[{0: "current", 6: 3, 2: 1.5 }]</tt> would be enveloped as follows (in diagnostic notation):</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
55799(1668546929([{0: "current", 6: 3, 2: 1.5}])) 55799(1668546929([{0: "current", 6: 3, 2: 1.5}]))
]]></sourcecode> ]]></sourcecode>
<t>Or in hex:</t> <t>Or in hex:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
d9 d9f7 # tag(55799) d9 d9f7 # tag(55799)
da 63740171 # tag(1668546929) da 63740171 # tag(1668546929)
81 # array(1) 81 # array(1)
a3 # map(3) a3 # map(3)
00 # unsigned(0) 00 # unsigned(0)
skipping to change at line 211 skipping to change at line 229
81 # array(1) 81 # array(1)
a3 # map(3) a3 # map(3)
00 # unsigned(0) 00 # unsigned(0)
67 # text(7) 67 # text(7)
63757272656e74 # "current" 63757272656e74 # "current"
06 # unsigned(6) 06 # unsigned(6)
03 # unsigned(3) 03 # unsigned(3)
02 # unsigned(2) 02 # unsigned(2)
f9 3e00 # primitive(15872) f9 3e00 # primitive(15872)
]]></sourcecode> ]]></sourcecode>
<t>At the representation level, the unique fingerprint for <tt>applica tion/senml+cbor</tt> is composed of the 8 bytes d9d9f7da63740171 hex, after whic h the unadorned CBOR data (81... for the SenML data) is appended.</t> <t>At the representation level, the unique fingerprint for <tt>applica tion/senml+cbor</tt> is composed of the 8 bytes d9d9f7da63740171 hex, after whic h the unadorned CBOR data (81... for the SenML data) is appended.</t>
</section> </section>
</section> </section>
<section anchor="sequences"> <section anchor="sequences">
<name>Enveloping Method: Labeled CBOR Sequence</name> <name>Enveloping Method: Labeled CBOR Sequence</name>
<t>The Labeled CBOR Sequence method is appropriate for use with CBOR Seq uences as described in <xref target="RFC8742"/>.</t> <t>The Labeled CBOR Sequence method is appropriate for use with CBOR Seq uences as described in <xref target="RFC8742"/>.</t>
<t>This method prepends a newly constructed, separate data item to the <t>This method prepends a newly constructed, separate data item to the
CBOR Sequence, the <em>label</em>.</t> CBOR Sequence, the <em>label</em>.</t>
<t>The label is a nesting of two tags, similar to but distinct from the <t>The label is a nesting of two tags, similar to but distinct from the
CBOR Tag Wrapped methods, with an inner tag content of a constant byte CBOR Tag Wrapped methods, with an inner tag content of a constant byte
string. string.
The total length of the label is 12 bytes.</t> The total length of the label is 12 bytes.</t>
<ol spacing="normal" type="1"><li>The outer tag is the self-described CB OR Sequence tag, 55800.</li> <ol spacing="normal" type="1"><li>The outer tag is the self-described CB OR Sequence tag, 55800.</li>
<li>The inner tag is a CBOR tag, from the First Come First Served spac <li>The inner tag is a CBOR tag from the First Come First Served space
e, that uniquely identifies the CBOR Protocol. that uniquely identifies the CBOR Protocol.
As with CBOR Tag Wrapped, the use of a four-byte tag is encouraged that encodes As with the CBOR Tag Wrapped method, the use of a 4-byte tag that encodes withou
without zero bytes.</li> t zero bytes is encouraged.</li>
<li>The tag content is a three byte CBOR byte string containing <li>The tag content is a 3-byte CBOR byte string containing
0x42_4f_52 ('BOR' in diagnostic notation).</li> 0x42_4f_52 ('BOR' in diagnostic notation).</li>
</ol> </ol>
<t>The outer tag in the label identifies the file as being a CBOR Sequen <t>The outer tag in the label identifies the file as being a CBOR Sequen
ce, and does so with all ce and does so with all
the desirable properties explained in <xref section="3.4.6" sectionFormat="of" t the desirable properties explained in <xref target="RFC8949" section="3.4.6" sec
arget="STD94"/>. tionFormat="of"/>.
Specifically, it does not appear to conflict with any known file types, and it i s not valid Unicode in any Unicode encoding.</t> Specifically, it does not appear to conflict with any known file types, and it i s not valid Unicode in any Unicode encoding.</t>
<t>The inner tag in the label identifies which CBOR Protocol is used, as described above.</t> <t>The inner tag in the label identifies which CBOR Protocol is used, as described above.</t>
<t>The inner tag content is a constant byte string which is represented as <t>The inner tag content is a constant byte string that is represented a s
0x43_42_4f_52, the ASCII characters "CBOR", 0x43_42_4f_52, the ASCII characters "CBOR",
which is the CBOR encoded data item for the three-byte string which is the CBOR-encoded data item for the 3-byte string
0x42_4f_52 ('BOR' in diagnostic notation).</t> 0x42_4f_52 ('BOR' in diagnostic notation).</t>
<t>The actual CBOR Protocol data then follow as the next data item(s) in
the CBOR Sequence, without a need for any further specific tag. <t>The actual CBOR Protocol data then follows as the next data item(s) i
n the CBOR Sequence, without a need for any further specific tag.
The use of a CBOR Sequence allows the application to trivially remove the first item with the two tags.</t> The use of a CBOR Sequence allows the application to trivially remove the first item with the two tags.</t>
<t>Should this file be reviewed by a human (directly in an <t>Should this file be reviewed by a human (directly in an
editor, or in a hexdump display), it will include the ASCII characters "CBOR" pr ominently. editor or in a hexdump display), it will include the ASCII characters "CBOR" pro minently.
This value is also included simply because the inner nested tag needs to tag som ething.</t> This value is also included simply because the inner nested tag needs to tag som ething.</t>
<section anchor="tag-seq-example"> <section anchor="tag-seq-example">
<name>Example</name> <name>Example</name>
<t>To construct an example without registering a new tag, we use the <t>To construct an example without registering a new tag, we use
Content-Format number registered in <xref target="RFC9177"/> for ID 272 as assigned for <tt>application/missing-blocks+cbor-seq</tt> of the "CoAP
<tt>application/missing-blocks+cbor-seq</tt> (as per Registry Content-Formats" registry <xref target="RFC9177"/>.</t>
<xref section="Content-Formats" relative="#content-formats" sectionFormat="bare"
target="IANA.core-parameters"/> of
<xref target="IANA.core-parameters"/>), the number 272.</t>
<t>Using the technique described in <xref target="ct-tags"/>, this tra nslates into the <t>Using the technique described in <xref target="ct-tags"/>, this tra nslates into the
tag TN(272) = 1668547090.</t> tag TN(272) = 1668547090.</t>
<t>This is a somewhat contrived example, as this is not a media type t hat <t>This is a somewhat contrived example, as this is not a media type t hat
is likely to be committed to storage. is likely to be committed to storage.
Nonetheless, with this tag, missing blocks list <tt>0, 8, 15</tt> would be Nonetheless, with this tag, missing blocks list <tt>0, 8, 15</tt> would be
enveloped as (in diagnostic notation):</t> enveloped as (in diagnostic notation):</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
55800(1668547090('BOR')), 55800(1668547090('BOR')),
0, 0,
8, 8,
skipping to change at line 288 skipping to change at line 305
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document provides a way to identify CBOR Protocol objects. <t>This document provides a way to identify CBOR Protocol objects.
Clearly identifying CBOR contents in files may have a variety of impacts.</t> Clearly identifying CBOR contents in files may have a variety of impacts.</t>
<t>The most obvious is that it may allow malware to identify interesting <t>The most obvious is that it may allow malware to identify interesting
stored objects, and then exfiltrate or corrupt them.</t> stored objects, and then exfiltrate or corrupt them.</t>
<t>Protective applications (that check data) cannot rely on the <t>Protective applications (that check data) cannot rely on the
applications they try to protect (that use the data) to make applications they try to protect (that use the data) to make
exactly the same decisions in recognizing file formats. exactly the same decisions in recognizing file formats.
(This is an instance of a check vs. use issue.) (This is an instance of a check versus use issue.)
For example, end-point assessment technologies should not solely rely For example, end-point assessment technologies should not solely rely
on the labeling approaches described in this document to decide on the labeling approaches described in this document to decide
whether to inspect a given file. whether to inspect a given file.
Similarly, depending on operating systems configurations and related Similarly, depending on operating system configurations and related
properties of the execution environment the labeling might influence properties of the execution environment, the labeling might influence
the default application used to process a file in a way that may not the default application used to process a file in a way that may not
be predicted by a protective application.</t> be predicted by a protective application.
</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>These IANA considerations are entirely about CBOR Tags, in the <t>These IANA considerations are entirely about CBOR tags in the
registry <xref section="CBOR Tags" relative="#cbor-tags" sectionFormat="bare" ta "Concise Binary Object Representation (CBOR) Tags" registry <xref target="IANA.C
rget="IANA.cbor-tags"/> of <xref target="IANA.cbor-tags"/>.</t> BOR-TAGS"/>.</t>
<t><xref target="cbor-sequence-tag"/> documents the allocation that was do <t><xref target="cbor-sequence-tag"/> documents the allocation for a
ne for a
CBOR tag to be used in a CBOR sequence to identify the sequence (an CBOR tag to be used in a CBOR sequence to identify the sequence (an
example for using this tag is found in <xref target="openswan"/>). example for using this tag is found in <xref target="openswan"/>). <xref target ="cbor-labeled-non-cbor-data-tag"/> documents the allocation for a CBOR tag to b e used in the CBOR-Labeled Non-CBOR Data Enveloping Method (<xref target="header s"/>, which also shows examples).
<xref target="iana-ct-tags"/> allocates a CBOR tag for each actual or <xref target="iana-ct-tags"/> allocates a CBOR tag for each actual or
potential CoAP Content-Format number (examples are in <xref target="ct-tags"/>). </t> potential CoAP Content-Format number (examples are in <xref target="ct-tags"/>). </t>
<section anchor="cbor-sequence-tag"> <section anchor="cbor-sequence-tag">
<name>Labeled CBOR Sequence Tag</name> <name>Labeled CBOR Sequence Tag</name>
<t>IANA has allocated tag 55800 as the tag for the Labeled CBOR Sequence <t>IANA has allocated tag 55800 for the Labeled CBOR Sequence
Enveloping Method from the CBOR Tags Registry. Enveloping Method from the "CBOR Tags" registry.
IANA is asked to update this tag registration to point to this document.</t> IANA has updated this tag registration to point to this document.</t>
<t>This tag is from the First Come/First Served area.</t> <t>This tag is from the First Come First Served area.</t>
<t>The value has been picked to have properties similar to the 55799 tag <t>The value has been picked to have properties similar to the 55799 tag
(<xref section="3.4.6" sectionFormat="of" target="STD94"/>).</t> (<xref target="RFC8949" sectionFormat="of" section="3.4.6"/>).</t>
<t>The hexadecimal representation of the encoded tag head is: 0xd9_d9_f8 <t>The hexadecimal representation of the encoded tag head is 0xd9_d9_f8.
.</t> </t>
<t>This is not valid UTF-8: the first 0xd9 introduces a three-byte seque <t>This is not valid UTF-8: the first 0xd9 introduces a 3-byte sequence
nce in UTF-8, but the 0xd9 as the second value is not a valid second byte for UT in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.
F-8.</t> </t>
<t>This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian
order) puts this value into the UTF-16 high-half zone, which would signal that t <t>This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian
his a 32-bit Unicode value. However, the following 16-bit big-endian value 0xf8 order) puts this value into the UTF-16 high-half zone, which would signal that t
.. is not a valid second sequence according to <xref target="RFC2781"/>. his is a 32-bit Unicode value. However, the following 16-bit big-endian value 0
On a little-endian system, it would be necessary to examine the fourth byte to d xf8_xx is not a valid second sequence according to <xref target="RFC2781"/>.
etermine if it is valid. That next byte is determined by the subsequent encodin On a little-endian system, it would be necessary to examine the fourth byte to d
g, and <xref section="3.4.6" sectionFormat="of" target="STD94"/> has already det etermine if it is valid. That next byte is determined by the subsequent encodin
ermined that no valid CBOR encodings result in valid UTF-16.</t> g, and <xref target="RFC8949" section="3.4.6" sectionFormat="of"/> has already d
etermined that no valid CBOR encodings result in valid UTF-16.</t>
<dl newline="true"> <dl newline="true">
<dt>Data Item:</dt> <dt>Data Item:</dt>
<dd> <dd>
<t>tagged byte string <t>tagged byte string
<!-- this needs to be updated in the registry -->
</t> </t>
</dd> </dd>
<dt>Semantics:</dt> <dt>Semantics:</dt>
<dd> <dd>
<t>indicates that the file contains CBOR Sequences</t> <t>indicates that the file contains CBOR Sequences</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="cbor-labeled-non-cbor-data-tag"> <section anchor="cbor-labeled-non-cbor-data-tag">
<name>CBOR-Labeled Non-CBOR Data Tag</name> <name>CBOR-Labeled Non-CBOR Data Tag</name>
<t>IANA is requested to allocate tag 55801 as the tag for the CBOR-Label <t>IANA has allocated tag 55801 for the CBOR-Labeled Non-CBOR Data
ed Non-CBOR Data Enveloping Method (<xref target="headers"/>) from the "CBOR Tags" registry.
Enveloping Method (<xref target="headers"/>) from the CBOR Tags Registry. IANA updated this tag registration to point to this document.</t>
IANA is asked to update this tag registration to point to this document.</t> <t>This tag is from the First Come First Served area.</t>
<t>This tag is from the First Come/First Served area.</t> <t>The value has been picked to have properties similar to the 55799 tag
<t>The value has been picked to have properties similar to the 55799 tag (<xref target="RFC8949" section="3.4.6" sectionFormat="of"/>).</t>
(<xref section="3.4.6" sectionFormat="of" target="STD94"/>).</t> <t>The hexadecimal representation of the encoded tag head is 0xd9_d9_f9.
<t>The hexadecimal representation of the encoded tag head is: 0xd9_d9_f9 </t>
.</t> <t>This is not valid UTF-8: the first 0xd9 introduces a 3-byte sequence
<t>This is not valid UTF-8: the first 0xd9 introduces a three-byte seque in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.
nce in UTF-8, but the 0xd9 as the second value is not a valid second byte for UT </t>
F-8.</t> <t>This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian
<t>This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian order) puts this value into the UTF-16 high-half zone, which would signal that t
order) puts this value into the UTF-16 high-half zone, which would signal that t his is a 32-bit Unicode value. However, the following 16-bit big-endian value 0
his a 32-bit Unicode value. However, the following 16-bit big-endian value 0xf9 xf9_xx is not a valid second sequence according to <xref target="RFC2781"/>.
.. is not a valid second sequence according to <xref target="RFC2781"/>. On a little-endian system, it would be necessary to examine the fourth byte to d
On a little-endian system, it would be necessary to examine the fourth byte to d etermine if it is valid. That next byte is determined by the subsequent encodin
etermine if it is valid. That next byte is determined by the subsequent encodin g, and <xref target="RFC8949" sectionFormat="of" section="3.4.6"/> has already d
g, and <xref section="3.4.6" sectionFormat="of" target="STD94"/> has already det etermined that no valid CBOR encodings result in valid UTF-16.</t>
ermined that no valid CBOR encodings result in valid UTF-16.</t>
<dl newline="true"> <dl newline="true">
<dt>Data Item:</dt> <dt>Data Item:</dt>
<dd> <dd>
<t>tagged byte string <t>tagged byte string
<!-- this needs to be updated in the registry -->
</t> </t>
</dd> </dd>
<dt>Semantics:</dt> <dt>Semantics:</dt>
<dd> <dd>
<t>indicates that the file starts with a CBOR-Labeled Non-CBOR Data label.</t> <t>indicates that the file starts with a CBOR-Labeled Non-CBOR Data label.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-ct-tags"> <section anchor="iana-ct-tags">
<name>CBOR Tags for CoAP Content-Format Numbers</name> <name>CBOR Tags for CoAP Content-Format Numbers</name>
<t>IANA is requested to allocate the
tag numbers 1668546817 (0x63740101) to <!-- [IANA] Per the authors, please update the entry for 1668546817-1668612095 o
n <https://www.iana.org/assignments/cbor-tags> as follows:
OLD: 0x63470101
NEW: 0x63740101
-->
<t>IANA allocated the tag numbers 1668546817 (0x63740101) to
1668612095 (0x6374ffff) as follows:</t> 1668612095 (0x6374ffff) as follows:</t>
<dl newline="true"> <dl newline="true">
<dt>Data Item:</dt> <dt>Data Item:</dt>
<dd> <dd>
<t>byte string or any CBOR data item (see <xref target="ct-tags"/> o f RFC XXXX)</t> <t>byte string or any CBOR data item (see <xref target="ct-tags"/>)< /t>
</dd> </dd>
<dt>Semantics:</dt> <dt>Semantics:</dt>
<dd> <dd>
<t>the representation of content-format ct &lt; 65025 is indicated b y <t>the representation of content-format ct &lt; 65025 is indicated b y
tag number <br/> tag number <br/>
TN(ct) = 0x63470101 + (ct / 255) * 256 + ct % 255</t> TN(ct) = 0x63740101 + (ct / 255) * 256 + ct % 255</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>RFC XXXX</t> <t>RFC 9277</t>
</dd> </dd>
</dl> </dl>
<t>The Registry for <xref section="Content-Formats" relative="#content-f ormats" sectionFormat="bare" target="IANA.core-parameters"/> of <xref target="IA NA.core-parameters"/> has been defined in <xref section="12.3" sectionFormat="of " target="RFC7252"/>.</t> <t>The "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETER S"/> is defined in <xref section="12.3" sectionFormat="of" target="RFC7252"/>.</ t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="STD94" to="STD94"/>
<references> <displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="C509-CERT"/>
<displayreference target="I-D.ietf-rats-eat" to="EAT"/>
<displayreference target="I-D.ietf-sacm-coswid" to="CoSWID"/>
<displayreference target="RFC0020" to="RFC20"/>
<displayreference target="RFC8949" to="STD94"/>
<references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="STD94" target="https://www.rfc-editor.org/info/rfc894
9"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8742.
<front> xml"/>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"> <!--[rfced] May we update the citations/reference pointing to STD 94 to instead
<organization/> point to RFC 8949? As there are a number of instances referencing specific sect
</author> ions from RFC 8949, this seems like best practice for in case more RFCs are adde
<author fullname="P. Hoffman" initials="P." surname="Hoffman"> d to STD 94.
<organization/>
</author> [authors] That seems to be about a limitation of the current RFCXML format.
<date month="December" year="2020"/> We do prefer citing STDs if we can.
<abstract> We note that the current text under [STD94] unambiguously specifies one RFC,
<t>The Concise Binary Object Representation (CBOR) is a data forma and the section references therefore work in draft-ietf-cbor-file-magic-12.html
t whose design goals include the possibility of extremely small code size, fairl — what caused these to be lost?
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a [rfced] The links were lost because use of <referencegroup> is recommended, even
s ASN.1 and MessagePack.</t> when there is only 1 RFC associated with a given STD/BCP number. Currently, an
<t>This document obsoletes RFC 7049, providing editorial improveme xref cannot link directly to sections when <referencegroup> is used because it
nts, new details, and errata fixes while keeping full compatibility with the int will not know which RFC to link to.
erchange format of RFC 7049. It does not create a new version of the format.</t
> While it is not recommended, we have updated the reference the reference and lin
</abstract> ks as desired.
</front> -->
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/> <reference anchor='RFC8949' target='https://www.rfc-editor.org/info/std94'>
<seriesInfo name="DOI" value="10.17487/RFC8949"/> <front>
</reference> <title>Concise Binary Object Representation (CBOR)</title>
<reference anchor="RFC8742" target="https://www.rfc-editor.org/info/rfc8 <author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
742"> author>
<front> <author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></
<title>Concise Binary Object Representation (CBOR) Sequences</title> author>
<author fullname="C. Bormann" initials="C." surname="Bormann"> <date year='2020' month='December' />
<organization/> </front>
</author> <seriesInfo name='STD' value='94'/>
<date month="February" year="2020"/> <seriesInfo name='RFC' value='8949'/>
<abstract> <seriesInfo name='DOI' value='10.17487/RFC8949'/>
<t>This document describes the Concise Binary Object Representatio </reference>
n (CBOR) Sequence format and associated media type "application/cbor-seq". A CB
OR Sequence consists of any number of encoded CBOR data items, simply concatenat <reference anchor="C" target="https://www.iso.org/standard/74528.html">
ed in sequence.</t>
<t>Structured syntax suffixes for media types allow other media ty
pes to build on them and make it explicit that they are built on an existing med
ia type as their foundation. This specification defines and registers "+cbor-se
q" as a structured syntax suffix for CBOR Sequences.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8742"/>
<seriesInfo name="DOI" value="10.17487/RFC8742"/>
</reference>
<reference anchor="C" target="https://www.iso.org/standard/74528.html">
<front> <front>
<title>Information technology — Programming languages — C</title> <title>Information technology -- Programming languages -- C</title>
<author> <author>
<organization>International Organization for Standardization</orga nization> <organization>International Organization for Standardization</orga nization>
</author> </author>
<date year="2018" month="June"/> <date year="2018" month="June"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="9899:2018, Fourth Edition"/> <seriesInfo name="ISO/IEC" value="9899:2018, Fourth Edition"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="file" target="https://en.wikipedia.org/wiki/File_%28c
ommand%29"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0020.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2781.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9177.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.
xml"/>
<reference anchor="FILE" target="https://en.wikipedia.org/w/index.php?tit
le=File_(command)&amp;oldid=1096086462">
<front> <front>
<title>file (command)</title> <title>file (command)</title>
<author> <author>
<organization>Wikipedia</organization> <organization>Wikipedia</organization>
</author> </author>
<date year="2021" month="January" day="20"/> <date year="2022" month="July" day="2"/>
</front>
</reference>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title>
<author fullname="H. Birkholz" initials="H." surname="Birkholz">
<organization/>
</author>
<author fullname="C. Vigano" initials="C." surname="Vigano">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<date month="June" year="2019"/>
<abstract>
<t>This document proposes a notational convention to express Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa
l is to provide an easy and unambiguous way to express structures for protocol m
essages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
252">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author fullname="Z. Shelby" initials="Z." surname="Shelby">
<organization/>
</author>
<author fullname="K. Hartke" initials="K." surname="Hartke">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<date month="June" year="2014"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a specialized we
b transfer protocol for use with constrained nodes and constrained (e.g., low-po
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small am
ounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wir
eless Personal Area Networks (6LoWPANs) often have high packet error rates and a
typical throughput of 10s of kbit/s. The protocol is designed for machine- to-
machine (M2M) applications such as smart energy and building automation.</t>
<t>CoAP provides a request/response interaction model between appl
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is d
esigned to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simp
licity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="RFC20" target="https://www.rfc-editor.org/info/rfc20"
>
<front>
<title>ASCII format for network interchange</title>
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
<organization/>
</author>
<date month="October" year="1969"/>
</front> </front>
<seriesInfo name="STD" value="80"/>
<seriesInfo name="RFC" value="20"/>
<seriesInfo name="DOI" value="10.17487/RFC0020"/>
</reference> </reference>
<reference anchor="IANA.core-parameters" target="https://www.iana.org/as
signments/core-parameters"> <reference anchor="IANA.CORE-PARAMETERS" target="https://www.iana.org/as
signments/core-parameters">
<front> <front>
<title>Constrained RESTful Environments (CoRE) Parameters</title> <title>Constrained RESTful Environments (CoRE) Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme
nts/cbor-tags"> <reference anchor="IANA.CBOR-TAGS" target="https://www.iana.org/assignme
nts/cbor-tags">
<front> <front>
<title>Concise Binary Object Representation (CBOR) Tags</title> <title>Concise Binary Object Representation (CBOR) Tags</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front>
</reference>
<reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8
017">
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="
Moriarty">
<organization/>
</author>
<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization/>
</author>
<author fullname="J. Jonsson" initials="J." surname="Jonsson">
<organization/>
</author>
<author fullname="A. Rusch" initials="A." surname="Rusch">
<organization/>
</author>
<date month="November" year="2016"/>
<abstract>
<t>This document provides recommendations for the implementation o
f public-key cryptography based on the RSA algorithm, covering cryptographic pri
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
or representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/>
</reference> </reference>
<reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8
428"> <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
<front>
<title>Sensor Measurement Lists (SenML)</title>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<author fullname="Z. Shelby" initials="Z." surname="Shelby">
<organization/>
</author>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization/>
</author>
<author fullname="A. Keranen" initials="A." surname="Keranen">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This specification defines a format for representing simple sen
sor measurements and device parameters in Sensor Measurement Lists (SenML). Rep
resentations are defined in JavaScript Object Notation (JSON), Concise Binary Ob
ject Representation (CBOR), Extensible Markup Language (XML), and Efficient XML
Interchange (EXI), which share the common SenML data model. A simple sensor, su
ch as a temperature sensor, could use one of these media types in protocols such
as HTTP or the Constrained Application Protocol (CoAP) to transport the measure
ments of the sensor or to be configured.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8428"/>
<seriesInfo name="DOI" value="10.17487/RFC8428"/>
</reference>
<reference anchor="RFC9177" target="https://www.rfc-editor.org/info/rfc9
177">
<front>
<title>Constrained Application Protocol (CoAP) Block-Wise Transfer O
ptions Supporting Robust Transmission</title>
<author fullname="M. Boucadair" initials="M." surname="Boucadair">
<organization/>
</author>
<author fullname="J. Shallow" initials="J." surname="Shallow">
<organization/>
</author>
<date month="March" year="2022"/>
<abstract>
<t>This document specifies alternative Constrained Application Pro
tocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.</t>
<t>These options are similar to, but distinct from, the CoAP Block
1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are
not intended to replace the Block1 and Block2 options but rather have the goal o
f supporting Non-confirmable (NON) messages for large amounts of data with fewer
packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster rec
overy should any of the blocks get lost in transmission.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9177"/>
<seriesInfo name="DOI" value="10.17487/RFC9177"/>
</reference>
<reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6
838">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization/>
</author>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<date month="January" year="2013"/>
<abstract>
<t>This document defines procedures for the specification and regi
stration of media types for use in HTTP, MIME, and other Internet protocols. Th
is memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="13"/>
<seriesInfo name="RFC" value="6838"/>
<seriesInfo name="DOI" value="10.17487/RFC6838"/>
</reference>
<reference anchor="X.690">
<front> <front>
<title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1"/> <seriesInfo name="ISO/IEC" value="8825-1"/>
</reference> </reference>
skipping to change at line 613 skipping to change at line 507
<front> <front>
<title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1"/> <seriesInfo name="ISO/IEC" value="8825-1"/>
</reference> </reference>
<reference anchor="MAGIC" target="https://www.bell-labs.com/usr/dmr/www/ man51.pdf#page=4"> <reference anchor="MAGIC" target="https://www.bell-labs.com/usr/dmr/www/ man51.pdf#page=4">
<front> <front>
<title>archive (library) file format</title> <title>archive (library) file format</title>
<author initials="D." surname="Ritchie" fullname="Dennis Ritchie"> <author>
<organization/> <organization>Bell Labs</organization>
</author> </author>
<date year="1971" month="November" day="03"/> <date year="1971" month="November" day="3"/>
</front> </front>
<refcontent>in Bell Labs, Unix Programmer's Manual, First Edition: Fil e Formats</refcontent> <refcontent>Unix Programmer's Manual, First Edition: File Formats</refc ontent>
</reference> </reference>
<reference anchor="I-D.ietf-sacm-coswid" target="https://www.ietf.org/ar
chive/id/draft-ietf-sacm-coswid-21.txt">
<front>
<title>Concise Software Identification Tags</title>
<author fullname="Henk Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<author fullname="Jessica Fitzgerald-McKay">
<organization>National Security Agency</organization>
</author>
<author fullname="Charles Schmidt">
<organization>The MITRE Corporation</organization>
</author>
<author fullname="David Waltermire">
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date day="7" month="March" year="2022"/>
<abstract>
<t> ISO/IEC 19770-2:2015 Software Identification (SWID) tags pro
vide an
extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles. SWID tag
representations can be too large for devices with network and storage
constraints. This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of
semantics and features as SWID tags, as well as new semantics that
allow CoSWIDs to describe additional types of information, all in a
more memory efficient format.
</t> <!--I-D exists as of 6/28/22-->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sa
</front> cm-coswid.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-sacm-coswid-21"/>
</reference>
<reference anchor="I-D.ietf-rats-eat" target="https://www.ietf.org/archi
ve/id/draft-ietf-rats-eat-12.txt">
<front>
<title>The Entity Attestation Token (EAT)</title>
<author fullname="Laurence Lundblade">
<organization>Security Theory LLC</organization>
</author>
<author fullname="Giridhar Mandyam">
<organization>Qualcomm Technologies Inc.</organization>
</author>
<author fullname="Jeremy O'Donoghue">
<organization>Qualcomm Technologies Inc.</organization>
</author>
<date day="24" month="February" year="2022"/>
<abstract>
<t> An Entity Attestation Token (EAT) provides an attested claim
s set
that describes state and characteristics of an entity, a device like
a phone, IoT device, network equipment or such. This claims set is
used by a relying party, server or service to determine how much it
wishes to trust the entity.
An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with <!--I-D exists as of 6/28/22-->
attestation-oriented claims. To a large degree, all this document <xi:include h
does is extend CWT and JWT. ref="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rats-eat.xml"/>
</t> <!--I-D exists as of 6/28/22-->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-i
</front> etf-cose-cbor-encoded-cert.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-12"/>
</reference>
<reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8
152">
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad">
<organization/>
</author>
<date month="July" year="2017"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format de
signed for small code size and small message size. There is a need for the abil
ity to have basic security services defined for this data format. This document
defines the CBOR Object Signing and Encryption (COSE) protocol. This specificat
ion describes how to create and process signatures, message authentication codes
, and encryption using CBOR for serialization. This specification additionally
describes how to represent cryptographic keys using CBOR.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8152"/>
<seriesInfo name="DOI" value="10.17487/RFC8152"/>
</reference>
<reference anchor="I-D.ietf-cose-cbor-encoded-cert" target="https://www.
ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-03.txt">
<front>
<title>CBOR Encoded X.509 Certificates (C509 Certificates)</title>
<author fullname="John Preuß Mattsson">
<organization>Ericsson AB</organization>
</author>
<author fullname="Göran Selander">
<organization>Ericsson AB</organization>
</author>
<author fullname="Shahid Raza">
<organization>RISE AB</organization>
</author>
<author fullname="Joel Höglund">
<organization>RISE AB</organization>
</author>
<author fullname="Martin Furuhed">
<organization>Nexus Group</organization>
</author>
<date day="10" month="January" year="2022"/>
<abstract>
<t> This document specifies a CBOR encoding of X.509 certificate
s. The
resulting certificates are called C509 Certificates. The CBOR
encoding supports a large subset of RFC 5280 and all certificates
compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA
eUICC, and CA/Browser Forum Baseline Requirements profiles. When
used to re-encode DER encoded X.509 certificates, the CBOR encoding
can in many cases reduce the size of RFC 7925 profiled certificates
with over 50%. The CBOR encoded structure can alternatively be
signed directly ("natively signed"), which does not require re-
encoding for the signature to be verified. The document also
specifies C509 COSE headers, a C509 TLS certificate type, and a C509
file format.
</t> </references>
</abstract>
</front> </references>
<seriesInfo name="Internet-Draft" value="draft-ietf-cose-cbor-encoded-
cert-03"/>
</reference>
<reference anchor="RFC2781" target="https://www.rfc-editor.org/info/rfc2
781">
<front>
<title>UTF-16, an encoding of ISO 10646</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<author fullname="F. Yergeau" initials="F." surname="Yergeau">
<organization/>
</author>
<date month="February" year="2000"/>
<abstract>
<t>This document describes the UTF-16 encoding of Unicode/ISO-1064
6, addresses the issues of serializing UTF-16 as an octet stream for transmissio
n over the Internet, discusses MIME charset naming as described in [CHARSET-REG]
, and contains the registration for three MIME charset parameter values: UTF-16B
E (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides infor
mation for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2781"/>
<seriesInfo name="DOI" value="10.17487/RFC2781"/>
</reference>
</references>
</references>
<section anchor="advice"> <section anchor="advice">
<name>Advice to Protocol Designer</name> <name>Advice to Protocol Designer</name>
<t>This document introduces a choice between wrapping a single CBOR data i tem into a (pair of) identifying CBOR tags, or prepending an identifying encoded CBOR data item (which in turn contains a pair of identifying CBOR tags) to a CB OR Sequence (which might be single data item).</t> <t>This document introduces a choice between wrapping a single CBOR data i tem into a pair of identifying CBOR tags or prepending an identifying encoded CB OR data item (which, in turn, contains a pair of identifying CBOR tags) to a CBO R Sequence (which might be a single data item).</t>
<t>Which should a protocol designer use?</t> <t>Which should a protocol designer use?</t>
<t>In this discussion, one assumes that there is an object stored in a fil e, perhaps specified by a system operator in a configuration file.</t> <t>In this discussion, one assumes that there is an object stored in a fil e, perhaps specified by a system operator in a configuration file.</t>
<t>For example: a private key used in COSE operations, a public key/certif icate in C509 (<xref target="I-D.ietf-cose-cbor-encoded-cert"/>) or CBOR format, a recorded sensor reading stored for later transmission, or a COVID-19 vaccinat ion certificate that needs to be displayed in QR code form.</t> <t>For example: a private key used in COSE operations, a public key/certif icate in C509 <xref target="I-D.ietf-cose-cbor-encoded-cert"/> or CBOR format, a recorded sensor reading stored for later transmission, or a COVID-19 vaccinatio n certificate that needs to be displayed in QR code form.</t>
<t>Both the Labeled CBOR Sequence and the wrapped tag can be trivially rem oved by an application before sending the CBOR content out on the wire.</t> <t>Both the Labeled CBOR Sequence and the wrapped tag can be trivially rem oved by an application before sending the CBOR content out on the wire.</t>
<t>The Labeled CBOR Sequence can be slightly easier to remove as in most c
ases, CBOR parsers will return it as a unit, and then return the actual CBOR ite <t>The Labeled CBOR Sequence can be slightly easier to remove as, in most
m, which could be anything at all, and could include CBOR tags that <em>do</em> cases, CBOR parsers will return it as a unit and then return the actual CBOR ite
need to be sent on wire.</t> m, which could be anything at all and could include CBOR tags that <em>do</em> n
<t>On the other hand, having the Labeled CBOR Sequence in the file require eed to be sent on the wire.</t>
s that all programs that expect to examine that file are able to skip what appea <t>On the other hand, having the Labeled CBOR Sequence in the file require
rs to be a CBOR item with two tags nested around a three-byte byte string. s that all programs that expect to examine that file be able to skip what appear
The three byte entry is not of the format the program would normally have proces s to be a CBOR item with two tags nested around a 3-byte byte string.
sed, so it may be a surprise. The 3-byte entry is not of the format the program would normally have processed,
so it may be a surprise.
On the other hand, CBOR parsers are generally tolerant of tags that appear: many of them will process extra tags, making unknown tags available as meta informat ion. On the other hand, CBOR parsers are generally tolerant of tags that appear: many of them will process extra tags, making unknown tags available as meta informat ion.
A program that is not expecting those tags may just ignore those extra tags.</t> A program that is not expecting those tags may just ignore them.</t>
<t>As an example of where there was a problem with previous security syste ms, "PEM" format certificate files grew to be able to contain multiple certifica tes by simple concatenation. <t>As an example of where there was a problem with previous security syste ms, "PEM" format certificate files grew to be able to contain multiple certifica tes by simple concatenation.
<!-- Note that PKCS1 is not an abbreviation any more in standard usage. --> <!-- Note that PKCS1 is not an abbreviation any more in standard usage. -->
The PKCS1 format <xref target="RFC8017"/> could also contain a private key objec t followed by a one or more certificate objects: but only when in PEM format. The PKCS1 format <xref target="RFC8017"/> could also contain a private key objec t followed by one or more certificate objects, but only when in PEM format.
Annoyingly, when in binary DER format (<xref target="X.690"/>, which like CBOR i s self-delimiting), concatenation of certificates was not compatible with most p rograms as they did not expect to read more than one item in the file.</t> Annoyingly, when in binary DER format (<xref target="X.690"/>, which like CBOR i s self-delimiting), concatenation of certificates was not compatible with most p rograms as they did not expect to read more than one item in the file.</t>
<t>The use of CBOR Tag Wrapped format is easier to retrofit to an existing format with existing and unchangeable stored format for a single CBOR data item . <t>The use of CBOR Tag Wrapped format is easier to retrofit to an existing format with existing and unchangeable stored format for a single CBOR data item .
This new sequence of tags is expected to be trivially ignored by many This new sequence of tags is expected to be trivially ignored by many
existing programs when reading CBOR from files or similar units of storage, even if the program only existing programs when reading CBOR from files or similar units of storage, even if the program only
supports decoding a single data item (and not a CBOR sequence). supports decoding a single data item (and not a CBOR sequence).
But, a naive program might also then transmit the additional tags across the net work. But, a naive program might also then transmit the additional tags across the net work.
Removing the CBOR Tag Wrapped format requires knowledge of the two tags involved . Removing the CBOR Tag Wrapped format requires knowledge of the two tags involved .
Other tags present might be needed.</t> Other tags present might be needed.</t>
<t>For a representation matching a specific media-type that is carried in <t>For a representation matching a specific media-type that is carried in
a CBOR byte string, the byte string head will already have to be a CBOR byte string, the byte string head will already have to be
removed for use as such a representation, so it should be easy to removed for use as such a representation, so it should be easy to
remove the enclosing tag heads as well. remove the enclosing tag heads as well.
This is of particular interest with the pre-defined tags provided by This is of particular interest with the predefined tags provided in
<xref target="ct-tags"/> for media-types with CoAP Content-Format numbers.</t> <xref target="ct-tags"/> for media types with CoAP Content-Format numbers.</t>
<t>Here are some considerations in the form of survey questions:</t> <t>Some considerations in the form of survey questions follow.</t>
<section anchor="is-the-on-wire-format-new"> <section anchor="is-the-on-wire-format-new">
<name>Is the on-wire format new?</name> <name>Is the on-wire format new?</name>
<t>If the on-wire format is new, then it could be specified with the CBO R Tag Wrapped format if the extra eight bytes are not a problem. <t>If the on-wire format is new, then it could be specified with the CBO R Tag Wrapped format if the extra 8 bytes are not a problem.
The stored format is then identical to the on-wire format.</t> The stored format is then identical to the on-wire format.</t>
<t>If the eight bytes are a problem on the wire (and they often are if C BOR is being considered), then the Labeled CBOR Sequence format should be adopte d for the stored format.</t> <t>If the 8 bytes are a problem on the wire (and they often are if CBOR is being considered), then the Labeled CBOR Sequence format should be adopted fo r the stored format.</t>
</section> </section>
<section anchor="can-many-items-be-trivially-concatenated"> <section anchor="can-many-items-be-trivially-concatenated">
<name>Can many items be trivially concatenated?</name> <name>Can many items be trivially concatenated?</name>
<t>If the programs that read the contents of the file already expect to process all of the CBOR data items in the file (not just the first), then the La beled CBOR Sequence format may be easily retrofitted.</t> <t>If the programs that read the contents of the file already expect to process all of the CBOR data items in the file (not just the first), then the La beled CBOR Sequence format may be easily retrofitted.</t>
<t>The program involved may throw errors or warnings on the Labeled CBOR <t>The programs involved may throw errors or warnings on the Labeled CBO
Sequence if they have not yet been updated, but this may not be a problem.</t> R
Sequence if they have not yet been updated, but this may not be a problem.</t>
<t>There are situations where multiple objects may be concatenated into a single file. <t>There are situations where multiple objects may be concatenated into a single file.
If each object is preceded by a Labeled CBOR Sequence label then there may be If each object is preceded by a Labeled CBOR Sequence label, then there may be
multiple such labels in the file.</t> multiple such labels in the file.</t>
<t>A protocol based on CBOR Sequences may specify that Labeled CBOR <t>A protocol based on CBOR Sequences may specify that Labeled CBOR
Sequence labels can occur within a CBOR Sequence, possibly even to Sequence labels can occur within a CBOR Sequence, possibly even to
switch to data items following in the sequence that are of a different type.</t> switch to data items following in the sequence that are of a different type.</t>
<t>If the CBOR Sequence based protocol does not define the semantics for <t>If the CBOR-Sequence-based protocol does not define the semantics for
or at least tolerate embedded labels, care must be taken when or at least tolerate embedded labels, care must be taken when
concatenating Labeled CBOR Sequences to remove the label from all but concatenating Labeled CBOR Sequences to remove the label from all but
the first part.</t> the first part.</t>
<aside> <aside>
<t>As an example from legacy PEM encoded PKIX certificates, many progr <t>As an example from legacy PEM-encoded PKIX certificates, many progr
ams accept a series of PKIX certificates in a single file in order to set up a c ams accept a series of PKIX certificates in a single file in order to set up a c
ertificate chain. ertificate chain.
The file would contain not just the End-Entity (EE) certificate, but also any su The file would contain not just the End-Entity (EE) certificate, but also any su
bordinate certification authorities (CA) needed to validate the EE. bordinate certification authorities (CAs) needed to validate the EE.
This mechanism actually only works for PEM encoded certificates, and not DER enc This mechanism actually only works for PEM-encoded certificates, and not DER-enc
oded certificates. oded certificates.
One of the reasons for this specification is to make sure that CBOR encoded cert One of the reasons for this specification is to make sure that CBOR-encoded cert
ificates do not suffer from this problem.</t> ificates do not suffer from this problem.</t>
<t>As an example of mixing of types, some TLS server programs also can <t>As an example of mixing of types, some TLS server programs also can
accept both their PEM encoded private key, and their PEM encoded certificate in accept both their PEM-encoded private key and their PEM-encoded certificate in
the same file.</t> the same file.</t>
</aside> </aside>
<t>If only one item is ever expected in the file, the use of Labeled CBO <t>If only one item is ever expected in the file, the use of the Labeled
R Sequence may present an implementation hurdle to programs that previously just CBOR Sequence may present an implementation hurdle to programs that previously
read a single data item and used it.</t> just read a single data item and used it.</t>
</section> </section>
<section anchor="are-there-tags-at-the-start"> <section anchor="are-there-tags-at-the-start">
<name>Are there tags at the start?</name> <name>Are there tags at the start?</name>
<t>If the Protocol expects to use other tags at its top-level, then the <t>If the Protocol expects to use other tags at its top level, then the
use of the CBOR Tag Wrapped format may be easy to explain at the same use of the CBOR Tag Wrapped format may be easy to explain at the same
place in the protocol description.</t> place in the protocol description.</t>
</section> </section>
</section> </section>
<section anchor="ct-tags"> <section anchor="ct-tags">
<name>CBOR Tags for CoAP Content Formats</name> <name>CBOR Tags for CoAP Content Formats</name>
<t><xref section="5.10.3" sectionFormat="of" target="RFC7252"/> defines th e concept of a Content-Format, <t><xref section="5.10.3" sectionFormat="of" target="RFC7252"/> defines th e concept of a Content-Format,
which is a short 16-bit unsigned integer that identifies a specific which is a short, 16-bit unsigned integer that identifies a specific
content type (media type plus optionally parameters), optionally content type (media type plus (optionally) parameters), optionally
together with a content encoding.</t> together with a content coding (see <xref target="RFC9110" section="8.4.1" secti
onFormat="of"/>).
</t>
<t>Outside of a transfer protocol that indicates the Content-Format for a representation, it may be necessary to identify the Content-Format of the repres entation when it is stored in a file, in firmware, or when debugging.</t> <t>Outside of a transfer protocol that indicates the Content-Format for a representation, it may be necessary to identify the Content-Format of the repres entation when it is stored in a file, in firmware, or when debugging.</t>
<t>This specification allocates CBOR tag numbers 1668546817 (0x63740101) t o <t>This specification allocates CBOR tag numbers 1668546817 (0x63740101) t o
1668612095 (0x6374FFFF) for the tagging of representations of specific 1668612095 (0x6374FFFF) for the tagging of representations of specific
content formats.</t> content formats.</t>
<t>Using tags from this range, a byte string that is to be interpreted as <t>Using tags from this range, a byte string that is to be interpreted as
a representation of Content-Format number <tt>ct</tt>, with ct &lt; 65025 a representation of Content-Format number <tt>ct</tt>, with ct &lt; 65025
(255*255), can be identified by enclosing it in a tag with tag number (255*255), can be identified by enclosing it in a tag with tag number
<tt>TN(ct)</tt> where:</t> <tt>TN(ct)</tt> where:</t>
<ul empty="true"> <ul empty="true">
<li> <li>
<t>TN(ct) = 0x63470101 + (ct / 255) * 256 + ct % 255.</t> <t>TN(ct) = 0x63740101 + (ct / 255) * 256 + ct % 255.</t>
</li> </li>
</ul> </ul>
<t>(where <tt>+</tt>, <tt>*</tt>, <tt>/</tt> and <tt>%</tt> stand for inte ger addition, <t>(where <tt>+</tt>, <tt>*</tt>, <tt>/</tt> and <tt>%</tt> stand for inte ger addition,
multiplication, division and remainder as in the programming language multiplication, division, and remainder as in the programming language C <xref t
C <xref target="C"/>.)</t> arget="C"/>.)</t>
<aside> <aside>
<t>This formula avoids the use of zero bytes in the representation of <t>This formula avoids the use of zero bytes in the representation of
the tag number.</t> the tag number.</t>
<t>Note that no tag numbers are assigned for Content-Format numbers in <t>Note that no tag numbers are assigned for Content-Format numbers in
the range 65025 <contact fullname="≤"/> ct <contact fullname="≤"/> 65535. the range 65025 <contact fullname="≤"/> ct <contact fullname="≤"/> 65535.
(This range is in the range reserved by <xref section="12.3" sectionFormat="of" (This range is in the range reserved for Experimental Use <xref target="RFC8126"
target="RFC7252"/> for format="default"/> by <xref section="12.3" sectionFormat="of" target="RFC7252"/
experimental use. >.
The overlap of 25 code points between this experimental range with the The overlap of 25 code points between this experimental range with the
range this appendix defines tag numbers for can be used for range this appendix defines tag numbers for can be used for
experiments that want to employ a tag number.)</t> experiments that want to employ a tag number.)</t>
</aside> </aside>
<t>Exceptionally, when used immediately as tag content of one of the tags <t>Exceptionally, when used immediately as tag content of one of the tags
55799, 55800, or 55801, the tag content is as follows:</t> 55799, 55800, or 55801, the tag content is as follows:</t>
<dl> <dl>
<dt>Tag 55799 (<xref target="wrapped"/>):</dt> <dt>Tag 55799 (<xref target="wrapped"/>):</dt>
<dd> <dd>
<t>One of: <t>One of:
</t> </t>
<ol spacing="normal" type="1"><li>The CBOR data item within the repres <ol spacing="normal" type="1"><li>The CBOR data item within the repres
entation (without byte string entation (without byte-string
wrapping). This only works for Content Formats that are represented wrapping). This only works for Content-Formats that are represented
by a single CBOR data item in identity content-coding.</li> by a single CBOR data item in identity content-coding.</li>
<li>The data items in the CBOR sequence within the representation, w ithout byte string <li>The data items in the CBOR sequence within the representation, w ithout byte string
wrapping, but wrapped in a CBOR array. wrapping, but wrapped in a CBOR array.
This works for Content Formats that are represented This works for Content-Formats that are represented
by a CBOR sequence in identity content-coding.</li> by a CBOR sequence in identity content-coding.</li>
</ol> </ol>
</dd> </dd>
<dt>Tags 55800 (<xref target="sequences"/>) or 55801 (<xref target="head ers"/>):</dt> <dt>Tags 55800 (<xref target="sequences"/>) or 55801 (<xref target="head ers"/>):</dt>
<dd> <dd>
<t>the byte string 'BOR', signifying that the representation of the <t>the byte string 'BOR', signifying that the representation of the
given content-format follows in the file, in the way defined for these tags.</t> given content-format follows in the file, in the way defined for these tags.</t>
</dd> </dd>
</dl> </dl>
<section anchor="ct-examples"> <section anchor="ct-examples">
<name>Content-Format Tag Examples</name> <name>Content-Format Tag Examples</name>
<t>Registry <xref section="Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/> of <xref target="IANA.core- parameters"/> defines content formats that can be used as examples:</t> <t>The "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETER S"/> defines content formats that can be used as examples:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>As discussed in <xref target="tag-wrap-example"/>, Content-Format <t>As discussed in <xref target="tag-wrap-example"/>, Content-Format
112 stands for ID 112 represents the application/senml+cbor media type (no parameters).
media type application/senml+cbor (no parameters).
The corresponding tag number is TN(112) = 1668546929. </t> The corresponding tag number is TN(112) = 1668546929. </t>
<t> <t>
So the following CDDL snippet can be used to identify The following CDDL snippet can be used to identify
application/senml+cbor representations: </t> application/senml+cbor representations: </t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
senml-cbor = #6.1668546929(bstr) senml-cbor = #6.1668546929(bstr)
]]></sourcecode> ]]></sourcecode>
<t> <t>
Note that a byte string is used as the type of the tag content, because a Note that a byte string is used as the type of the tag content because a
media type representation in general can be any byte string.</t> media type representation in general can be any byte string.</t>
</li> </li>
<li> <li>
<t>Content-Format 272 stands for media type <t>Content-Format ID 272 represents the
application/missing-blocks+cbor-seq, a CBOR sequence application/missing-blocks+cbor-seq media type, which is a CBOR sequence
<xref target="RFC9177"/>. </t> <xref target="RFC9177"/>. </t>
<t> <t>
The corresponding tag number is TN(272) = 1668547090. </t> The corresponding tag number is TN(272) = 1668547090. </t>
<t> <t>
So the following CDDL snippet can be used to identify The following CDDL snippet can be used to identify
application/missing-blocks+cbor-seq representations as embedded in a application/missing-blocks+cbor-seq representations as embedded in a
CBOR byte string: </t> CBOR byte string: </t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
missing-blocks = #6.1668547090(bstr) missing-blocks = #6.1668547090(bstr)
]]></sourcecode> ]]></sourcecode>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="openswan"> <section anchor="openswan">
<name>Example from Openswan</name> <name>Example from Openswan</name>
<t>The Openswan IPsec project has a daemon ("pluto"), and two control prog <t>The Openswan IPsec project has a daemon ("pluto") and two control progr
rams ("addconn", and "whack"). ams ("addconn" and "whack"). They communicate via a Unix-domain socket, over whi
They communicate via a Unix-domain socket, over which a C-structure containing p ch a C-structure containing pointers to strings is serialized using a bespoke me
ointers to strings is serialized using a bespoke mechanism. chanism.
This is normally not a problem as the structure is compiled by the same compiler This is normally not a problem as the structure is compiled by the same compiler
; but when there are upgrades it is possible for the daemon and the control prog ; but when there are upgrades, it is possible for the daemon and the control pro
rams to get out of sync by the bespoke serialization. grams to get out of sync by the bespoke serialization.
As a result, there are extra compensations to deal with shutting the daemon down . As a result, there are extra compensations to deal with shutting the daemon down .
During testing, it is sometimes the case that upgrades are backed out.</t> During testing, it is sometimes the case that upgrades are backed out.</t>
<t>In addition, when doing unit testing, the easiest way to load policy is to use the <t>In addition, when doing unit testing, the easiest way to load policy is to use the
normal policy reading process, but that is not normally loaded in the daemon. normal policy-reading process, but that is not normally loaded in the daemon.
Instead, the IPC that is normally sent across the wire is compiled/serialized an Instead, the IPC that is normally sent across the wire is compiled, serialized,
d placed in a file. and placed in a file.
The above magic number is included in the file, and also on the IPC in order to The above magic number is included in the file and on the IPC in order to distin
distinguish the "shutdown" command CBOR operation.</t> guish the "shutdown" command CBOR operation.</t>
<t>In order to reduce the problems due to serialization, the serialization <t>In order to reduce the problems due to serialization, the serialization
is being changed to CBOR. is being changed to CBOR. Additionally, this change allows the IPC to be descri
Additionally, this change allows the IPC to be described by CDDL, and for any la bed by CDDL and any implementation language to be used that can encode CBOR.
nguage that encode to CBOR can be used.</t> </t>
<t>IANA has allocated the tag 1330664270, or 0x4f_50_53_4e for this purpos <t>IANA has allocated the tag 1330664270 or 0x4f_50_53_4e for this purpose
e. .
As a result, each file and each IPC is prefixed with a CBOR Tag Sequence.</t> As a result, each file and each IPC is prefixed with a CBOR Sequence tag.</t>
<t>In diagnostic notation:</t> <t>In diagnostic notation:</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
55800(1330664270(h'424F52')) 55800(1330664270(h'424F52'))
]]></sourcecode> ]]></sourcecode>
<t>Or in hex:</t> <t>Or in hex:</t>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
d9 d9f8 # tag(55800) d9 d9f8 # tag(55800)
da 4f50534e # tag(1330664270) da 4f50534e # tag(1330664270)
43 # bytes(3) 43 # bytes(3)
424f52 # "BOR" 424f52 # "BOR"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="headers"> <section anchor="headers">
<name>Using CBOR Labels for non-CBOR data</name> <name>Using CBOR Labels for Non-CBOR Data</name>
<t>The CBOR-Labeled non-CBOR data method is appropriate for adding a magic <t>The CBOR-Labeled Non-CBOR data method is appropriate for adding a magic
number to a number to a
non-CBOR data format, particularly one that can be described by a Non-CBOR data format, particularly one that can be described by a
Content-Format tag (<xref target="ct-tags"/>).</t> Content-Format tag (<xref target="ct-tags"/>).</t>
<t>This method prepends a CBOR data item to the non-CBOR data; this data <t>This method prepends a CBOR data item to the Non-CBOR data; this data
item is called the "header" and, similarly to the Labeled item is called the "header" and, similar to the Labeled
CBOR-Sequence label, consists of two nested tags around a constant CBOR-Sequence label, consists of two nested tags around a constant
byte string for a total of 12 bytes.</t> byte string for a total of 12 bytes.</t>
<ol spacing="normal" type="1"><li>The outer tag is the CBOR-Labeled Non-CB OR Data tag, 55801.</li> <ol spacing="normal" type="1"><li>The outer tag is the CBOR-Labeled Non-CB OR Data tag, 55801.</li>
<li>The inner tag is a CBOR tag, from the First Come First Served space, <li>The inner tag is a CBOR tag from the First Come First Served space t
that uniquely identifies the CBOR Protocol. hat uniquely identifies the CBOR Protocol.
As with CBOR Tag Wrapped, the use of a four-byte tag is encouraged that encodes As with CBOR Tag Wrapped, the use of a 4-byte tag is encouraged that encodes wit
without zero bytes.</li> hout zero bytes.</li>
<li>The tag content is a three byte CBOR byte string containing <li>The tag content is a 3-byte CBOR byte string containing
0x42_4F_52 ('BOR' in diagnostic notation).</li> 0x42_4F_52 ('BOR' in diagnostic notation).</li>
</ol> </ol>
<t>The outer tag in the label identifies the file as being file as being p <t>The outer tag in the label identifies the file as being prefixed by a N
refixed by a non-CBOR on-CBOR
data label, and does so with all data label and does so with all
the desirable properties explained in <xref section="3.4.6" sectionFormat="of" t the desirable properties explained in <xref target="RFC8949" section="3.4.6" sec
arget="STD94"/>. tionFormat="of"/>.
Specifically, it does not appear to conflict with any known file types, and it i s not valid Unicode in any Unicode encoding.</t> Specifically, it does not appear to conflict with any known file types, and it i s not valid Unicode in any Unicode encoding.</t>
<t>The inner tag in the label identifies which non-CBOR Protocol is used.< <t>The inner tag in the label identifies which Non-CBOR Protocol is used.<
/t> /t>
<t>The inner tag content is a constant byte string which is represented as <t>The inner tag content is a constant byte string that is represented as
0x43_42_4f_52, the ASCII characters "CBOR", 0x43_42_4f_52, the ASCII characters "CBOR",
which is the CBOR encoded data item for the three-byte string which is the CBOR-encoded data item for the 3-byte string
0x42_4f_52 ('BOR' in diagnostic notation).</t> 0x42_4f_52 ('BOR' in diagnostic notation).</t>
<t>The actual non-CBOR Protocol data then follow directly appended to the <t>The actual Non-CBOR Protocol data then follow directly appended to the
CBOR representation of the header. CBOR representation of the header.
This allows the application to trivially remove the header item with This allows the application to trivially remove the header item with
the two nested tags and the byte string.</t> the two nested tags and the byte string.</t>
<t>As with the Labeled CBOR Sequence {#sequences}, this choice of the tag <t>As with the Labeled CBOR Sequence {#sequences}, this choice of the tag
content places the ASCII characters "CBOR" prominently into the content places the ASCII characters "CBOR" prominently into the
header.</t> header.</t>
<section anchor="header-ct-examples"> <section anchor="header-ct-examples">
<name>Content-Format Tag Examples</name> <name>Content-Format Tag Examples</name>
<t>Registry <xref section="Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/> of <xref target="IANA.core- parameters"/> defines content formats that can be used as examples:</t> <t>The "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETER S"/> defines content formats that can be used as examples:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Content-Format 432 stands for media type application/td+json (no <t>Content-Format ID 432 represents the application/td+json media ty
parameters). pe (no
The corresponding tag number is TN(432) = 1668547250. </t> parameters).</t>
<t>The corresponding tag number is TN(432) = 1668547250. </t>
<t> <t>
So the following CDDL snippet can be used to identify a CBOR-Labeled non-CBOR da ta for application/td+json representations: </t> The following CDDL snippet can be used to identify a CBOR-Labeled Non-CBOR data for application/td+json representations: </t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
td-json-header = #6.55801(#6.1668547250('BOR')) td-json-header = #6.55801(#6.1668547250('BOR'))
]]></sourcecode> ]]></sourcecode>
</li> </li>
<li> <li>
<t>Content-Format 11050 stands for media type application/json in <t>Content-Format 11050 represents the application/json media type i n
deflate content-coding. </t> deflate content-coding. </t>
<t> <t>
The corresponding tag number is TN(11050) = 1668557910. </t> The corresponding tag number is TN(11050) = 1668557910. </t>
<t> <t>
So the following CDDL snippet can be used to identify a CBOR-Labeled non-CBOR da ta for application/json representations compressed in deflate content-coding: </t> The following CDDL snippet can be used to identify a CBOR-Labeled Non-CBOR data for application/json representations compressed in deflate content-coding: </t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
json-deflate-header = #6.55801(#6.1668557910('BOR')) json-deflate-header = #6.55801(#6.1668557910('BOR'))
]]></sourcecode> ]]></sourcecode>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="changelog"> <section numbered="false" anchor="acknowledgements">
<name>Changelog</name>
</section>
<section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The CBOR WG brainstormed this protocol on January 20, 2021 via a number of productive email exchanges on the mailing list.</t> <t>The CBOR WG brainstormed this protocol on January 20, 2021 via a number of productive email exchanges on the mailing list.</t>
<!-- LocalWords: prepending COVID exfiltrate <!-- LocalWords: prepending COVID exfiltrate
--> -->
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
<name>Contributors</name> <name>Contributors</name>
<contact initials="J. 'Jeff'" surname="Sipek" fullname="Josef 'Jeff' Sipek "> <contact initials="J. 'Jeff'" surname="Sipek" fullname="Josef 'Jeff' Sipek ">
<organization/> <organization/>
<address> <address>
<email>jeffpc@josefsipek.net</email> <email>jeffpc@josefsipek.net</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1925LjRnbgO74ilx0TTUokm2TdqZE8peqSXLPd6nZXjzVh
y6tOAiAJFQjQSKBYVEVN7Kvf/Qn+k/0Tf8meWyYSINnqudiOXU9HzKhIJPJy
zslzP4eDwSC4n6qjICiTMo2n6k2mTJkXSbZQV1+/eafiLMyjOFJJGa+MyvGp
nqUxDdKLONCzWRHDDOEsLwbzJI0HK71IwiDKw0yvYMKo0PNykMTlfNAaMxhP
gkAXsZ6qm6yMiywug81iyut+nxd3uIlvi7xaB3ebeszgJc4YhLqcwi6iIMwz
E2emMlNVFlUcmGq2SoxJ8qzcrmEDN9fvv4F1qnKZF9NgoHhbr5NwqeNUvcP/
FpHJs0CpvIDlb3UWxelKZ+o2n5cb2CBtxsDzeKWTdKpWYfE5Hug3xg4dhtrN
fKULU8aZ+jov4Imb9ndZch8XJin/z7+V6usiXsGQ9/9wA49NWcQxHOZtbsq5
Dpfq6Gh0fDyCJ2FSbqfq5WByfnRyIS/h13mVlQU8+TbGJbbw1XqZZ7B25/Pj
i8HxZDyYjM8Hp0cXk3Gn3naoZ/lvyp+TIewnQLCVRTKrSoSKUnb3v81NPFfP
fxvP58/VbbKO7+Chm+In+Hod/uYnHGTw4RCRFmR41BLOhzPdvn95cTylt76c
qnffXJ1fHF/Qxygx61TDvmkIfIUPz44ngMf4n+HjFb8llHiTzXlaILoyDpdZ
nuaLrfr3//2v6m2RLwq9WiGBpDpbVECJhp5c0QwW2Yr+EfiZemg2nao3xUJn
yc88OSyjbktAJdCBfMfb1SVsYzICUI5OeWe6WCCmlmW5NtMXLzabzTAxOQL0
hZEZXpwdn0zOh8tyldI7Ji6S2CRwGLufm9s3L26ur6bq4vziYorz99U3eVWU
S3UdJbR8kNjDM0zx0jSA08FvVDfMV0AAUa/T2F7H7i/OhpvkDvAUJZo2iZ9e
fAOv/virybm8/KvJRecQ1L63bzcAAvQ1AhIbCQZPx6Mp/3k2OQFkhrle8+fJ
aKq0CZMEPt5cfnc5DPMiHqw14C4GdJip+x45Q6kXRiY6H43Ppmp9F5qxfHE8
OUcyyQiq8MXF+AxGZPFmMEvz8I6/PD0/glEr3HARL+C73w9PL0YNwD0/QFYD
dXn73XDM/A7pqqjSGFjK7ToOk3kS8gv5XH2tDbA3htG1HfwOB6vu19fven1g
AFmewRvpzvMreK4A5OplYkr4vkrMEnirHSazyuCXMPj5DmIGQs7vfzd4v4OU
ySGKw9HqXYwYj4FK8SxTBk6bJs/PJycDBPrry29vmheyo4twCQSpumkyK3Sx
7RFdKoZn5+ANmcVpOkj1zAD6Vy8qU7yIVgU+eQHkdzIerqP5szXc4C+PvQON
L87GgzGc6WgPCJhVvYyzLDHAwUvYVkyPinCqvpIjJcCCYWX1ClbuI/t9cHwj
Lp4b9VpnlU7h6iXAr+3Nmyq8HXAd8UgmCO7jrKKbJywU6PQ3yPqJhyq1SMpl
NRPpt1m8oP+ycMuq1SwugmAwGCjYQVnoEDjl+yXsGGRjBXgoVRTPkwxwrUmc
AiV06V53egJTYk0kDgEoWmRwudRlALPMActZlG5VmStELHIy3DtKPVUArhcZ
HUmZraEXTQWyReMEMYMDh3fHPSWMYMibXSVRlMZB8Ax5ZpFHVcgs6TbJwliB
DNuqWBewLgAY3lxXSMl9la/jQuOfbr2lBloxebVYlmqjtwY3utLFndosQejS
6gZlWRqpWazWRR7GxgAQZlsZsWZ0mWFwk9GO+yrG9cslLpMw3EB/WOG9nG3L
2HyhkggAm8y3OAIPimIOvjE4ZGc4rBsCKcGDZVwVeCdDBWhK7kHuAjSACuCQ
yNjDuH8QbH3Z7RJAGz/AJHAEQ7ACGj5Sj484/umpTwMQoREsGtHioAKQMgWA
sftWKND9ewXjNEKlWiPDap0IP+NY2OxrfM+CvvsqySoA10qHb277wMazKN+Y
ntokcCFMnMZhKXMVBf6t1+vU8rjWcrQVu2ZfJbwoLwQqRaayHAkZ2DmI4xho
FPGXw5gCGLHOAHlNMCLVpBr0M2SQr3l/GugVCKUI6dBAIAApuHBZCf+Lo8DE
KDLKGGhuXuSrelt0K/A+wKxhWqGeWl+BpGb0XwQl3jsgQkbjm1uEt05hwgwp
Cv4/xpcBD3dZvgEWLTQGGlNVuvUCWs/BH0bX58YxJHhocYsPhoPFSpQr2sdM
EBw/wESoqAKQaLhc4008QyaO6iKsUCDLddMP2mdjkOzMF/ytvqcTeLuCy2/y
MNFIoRvgXLv4JYTq+zwBEs5XcSAkNiuSEkQAsCqhOrx7a7ieoK0Og++XcSa3
eYYiJkZFD2bMgLIQI4KypNjBS9/xpA3OoUsA05p4CMI2R2LAA4VkeGhAN7BW
vF0ET0IlkGvMiGpdI9w2LQf79aHF1GIsw02EaeK5ZfPE4ZLVOi+AYkuA5KXD
i94eXEPLncXDJghIC9EECSUAvTdEPtMh4aBYOHTgxHybQGyW/n2uX398JEH8
9ARMkDYO1w0plYm+RXZwjRYJihrRblawbBnDHAOrEyEfApLwNkF81NwhovKC
7re+B1mHAO0jZojNNsmLYbKE+xNnC7qybuMeX8Q3wYCKLcxLATKebV4Jo8f3
nMp1b4Y+h2tzDnj7MosKJM6OXt91VBe2RxMBUuDQmZnDcXBlQi6O9/haD069
xeUFfQm8p/Fs/3DzVnjoZcRKADKGvprB5VVv1nH2Zg76X0wTv76VD0zuaBva
1+lm/P71K/7Qp+G4ok5N/vFlg0vDQp4JEB+ueP8R/yHk5+CEANdwgyMgVg1a
QLklCixgepBeyKSbQnCFK/5UgZbTwXU6iBm4vDPA8ZbYt6nwVAnBvKmhwLD7
JKI9CfWzQ2CHiDLEAbIKoEBQy2BhuhR0LqvMMJBN62sEEmARpTO8BnTWVHgU
HZa+AyuxilGw5vPAU4iAvOEJUHZQbnK1zkG2IDcAE2OZR4SWOLuP03yNu6L3
EG9rEDlwwjj6wk4P2mGZh3kKPNckiwxOxeKSLAAAcQa77162xrIW0jASWB2A
Iwla8RLBTbboG/baaiCRyALYPMwV3SN5kWjhTdABGmsiNwzCZZ4bAnMWC+cw
eGa4lqAUr1jTaNEBcGDLVwTPshz85RmcdL2BxxeRwJAOiXsEagDw+ioaiQIf
mwBWuDIkTDXpaPaCOq4JxtGA38CLIhtpLIeKEilHxDWJST8+LmNQmgrz9ERK
GxJMYvlhwGLaP23NE5kVgyJhXVoD69KqSUg2IUoEYRQEANCQ0LwI4RbNk95N
4ByIqhZoIzo9gQgIE21h5LmgZWTIW/G2wXEcxADW1w8a19qH57AC9Swr4ZZW
AFLUHImOiWhks+oqz8LExIFzVt0IoxFqfA9WNVie+e33Ny/7sKW/uRm8HJI7
zuhwBRs0wEiensguDa7hTeAmlyCIgevy+/kdcH3Vvb5833wdpIwZxLqEd4fB
1Zvba6TyOJ3jILTYxycTQFZC8DeAGxa380KDgAKboipiBLvH/uH862oG/Frd
xVvjwEQwNWGRzCwp1HuA3cfsVhSkDsK4gB3hSz9enYwuflQbMTAywEvJ8llU
hsznyQ3I0w1Y6Z9Y/KyTonYUlY2biyJuhqqaNTdA89FFodk4gq0A3QXsWGC1
2qqCoO8Aqla5KT1R8vb6tfW3fiEXGr8mNQdkkr9dKzqtSFaddbzq9EW24m48
UPbhVib3qAnwJ9wYEwhqDMBTTSkC6/bF65vX17UABt2O9GlCE9FeXFM4qR+o
SjW4n46ipsKVqyWo1FZ1xgei4LWIHY/a1MoMqXhFzNectpqQD7RklSJOSL22
KpjdIUpbqw7gbGLIbBKkuL/NN6jx25lpUdT61m4fzNhYWfCIZsn6NCusTUbg
LSD20dYXMXh9DeviUTKHTeEBumm80OG2V5O/CUFSy53gN0PL2R3mSc3ltZ0w
FK3K8lmUGjoNCEBtwYa2B9E+DYY7kq+Zn8N7WvGO3D6CZ8/Ue7JuyEMWBF+D
ySzybgtMfLuiC5GDkl/yrtEWUh20rNHQhnU6gLM5ijBRDmqh7tHQ4yO5g1HD
9WYhPwjJD+R8QBc5n64kzRKtgQVgpwAbEnk0a0RMPQFIIAZ8S+MHNG/wbzDa
wG7xLBNQMRLQWmAuIvwHVMWDyoCtwfCHd5pzfkECnUfYW+B4AiJ0tQZTKzYB
iBFQpQs4RMIGu4RNeFKkMXKS1GSRNJh3wLioXTdrVPLwiUG1iIUc+T9NA3jw
9SLLyZ0BAoemaqNiWYGOPihAqBJN2WHBPo9TE1kx+YPUOR5HMEe8o370LT4S
z3ATrVcvX75CYUQiS73EJV7i5OyoeiWu/F5zr4F18Tc30l5gXmW8/PvvumHZ
Q5Q3xocleZhpPJD2u5qbGKGf13SxvhPH3eWOmWR9BmgPgeFTAFe1rIgINYEb
yVfJskQGpeUtfcsRrOU2J9fjPN6orlkhh19VaZmg4gEAPO6Jk8qzC/sBc6co
j0nzQSsMTTAynxvOIX7AXN2Njkg3q307aL+BkdN0JL1CK5+OClcmrZjaiEw1
0F+JYRQ+MzpNCEcz5EklXimwmio6HW+TOCsfAgfLWGBQeE+HnnDZ51ezjK3M
U1Yg6TUrVXnaPt89HJkCKRPwV7NkUQFBoW4ZPHPMT5RuS6OCCdj/JvftA7Ea
hsHXaP6hmkkoJC2K2A6phMwSDGBLvrWOIPYhMl7PcTvjCe+UTgsgQXU9sVBD
Noyu3Gptr+UBQ8R3NX0BrB9tetbd4fIB8QYEaTh2hKay8O6d6WwsA0+jHp8h
kcKNeArQvUrW7i4c+sH+HdUIzWeEDhE1qPTjZYoxjnmXABaBuPLZT+xwZHfH
Vq0S9AmzlW5lPVmGtVAmwxfeyNSxmoEZRqqFdUyo4wFJGbzPVpKbpfUkp+Ss
AiibiqaHi5WH7JrWdNnQisX91fO1tT+EHQamwJoEJYrli6zpkYOR2MEVAp//
vEW3HVwDMJbwPlveIKpLJOKTjYsEQ5KaybEbDxfDvroHfo7eP4QgRhx67KfD
rfStBgLQSq32BccmvuFcPWKvt3j1xXDicWtyp5PvSt7qiyllqsUiJv81Xjex
LzQzY1I1SnZgBk2NrwucWP0e/oENkebZApV9mv8lqe1riZwFBo4Ewi00Q/WP
/wvH/1MQyB9T1f0uL2kBnAyDMXkxVW/hUhvUUcV9BifNQzaKQmaMHRhO8R6c
plN7NXEWq50xd7Ost6WtAoWCEMjvOX5E3AQ9bGikXwrdcNzP3U4kcZ/1kfQi
n6oo5e7Wem8Fb50M2CxzYliCKuSq1qymqWnXhKO8iPjuz2InMfKqYDosav5u
cne35PZkeYD8EMnl57jIhQfvzOGbXkQQbn26VcG9TuEKNQ9LA2lxNXoYjUf0
T3UjgCqQYjA+PTs7m4xPe/jC6OEb+ecGqOPJxfHF6dnk4qTHNGbI5cDOzTlG
wdFj7lMi+6NpLxz9EmmUwR0BmxCp3R0SpgzsGRviM4GPoOIV25YqB5JXdKvR
w3gyGh0dn5z20PEZiEdFb63DUtG1Xdk3ZS8YUWIvbkNdIB/flejBwlFwDg5D
1Y4s3unvbgeXt1c3N+gyoIA5sHW0A601QhwxAzrNYAXRitaeVo+IrFCxFAmM
wt7xnC7Thbg/YbuGNp8H4srjIIVvszlvHhCEFTdOfWJlCYDPfote2037+Ag2
WGY2OoOx5AXrvHl7+13HeozQMkOu41RRmDYQqI2Pjkanp8eTs5G4sslrQK6s
UgJy+8Kh5EohTrVP8w9q98EMlber/PItuk3Ic8ORXlH6VLfmmePJ8AjxY104
wTv2rW8DgEXT7YMa7c6UpvfrfSkPT08YVHl83P+s1w+0dwvJEwZ4HlBQEuNf
HDNkxmS5fKIzPajR023hK+CYI0hpNLKBXQjiTI/1hOta6L8moT91Mk59X+j1
GtZ5fLbhv56YkncGeI5CjAuBZozSCFdGoie23FCFBW/OmbzX9Wud0c5qJEpn
Iz8SIgXtLRNOQekjtL28KpFxagkS38bpfFATgeXifXVycnZxQZe95WGyRHA0
PB6eNkQn2zIws9CAZZ2tJU0Mz+ulkOmbuIXZoIVMdvrSNli0W3Wttt+z+zwl
/QK3nJiwooA5bdlqc0/D/Vsk/2ZW75FW2A91BrugFBFvaulXI0Mbdzy0hSsy
jaIc9Lg66GJqS4Gsd7Q+OOBFfp72jGGRg+2hKaUP+ATZblkMOC7uiH1tErPE
eVhiM/MAAqAdSGCaQ4wm8NwGzsx3HFPM/L5irYsG7OULwRvWXjy+cDIcj5gz
SMIT+T/bYYGmlrEimwF4GQY01ToJ75oIDjU6C9gnWO67XjuKedOG2Imxl1bF
ltgFuyv4Qtr0TpLjDYYZkB6P5JhyxA9G4xvfg0aqQ8zOqKULXukkq0G6gqeU
hUfpKTpFz8LW6Ti4VhbjDCiBBfzEfoD/MDsCHgN4HCC5DYRDIbMhHzt7jD2h
Q8ujz99KCVbuM1Tu8WJvWNiimGwxerl+nnSh2zOg1DIxpj54YcMX9OBz9DF/
oIDjGt62okDtiIKg+4lSQH1cChDARCaCJAqC3xmLM0paI1dDi2k5ji9WsSdp
rUAP8PK//64Lc/bUl2p8enp+cnx6MblAVy/rzvgighCXuo2z1684WLPWQLQf
/vFxNFUdCUt0+up0qo76ajJV4+HJ0z99cM52j00DyLqwvT0uqR5w6z/84Q+c
PIXPA+LH3XpX3Y+v1+vh+0HwBmlfLeMHnlBmBMouy20QXajoYn6m9v97hoft
0rq9gJLP1OnR2fFofDbeP7TeXE/yzM53RtrxFAnoju1ATGM72jtwpdfdI28Y
/AOdemdYlZFhEXVHzbGnO6eDvcIF6541x+HQo7OTs8nZ5PTkND47hnEOuM3V
Tz+y+mlrpztn8sa2TzX5yNhJc+z8Qh3FDTA8wzjGKkFVqDs+OT+bEP6BAC7L
PdxMpRgtY0IW35zvtkPGdvCiU9RqxUaZCPhzMSeiCySnSDsyAboDeTxH8W9j
origjvIia8i47vl4OBy6dAm6XPSkJ3oTxU0PKmWv9CxO7YS31oJ4fGaNCSO6
2f5xn6qg2RfMnribpGuLGlSrCBLzNcyB023NsskVItlbnqAXZtRYkBH1WYq7
/0z0LPrAChUqedZSFZHfV9a9jpIQhEFEWbVh6SR+cEBPhVfpxBgCdDqRpy1p
PoHOSkJ6YK04UqyAe6Utz6nbZ+3tC8ZDtaOKktDfo4w6LIlWej4aDYMJT9BQ
2rSnvDq15oATCoS/ZrCC2OMLgEmbNobo6XS14+vSeKTgwU1ukbVfaw+C7Ku2
P3293jgxXTshhsERn8sHOZ2sXBYxe4slG6aOI3khfGQRo4fjyQ8/Hs9/+PFk
orrPYfBzdUDEDHcMgszHWBMYpPNoGyPTqkWfzpVuciGfNA2sw6cgPyLeLAyu
xpgKuk71bthk16JwGeaUdQSqm3PXI+i1zTOYA6MqLdluKU/RS/iV+K1LiUB3
SRKhX50MLFTs4CX70aWiMHQ8EjsAHWZsO8FE1D37TUahZzllkDTnbSC6cbcs
hnkFcpW6zBy0cgDXR4Brh2+mRHaWYOUOWMbojebEJhseSTzi3sn2cAyYCG7g
bSL44wkLlgfDp+2257RUzIrMwbrb2KTrDEOLbh9d07PwbhGavTWaDSf2t2xr
55g1GwCyw6ZjqclN0LTc8NJ+gi9lyyX3CRlsninFUQsCkfOjWl4Lx71lBztp
iER35Ey6T+KNdaxQTFF1owRzijlBXGdBTM7cviILhVKtH6JqtbbVQD2iecq0
si7nj2AYbxgGQTCqLu4BdlLaFCWXCExO9q1LFiodPdbugtqziR8whEJZv3DW
PYYJiNn/CrvEVbjss02ozi1b8ABDugvuc9dQ2e+z+lRDJThsqCjPUAG18i9u
qMCctaFyNroYWdWDvSw2pM/FbCj0BBF9vnM8kHipnyZrSyjS5C7mAooZZ1km
pThiJE4/DL7LM6AKUKiMVRpqE0nALxF4mA2uz4dRX5331fikNoaCP9UYAjWg
W5+c+VEPjMNRPzjvB+OTT7B+nrUyJ+kExypmP7YR6+jcNxzIHoKlG/bQBDSb
hgWEO7L6+vFR/ToJ+Ybafzw5ngM7BVMDL3AAGn3Tkhmd+1+cwxdz/4vxyZ+p
5X/ilTms8gek8p+Lyo+Q+BSV34I86IIy56n9DaJhmsHUz6xtBGApzgyMboxh
X7qsUCdjXtog0+MzCQS3s0oTqd6hfMZwmeMMs7jcoNORvLnMm/Yn3dI9BJNl
rROMY/UayZXO7UdMXbT/ZkodjbOitzV3V4Q0SKKqyKxuZyi9gFbbv1iPUyua
Ik7mYm/XzHk03WI9zmHDXAQWX7p2Wbk4HbDkvwk4KIoAZL8qlSdgtF4bU61s
5Mnlo8FRJaxd56xxnnwfOe8SnaYiqK14lJoZLpSy0hA1u2RR2QxDTsFAb54w
sint2GXvceYWpkZiwqXUXIEgwqz+OuPvhZ/hh4NPRhfow/zlxMmesiEWlhNc
mxNiJDJC963JUUZxZFEOjoSNzLtgPi61133J237z9zcvB+MLkNJhmHD9bSP/
cCeTRNQCPuXfvaMwmE2VpZyM8qCNq8W7LLEK1jwliaSl8DBKsmbhE7tnjRCz
U8ycYQhyvZFL+BFzW5Y1KRJmihVzJuFYrihcmsKxlABK3t++xEd0YVDbIX0I
WDheEFCPKJqISWR9e8jMPi1bWmhCpTF8LVxxXV3QhNnmKc/CT10esfPlE0o+
i/LP/KQdip1jcjuf/A0vzKHDJVXBSXrCYfQkXkGZBCdlMQzs22I/MSAf1pQy
ktM94AIrKSGgYKit9zF3yVqRCsDGkqUiXQNDpLaNE4j6p4u8yiJrdrIV4JkC
YuvXJmmMFfdWmbAJU6y6SWgBdy8yn+rhkdgoUO0qGyktJCltJBY4QoViygBA
98CzQQ94Zkl4JIUlhb8ksuNQxhCYcgUhb3HFhCQ7wHThQgvnXmnqr1BlbEnS
NHVCjCbnjvajwhjksMe0eS0IDEYVo16CXIaOSBUnkrXFj+r1uerFU5xhvy7+
UcRUAUisGjYjGFyjsZFXBmNrVYFp6pJM3Vedt9evOxYdPnfh3OpFwUk/s5pu
ROjUCXfeW1SgJzk6MA6/ygQCv/4fIJU5UwUh8PZ/Xt2OnYaJxZzYDCOxqSVb
zmJKMmWbA3DO6FANBl8RgfEEsnHQ9qninWL/JKvQoLE7bYoBkT1sX1oBQ6Ug
hdQMeVDgwWZKTrI8S7ecLwiTYsY5rw7YzbIcJS56IexzSZl4ee3qO0CKUN04
Ku/MZFCJlttmrHcrJTdttuj1mxBENDcgjXimPEZMmS2pboeQTYzRsQS2n7cg
GyKP5Jib6sjLFaPsOtZfHK9pJl/seATlXOjE8ng0qE6Y+Y0aR8ZVvVJ4hWNp
h+5LZKVVxvmWrjVKPbGkJn8kvo3WoZ8RUkpyGZ/SceBahEkCJSKd2n+4rTiA
bVhAsJxmcW6rRClz+FBecl2o4jM1JJnAVGssiURfjyQN6R1tC+zOLBJzq6EE
gxr2dUXKRKaT+3pm1tuIzkmmiQbBPFW7cjzhThweZk8KBYWHwTuUpg1pvQe3
TtggqwO5tHB59XX0WCLrwImJBdOXNmXMaZdcJiwK2k66CeXACmCsi8ar2bU8
M9RFkZB6E+gdTycbMr5jDOuemIvboCoJFaKJwCoz1o+vbap4a29W8tRJkkDs
KEcCz/8DiEq5pgwVJ1yXbt4mTtOhM7qxSAeT0MMK6YdSGEGg1g4jWHVg064F
iJKROCMvRCOLqIaO9TvvSc1h7wKVNDcqNmxZkSQauOS2gur7QbTeA8eg4hZ8
PqWwyg2TT54NqFhD6AMuIOr/833P+H5KrTHWsFoA1sq9O/tB3sIzs/SLmZgo
lsSpemUt6VjtaDIQdmZaywpj85I31dzp0J2gvUItR/1Cla4oklsp0tVcvGIZ
OfvA69KtnoDgsHon261JDMzhdSnEWbaPxWGuK52xusK5XA0uVwuOOKrR01QT
if2Xy/1NEdyFqcWFVYQok9TL6fTyyXwttYvIITXG+Uc/GQ6i5KFQIauDJUpJ
7OO9x1wt55EkkSLfqLgo8oL49EYXGPQwFnMHFGupOSLGgFvexiVnilVr7KYi
SYFk3eIqOGQW+1SHO7J3KwFbgq+UFKm5mgRWI+zJfPxYf4EIBBa7gDFKsxZd
hYqO4zCOrLqy/zAce7AwdnmLgdsGMTgaZVpi/rK27bnaLs/aQU2czCbFEAX5
mwiam+C6Ako4tukuOzEhqTbestwEfmo22I6GcrlqmmI1jZqWSNa2C/iR4l6I
+76uA5ImEjcejbrN8dlqN0Zd3TG3nShcqjU5wFBYlVgggYRMpgMaNDZ3ls/a
R7mEyDZEG6W+QzcRYCHwFDg4wF6kmVZSFuOQ06rgpgHxBXWAAcUHHO1xqpG1
PAVfqaYlQK9JLZpXEQm68s3vG8pjn1lHrSWGYbwuKfkOGyAhSHfeYaeLR6b4
hcuzNnBvqjV6ZTztGTS7BFT/ryhqSa+wkWcV8waPuM6igRTRdq+ve/5EfAlJ
16FWLdUM1kWXiK+sk+FAvY6ogkV1ry57XncSiuqx2wTWuuZdUSBe6r7FFZBu
Rc/HxnXEgH1INoFoVTZU8veNQOPUKUw2e9iVwjYT3RJp8nOH17QQ8m6E4RrI
iHLXfgAQIAFtaU5AfOmrHeqAfaySB5sJwJFPUgfev7qVpikeRZABhYYZk8ZM
/EdJEx6eYeX8K8lBkLk7jJ2DhPPAPSV41/aHoVZFtQ7vcapGMP1AtobeOu0T
naqNxHO1rIqIzdimNLQWciq2N0nHPVo6WSzkRxQxfOnsbla0va4kteR1rmc+
E2GaDlErzNTmAx+sB7Vbng4eyHE/pibVEpMbTXAA3e0GwC1tVASWviPX1pns
9LC6tc6Cq4a62HaW7/a5cP0KmrFdEYLD4CqVLlhtX3Xd+cV2xXF1ntrv1wFI
1TQTqQNk8OYz9nAkglDxFVEcF/5Kqb7f35vVvzF4LeqVbNBzFMYPsI2SmH5e
UMunak0wRcGPB4spu9z3hRosGkBfyjIO7yRHCe4RlxUQnRNSdTPTF1QQdJIx
XeKsMouNv/I8wiDAatUUJXZ3CStEjNXlpYHZz1Lx5LphDYOui/9lLuVVknZo
t9hFhqo1sP5r2POd6WDeAn9e5xgZogJdw8Xktg0gclzRX4kvgawk3Q3M39zL
jCAbT9ofxa0sqWYtMKV0h4AuTO7le5JTSwFqusWBH+Eht2ySo/clcgEV9Jjs
9FVrhAyMlDChBz4KvPyT3BodcAGIa8TZfVLkmZTPe0dh8zbJ5ikHrDilZa5B
4Wr4x22FuVOinQD1qiJFvwyooxuYd2Fp1b31XkqjGk0qtdu9oFh/Q49aph7e
ArwARIrc+8NV5fWFOwSFl6Nru0uCOLXjbLjbPmpm5NbfoqbyaKOEBJ8BZdk7
HEt+RV0rRmBAv1aE0oDcP4GrA6hztlWtTtbaYKu5lHvQxTwKqx+Rrc8+D45E
U+UUubMpvF6X3/SGwU55iK038JPJ6pJNiSSA0rjOkYslGFY4aJSrrq0lYfOx
EdyX8pL9Ao4rUHfhCtIGEY51L15hBAymkLRNpLFbPmgSBTv5k3W6XF3AabMj
hryoa4SFgm0tapZAuNlYC7sMJXy9G/fdJidYnOxm6L1oZOhh82Ph/5zFUne+
SULZiQ0h2Hvt5Tzi1JS6TAt2DyeZ2WylJaDL1uG1nFeWXYi+Yz1AcIypGj1E
Fz/8iP+bn3v5F16a2ftvBufT2kimN5oBaD/ZygsI0ZvWPI35PW0TJamExqX3
sKOEF5RnNB0SAk1zcGvj06nnVrOr41qwGuZjSCMRZLpazIGeWlelpJDIFmxR
HE+plsA2B0udztXPcNGtN5xtA27CoSRkTLkqR5PBDOS5TcGjOYdK+f1IPDtx
fEqjZ8liILviTYweAAXDA+BwRwN1l2wL4jfcjmdydj5GbvaGSjyoQtrObNvp
YRqW9d3UxRqNEBwXVoISzcmffgPEZC7Zh7QlONl7juw+SJ4ftWOQwa5UFowg
3nTpchL7rWYSbVoW3sCeHW9GDiSLieTZHOQ+4Vp9JDifKsgKpZRlmOHLDnYP
7zwF1JXiBiAyDaZ4DxZx5DtkOQbEhcJe2Fo8La5A1kofjPQEt9YcxykTgDoz
YJtRULf8ozyIpmkdsKMMG1dZVved7aBFWwVWFjgGJu18pHBWOKhjoON9DPTw
1Hu4aNdrxNX7K0/9i/DUi7/y1P9qnnrxV576/yVPJReGxJb0x5goGUNDx2qZ
l1EvpIPF4gYU2IZu/YtcWNJaJaBlq+/Ox2eqO3rgeqLRGA3kAB+djiejixP7
aA7/ekpbXzLGs34Jzn4UUVLI25l47dJ+rmrlZh4tEJe7qZcYzG9kFSuwan+t
Tk9GkxPuKclYodif8quff/gBPkufpi8VnvD4DA+vPlfwnXqhJicnPfUZ/OcU
voJvfoXfBME724oEd2R3ynzY1WQi1v6sdOeDdZm1KNnbEct2DHB1wa0szsOE
ZfvNo0nkiGlfybE0I3CN4yX0Rc5NLgBonNKrh9Do2ChKywRtei15kBbolyB/
U13xUcewA5v/RlHsrpdGvU4rbCFnW+aqGla9vvd9UOYLdn7IPbQTemUob0Aw
YKEwHcL18nUePml3XF/yuH0n53si8n0v2arBfBtGdmsi5+hukPpGwr+J2ZPv
SY6+YoXeOUp7pMFRPKsWC1tks9sm0ZnhdVOZP4UvYHOVXl3SomlJPETzAJzk
0cao86nZrH0iTueGty1mGpzEpjHYfjAlplrHUq2zkxOBGTd7PQcfwvKDJNTX
TCPowi3/DO9+32ZQNnte1ikKSckYoOYKFIB3EAw+MGf5wAFM4JRf/fG8BmDS
5fjnh89hox8+w/978YEE6YdffZBGhNSZRG6QTVfp21CloLqvouSeHJu22xBo
+RG3iKk92Tu/ZxNcAWvBvt+9RqyMSAnxVqWaO+MYP5yw2+1nByGBNQBspyEM
stQ5bVneIEZKIDDCLJhv7cvOsH13uDEQS4DHx8d//5d/e8J0ttL7cHpycnRi
3bg8Pql3S59xw4Uk6R7syEKhTYxFFAmFRlKEASdQ5KD9pXqNg2EfpBuScWFc
AjzRd+NlXtnmcgT80Xa6R63uoea6HnwQJH4HzuamjPUGsmGD/bbyrfJbvCB6
rx+QgbvG48Q+2EW4Im5Lv3ygTbtKte78TBc3kG4m5CkjPkQmX98ZfH4Rnq9H
vCfrEE0eMHdsn5enHopYjvzBGKWknrWlQUhcfA+hdW0plK/nUUGILT7okUKL
OUXNUGVbKLoYuVcayDNxWv2BAgZhHeXWKSlW2igltbW7aR+71TJ7T1fX6B08
HRtgNhW9dvZSU4Ahj6XT/8kHb+71YwcOSOtgFyrguK4Y53x/dg00THur8fmc
n+qP+mSHuZ7iem9NDlMl/T4OBjhaSqJQXjMkKh8wjmCVKxFqklIsynmT+yDp
uv7ZpDxZh/RTEBzu0vGX0QYtO2hJU4aKzxPoh2F4W3CVPsOIdqt5z07nk6d+
+6jj8YSFDud0qMbveuxtY4DpS75OhkT3fik/+mLWuZQ51Fo5EOOB3iBK3eYt
a5pauZosAfIu2z2IrX4F7x3YWks7IQ7DxWtRhL/wRUOpQAW28ux06PUEwd9S
6slwfK0WXU1FReqTnctLukS3uGHfVYjqJkxbJA1osg2H5bBoTzUqBgCzLZxN
znycebO3AHOgKK3fvuTwWrMklFDzCTjdV0b5l8Hpga3vqJ94B2zGETJD/Lm/
Vu7rDhE05/YJgeohm4RQ1+uSAvtGgmDAFVw8jA1F9+TmrYlD1L0oPY1cICAR
sMme6nbAtinzTk/C6BvOwy9yr06l2wGND3/mpsODOpslGHqdHqkg/Fs+VcYZ
I9jWU1OT20GUo/qnDJwoBuJDTcX2+FNXA9ca3//RAlJdpB0yQ8pwqn2R6DT5
OY5ce/EZksCd9zMQQ897JyUpjXxT5xd060oZZJJ6DiVN2bb0ZfEFi7U6PQ/l
U7UGkGD2BFtI7ic4rFkiULX1WTughIOBhcgFVnPsLh7ate2J7GFtJYohYw8d
UH4nd86wxa0Cim1aAjrUsE04anZmWZWl69XPu4ryDcz4smLrhpMpXEdUrAlP
VtbS1kY4jTswror2PSZeVJSDm9WGgBiCOdfZYFa7nZ3cwlhuYEqbb5LmOrLt
ZhOXXINilFFnn9msfonCWz9vXY/jMI0z1t4zPi32FTUlTMF7uHl75b0r73HW
UZ1sz33ta7p44VEeorT+lQ4tuQx4zagRxG4LbVue3xD+OAvlakmWBW7Lz8uL
6p9LpOcdxCPireOaRRMzcfWQjAj3PtjrVRhbUwsJHyQw9+puEFZfnOTeV14u
NFV4RPaXC9o/F8SNqLkdt9d4gSDMhY1+F0rktHxu293BNTn3GyPaX0nwePFw
f4hcpFrdQJMsgNEDNbMYwf+wi4a9kXhHqwJrnVtXiXIAOHcaG0XiJ8IFpe7O
kweb7a7rJC4bqGKQ76lsb5Sl+5Xtbqvd5fPjyfE3J5PnPVvr/QktvT5atH48
PxmdHMGBbdG6W+xPKlq3IobdJHT2V5wijAB1v2hD9sTjM6tGB3WzTOd2bo49
3JUJmQj/fFvrJ2d00JzC1unWVRmSh+iroc0OqO3eExLpamRuHOjv1LKyJHrT
2NEXEr/DAKLNhcTmNkKlHYZOR1GRo7FZT3YqgRNlzAya+dh9zgMykuXf7PxZ
F3Ta9jKBrwyye5B7N8HLXp+mg42aPhItcG2axn9t0/SLbZq++Y9t09T85NgU
WciWLvnXwoSI/tu3cXK3td3K6b9d26ZdSOy0bnLNjGxrjkbzuv0Bf+Zw9ifW
/rgmTPxu7Vxjb22b14ki3TQ/LVc4mBXXaBboNBZqDFIbxi44QGqd+Rje/GZM
decee/pfdtfwyMH/I16b1lmOjw7Y9g3zuIw+/8mgQZnlwBL/eGcMrOIZ7pOT
P8NwbwfAm2oES8g9O/8lT00ZDXDcQAiXjHQSjd3aWod92+5Fzl7fAeh4PDoZ
fQJIaVdJBhMBKulHL3bcnZ/o54L1HHBPzi7G/3nA3QdZsq+K2DoF9x9uB/wE
exn7ERzQ8XZwgEFpsljSfEF9hkJXIc3toTDFgGAWR1925mCiYZJB3QH++2/V
DNt0Y0h0FUtvOBe0hSP+Fn9jHe7yBMwR/Il68YTUv8yxlh8Yv4/5B0/gyrEN
5Uoe8VuKiwFXQHWNUkXUK2xS/T0YeGaq/A5E1G/Gq3gIKFnk/wIAw2p/5oQA
AA==
<!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.
In the html and pdf outputs, the text enclosed in <em> is output in
italics. In the txt output, the text enclosed in <em> appears with an
underscore before and after.
Please review carefully and let us know if the output is acceptable or if any
updates are needed.
--> -->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script did not flag any
terms or phrases.-->
</rfc> </rfc>
 End of changes. 121 change blocks. 
977 lines changed or deleted 454 lines changed or added

This html diff was produced by rfcdiff 1.48.