< draft-ietf-cbor-file-magic-10.txt   draft-ietf-cbor-file-magic-11.txt >
CBOR Working Group M. Richardson CBOR Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: 8 September 2022 Universität Bremen TZI Expires: 6 October 2022 Universität Bremen TZI
7 March 2022 4 April 2022
On storing CBOR encoded items on stable storage On storing CBOR encoded items on stable storage
draft-ietf-cbor-file-magic-10 draft-ietf-cbor-file-magic-11
Abstract Abstract
This document defines an on-disk format for CBOR objects that is This document defines an on-disk format for CBOR data items that is
friendly to common on-disk recognition systems such as the Unix friendly to common on-disk recognition systems such as the Unix
file(1) command. file(1) command.
About This Document About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Status information for this document may be found at Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/. https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 September 2022. This Internet-Draft will expire on 6 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements for a Magic Number . . . . . . . . . . . . . 5 1.2. Requirements for a Magic Number . . . . . . . . . . . . . 5
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The CBOR Protocol Specific Tag . . . . . . . . . . . . . 5 2.1. The CBOR Protocol Specific Tag . . . . . . . . . . . . . 5
2.2. Enveloping Method: CBOR Tag Wrapped . . . . . . . . . . . 6 2.2. Enveloping Method: CBOR Tag Wrapped . . . . . . . . . . . 6
2.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Enveloping Method: Labeled CBOR Sequence . . . . . . . . 7 2.3. Enveloping Method: Labeled CBOR Sequence . . . . . . . . 7
3. Advice to Protocol Developers . . . . . . . . . . . . . . . . 8 3. Advice to Protocol Designer . . . . . . . . . . . . . . . . . 8
3.1. Is the on-wire format new? . . . . . . . . . . . . . . . 9 3.1. Is the on-wire format new? . . . . . . . . . . . . . . . 9
3.2. Can many items be trivially concatenated? . . . . . . . . 9 3.2. Can many items be trivially concatenated? . . . . . . . . 10
3.3. Are there tags at the start? . . . . . . . . . . . . . . 10 3.3. Are there tags at the start? . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Labeled CBOR Sequence Tag . . . . . . . . . . . . . . . . 11 5.1. Labeled CBOR Sequence Tag . . . . . . . . . . . . . . . . 11
5.2. CBOR-Labeled Non-CBOR Data Tag . . . . . . . . . . . . . 11 5.2. CBOR-Labeled Non-CBOR Data Tag . . . . . . . . . . . . . 12
5.3. CBOR Tags for CoAP Content-Format Numbers . . . . . . . . 12 5.3. CBOR Tags for CoAP Content-Format Numbers . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. CBOR Tags for CoAP Content Formats . . . . . . . . . 14 Appendix A. CBOR Tags for CoAP Content Formats . . . . . . . . . 15
A.1. Content-Format Tag Examples . . . . . . . . . . . . . . . 15 A.1. Content-Format Tag Examples . . . . . . . . . . . . . . . 15
Appendix B. Example from Openswan . . . . . . . . . . . . . . . 15 Appendix B. Example from Openswan . . . . . . . . . . . . . . . 16
Appendix C. Using CBOR Labels for non-CBOR data . . . . . . . . 16 Appendix C. Using CBOR Labels for non-CBOR data . . . . . . . . 17
C.1. Content-Format Tag Examples . . . . . . . . . . . . . . . 17 C.1. Content-Format Tag Examples . . . . . . . . . . . . . . . 18
Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 17 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Since very early in computing, operating systems have sought ways to Since very early in computing, operating systems have sought ways to
mark which files could be processed by which programs. In Unix, mark which files could be processed by which programs. In Unix,
everything is a stream of bytes (related to the TCP/IP socket model, everything is a stream of bytes (related to the TCP/IP socket model,
where all network connectivity also is a stream of bytes); where all network connectivity also is a stream of bytes);
skipping to change at page 3, line 26 skipping to change at page 3, line 26
upon the contents of the file. upon the contents of the file.
Many systems (Linux, macOS, Windows) will select the correct Many systems (Linux, macOS, Windows) will select the correct
application based upon the file contents, if the system can not application based upon the file contents, if the system can not
determine it by other means. For instance, in classical MacOS, a determine it by other means. For instance, in classical MacOS, a
resource fork was maintained that includes media type ("MIME type") resource fork was maintained that includes media type ("MIME type")
information and therefore ideally never needs to know anything about information and therefore ideally never needs to know anything about
the file. the file.
But, many other systems do this by file extensions. Many common web But, many other systems do this by file extensions. Many common web
servers derive the MIME-type information from file extensions. servers derive the media-type information from file extensions.
Having a media type associated with the file is a better solution in Having a media type associated with the file is a better solution in
general. When files become disconnected from their type information, general. When files become disconnected from their type information,
such as when attempting to do forensics on a damaged system, then such as when attempting to do forensics on a damaged system, then
being able to identify a file type can become very important. being able to identify a file type can become very important.
It is noted that in the media type registration, that a magic number It is noted that in the media type registration template, a magic
is asked for, if available, as is a file extension. number is asked for, if available, as is a file extension.
A challenge for the file(1) program is often that it can be confused A challenge for the file(1) program is often that it can be confused
by the encoding vs the content. For instance, an Android "apk" used by the encoding vs the content. For instance, an Android "apk" used
to transfer and store an application may be identified as a ZIP file. to transfer and store an application may be identified as a ZIP file.
Additionally, both OpenOffice and MSOffice files are ZIP files of XML Additionally, both OpenOffice and MSOffice files are ZIP files of XML
files, and may also be identified as a ZIP file. files, and may also be identified as a ZIP file.
As CBOR becomes a more and more common encoding for a wide variety of As CBOR becomes a more and more common encoding for a wide variety of
artifacts, identifying them as just "CBOR" is probably not artifacts, identifying them as just "CBOR" is probably not
sufficient. This document provides a way to encode a magic number sufficient. This document provides a way to encode a magic number
into the beginning of a CBOR format file. Two possible methods of into the beginning of a CBOR format file. As a CBOR format may use a
enveloping data are presented: a CBOR Protocol author will specify single CBOR data item or a CBOR sequence of data items [RFC8742], two
one. (A CBOR Protocol is a specification which uses CBOR as its possible methods of enveloping data are presented: a CBOR Protocol
encoding.) designer will specify one. (A CBOR Protocol is a specification which
uses CBOR as its encoding.)
A third method is also proposed by which this CBOR format prepended A third method is also proposed by which this CBOR format prepended
tag is used to identify non-CBOR files. This third method has been tag is used to identify non-CBOR files. This third method has been
placed in an appendix because it is not about identifying media types placed in an appendix because it is not about identifying media types
containing CBOR-encoded data items. containing CBOR-encoded data items.
This document also gives advice to designers of CBOR protocols on 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. This advice is informative.
Examples of CBOR Protocols currently under development include CoSWID Examples of CBOR Protocols currently under development include
[I-D.ietf-sacm-coswid] and EAT [I-D.ietf-rats-eat]. COSE itself Concise Software Identification Tags (CoSWID, [I-D.ietf-sacm-coswid])
[RFC8152] is considered infrastructure, however the encoding of and Entity Attestation Tokens (EAT, [I-D.ietf-rats-eat]). COSE
itself [RFC8152] is considered infrastructure. The encoding of
public keys in CBOR as described in [I-D.ietf-cose-cbor-encoded-cert] public keys in CBOR as described in [I-D.ietf-cose-cbor-encoded-cert]
would be an identified CBOR Protocol as well. as _C509_ would benefit from being an identified CBOR Protocol.
A major inspiration for this document is observing the mess in A major inspiration for this document is observing the disarray in
certain ASN.1 based systems where most files are PEM encoded; these certain ASN.1 based systems where most files are PEM encoded; these
are then all identified by the extension "pem", confusing public are then all identified by the extension "pem", confusing public
keys, private keys, certificate requests, and S/MIME content. keys, private keys, certificate requests, and S/MIME content.
While the envelopes defined in this specification add information to While the envelopes defined in this specification add information to
how data conforming to CBOR Protocols are stored in files, there is how data conforming to CBOR Protocols are stored in files, there is
no requirement that either type of envelope be transferred on the no requirement that either type of envelope be transferred on the
wire. wire.
In addition to the on-disk identification aspects, there are some In addition to the on-disk identification aspects, there are some
skipping to change at page 4, line 45 skipping to change at page 4, line 46
In addition, for convenience, Appendix C defines a simple way to In addition, for convenience, Appendix C defines a simple way to
retroactively add a magic number to content-formats as defined by retroactively add a magic number to content-formats as defined by
[RFC7252], even if not in CBOR form. [RFC7252], even if not in CBOR form.
1.1. Terminology 1.1. Terminology
Byte is a synonym for octet. The term "byte string" refers to the Byte is a synonym for octet. The term "byte string" refers to the
data item defined in [STD94]. data item defined in [STD94].
The term "diagnostic notation" refers to the human-readable notation The term "diagnostic notation" refers to the human-readable notation
for CBOR data items defined in Section 8 of [RFC8949] and Appendix G for CBOR data items defined in Section 8 of [STD94] and Appendix G of
of [RFC8610]. [RFC8610].
The term CDDL (Concise Data Definition Language) refers to the The term CDDL (Concise Data Definition Language) refers to the
language defined in [RFC8610]. language defined in [RFC8610].
1.2. Requirements for a Magic Number 1.2. Requirements for a Magic Number
A magic number is ideally a fingerprint that is unique to a CBOR A magic number is ideally a fingerprint that is unique to a CBOR
protocol, present in the first few (small multiple of 4) bytes of the protocol, present in the first few (small multiple of 4) bytes of the
file, which does not change when the contents change, and does not file, which does not change when the contents change, and does not
depend upon the length of the file. depend upon the length of the file.
Less ideal solutions have a pattern that needs to be matched, but in 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 which some bytes need to be ignored. While the Unix file(1) command
can be told to ignore certain bytes, this can lead to ambiguities. can be told to ignore certain bytes, this can lead to ambiguities.
2. Protocol 2. Protocol
This Section presents two enveloping methods. Which one is to be This Section presents two enveloping methods. Which one is to be
used is up to the CBOR Protocol author to determine. Both use CBOR used is up to the CBOR Protocol designer to determine. Both use CBOR
Tags in a way that results in a deterministic first 8 to 12 bytes. Tags in a way that results in a deterministic first 8 to 12 bytes.
2.1. The CBOR Protocol Specific Tag 2.1. The CBOR Protocol Specific Tag
In both enveloping methods, CBOR Protocol designers need to obtain a In both enveloping methods, CBOR Protocol designers need to obtain a
CBOR tag for each kind of object that they might store on disk. As CBOR tag for each kind of object that they might store on disk. As
there are more than 4 billion available 4-byte tags, there should be there are more than 4 billion available 4-byte tags, there should be
little issue in allocating a few to each available CBOR Protocol. little issue in allocating a few to each available CBOR Protocol.
The IANA policy for 4-byte CBOR Tags is First Come First Served, so The IANA policy for 4-byte CBOR Tags is First Come First Served, so
all that is required is an email to IANA, having filled in the small all that is required is an email to IANA, having filled in the small
template provided in Section 9.2 of [RFC8949]. template provided in Section 9.2 of [STD94]. In the template, it is
suggested to include a reference to this specification (RFC XXXX)
alongside the Description of semantics.
// (Note to RFC Editor: Please replace all occurrences of "RFC XXXX"
// with the RFC number of the present specification and remove this
// note.)
This tag needs to be allocated by the author of the CBOR Protocol. This tag needs to be allocated by the author of the CBOR Protocol.
In order to be in the four-byte range, and so that there are no In order to be in the four-byte range, and so that there are no
leading zeros, the value needs to be in the range 0x01000000 (decimal leading zeros, the value needs to be in the range 0x01000000 (decimal
16777216) to 0xFFFFFFFF (decimal 4294967295). It is further 16777216) to 0xFFFFFFFF (decimal 4294967295). It is further
suggested to avoid values that have an embedded zero byte in the four suggested to avoid values that have an embedded zero byte in the four
bytes of their binary representation (such as 0x12003456). bytes of their binary representation (such as 0x12003456), as these
may confuse implementations that treat the magic number as a C
string.
The use of a sequence of four US-ASCII codes which are mnemonic to The use of a sequence of four US-ASCII codes which are mnemonic to
the protocol is encouraged, but not required. the protocol is encouraged, but not required.
For CBOR data items that form a representation that is described by a For CBOR data items that form a representation that is described by a
CoAP Content-Format Number (Section 12.3 of [RFC7252], Registry CoAP CoAP Content-Format Number (Section 12.3 of [RFC7252], Registry CoAP
Content-Formats of [IANA.core-parameters]), a tag number has already Content-Formats of [IANA.core-parameters]), a tag number has already
been allocated in Section 5.3 (see Appendix A for details and been allocated in Section 5.3 (see Appendix A for details and
examples). examples).
2.2. Enveloping Method: CBOR Tag Wrapped 2.2. Enveloping Method: CBOR Tag Wrapped
The CBOR Tag Wrapped method is appropriate for use with CBOR The CBOR Tag Wrapped method is appropriate for use with CBOR
protocols that encode a single CBOR data item. This data item is protocols that encode a single CBOR data item. This data item is
enveloped into two nested tags: enveloped into two nested tags:
The outer tag is a Self-described CBOR tag, 55799, as described in The outer tag is a Self-described CBOR tag, 55799, as described in
Section 3.4.6 of [RFC8949]. Section 3.4.6 of [STD94].
The tag content of that tag is a second CBOR Tag that has been The tag content of that tag is a second CBOR Tag that has been
allocated to describe the specific Protocol involved, as described allocated to describe the specific Protocol involved, as described
above. above.
This method wraps the CBOR value as tags usually do. Applications This method wraps the CBOR value as tags usually do. Applications
that need to send the CBOR value across a constrained link may wish that need to send the CBOR value across a constrained link may wish
to remove the two tags if the use is implicitly understood. to remove the two tags if the use is implicitly understood.
Whether these two tags should be removed for specific further A CBOR Protocol specification may specify the use of two tags only
processing is a decision made by the CBOR Protocol specification. for specific cases. For instance, it might use them when storing the
representation in a local file or for Web access, but not when using
them in protocol messages that already provide the necessary context.
2.2.1. Example 2.2.1. Example
To construct an example without registering a new tag, we use the To construct an example without registering a new tag, we use the
technique described in Appendix A to translate the Content-Format technique described in Appendix A to translate the Content-Format
number registered for application/senml+cbor, the number 112, into number registered for application/senml+cbor (as per Registry
the tag 1668546560+112 = 1668546672. Content-Formats of [IANA.core-parameters]), the number 112, into the
tag 1668546560+112 = 1668546672.
With this tag, the SenML-CBOR pack [{0: "current", 6: 3, 2: 1.5}] With this tag, the SenML-CBOR pack [{0: "current", 6: 3, 2: 1.5}]
would be enveloped as (in diagnostic notation): would be enveloped as (in diagnostic notation):
55799(1668546672([{0: "current", 6: 3, 2: 1.5}])) 55799(1668546672([{0: "current", 6: 3, 2: 1.5}]))
Or in hex: Or in hex:
d9 d9f7 # tag(55799) d9 d9f7 # tag(55799)
da 63740070 # tag(1668546672) da 63740070 # tag(1668546672)
skipping to change at page 7, line 33 skipping to change at page 7, line 45
2. The inner tag is a CBOR tag, from the First Come First Served 2. The inner tag is a CBOR tag, from the First Come First Served
space, that uniquely identifies the CBOR Protocol. As with CBOR space, that uniquely identifies the CBOR Protocol. As with CBOR
Tag Wrapped, the use of a four-byte tag is encouraged that Tag Wrapped, the use of a four-byte tag is encouraged that
encodes without zero bytes. encodes without zero bytes.
3. The tag content is a three byte CBOR byte string containing 3. The tag content is a three byte CBOR byte string containing
0x42_4F_52 ('BOR' in diagnostic notation). 0x42_4F_52 ('BOR' in diagnostic notation).
The outer tag in the label identifies the file as being a CBOR The outer tag in the label identifies the file as being a CBOR
Sequence, and does so with all the desirable properties explained in Sequence, and does so with all the desirable properties explained in
Section 3.4.6 of [RFC8949]. Specifically, it does not appear to Section 3.4.6 of [STD94]. Specifically, it does not appear to
conflict with any known file types, and it is not valid Unicode in conflict with any known file types, and it is not valid Unicode in
any Unicode encoding. any Unicode encoding.
The inner tag in the label identifies which CBOR Protocol is used, as The inner tag in the label identifies which CBOR Protocol is used, as
described above. described above.
The inner tag content is a constant byte string which is represented The inner tag content is a constant byte string which is represented
as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR
encoded data item for the three-byte string 0x42_4f_52 ('BOR' in encoded data item for the three-byte string 0x42_4f_52 ('BOR' in
diagnostic notation). diagnostic notation).
skipping to change at page 8, line 10 skipping to change at page 8, line 20
The actual CBOR Protocol data then follow as the next data item(s) in 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. The the CBOR Sequence, without a need for any further specific tag. The
use of a CBOR Sequence allows the application to trivially remove the use of a CBOR Sequence allows the application to trivially remove the
first item with the two tags. first item with the two tags.
Should this file be reviewed by a human (directly in an editor, or in Should this file be reviewed by a human (directly in an editor, or in
a hexdump display), it will include the ASCII characters "CBOR" a hexdump display), it will include the ASCII characters "CBOR"
prominently. This value is also included simply because the inner prominently. This value is also included simply because the inner
nested tag needs to tag something. nested tag needs to tag something.
3. Advice to Protocol Developers 3. Advice to Protocol Designer
This document introduces a choice between wrapping a single CBOR data This document introduces a choice between wrapping a single CBOR data
item into a (pair of) identifying CBOR tags, or prepending an item into a (pair of) identifying CBOR tags, or prepending an
identifying encoded CBOR data item (which in turn contains a pair of identifying encoded CBOR data item (which in turn contains a pair of
identifying CBOR tags) to a CBOR Sequence (which might be single data identifying CBOR tags) to a CBOR Sequence (which might be single data
item). item).
Which should a protocol designer use? Which should a protocol designer use?
In this discussion, one assumes that there is an object stored in a In this discussion, one assumes that there is an object stored in a
file, perhaps specified by a system operator in a configuration file. file, perhaps specified by a system operator in a configuration file.
For example: a private key used in COSE operations, a public key/ For example: a private key used in COSE operations, a public key/
certificate in C509 or CBOR format, a recorded sensor reading stored certificate in C509 ([I-D.ietf-cose-cbor-encoded-cert]) or CBOR
for later transmission, or a COVID vaccination certificate that needs format, a recorded sensor reading stored for later transmission, or a
to be displayed in QR code form. COVID vaccination certificate that needs to be displayed in QR code
form.
Both the Labeled CBOR Sequence and the wrapped tag can be trivially Both the Labeled CBOR Sequence and the wrapped tag can be trivially
removed by an application before sending the CBOR content out on the removed by an application before sending the CBOR content out on the
wire. wire.
The Labeled CBOR Sequence can be slightly easier to remove as in most The Labeled CBOR Sequence can be slightly easier to remove as in most
cases, CBOR parsers will return it as a unit, and then return the cases, CBOR parsers will return it as a unit, and then return the
actual CBOR item, which could be anything at all, and could include actual CBOR item, which could be anything at all, and could include
CBOR tags that _do_ need to be sent on wire. CBOR tags that _do_ need to be sent on wire.
On the other hand, having the Labeled CBOR Sequence in the file On the other hand, having the Labeled CBOR Sequence in the file
requires that all programs that expect to examine that file are able requires that all programs that expect to examine that file are able
to skip what appears to be a CBOR item with two tags nested around a to skip what appears to be a CBOR item with two tags nested around a
three-byte byte string. Programs which might not expect the Labeled three-byte byte string. The three byte entry is not of the format
CBOR Sequence, but which would operate without a problem would the program would normally have processed, so it may be a surprise.
include any program that expects to process CBOR Sequences from the
file. 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 information. A program that is not expecting those
tags may just ignore those extra tags.
As an example of where there was a problem with previous security As an example of where there was a problem with previous security
systems, "PEM" format certificate files grew to be able to contain systems, "PEM" format certificate files grew to be able to contain
multiple certificates by simple concatenation. The PKCS1 format multiple certificates by simple concatenation. The PKCS1 format
could also contain a private key object followed by a one or more [RFC8017] could also contain a private key object followed by a one
certificate objects: but only when in PEM format. Annoyingly, when or more certificate objects: but only when in PEM format.
in binary DER format (which like CBOR is self-delimiting), Annoyingly, when in binary DER format ([X.690], which like CBOR is
concatenation of certificates was not compatible with most programs self-delimiting), concatenation of certificates was not compatible
as they did not expect to read more than one item in the file. with most programs as they did not expect to read more than one item
in the file.
The use of CBOR Tag Wrapped format is easier to retrofit to an The use of CBOR Tag Wrapped format is easier to retrofit to an
existing format with existing and unchangeable on-disk format for a existing format with existing and unchangeable on-disk format for a
single CBOR data item. This new sequence of tags is expected to be single CBOR data item. This new sequence of tags is expected to be
trivially ignored by many existing programs when reading CBOR from trivially ignored by many existing programs when reading CBOR from
disk, even if the program only supports decoding a single data item disk, even if the program only supports decoding a single data item
(and not a CBOR sequence). But, a naive program might also then (and not a CBOR sequence). But, a naive program might also then
transmit the additional tags across the network. Removing the CBOR transmit the additional tags across the network. Removing the CBOR
Tag Wrapped format requires knowledge of the two tags involved. Tag Wrapped format requires knowledge of the two tags involved.
Other tags present might be needed. Other tags present might be needed.
skipping to change at page 10, line 31 skipping to change at page 10, line 50
| can accept both their PEM encoded private key, and their PEM | can accept both their PEM encoded private key, and their PEM
| encoded certificate in the same file. | encoded certificate in the same file.
If only one item is ever expected in the file, the use of Labeled If only one item is ever expected in the file, the use of Labeled
CBOR Sequence may present an implementation hurdle to programs that CBOR Sequence may present an implementation hurdle to programs that
previously just read a single data item and used it. previously just read a single data item and used it.
3.3. Are there tags at the start? 3.3. Are there tags at the start?
If the Protocol expects to use other tags values at the top-level, If the Protocol expects to use other tags values at the top-level,
then it may be easier to explain if the Labeled CBOR Sequence format then the use of the tag wrapped format may be easier to explain in
is used. the protocol description.
4. Security Considerations 4. Security Considerations
This document provides a way to identify CBOR Protocol objects. This document provides a way to identify CBOR Protocol objects.
Clearly identifying CBOR contents on disk may have a variety of Clearly identifying CBOR contents on disk may have a variety of
impacts. impacts.
The most obvious is that it may allow malware to identify interesting The most obvious is that it may allow malware to identify interesting
objects on disk, and then exfiltrate or corrupt them. objects on disk, and then exfiltrate or corrupt them.
5. IANA Considerations 5. IANA Considerations
These IANA considerations are entirely about CBOR Tags, in the
registry CBOR Tags of [IANA.cbor-tags].
Section 5.1 documents the allocation that was done for a CBOR tag to Section 5.1 documents the allocation that was done for a CBOR tag to
be used in a CBOR sequence to identify the sequence (an example for be used in a CBOR sequence to identify the sequence (an example for
using this tag is found in Appendix B). Section 5.3 allocates a CBOR using this tag is found in Appendix B). Section 5.3 allocates a CBOR
tag for each actual or potential CoAP Content-Format number (examples tag for each actual or potential CoAP Content-Format number (examples
are in Appendix A). are in Appendix A).
5.1. Labeled CBOR Sequence Tag 5.1. Labeled CBOR Sequence Tag
IANA has allocated tag 55800 as the tag for the Labeled CBOR Sequence IANA has allocated tag 55800 as the tag for the Labeled CBOR Sequence
Enveloping Method. Enveloping Method from the CBOR Tags Registry. IANA is asked to
update this tag registration to point to this document.
This tag is from the First Come/First Served area. This tag is from the First Come/First Served area.
The value has been picked to have properties similar to the 55799 tag The value has been picked to have properties similar to the 55799 tag
(Section 3.4.6 of [RFC8949]). (Section 3.4.6 of [STD94]).
The hexadecimal representation of the encoded tag head is: The hexadecimal representation of the encoded tag head is:
0xd9_d9_f8. 0xd9_d9_f8.
This is not valid UTF-8: the first 0xd9 introduces a three-byte This is not valid UTF-8: the first 0xd9 introduces a three-byte
sequence in UTF-8, but the 0xd9 as the second value is not a valid sequence in UTF-8, but the 0xd9 as the second value is not a valid
second byte for UTF-8. second byte for UTF-8.
This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian 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 order) puts this value into the UTF-16 high-half zone, which would
signal that this a 32-bit Unicode value. However, the following signal that this a 32-bit Unicode value. However, the following
16-bit big-endian value 0xf8.. is not a valid second sequence 16-bit big-endian value 0xf8.. is not a valid second sequence
according to [RFC2781]. On a little-endian system, it would be according to [RFC2781]. On a little-endian system, it would be
necessary to examine the fourth byte to determine if it is valid. necessary to examine the fourth byte to determine if it is valid.
That next byte is determined by the subsequent encoding, and That next byte is determined by the subsequent encoding, and
Section 3.4.6 of [RFC8949] has already determined that no valid CBOR Section 3.4.6 of [STD94] has already determined that no valid CBOR
encodings result in valid UTF-16. encodings result in valid UTF-16.
Data Item: Data Item:
tagged byte string tagged byte string
Semantics: Semantics:
indicates that the file contains CBOR Sequences indicates that the file contains CBOR Sequences
5.2. CBOR-Labeled Non-CBOR Data Tag 5.2. CBOR-Labeled Non-CBOR Data Tag
IANA is requested to allocate tag 55801 as the tag for the CBOR- IANA is requested to allocate tag 55801 as the tag for the CBOR-
Labeled Non-CBOR Data Enveloping Method (Appendix C). Labeled Non-CBOR Data Enveloping Method (Appendix C) from the CBOR
Tags Registry. IANA is asked to update this tag registration to
point to this document.
This tag is from the First Come/First Served area. This tag is from the First Come/First Served area.
The value has been picked to have properties similar to the 55799 tag The value has been picked to have properties similar to the 55799 tag
(Section 3.4.6 of [RFC8949]). (Section 3.4.6 of [STD94]).
The hexadecimal representation of the encoded tag head is: The hexadecimal representation of the encoded tag head is:
0xd9_d9_f9. 0xd9_d9_f9.
This is not valid UTF-8: the first 0xd9 introduces a three-byte This is not valid UTF-8: the first 0xd9 introduces a three-byte
sequence in UTF-8, but the 0xd9 as the second value is not a valid sequence in UTF-8, but the 0xd9 as the second value is not a valid
second byte for UTF-8. second byte for UTF-8.
This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian 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 order) puts this value into the UTF-16 high-half zone, which would
signal that this a 32-bit Unicode value. However, the following signal that this a 32-bit Unicode value. However, the following
16-bit big-endian value 0xf9.. is not a valid second sequence 16-bit big-endian value 0xf9.. is not a valid second sequence
according to [RFC2781]. On a little-endian system, it would be according to [RFC2781]. On a little-endian system, it would be
necessary to examine the fourth byte to determine if it is valid. necessary to examine the fourth byte to determine if it is valid.
That next byte is determined by the subsequent encoding, and That next byte is determined by the subsequent encoding, and
Section 3.4.6 of [RFC8949] has already determined that no valid CBOR Section 3.4.6 of [STD94] has already determined that no valid CBOR
encodings result in valid UTF-16. encodings result in valid UTF-16.
Data Item: Data Item:
tagged byte string tagged byte string
Semantics: Semantics:
indicates that the file starts with a CBOR-Labeled Non-CBOR Data indicates that the file starts with a CBOR-Labeled Non-CBOR Data
label. label.
5.3. CBOR Tags for CoAP Content-Format Numbers 5.3. CBOR Tags for CoAP Content-Format Numbers
skipping to change at page 12, line 32 skipping to change at page 13, line 4
Semantics: Semantics:
indicates that the file starts with a CBOR-Labeled Non-CBOR Data indicates that the file starts with a CBOR-Labeled Non-CBOR Data
label. label.
5.3. CBOR Tags for CoAP Content-Format Numbers 5.3. CBOR Tags for CoAP Content-Format Numbers
IANA is requested to allocate the tag numbers 1668546560 (0x63740000) IANA is requested to allocate the tag numbers 1668546560 (0x63740000)
to 1668612095 (0x6374FFFF) as follows: to 1668612095 (0x6374FFFF) as follows:
Data Item: Data Item:
byte string byte string
Semantics: Semantics:
for each tag number NNNNNNNN, the representation of content-format for each tag number NNNNNNNN, the representation of content-format
(RFC7252) NNNNNNNN-1668546560 NNNNNNNN-1668546560
Reference: Reference:
RFCthis RFCthis
The Registry for Content-Formats of [IANA.core-parameters] has been
defined in Section 12.3 of [RFC7252].
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object [STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020. Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/std94> <https://www.rfc-editor.org/info/rfc8949>.
6.2. Informative References 6.2. Informative References
[file] Wikipedia, "file (command)", 20 January 2021, [file] Wikipedia, "file (command)", 20 January 2021,
<https://en.wikipedia.org/wiki/File_%28command%29>. <https://en.wikipedia.org/wiki/File_%28command%29>.
[I-D.ietf-core-new-block]
Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", Work in Progress, Internet-Draft,
draft-ietf-core-new-block-14, 26 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-core-new-
block-14.txt>.
[I-D.ietf-cose-cbor-encoded-cert] [I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509 M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft- Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-03, 10 January 2022, ietf-cose-cbor-encoded-cert-03, 10 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-cose-cbor- <https://www.ietf.org/archive/id/draft-ietf-cose-cbor-
encoded-cert-03.txt>. encoded-cert-03.txt>.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
skipping to change at page 13, line 40 skipping to change at page 14, line 8
<https://www.ietf.org/archive/id/draft-ietf-rats-eat- <https://www.ietf.org/archive/id/draft-ietf-rats-eat-
12.txt>. 12.txt>.
[I-D.ietf-sacm-coswid] [I-D.ietf-sacm-coswid]
Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags", Work Waltermire, "Concise Software Identification Tags", Work
in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7 in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7
March 2022, <https://www.ietf.org/archive/id/draft-ietf- March 2022, <https://www.ietf.org/archive/id/draft-ietf-
sacm-coswid-21.txt>. sacm-coswid-21.txt>.
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.
[IANA.core-parameters] [IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE) IANA, "Constrained RESTful Environments (CoRE)
Parameters", Parameters",
<https://www.iana.org/assignments/core-parameters>. <https://www.iana.org/assignments/core-parameters>.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000,
<https://www.rfc-editor.org/info/rfc2781>. <https://www.rfc-editor.org/info/rfc2781>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
March 2022, <https://www.rfc-editor.org/info/rfc9177>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1,
February 2021.
Appendix A. CBOR Tags for CoAP Content Formats Appendix A. CBOR Tags for CoAP Content Formats
Section 5.10.3 of [RFC7252] defines the concept of a Content-Format, Section 5.10.3 of [RFC7252] defines the 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. together with a content encoding.
Outside of a transfer protocol that indicates the Content-Format for Outside of a transfer protocol that indicates the Content-Format for
a representation, it may be necessary to identify the Content-Format a representation, it may be necessary to identify the Content-Format
of the representation when it is on disk, in firmware, or when of the representation when it is on disk, in firmware, or when
skipping to change at page 15, line 24 skipping to change at page 16, line 12
So the following CDDL snippet can be used to identify application/ So the following CDDL snippet can be used to identify application/
senml+cbor representations: senml+cbor representations:
senml-cbor = #6.1668546672(bstr) senml-cbor = #6.1668546672(bstr)
Note that a byte string is used as the type of the tag content, 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 because a media type representation in general can be any byte
string. string.
* Content-Format 272 stands for media type application/missing- * Content-Format 272 stands for media type application/missing-
blocks+cbor-seq, a CBOR sequence [I-D.ietf-core-new-block]. blocks+cbor-seq, a CBOR sequence [RFC9177].
The corresponding tag number is 1668546832 (i.e., 1668546560+272). The corresponding tag number is 1668546832 (i.e., 1668546560+272).
So the following CDDL snippet can be used to identify application/ So the following CDDL snippet can be used to identify application/
missing-blocks+cbor-seq representations as embedded in a CBOR byte missing-blocks+cbor-seq representations as embedded in a CBOR byte
string: string:
missing-blocks = #6.1668546832(bstr) missing-blocks = #6.1668546832(bstr)
Appendix B. Example from Openswan Appendix B. Example from Openswan
skipping to change at page 16, line 48 skipping to change at page 17, line 37
2. The inner tag is a CBOR tag, from the First Come First Served 2. The inner tag is a CBOR tag, from the First Come First Served
space, that uniquely identifies the CBOR Protocol. As with CBOR space, that uniquely identifies the CBOR Protocol. As with CBOR
Tag Wrapped, the use of a four-byte tag is encouraged that Tag Wrapped, the use of a four-byte tag is encouraged that
encodes without zero bytes. encodes without zero bytes.
3. The tag content is a three byte CBOR byte string containing 3. The tag content is a three byte CBOR byte string containing
0x42_4F_52 ('BOR' in diagnostic notation). 0x42_4F_52 ('BOR' in diagnostic notation).
The outer tag in the label identifies the file as being file as being The outer tag in the label identifies the file as being file as being
prefixed by a non-CBOR data label, and does so with all the desirable prefixed by a non-CBOR data label, and does so with all the desirable
properties explained in Section 3.4.6 of [RFC8949]. Specifically, it properties explained in Section 3.4.6 of [STD94]. Specifically, it
does not appear to conflict with any known file types, and it is not does not appear to conflict with any known file types, and it is not
valid Unicode in any Unicode encoding. valid Unicode in any Unicode encoding.
The inner tag in the label identifies which non-CBOR Protocol is The inner tag in the label identifies which non-CBOR Protocol is
used. used.
The inner tag content is a constant byte string which is represented The inner tag content is a constant byte string which is represented
as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR
encoded data item for the three-byte string 0x42_4f_52 ('BOR' in encoded data item for the three-byte string 0x42_4f_52 ('BOR' in
diagnostic notation). diagnostic notation).
 End of changes. 47 change blocks. 
75 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/