idnits 2.17.1 draft-ietf-cbor-file-magic-07.txt: -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 December 2021) is 863 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-02 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-11 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-19 -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CBOR Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice C. Bormann 5 Expires: 18 June 2022 Universität Bremen TZI 6 15 December 2021 8 On storing CBOR encoded items on stable storage 9 draft-ietf-cbor-file-magic-07 11 Abstract 13 This document defines an on-disk format for CBOR objects that is 14 friendly to common on-disk recognition systems such as the Unix 15 file(1) command. 17 About This Document 19 This note is to be removed before publishing as an RFC. 21 Status information for this document may be found at 22 https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/. 24 Discussion of this document takes place on the cbor Working Group 25 mailing list (mailto:cbor@ietf.org), which is archived at 26 https://mailarchive.ietf.org/arch/browse/cbor/. 28 Source for this draft and an issue tracker can be found at 29 https://github.com/cbor-wg/cbor-magic-number. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 18 June 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Requirements for a Magic Number . . . . . . . . . . . . . 4 67 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. The CBOR Protocol Specific Tag . . . . . . . . . . . . . 5 69 2.2. Enveloping Method: CBOR Tag Wrapped . . . . . . . . . . . 5 70 2.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.3. Enveloping Method: CBOR Tag Sequence . . . . . . . . . . 6 72 3. Advice to Protocol Developers . . . . . . . . . . . . . . . . 7 73 3.1. Is the on-wire format new? . . . . . . . . . . . . . . . 8 74 3.2. Can many items be trivially concatenated? . . . . . . . . 9 75 3.3. Are there tags at the start? . . . . . . . . . . . . . . 9 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 5.1. CBOR Sequence Tag . . . . . . . . . . . . . . . . . . . . 9 79 5.2. CBOR Header Tag . . . . . . . . . . . . . . . . . . . . . 10 80 5.3. CBOR Tags for CoAP Content-Format Numbers . . . . . . . . 11 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 6.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Appendix A. CBOR Tags for CoAP Content Formats . . . . . . . . . 13 85 A.1. Content-Format Tag Examples . . . . . . . . . . . . . . . 13 86 Appendix B. Example from Openswan . . . . . . . . . . . . . . . 14 87 Appendix C. Using CBOR headers for non-CBOR data . . . . . . . . 15 88 C.1. Content-Format Tag Examples . . . . . . . . . . . . . . . 15 89 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 16 90 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 91 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 Since very early in computing, operating systems have sought ways to 97 mark which files could be processed by which programs. 99 For instance, the Unix file(1) command, which has existed since 1973 100 [file], has been able to identify many file formats for decades based 101 upon the contents of the file. 103 Many systems (Linux, macOS, Windows) will select the correct 104 application based upon the file contents, if the system can not 105 determine it by other means. For instance, starting in MacOS, a 106 resource fork was maintained that includes media type ("MIME type") 107 information and therefore ideally never needs to know anything about 108 the file. 110 But, many other systems do this by file extensions. Many common web 111 servers derive the MIME-type information from file extensions. 113 While having a media type associated with the file is a better 114 solution in general, when files become disconnected from their type 115 information, such as when attempting to do forensics on a damaged 116 system, then being able to identify a file type can become very 117 important. 119 It is noted that in the media type registration, that a magic number 120 is asked for, if available, as is a file extension. 122 A challenge for the file(1) program is often that it can be confused 123 by the encoding vs the content. For instance, an Android "apk" used 124 to transfer and store an application may be identified as a ZIP file. 125 Additionally, both OpenOffice and MSOffice files are ZIP files of XML 126 files. 128 As CBOR becomes a more and more common encoding for a wide variety of 129 artifacts, identifying them as just "CBOR" is probably not 130 sufficient. This document provides a way to encode a magic number 131 into the beginning of a CBOR format file. Two possible methods of 132 enveloping data are presented: a CBOR Protocol author will specify 133 one. (A CBOR Protocol is a specification which uses CBOR as its 134 encoding.) 136 Examples of CBOR Protocols currently under development include CoSWID 137 [I-D.ietf-sacm-coswid], and EAT [I-D.ietf-rats-eat]. COSE itself 138 [RFC8152] is considered infrastructure, however the encoding of 139 public keys in CBOR as described in [I-D.ietf-cose-cbor-encoded-cert] 140 would be an identified CBOR Protocol as well. 142 A major inspiration for this document is observing the mess in 143 certain ASN.1 based systems where most files are PEM encoded, 144 identified by the extension "pem", confusing public keys, private 145 keys, certificate requests, and S/MIME content. 147 While these envelopes add information to how data conforming to CBOR 148 Protocols are stored in files, there is no requirement that either 149 type of envelope be transferred on the wire. 151 In addition to the on-disk identification aspects, there are some 152 protocols which may benefit from having such a magic number on the 153 wire if they are presently using a different (legacy) encoding 154 scheme. The presence of the identifiable magic sequence signals that 155 CBOR is being used as opposed to a legacy scheme. In addition, for 156 convenience, Appendix C defines a simple way to retroactively add a 157 magic number to content-formats as defined by [RFC7252], even if not 158 in CBOR form. 160 1.1. Terminology 162 The term "diagnostic notation" refers to the human-readable notation 163 for CBOR data items defined in Section 8 of [RFC8949] and Appendix G 164 of [RFC8610]. 166 The term CDDL (Concise Data Definition Language) refers to the 167 language defined in [RFC8610]. 169 1.2. Requirements for a Magic Number 171 A magic number is ideally a fingerprint that is unique to a CBOR 172 protocol, present in the first few (small multiple of 4) bytes of the 173 file, which does not change when the contents change, and does not 174 depend upon the length of the file. 176 Less ideal solutions have a pattern that needs to be matched, but in 177 which some bytes need to be ignored. While the Unix file(1) command 178 can be told to ignore certain bytes, this can lead to ambiguities. 180 2. Protocol 182 There are two enveloping methods presented. Which one is to be used 183 is up to the CBOR Protocol author to determine. Both use CBOR Tags 184 in a way that results in a deterministic first 8 to 12 bytes. 186 2.1. The CBOR Protocol Specific Tag 188 In both enveloping methods, CBOR Protocol designers need to obtain a 189 CBOR tag for each major type of object that they might store on disk. 190 As there are more than 4 billion available 4-byte tags, there should 191 be little issue in allocating a few to each available CBOR Protocol. 193 The IANA policy for 4-byte CBOR Tags is First Come First Served, so 194 all that is required is an email to IANA, having filled in the small 195 template provided in Section 9.2 of [RFC8949]. 197 This tag needs to be allocated by the author of the CBOR Protocol. 198 In order to be in the four-byte range, and so that there are no 199 leading zeros, the value needs to be in the range 0x01000000 (decimal 200 16777216) to 0xFFFFFFFF (decimal 4294967295). It is further 201 suggested to avoid values that have an embedded zero byte in the four 202 bytes of their binary representation (e.g., 0x12003456). 204 The use of a sequence of four US-ASCII codes which are mnemonic to 205 the protocol is encouraged, but not required. 207 For CBOR byte strings that happen to contain a representation that is 208 described by a CoAP Content-Format Number (Section 12.3 of [RFC7252], 209 Registry CoAP Content-Formats of [IANA.core-parameters]), a tag 210 number has already been allocated in Section 5.3 (see Appendix A for 211 details and examples). 213 2.2. Enveloping Method: CBOR Tag Wrapped 215 The CBOR Tag Wrapped method is appropriate for use with CBOR 216 protocols that encode a single CBOR data item. 218 It starts with the Self-described CBOR tag, 55799, as described in 219 Section 3.4.6 of [RFC8949]. 221 A second CBOR Tag is then allocated to describe the specific Protocol 222 involved, as described above. 224 This method wraps the CBOR value as tags usually do. Applications 225 that need to send the CBOR value across a constrained link may wish 226 to remove the two tags if the use is implicitly understood. 228 Whether or not to remove the tags for specific further processing is 229 a decision made by the CBOR Protocol specification. 231 2.2.1. Example 233 To construct an example without registering a new tag, we use the 234 technique described in Appendix A to translate the Content-Format 235 number registered for application/senml+cbor, the number 112, into 236 the tag 1668546560+112 = 1668546672. 238 With this tag, the SenML-CBOR pack [{0: "current", 6: 3, 2: 1.5}] 239 would be enveloped as (in diagnostic notation): 241 55799(1668546672([{0: "current", 6: 3, 2: 1.5}])) 243 Or in hex: 245 d9 d9f7 # tag(55799) 246 da 63740070 # tag(1668546672) 247 81 # array(1) 248 a3 # map(3) 249 00 # unsigned(0) 250 67 # text(7) 251 63757272656e74 # "current" 252 06 # unsigned(6) 253 03 # unsigned(3) 254 02 # unsigned(2) 255 f9 3e00 # primitive(15872) 257 In other words, the unique fingerprint for application/senml+cbor is 258 composed of the 8 bytes d9d9f7da63740070 hex, after which the 259 unadorned CBOR data (81... for the SenML data) is appended. 261 2.3. Enveloping Method: CBOR Tag Sequence 263 The CBOR Taq Sequence method is appropriate for use with CBOR 264 Sequences as described in [RFC8742]. 266 This method prepends a data item to the sequence to be tagged that 267 consists of two tags nested around a constant string for a total of 268 12 bytes. 270 1. The file shall start with the Self-described CBOR Sequence tag, 271 55800. 273 2. The file shall continue with a CBOR tag, from the First Come 274 First Served space, which uniquely identifies the CBOR Protocol. 275 As with the previous method, the use of a four-byte tag is 276 encouraged that encodes without zero bytes. 278 3. The encoded three byte CBOR byte string containing 0x42_4F_52. 280 The first part identifies the file as being a CBOR Sequence, and does 281 so with all the desirable properties explained in Section 3.4.6 of 282 [RFC8949]. Specifically, it does not appear to conflict with any 283 known file types, and it is not valid Unicode in any Unicode 284 encoding. 286 The second part identifies which CBOR Protocol is used, as described 287 above. 289 The third part is represented as a constant byte sequence 290 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR encoded 291 data item for the three byte sequence 0x42_4f_52 ('BOR' in diagnostic 292 notation). This is the data item that is being tagged. 294 The actual CBOR Protocol value then follows as the next data item(s) 295 in the CBOR sequence, without a need for any further specific tag. 296 The use of a CBOR Sequence allows the application to trivially remove 297 the first item with the two tags. 299 Should this file be reviewed by a human (directly in an editor, or in 300 a hexdump display), it will include the ASCII characters "CBOR" 301 prominently. This value is also included simply because the two tags 302 need to tag something. 304 3. Advice to Protocol Developers 306 This document introduces a choice between wrapping a single CBOR data 307 item into a (pair of) identifying CBOR tags, or prepending an 308 identifying encoded CBOR data item (which in turn contains a pair of 309 identifying CBOR tags) to a CBOR Sequence (which might be single data 310 item). 312 Which should a protocol designer use? 314 In this discussion, one assumes that there is an object stored in a 315 file, perhaps specified by a system operator in a configuration file. 317 For example: a private key used in COSE operations, a public key/ 318 certificate in C509 or CBOR format, a recorded sensor reading stored 319 for later transmission, or a COVID vaccination certificate that needs 320 to be displayed in QR code form. 322 Both the CBOR Tag Sequence and the wrapped tag can be trivially 323 removed by an application before sending the CBOR content out on the 324 wire. 326 The CBOR Tag Sequence can be slightly easier to remove as in most 327 cases, CBOR parsers will return it as a unit, and then return the 328 actual CBOR item, which could be anything at all, and could include 329 CBOR tags that _do_ need to be sent on wire. 331 On the other hand, having the CBOR Tag Sequence in the file requires 332 that all programs that expect to examine that file are able to skip 333 what appears to be a CBOR item with two tags nested around a three- 334 byte byte string. Programs which might not expect the CBOR Tag 335 Sequence, but which would operate without a problem would include any 336 program that expects to process CBOR Sequences from the file. 338 As an example of where there was a problem with previous security 339 systems, "PEM" format certificate files grew to be able to contain 340 multiple certificates by simple concatenation. The PKCS1 format 341 could also contain a private key object followed by a one or more 342 certificate objects: but only when in PEM format. Annoyingly, when 343 in binary DER format (which like CBOR is self-delimiting), 344 concatenation of certificates was not compatible with most programs 345 as they did not expect to read more than one item in the file. 347 The use of CBOR Tag Wrapped format is easier to retrofit to an 348 existing format with existing and unchangeable on-disk format for a 349 single CBOR data item. This new sequence of tags is expected to be 350 trivially ignored by many existing programs when reading CBOR from 351 disk, even if the program only supports decoding a single data item 352 (and not a CBOR sequence). But, a naive program might also then 353 transmit the additional tags across the network. Removing the CBOR 354 Tag Wrapped format requires knowledge of the two tags involved. 355 Other tags present might be needed. 357 For a representation matching a specific media-type that is carried 358 in a CBOR byte string, the byte string head will already have to be 359 removed for use as such a representation, so it should be easy to 360 remove the enclosing tag heads as well. This is of particular 361 interest with the pre-defined tags provided by Appendix A for media- 362 types with CoAP Content-Format numbers. 364 Here are some considerations in the form of survey questions: 366 3.1. Is the on-wire format new? 368 If the on-wire format is new, then it could be specified with the 369 CBOR Tag Wrapped format if the extra eight bytes are not a problem. 370 The disk format is then identical to the on-wire format. 372 If the eight bytes are a problem on the wire (and they often are if 373 CBOR is being considered), then the CBOR Tag Sequence format should 374 be adopted for on-disk storage. 376 3.2. Can many items be trivially concatenated? 378 If the programs that read the contents of the file already expect to 379 process all of the CBOR data items in the file (not just the first), 380 then the CBOR Tag Sequence format may be easily retrofitted. 382 The program involved may throw errors or warnings on the CBOR Tag 383 Sequence if they have not yet been updated, but this may not be a 384 problem. If it is, then consideration should be given to CBOR Tag 385 Wrapped. 387 If only one item is ever expected in the file, the use of CBOR Tag 388 Sequence may present an implementation hurdle to programs that 389 previously just read a single data item and used it. 391 3.3. Are there tags at the start? 393 If the Protocol expects to use other tags values at the top-level, 394 then it may be easier to explain if the CBOR Tag Sequence format is 395 used. 397 4. Security Considerations 399 This document provides a way to identify CBOR Protocol objects. 400 Clearly identifying CBOR contents on disk may have a variety of 401 impacts. 403 The most obvious is that it may allow malware to identify interesting 404 objects on disk, and then exfiltrate or corrupt them. 406 5. IANA Considerations 408 Section 5.1 documents the allocation that was done for a CBOR tag to 409 be used in a CBOR sequence to identify the sequence (an example for 410 using this tag is found in Appendix B). Section 5.3 allocates a CBOR 411 tag for each actual or potential CoAP Content-Format number (examples 412 are in Appendix A). 414 5.1. CBOR Sequence Tag 416 IANA has allocated tag 55800 as the tag for the CBOR Tag Sequence 417 Enveloping Method. 419 This tag is from the First Come/First Served area. 421 The value has been picked to have properties similar to the 55799 tag 422 (Section 3.4.6 of [RFC8949]). 424 The hexadecimal representation of the encoded tag head is: 425 0xd9_d9_f8. 427 This is not valid UTF-8: the first 0xd9 introduces a three-byte 428 sequence in UTF-8, but the 0xd9 as the second value is not a valid 429 second byte for UTF-8. 431 This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian 432 order) puts this value into the UTF-16 high-half zone, which would 433 signal that this a 32-bit Unicode value. However, the following 434 16-bit big-endian value 0xf8.. is not a valid second sequence 435 according to [RFC2781]. On a little-endian system, it would be 436 necessary to examine the fourth byte to determine if it is valid. 437 That next byte is determined by the subsequent encoding, and 438 Section 3.4.6 of [RFC8949] has already determined that no valid CBOR 439 encodings result in valid UTF-16. 441 Data Item: 442 tagged byte string 444 Semantics: 445 indicates that the file contains CBOR Sequences 447 5.2. CBOR Header Tag 449 IANA is requested to allocate tag 55801 as the tag for the CBOR Tag 450 Header Enveloping Method (Appendix C). 452 This tag is from the First Come/First Served area. 454 The value has been picked to have properties similar to the 55799 tag 455 (Section 3.4.6 of [RFC8949]). 457 The hexadecimal representation of the encoded tag head is: 458 0xd9_d9_f9. 460 This is not valid UTF-8: the first 0xd9 introduces a three-byte 461 sequence in UTF-8, but the 0xd9 as the second value is not a valid 462 second byte for UTF-8. 464 This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian 465 order) puts this value into the UTF-16 high-half zone, which would 466 signal that this a 32-bit Unicode value. However, the following 467 16-bit big-endian value 0xf9.. is not a valid second sequence 468 according to [RFC2781]. On a little-endian system, it would be 469 necessary to examine the fourth byte to determine if it is valid. 470 That next byte is determined by the subsequent encoding, and 471 Section 3.4.6 of [RFC8949] has already determined that no valid CBOR 472 encodings result in valid UTF-16. 474 Data Item: 475 tagged byte string 477 Semantics: 478 indicates that the file starts with a CBOR Header 480 5.3. CBOR Tags for CoAP Content-Format Numbers 482 IANA is requested to allocate the tag numbers 1668546560 (0x63740000) 483 to 1668612095 (0x6374FFFF) as follows: 485 Data Item: 486 byte string 488 Semantics: 489 for each tag number NNNNNNNN, the representation of content-format 490 (RFC7252) NNNNNNNN-1668546560 492 Reference: 493 RFCthis 495 6. References 497 6.1. Normative References 499 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 500 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 501 . 503 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 504 Representation (CBOR)", STD 94, RFC 8949, 505 DOI 10.17487/RFC8949, December 2020, 506 . 508 6.2. Informative References 510 [file] Wikipedia, "file (command)", 20 January 2021, 511 . 513 [I-D.ietf-core-new-block] 514 Boucadair, M. and J. Shallow, "Constrained Application 515 Protocol (CoAP) Block-Wise Transfer Options Supporting 516 Robust Transmission", Work in Progress, Internet-Draft, 517 draft-ietf-core-new-block-14, 26 May 2021, 518 . 521 [I-D.ietf-cose-cbor-encoded-cert] 522 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 523 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 524 Certificates)", Work in Progress, Internet-Draft, draft- 525 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 526 . 529 [I-D.ietf-rats-eat] 530 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 531 Attestation Token (EAT)", Work in Progress, Internet- 532 Draft, draft-ietf-rats-eat-11, 24 October 2021, 533 . 536 [I-D.ietf-sacm-coswid] 537 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 538 Waltermire, "Concise Software Identification Tags", Work 539 in Progress, Internet-Draft, draft-ietf-sacm-coswid-19, 20 540 October 2021, . 543 [IANA.core-parameters] 544 IANA, "Constrained RESTful Environments (CoRE) 545 Parameters", 546 . 548 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 549 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, 550 . 552 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 553 Application Protocol (CoAP)", RFC 7252, 554 DOI 10.17487/RFC7252, June 2014, 555 . 557 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 558 RFC 8152, DOI 10.17487/RFC8152, July 2017, 559 . 561 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 562 Definition Language (CDDL): A Notational Convention to 563 Express Concise Binary Object Representation (CBOR) and 564 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 565 June 2019, . 567 Appendix A. CBOR Tags for CoAP Content Formats 569 Often, there is a need to identify a media type (or content type, 570 i.e., media type optionally used with parameters) that describes a 571 byte string in a CBOR data item. 573 Section 5.10.3 of [RFC7252] defines the concept of a Content-Format, 574 which is a short 16-bit unsigned integer that identifies a specific 575 content type (media type plus optionally parameters), optionally 576 together with a content encoding. 578 This specification allocates CBOR tag numbers 1668546560 (0x63740000) 579 to 1668612095 (0x6374FFFF) for the tagging of representations of 580 specific content formats. The tag content tagged with tag number 581 NNNNNNNN (in above range) is a byte string that is to be interpreted 582 as a representation of the content format NNNNNNNN-1668546560. 583 Exceptionally, when used immediately as tag content within a tag 584 58000 (Section 2.3) or 58001 (Appendix C), the tag content is the 585 byte string 'BOR', signifying that the representation of the given 586 content-format follows in the way defined for these tags. 588 A.1. Content-Format Tag Examples 590 Registry Content-Formats of [IANA.core-parameters] defines content 591 formats that can be used as examples: 593 * As discussed in Section 2.2.1, Content-Format 112 stands for media 594 type application/senml+cbor (no parameters). The corresponding 595 tag number is 1668546672 (i.e., 1668546560+112). 597 So the following CDDL snippet can be used to identify application/ 598 senml+cbor representations: 600 senml-cbor = #6.1668546672(bstr) 602 Note that a byte string is used as the type of the tag content, 603 because a media type representation in general can be any byte 604 string. 606 * Content-Format 272 stands for media type application/missing- 607 blocks+cbor-seq, a CBOR sequence [I-D.ietf-core-new-block]. 609 The corresponding tag number is 1668546832 (i.e., 1668546560+272). 611 So the following CDDL snippet can be used to identify application/ 612 missing-blocks+cbor-seq representations as embedded in a CBOR byte 613 string: 615 missing-blocks = #6.1668546832(bstr) 617 Appendix B. Example from Openswan 619 The Openswan IPsec project has a daemon ("pluto"), and two control 620 programs ("addconn", and "whack"). They communicate via a Unix- 621 domain socket, over which a C-structure containing pointers to 622 strings is serialized using a bespoke mechanism. This is normally 623 not a problem as the structure is compiled by the same compiler; but 624 when there are upgrades it is possible for the daemon and the control 625 programs to get out of sync by the bespoke serialization. As a 626 result, there are extra compensations to deal with shutting the 627 daemon down. During testing it is sometimes the case that upgrades 628 are backed out. 630 In addition, when doing unit testing, the easiest way to load policy 631 is to use the normal policy reading process, but that is not normally 632 loaded in the daemon. Instead the IPC that is normally sent across 633 the wire is compiled/serialized and placed in a file. The above 634 magic number is included in the file, and also on the IPC in order to 635 distinguish the "shutdown" command CBOR operation. 637 In order to reduce the problems due to serialization, the 638 serialization is being changed to CBOR. Additionally, this change 639 allows the IPC to be described by CDDL, and for any language that 640 encode to CBOR can be used. 642 IANA has allocated the tag 1330664270, or 0x4f_50_53_4e for this 643 purpose. As a result, each file and each IPC is prefixed with a CBOR 644 TAG Sequence. 646 In diagnostic notation: 648 55800(1330664270(h'424F52')) 650 Or in hex: 652 D9 D9F8 # tag(55800) 653 DA 4F50534E # tag(1330664270) 654 43 # bytes(3) 655 424F52 # "BOR" 657 Appendix C. Using CBOR headers for non-CBOR data 659 The CBOR header method is appropriate for adding a magic number to a 660 non-CBOR data format, particularly one that can be described by a 661 Content-Format tag (Appendix A). 663 This method prepends a CBOR data item to the non-CBOR data; this data 664 item is called the "header" and consists of two tags nested around a 665 constant string for a total of 12 bytes. 667 1. The file shall start with the Self-described CBOR header tag, 668 55801. 670 2. The file shall continue with a CBOR tag, from the First Come 671 First Served space, which uniquely identifies the non-CBOR 672 Protocol. As with the previous method, the use of a four-byte 673 tag is encouraged that encodes without zero bytes. 675 3. The encoded three byte CBOR byte string containing 0x42_4F_52. 677 The first part identifies the file as being prefixed by a CBOR 678 header, and does so with all the desirable properties explained in 679 Section 3.4.6 of [RFC8949]. Specifically, it does not appear to 680 conflict with any known file types, and it is not valid Unicode in 681 any Unicode encoding. 683 The second part identifies which non-CBOR Protocol is used, as 684 described above. 686 The third part is represented as a constant byte sequence 687 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR encoded 688 data item for the three byte sequence 0x42_4f_52 ('BOR' in diagnostic 689 notation). This is the data item that is being tagged. 691 The actual non-CBOR Protocol value then follows directly appended to 692 the CBOR header data item. The use of a CBOR header allows the 693 application to trivially remove the header item with the two tags. 695 Should this file be reviewed by a human (directly in an editor, or in 696 a hexdump display), it will include the ASCII characters "CBOR" 697 prominently. This value is also included simply because the two tags 698 need to tag something. 700 C.1. Content-Format Tag Examples 702 Registry Content-Formats of [IANA.core-parameters] defines content 703 formats that can be used as examples: 705 * Content-Format 432 stands for media type application/td+json (no 706 parameters). The corresponding tag number is 1668546992 (i.e., 707 1668546560+432). 709 So the following CDDL snippet can be used to identify a CBOR 710 header for application/td+json representations: 712 td-json-header = #6.55801(#6.1668546992('BOR')) 714 * Content-Format 11050 stands for media type application/json in 715 deflate content-coding. 717 The corresponding tag number is 1668557610 (i.e., 718 1668546560+11050). 720 So the following CDDL snippet can be used to identify a CBOR 721 header for application/json representations compressed in deflate 722 content-coding: 724 json-deflate-header = #6.55801(#6.1668557610('BOR')) 726 Appendix D. Changelog 728 Acknowledgements 730 The CBOR WG brainstormed this protocol on January 20, 2021 via a 731 number of productive email exchanges on the mailing list. 733 Contributors 735 Josef 'Jeff' Sipek 737 Email: jeffpc@josefsipek.net 739 Authors' Addresses 741 Michael Richardson 742 Sandelman Software Works 744 Email: mcr+ietf@sandelman.ca 745 Carsten Bormann 746 Universität Bremen TZI 747 Postfach 330440 748 D-28359 Bremen 749 Germany 751 Phone: +49-421-218-63921 752 Email: cabo@tzi.org