Internet Engineering Task Force (IETF) L. Camara Internet-Draft July 18, 2017 Intended Status: Standards Track Expires: January 19, 2018 The .0 format (v1.2) draft-luis140219-appsawg-zeroformat-01 [[RFC-Editor: please replace the second character of my surname by U+00E2 when publishing as RFC in the header and in all pages. Non-ASCII characters are allowed in RFCs as per RFC 7997.]] Abstract This document defines the .0 format, a format for transmitting data that can be efficiently parsed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 19, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Presentation Language . . . . . . . . . . . . . . . . . . . . . 3 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Camara Expires January 19, 2018 [Page 1] Internet-Draft .0 format July 2017 2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Typedef . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. 8-bit integer . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3. 16-bit integer . . . . . . . . . . . . . . . . . . . . . . 6 2.2.4. 32-bit integer . . . . . . . . . . . . . . . . . . . . . . 6 2.2.5. 64-bit integer . . . . . . . . . . . . . . . . . . . . . . 7 2.2.6. __m128 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.7. Float . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.8. Double . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.9. Long double . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.10. Void . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.11. Structure . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.12. Union . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.13. Pointer . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Basic definitions . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. The format . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. The HashTable structure . . . . . . . . . . . . . . . . . . . 11 3.2. The HashTableEntry structure . . . . . . . . . . . . . . . . 12 3.3. The UNICODE_STRING structure . . . . . . . . . . . . . . . . 13 3.4. The TypedData structure . . . . . . . . . . . . . . . . . . . 13 3.4.1. Types with GUIDs . . . . . . . . . . . . . . . . . . . . . 14 3.4.2. Universal types . . . . . . . . . . . . . . . . . . . . . . 15 3.4.2.1. The number type (0xFFFFFFFE) . . . . . . . . . . . . . . 16 3.4.2.2. The boolean type (0xFFFFFFFC) . . . . . . . . . . . . . . 16 3.4.2.3. The string type (0xFFFFFFF6) . . . . . . . . . . . . . . 16 3.4.2.4. The X.690 data type (0xFFFFFFF5) . . . . . . . . . . . . 16 3.5. GUID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.6. The Array structure . . . . . . . . . . . . . . . . . . . . . 17 3.7. The ArrayEntry structure . . . . . . . . . . . . . . . . . . 17 3.8. Special properties of the root hash table . . . . . . . . . . 18 3.8.1. ".::version" . . . . . . . . . . . . . . . . . . . . . . . 18 3.8.2. ".::purpose" . . . . . . . . . . . . . . . . . . . . . . . 18 3.8.3. ".::guid" . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.8.4. ".::signature" . . . . . . . . . . . . . . . . . . . . . . 18 3.8.5. ".::signature_pkcs7" . . . . . . . . . . . . . . . . . . . 19 3.8.6. ".::checksum" . . . . . . . . . . . . . . . . . . . . . . . 19 4. IANA registries . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Type registry . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Owner name registry . . . . . . . . . . . . . . . . . . . . . 21 5. Validation and Canonicalisation . . . . . . . . . . . . . . . . 21 5.1. Algorithm A . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1.1. Encoding a hash table . . . . . . . . . . . . . . . . . . . 22 5.1.2. Encoding a hash table (to HashTableEntry) . . . . . . . . . 22 5.1.3. Encoding a string . . . . . . . . . . . . . . . . . . . . . 23 5.1.4. Encoding an array . . . . . . . . . . . . . . . . . . . . . 23 5.1.5. Encoding an array (to ArrayEntry) . . . . . . . . . . . . . 23 5.1.6. Encoding X.690 data . . . . . . . . . . . . . . . . . . . . 24 5.1.7. Other types . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Algorithm B . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 Camara Expires January 19, 2018 [Page 2] Internet-Draft .0 format July 2017 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . . 26 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A.1. Algorithm A result example . . . . . . . . . . . . . 27 Appendix A.2. Algorithm B result example . . . . . . . . . . . . . 30 Appendix A.3. About the examples . . . . . . . . . . . . . . . . . 33 Appendix B. Writing related documents . . . . . . . . . . . . . . 33 Appendix C. Data leakage using a buffer underflow . . . . . . . . 33 1. Introduction This document defines the .0 format, a format that can be parsed very efficiently and designed for real-world performance. This is version 1.2 of the specification. All features in this specification apply to all versions, i.e. v1.0+, unless otherwise stated. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119, RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Presentation Language The definitions in this document use the presentation language defined in this section. 2.1. Syntax This is the syntax of the presentation language, defined using the Augmented Backus-Naur Form (ABNF) [RFC5234, RFC7405], the core rules of Appendix B of [RFC5234] and the rule UTFMB defined in Section 1.4 of [RFC4512] (the encoding of the presentation language is UTF-8 [RFC3629]): deflist = 1*( def / (*c-wsp c-nl) ) c-wsp = WSP / (c-nl WSP) c-nl = comment / CRLF ; comment or newline comment = comment1 / comment2 comment1 = ( "//" / "#" ) *(WSP / VCHAR) CRLF ; single-line comments use // or # Camara Expires January 19, 2018 [Page 3] Internet-Draft .0 format July 2017 comment2 = "/*" *( ( %x20-29 / %x2B-7E ) / *( ( %x20-2E / %x30-7E / UTFMB ) ) ) "*/" ; multi-line comments use /* ... */ def = typedef / struct1 / union1 typedef = %s"typedef" *c-wsp type *c-wsp name (*c-wsp "," *c-wsp name) ";" name = ( ALPHA / "_" / "$" ) *( ALPHA / DIGIT / "_" / "$" ) ; uses characters from [A-Za-z0-9_$] and first MUST NOT ; be a digit type = type0 *(c-wsp "*") ; pointers can be used in the presentation language type0 = primitive / struct2 / union2 / name primitive = ( u-len / [u-len] %s"int" ) / ( ["unsigned"] (%s"char" / %s"wchar_t" / ( %s"__int" ( "8" | "16" | "32" | "64" ) ) ) ) / %s"__m128" / %s"float" / ( [%s"long"] %s"double" ) / %s"void" ; 1. int is always 32 bits. ; 2. Microsoft convention: wchar_t is 16 bits. ; 3. float is 32 bits, double is 64 bits, long double is ; 80 bits. See sections 2.2.7, 2.2.8 and 2.2.9 for more ; details. ; 4. __m128 is 128 bits. u-len = "unsigned" / ["unsigned"] length length = %s"short" / 1*2( %s"long" ) ; short 16 bits, long 32 bits, long long 64 bits struct2 = struct1 / ( %s"struct" *c-wsp struct *c-wsp ";" ) struct1 = %s"struct" *c-wsp name *c-wsp struct *c-wsp ";" struct = "{" *c-wsp *( type *c-wsp name ["[" number "]"] ";" / c-wsp ) "}" union2 = union1 / ( %s"union" *c-wsp union *c-wsp ";" ) union1 = %s"union" *c-wsp name *c-wsp union *c-wsp ";" union = "{" *c-wsp *( type *c-wsp name ";" / c-wsp ) "}" 2.2. Semantics Camara Expires January 19, 2018 [Page 4] Internet-Draft .0 format July 2017 2.2.1. Typedef typedef TYPE NEWTYPE; The type NEWTYPE is defined to be the same as TYPE and has the same size and structure. 2.2.2. 8-bit integer char unsigned char __int8 unsigned __int8 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | 1 octet | +-+-+-+-+-+-+-+-+ The char type is normally signed, but can be unsigned in a C/C++ compiler given certain options. "unsigned char" and "unsigned __int8" are always unsigned. "__int8" is always signed. The unsigned types here can represent values from 0 to 255, and the signed types here can represent values from -128 to 127. Two's complement is used for signed values: +---------------+----------+------------+-------+ |0 1 2 3 4 5 6 7|Hex signed|Hex unsigned|Decimal| +---------------+----------+------------+-------+ |1 0 0 0 0 0 0 0| -0x80 | 0x80 | -128 | |1 0 0 0 0 0 0 1| -0x7F | 0x81 | -127 | |1 0 0 0 0 0 1 0| -0x7E | 0x82 | -126 | ................................................. ................................................. |1 0 1 1 1 1 1 1| -0x41 | 0xBF | -65 | |1 1 0 0 0 0 0 0| -0x40 | 0xC0 | -64 | |1 1 0 0 0 0 0 1| -0x3F | 0xC1 | -63 | ................................................. ................................................. |1 1 1 1 1 1 1 0| -0x02 | 0xFE | -2 | |1 1 1 1 1 1 1 1| -0x01 | 0xFF | -1 | |0 0 0 0 0 0 0 0| +0x00 | 0x00 | +0 | |0 0 0 0 0 0 0 1| +0x01 | 0x01 | +1 | |0 0 0 0 0 0 1 0| +0x02 | 0x02 | +2 | ................................................. ................................................. |0 1 1 1 1 1 1 0| +0x7E | 0x7E | +126 | |0 1 1 1 1 1 1 1| +0x7F | 0x7F | +127 | +---------------+----------+------------+-------+ Camara Expires January 19, 2018 [Page 5] Internet-Draft .0 format July 2017 2.2.3. 16-bit integer short unsigned short short int unsigned short int __int16 unsigned __int16 wchar_t 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 2 octets = 16 bits) The octet order is little-endian: this means the value is 256*o_1 + o_0, with o_1 being signed if and only if the type is signed. From the first 6 types, the ones with "unsigned" are unsigned, the others are signed. wchar_t is unsigned. 2.2.4. 32-bit integer int unsigned int long unsigned long long int unsigned long int __int32 unsigned __int32 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | o_2 | o_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 4 octets = 32 bits) The octet order is little-endian: this means the value is 16777216*o_3 + 65536*o_2 + 256*o_1 + o_0, with o_3 being signed if and only if the type is signed. From these 8 types, the ones with "unsigned" are unsigned, the others are signed. Camara Expires January 19, 2018 [Page 6] Internet-Draft .0 format July 2017 2.2.5. 64-bit integer long long unsigned long long long long int unsigned long long int __int64 unsigned __int64 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | o_2 | o_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_4 | o_5 | o_6 | o_7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 8 octets = 64 bits) The octet order is little-endian: this means the value is (2^^56)*o_7 + (2^^48)*o_6 + (2^^40)*o_5 + (2^^32)*o_4 + 16777216*o_3 + 65536*o_2 + 256*o_1 + o_0, with o_7 being signed if and only if the type is signed. From these 6 types, the ones with "unsigned" are unsigned, the others are signed. 2.2.6. 128-bit data __m128 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | o_2 | o_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_4 | o_5 | o_6 | o_7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_8 | o_9 | o_10 | o_11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_12 | o_13 | o_14 | o_15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 16 octets = 128 bits) This type is the in-memory representation of a XMM register in an Intel x86/x64 CPU supporting MMX and, therefore, is 128 bits in size. 2.2.7. Float float Camara Expires January 19, 2018 [Page 7] Internet-Draft .0 format July 2017 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | o_2 | o_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 4 octets = 32 bits) This type is the in-memory representation of a 32-bit floating-point value in an Intel x87 FPU or in an Intel 80486+/x64 CPU. 2.2.8. Double double 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | o_2 | o_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_4 | o_5 | o_6 | o_7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 8 octets = 64 bits) This type is the in-memory representation of a 64-bit floating-point value in an Intel x87 FPU or in an Intel 80486+/x64 CPU. 2.2.9. Long double long double 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | o_2 | o_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_4 | o_5 | o_6 | o_7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_8 | o_9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 10 octets = 80 bits) This type is the in-memory representation of an 80-bit floating-point value in an Intel x87 FPU or in an Intel 80486+/x64 CPU. 2.2.10. Void void Camara Expires January 19, 2018 [Page 8] Internet-Draft .0 format July 2017 (size = 0 bytes) This type is 0 bytes in size and is useful to indicate the absence of a return value or arguments in a C/C++ function. A void* pointer 2.2.11. Structure struct { ... } struct NAME { ... }; The structure type has a size equal to the sum of the size of all its components and has the structure of the concatenation of its components. 2.2.12. Union union { ... }; union NAME { ... }; The union type has a size equal to the maximum of the size of its components and every component's value is at the start of the union. 2.2.13. Pointer TYPE* 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_0 | o_1 | o_2 | o_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This has the same size and value semantics as a 32-bit integer (Section 2.2.4), but can be dereferenced by returning the value of type TYPE at N octets from the pointer base, where N is the integer value of the pointer. Adding to a pointer of type TYPE* returns N+V*S, where N is the integer value of the pointer, V is the integer value added to the pointer and S is the size of the type TYPE in octets. 2.3. Basic definitions This is a set of basic definitions used throughout this document, defined in the presentation language defined above. /// /// Represents an 8-bit integer. /// typedef __int8 int8_t; /// Camara Expires January 19, 2018 [Page 9] Internet-Draft .0 format July 2017 /// Represents an unsigned 8-bit integer. /// typedef unsigned __int8 uint8_t; /// /// Represents a 16-bit integer. /// typedef short int16_t; /// /// Represents an unsigned 16-bit integer. /// typedef unsigned short uint16_t; /// /// Represents a 32-bit integer. /// typedef long int32_t; /// /// Represents an unsigned 32-bit integer. /// typedef unsigned long uint32_t; /// /// Represents a 64-bit integer. /// typedef __int64 int64_t; /// /// Represents an unsigned 64-bit integer. /// typedef unsigned __int64 uint64_t; 2.4. Conventions The definitions use XML comments for being able to self-document in Microsoft Visual Studio, and the language is totally compatible with C/C++, assuming wchar_t is 2 octets (16 bits), int is 4 octets (32 bits), that __int8, __int16, __int32 and __int64 are working keywords, that a pointer is 4 octets (32 bits), that nameless unions are supported and that the endianness is little-endian (everything here is true for Microsoft's C/C++ Compiler targeting a WOW64/x86 architecture). For the .0 format specification, the "pointer base" in Section 2.2.13 refers to the start of the data using the format. 3. The format The format has the following header: /// /// Represents the .0 format header (16 bytes). /// struct ZeroHeader { /// Camara Expires January 19, 2018 [Page 10] Internet-Draft .0 format July 2017 /// Magic. MUST be "lm_data\0". /// uint8_t Magic[8]; /// /// Data mode. 0 - not canonicalised, 1 - algorithm A, 2 - /// algorithm B. /// uint32_t Mode; /// /// Reserved, MUST be set to 0 and SHOULD be ignored. /// uint32_t Reserved; /// /// The root hash table of this data. /// HashTable Root; }; This header is 20 octets in size. The Magic field is the magic number for the .0 format and MUST be set to 6C 6D 5F 64 61 74 61 00 (ASCII [RFC20] "lm_data" followed by NUL). The Mode field MUST be set to 0 if the data was not canonicalised, MUST be set to 1 if the data was canonicalised with algorithm A of Section 5 and MUST be set to 2 if the data was canonicalised with algorithm A of Section 5. Other values SHALL be The Reserved field is reserved, MUST be set to 0 by generators of data using this format and SHOULD be ignored by data parsers and readers (Section YY). The Size field of the HashTable (Section 3.1) Root MUST NOT be negative and MUST be the size of the entire data (including the header) (this "MUST" conflicts with Section 3.1, and this section takes priority). For stored files, it is RECOMMENDED that Size be a multiple of 4096. Following the header comes a HashTableEntry structure (Section 3.2). 3.1. The HashTable structure The HashTable structure is defined as follows: /// /// Represents a hash table in the .0 format. /// struct HashTable { /// /// Size of the hash table, in bytes. /// Camara Expires January 19, 2018 [Page 11] Internet-Draft .0 format July 2017 int Size; /// /// Count of name-value pairs in the hash table. /// int Count; }; (size = 8 octets) The Size field MUST be set to the number of contiguous octets following the Size field that are part of the hash table represented by the structure. The Count field MUST be the count of name-value pairs in the hash table represented by the structure. If the Size field is not 0, a HashTableEntry structure (Section 3.2) MUST follow the Size field. 3.2. The HashTableEntry structure /// /// Represents a hash table entry in the .0 format. /// struct HashTableEntry { /// /// Next entry. NULL if there is no next entry. /// HashTableEntry* Next; /// /// Name part of the hash table entry, in Unicode. /// UNICODE_STRING Name; /// /// Value part of the hash table entry. /// TypedData Data; }; (size = 24 octets) The Next pointer points to the next entry in the hash table. This pointer is 0 when there is no next entry. The Name pointer describes the name associated with the value described by Data. See Section 3.3 for the UNICODE_STRING structure. The Data pointer specifies the type, length and pointer to the value associated with the name. The TypedData structure is specified in Section 3.4. Camara Expires January 19, 2018 [Page 12] Internet-Draft .0 format July 2017 3.3. The UNICODE_STRING structure /// /// Represents a Unicode string. /// struct UNICODE_STRING { /// /// Length, in bytes, of the string of Unicode characters. /// uint16_t Length; /// /// Size of the buffer, in bytes. /// uint16_t BufferLength; /// /// Buffer containing the Unicode characters (UTF-16LE). wchar_t* Buffer; }; (size = 8 octets) The Length is the length, in octets, of the string of wide characters pointed to by the Buffer member. The BufferLength is the length, in octets, of the buffer pointed to by the Buffer member. The Buffer member points to a string of 2-byte Unicode characters using UTF-16LE [RFC2781]. 3.4. The TypedData structure /// /// Represents typed data in the .0 format. /// struct TypedData { /// /// Pointer to the value. /// void* Value; /// /// Type of the value. /// int Type; /// /// Length of the value, in bytes. /// int Size; Camara Expires January 19, 2018 [Page 13] Internet-Draft .0 format July 2017 }; The Value field MUST point to valid data of size Size octets. The Size field MUST NOT be negative, but MAY be 0. The Type field is the type of the data pointed to by Value. +----------------+--------------------------------------------------+ |Most significant| | |4 bits of Type | Meaning | +----------------+--------------------------------------------------+ | 0 x x x | Free for use | | 1 0 y z | Type identified by GUID (see Section 3.4.1) | | 1 1 0 x | Reserved (Section 4.1) | | 1 1 1 0 | Reserved (Section 4.1) | | 1 1 1 1 | Universal types | +----------------+--------------------------------------------------+ x - don't care bit, y and z - used in Section 3.4.1. 3.4.1. Types with GUIDs 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h_0 | l_0 | h_1 | l_1 | h_2 | l_2 |1|0|y|z| l_3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Type member with the above structure uses the GUID (Section 3.5) pointed to by a GUID* with the following structure: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | l_0 |y|z|0|0| l_1 | h_0 | l_2 | h_1 | l_3 | h_2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This can be done very efficiently in a x86 CPU with the following function defined in NASM assembly using __fastcall: ; GUID* __fastcall TypeToGUID(int Type) ; Assumes Type has the two MSBs 1 and 0. TypeToGUID: ; Example: convert 0xA1234567 to GUID* mov eax, ecx ; eax=0xA1234567, ecx=0xA1234567 shr ecx, 26 ; eax=0xA1234567, ecx=0x00000028 and ecx, byte +0x0C ; eax=0xA1234567, ecx=0x00000008 shl eax, 4 ; eax=0x12345670, ecx=0x00000008 or eax, ecx ; eax=0x12345678, ecx=0x12345678 ret ; Result=0x12345678 Camara Expires January 19, 2018 [Page 14] Internet-Draft .0 format July 2017 Portable and endian-neutral C implementation (a C version of the above assembly code): /// /// Converts a .0 type to a GUID pointer in the presentation language /// of the .0 specification (Section 2.2.13). /// /// The type value to convert. /// The obtained GUID pointer. GUID* TypeToGUID(int Type) { return (GUID*)(((Type >> 26) & 0x0C) + (Type << 4)); } 3.4.2. Universal types The following universal types are defined: +----------+-------------+---------------+--------------------------+ |Type value|Type |Minimum version|Section/remarks | +----------+-------------+---------------+--------------------------+ |0xFFFFFFFF|String |v1.0 |Section 3.3 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFFE|Number |v1.0 |Section 3.4.2.1 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFFD|Program |To be defined |This type is not defined | +----------+-------------+---------------+--------------------------+ |0xFFFFFFFC|Boolean |v1.0 |Section 3.4.2.2 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFFB|Float |v1.0 |Section 2.2.7 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFFA|Double |v1.0 |Section 2.2.8 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFF9|Long double |v1.0 |Section 2.2.9 | | |(TWORD) | | | +----------+-------------+---------------+--------------------------+ |0xFFFFFFF8|Array |v1.0 |Section 3.6 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFF7|Object |v1.0 |Section 3.1 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFF6|Binary |v1.0 |Section 3.4.2.3 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFF5|X.690 data |v1.1 |Section 3.4.2.5 | +----------+-------------+---------------+--------------------------+ |0xFFFFFFF4|GUID |v1.1 |Section 3.5 | +----------+-------------+---------------+--------------------------+ (In version 1.1, 0xFFFFFFF5 was "embedded ASN.1". The new name was adopted in version 1.2.) Universal types are allocated via the IANA registry defined in Section 4.1. Camara Expires January 19, 2018 [Page 15] Internet-Draft .0 format July 2017 3.4.2.1. The number type (0xFFFFFFFE) The number type represents a signed arbitrary-precision integer. A signed integer of a fixed size can be transformed into this format by initialising the value's octets with the signed integer's octets (in little-endian) and setting the Size field to the size of the signed integer, in octets. 3.4.2.2. The boolean type (0xFFFFFFFC) The boolean type MUST have its associated Size field equal to 1 or 4, and it is true if and only if at least one of the octets of its value is not 0x00. 3.4.2.3. The binary type (0xFFFFFFF6) The binary type represents an octet string, whose value octets are those of the octet string. 3.4.2.4. The X.690 data type (0xFFFFFFF5) The X.690 data type MUST contain a valid Basic Encoding Rules (BER) [X.690] structure in its value octets. 3.5. GUID 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_3 | o_2 | o_1 | o_0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_5 | o_4 | o_7 | o_6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_8 | o_9 | o_10 | o_11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o_12 | o_13 | o_14 | o_15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (size = 16 octets = 128 bits) The value is structured as above and the octets from o_0 to o_15 (in this order) represent an UUID as in [RFC4122]. GUID is a term used in Windows programming, that represents an UUID with native endianness (for the .0 format, little-endian) for some fields. The Microsoft version of the definition is available at . Camara Expires January 19, 2018 [Page 16] Internet-Draft .0 format July 2017 3.6. The Array structure The Array structure is defined as follows: /// /// Represents an array in the .0 format. /// struct Array { /// /// Size of the array, in bytes. /// int Size; /// /// Count of elements in the array. /// int Count; }; (size = 4 octets) The Size field MUST be set to the number of contiguous octets following the Size field that are part of the array represented by the structure. The Count field MUST be the count of elements in the array represented by the structure. If the Size field is not 0, an ArrayEntry structure (Section 3.7) MUST follow the Size field. 3.7. The ArrayEntry structure /// /// Represents an array entry in the .0 format. /// struct ArrayEntry { /// /// Next entry. NULL if there is no next entry. /// ArrayEntry* Next; /// /// Value of this entry. /// TypedData Data; }; (size = 16 octets) The Next pointer points to the next entry in the array. This pointer is 0 when there is no next entry. Camara Expires January 19, 2018 [Page 17] Internet-Draft .0 format July 2017 The Data pointer specifies the type, length and pointer to the value of this entry of the array. The TypedData structure is specified in Section 3.4. 3.8. Special properties of the root hash table The initial hash table entry in data using the .0 format is the first hash table entry in the root hash table. Here are defined some properties of the root hash table with names starting with ".::". 3.8.1. ".::version" It is RECOMMENDED that a value associated with the name ".::version" exist. If present, the value MUST have type String (0xFFFFFFFF, see sections 3.4.2 and 3.3) and MUST contain the version of the format used for the data (e.g. "v1.0" or "v1.2"). Encoders for version A of the .0 format SHOULD set the ".::version" field to A. If a decoder for version A of the .0 format receives data encoded in an earlier version B of the .0 format and it contains features specific to versions later than B, the decoder MAY raise a warning. If present, the ".::version" MUST be the first name in the root hash table. 3.8.2. ".::purpose" This value, if present, MUST have type String (0xFFFFFFFF, see sections 3.4.2 and 3.3) and MUST contain an owner name, followed by two colons "::" and by a local identifier. It is RECOMMENDED that local identifiers match the following regular expression (JavaScript): The company owning an owner name can freely use the names starting with any of its owner names followed by "::". The name "IETF" is an owner name of the Internet Engineering Task Force (IETF) and "." is an owner name of the authorities managing this format. Owner names are assigned by IANA in the registry defined in Section 4.2. 3.8.3. ".::guid" This value, if present, MUST have type Binary (0xFFFFFFF6, see Section 3.4.2.3), MUST be 16 octets in size and MUST contain a GUID structure (Section 3.5) identifying the data. Procedures for these identifiers are detailed in Section 3.5 and [RFC4122]. 3.8.4. ".::signature" This value, if present, MUST have type X.690 data (0xFFFFFFF5, see Camara Expires January 19, 2018 [Page 18] Internet-Draft .0 format July 2017 Section 3.4.2.4), is available since v1.1 and uses the following ASN.1 structure [X.680]: ZeroSig ::= SEQUENCE { algorithm OBJECT IDENTIFIER, [0] signingCertificate EXPLICIT X509Cert OPTIONAL, [1] intermediateCertificates IMPLICIT Intermediates OPTIONAL, rootCertificate X509Cert, [2] test IMPLICIT BOOLEAN OPTIONAL, hash BIT STRING } (X509Cert is the Certificate type from Appendix A.1 of [RFC5280]) This value SHOULD NOT be used in version 1.2 and later of the .0 format as it is deprecated in favour of ".::signature_pkcs7" (Section 3.8.5). 3.8.5. ".::signature_pkcs7" This value, if present, MUST have type X.690 data (0xFFFFFFF5, see Section 3.4.2.4), is available since v1.2 and MUST contain a valid PKCS#7 structure [RFC5652] with contentType signedData (1.2.840.113549.1.7.2), whose eContentType MUST be 1.3.6.1.4.1.37476.9000.46.2.7.2 (id-zeroDigest), that contains a ZeroDigest described in ASN.1 [X.680] below: ZeroDigest ::= SEQUENCE { } The ZeroDigest, to the digital signature in the data to be valid, MUST have the hash in the OCTET STRING equal to the hash using the algorithm identified by the AlgorithmIdentifier on the entire .0 data, excluding the octets of the values associated with the names ".::checksum" (if present) and ".::signature_pkcs7", if present. 3.8.6. ".::checksum" This value, if present, MUST have type binary (0xFFFFFFF6, see Section 3.4.2.3), is available since v1.1, MUST be 400 octets in size and MUST contain a structure as follows (defined in the presentation language of Section 2): /// /// Represents the checksum in .0 data. /// struct ZeroChecksum { /// /// The GUID of the format. MUST be /// BC72DD96-194F-11E7-82B1-E4F89C5A2296 using the GUID structure Camara Expires January 19, 2018 [Page 19] Internet-Draft .0 format July 2017 /// (Section 3.5 of the .0 specification). /// GUID guid1; /// /// The SHA3-512 hash of the entire .0 data, excluding the octets /// composing this structure. /// char sha3_512[64]; /// /// The Skein-512-512 hash of the entire .0 data, excluding the /// octets composing this structure. /// char skein[64]; /// /// The CubeHash160+16/32+160-512 hash of the entire .0 data, /// excluding the octets composing this structure. /// char cubehash[64]; /// /// The SHA-512 hash of the entire .0 data, excluding the octets /// composing this structure. /// char sha512[64]; /// /// The SHA-384 hash of the entire .0 data, excluding the octets /// composing this structure. /// char sha384[48]; /// /// The SHA-256 hash of the entire .0 data, excluding the octets /// composing this structure. /// char sha256[32]; /// /// The SHA-224 hash of the entire .0 data, excluding the octets /// composing this structure. /// char sha224[28]; /// /// The SHA-1 hash of the entire .0 data, excluding the octets /// composing this structure. /// char sha1[20]; }; (size = 400 octets) The checksum is valid if and only if the hashes contained in the checksum structure match the hashes obtained by hashing the entire .0 data, excluding the octets composing the checksum structure. Camara Expires January 19, 2018 [Page 20] Internet-Draft .0 format July 2017 SHA-1 is defined in [SHA1], SHA-* is defined in [SHA2], SHA3-512 is defined in [SHA3], Skein-512-512 is defined in [SKEIN] and CubeHash160+16/32+160-512 is defined in [CUBE]. 4. IANA registries This document requires that IANA create the registries defined below. 4.1. Type registry This registry is named ".0 type registry". Values 0x00000000 to 0x7FFFFFFF are Private Use [RFC8126]. Values 0x80000000 to 0xBFFFFFFF are Standards Action [RFC8126], with a reference to Section 3.4.1 of this document. Values 0xC0000000 to 0xEFFFFFFF are Specification Required [RFC8126]. Values 0xF0000000 to 0xFFFFFFFF are Standards Action [RFC8126]. Values 0xFFFFFFF4 to 0xFFFFFFFF include a reference to Section 3.4.2 of this document. Universal types SHOULD be allocated in reverse order (example: 0xFFFFFFF3 is allocated, then 0xFFFFFFF2, then 0xFFFFFFF1, etc...). 4.2. Owner name registry This registry is named ".0 owner name registry". The registered values are strings that MUST NOT contain the character ":". Owner names that are registered trademarks SHOULD NOT be owner names of companies that do not own the registered trademark. 5. Validation and Canonicalisation Data using the .0 format is valid if and only if all the following conditions apply: * it complies with all rules of Section 2 and Section 3; * one of the following applies: $ the Mode field is 0; $ the Mode field is unrecognised by the implementation; $ all of the following apply: * the Mode field is recognised by the implementation; * the data is valid in the canonicalisation form described by the Mode field. Camara Expires January 19, 2018 [Page 21] Internet-Draft .0 format July 2017 For any canonicalisation form, its recognition is OPTIONAL. The above validation algorithm implies that it is REQUIRED that a canonicalisation form be employed if it is recognised (this means to consider invalid data that claims to comply to a canonicalisation form and doesn't comply, see the security considerations in Section 7). In the following algorithms, the "header" is the target data structure of each encoding algorithm. The ".0 header" is the header of the data itself. 5.1. Algorithm A Algorithm A is as follows: 1. Set Magic to "lm_data\0" (the magic number). 2. Set Mode to 1 and Reserved to 0. 3. Apply the algorithm of Section 5.1.2 to the hash table to be encoded with pos = 24, resulting in two values: n and S. 4. Set Size to (n + 4119) & -4096. (This will align the data to 4096 bytes). 5. Append S to the header, resulting in T. 6. Pad T to Size octets using octets with value 0x00. 7. The canonicalised data is T. 5.1.1. Encoding a hash table 1. Set Count to the number of name-value pairs in the hash table. 2. If the hash table is empty, set Size to 0 and the results are 8 and the hash table header. 3. Encode the hash table using the algorithm of section 5.1.2, being the pos used for the encoding algorithm equal to pos + 4, resulting in n and S. 4. Append S to the header, resulting in T. 5. The results are (n + 8) and T. 5.1.2. Encoding a hash table (to HashTableEntry) 1. Let s and v be the name and value of the first pair of the hash table (s is encoded in UTF-16LE [RFC2781]). 2. Let l be the length of s, in octets. 3. Set Name.Length to l. 4. Let b be (l + 5) & -4. 5. Set Name.BufferLength to b. 6. Set Name.Buffer to pos + 24. 7. Set Data.Value to (void*)(pos + 24 + b). 8. Encode v using the algorithm in this section according to its type, being the pos used for the encoding algorithm equal to pos + 24 + b, resulting in two values, n and S. 9. Set Data.Type to the type of the value (Section 3.4). 10. Set Data.Length to n. Camara Expires January 19, 2018 [Page 22] Internet-Draft .0 format July 2017 11. Append s and S to the header, resulting in T. 12. Pad T to the next multiple of 4 octets using octets with value 0x00. 13. Let t = (27 + b + n) & -4. 14. If there is only one name-value pair in the hash table, set Next to (HashTableEntry*)(0), the results are t and T and this algorithm terminates. 15. Encode the remaining name-value pairs of the hash table according to this algorithm, being the pos used equal to pos + t, resulting in u and U. 16. Set Next in T to (void*)(pos + t). 17. Append U to T, resulting in V. 18. The results are (t + u) and V. 5.1.3. Encoding a string 1. Let s be the UTF-16LE [RFC2781] encoding of the string. 2. Let l be the length of s, in octets. 3. Set Length to l. 4. Let b be (l + 5) & -4. 5. Set BufferLength to b. 6. Set Buffer to pos + 8. 7. Append s to the header, resulting in S. 8. The results are (8 + b) and S. 5.1.4. Encoding an array 1. If the array is empty, set Size to 0 and the results are 8 and the array header. 2. Encode the array using the algorithm of section 5.1.5, being the pos used for the encoding algorithm equal to pos + 8, resulting in n and S. 3. Append S to the header, resulting in T. 4. The results are (n + 8) and T. 5.1.5. Encoding an array (to ArrayEntry) 1. Let v be the first value of the array. 2. Encode v using the algorithm in this section according to its type, being the pos used for the encoding algorithm equal to pos + 16, resulting in two values, n and S. 3. Set Data.Type to the type of the value (Section 3.4). 4. Set Data.Length to n. 5. Append s and S to the header, resulting in T. 6. Pad T to the next multiple of 4 octets using octets with value 0x00. 7. Let t = (19 + n) & -4. 8. If there is is only one element in the array, set Next to (ArrayEntry*)(0), the results are t and T and this algorithm terminates. 9. Encode the array, except for the first element, according to this Camara Expires January 19, 2018 [Page 23] Internet-Draft .0 format July 2017 to this algorithm, being the pos used equal to pos + t, resulting in u and U. 10. Set Next in T to (void*)(pos + t). 11. Append U to T, resulting in V. 12. The results are (t + u) and V. 5.1.6. Encoding X.690 data X.690 data canonicalised using Algorithm A MUST use the Distinguished Encoding Rules (DER) of [X.690]. 5.1.7. Other types Algorithms A and B do not pose constraints on other types as of version 1.2. Only types introduced in later versions may get subject to constraints by canonicalisation. 5.2. Algorithm B Algorithm B is very similar to Algorithm A, except that strings are stored in a temporary hash table, that begins empty, to save space and the result is not aligned to 4096 bytes. Formally, these are the changes to Algorithm A resulting in Algorithm B: Section 5.1, step 4 is replaced with "Set Size to n + 24." Section 5.1, step 6 is omitted. Section 5.1.2, step 7 is replaced with "If s is in the string hash table, set b to 0, set s to an empty sequence of octets and set Name.Buffer to the associated value in the string hash table. Otherwise, associate this value with s. After these substeps, set Data.Value to (void*)(pos + 24 + b). Section 5.1.3, step 7 is replaced with "If s is in the string hash table, set b to 0, set s to an empty sequence of octets, set Buffer to the associated value in the string hash table and let S be the header. Otherwise, append s to the header, resulting in S.". "b" becomes a mutable variable in the algorithms of Section 5.1.2 and Section 5.1.3. 6. IANA Considerations A MIME type may need to be registered for this format. The file extension is .0 and the magic number is 6C 6D 5F 64 61 74 61 00. The registries defined in Section 4 MUST be created by IANA. Camara Expires January 19, 2018 [Page 24] Internet-Draft .0 format July 2017 7. Security Considerations Implementations SHALL validate data using the .0 format to assure there is no data leakage or denial of service attacks. (For an attack that targets implementations violating the "no data leakage" requirement, see Appendix C.) If a certain data using the .0 format is invalid, the data MUST be rejected and the system handling the data MUST either give out no response or give a response indicating to the peer the data is invalid. A protocol using this format MAY impose further restrictions on the files, for example, enforcing digital signatures, checksums and/or canonicalisation and rejecting unsigned or uncanonicalised files. 8. References 8.1. Normative References [CUBE] Bernstein, D., "CubeHash specification (2.B.1)", [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2781] Hoffman, P., and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. [RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, December 2014. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017. Camara Expires January 19, 2018 [Page 25] Internet-Draft .0 format July 2017 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [SHA1] "Secure Hash Standard", United States of America, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 180-1, April 1993. [SHA2] "Secure Hash Standard", United States of America, National Institute of Standards and Technology, Federal Information Processing Standard (FIPS) PUB 180-4, March 2012. [SHA3] Drowkin, M., "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", United States of America, National Institute of Standards and Technology, Federal Information Processing Standard (FIPS) PUB 202, DOI 10.6028/NIST.FIPS.202, (currently redirects to ). [SKEIN] Ferguson, N., Lucks, S., Schneier, B., et al., "The Skein Hash Function Family", Version 1.3, 1 October 2010, . [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 8.2. Informative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [[RFC-Editor: please replace the 'i' in my name by U+00ED and the first 'a' in the surname by U+00E2, as non-ASCII characters are allowed as per RFC 7997]] 9. Author's Address Luis Camara EMail: Camara Expires January 19, 2018 [Page 26] Internet-Draft .0 format July 2017 Appendix A. Examples This section contains examples of data using the .0 format. Appendix A.1. Algorithm A result example This is the result of encoding the JSON data: {"Latn": "/[A-Za-z\u00C0-\u00FF\u0100-\u017F\uFB00-\uFB06]+/", "Hebr": "/[\u05D0-\u05EA]+/", "Arab": "/[\u0600-\u06FF]+/"} using the .0 format. ".::version" is added with a value of v1.2. Octets 0 1 2 3 4 5 6 7 +-------+-------+-------+-------+-------+-------+-------+-------+ | Magic ('lm_data\0') | +-------+-------+-------+-------+-------+-------+-------+-------+ | Mode = 1 | Reserved2 = 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Size = 4096 | Count = 4 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Next = 0x5C | Length = 20 |BufferLength=24| +-------+-------+-------+-------+-------+-------+-------+-------+ | Buffer = 0x30 | Value = 0x48 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Type = 0xFFFFFFFF (String) | Length = 20 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '.' | ':' | ':' | 'v' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'e' | 'r' | 's' | 'i' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'o' | 'n' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x50 | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'v' | '1' | '.' | '2' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | Next = 0x00B4 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x74 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Value = 0x80 | Type = 0xFFFFFFFF (String) | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 52 | 'L' | 'a' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 't' | 'n' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ Camara Expires January 19, 2018 [Page 27] Internet-Draft .0 format July 2017 (continuation) +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 40 |BufferLength=44| Buffer = 0x88 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '/' | '[' | 'A' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'Z' | 'a' | '-' | 'z' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '\u00C0' | '-' | '\u00FF' | '\u0100' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '-' | '\u017F' | '\uFB00' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '\uFB06' | ']' | '+' | '/' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | Next = 0x00F4 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x00CC | +-------+-------+-------+-------+-------+-------+-------+-------+ | Value = 0x00D8 | Type = 0xFFFFFFFF (String) | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 28 | 'H' | 'e' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'b' | 'r' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 16 |BufferLength=20| Buffer = 0x00E0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '/' | '[' | '\u05D0' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '\u05EA' | ']' | '+' | '/' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | Next = 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x010C | +-------+-------+-------+-------+-------+-------+-------+-------+ | Value = 0x0118 | Type = 0xFFFFFFFF (String) | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 28 | 'A' | 'r' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'a' | 'b' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 16 |BufferLength=20| Buffer = 0x0120 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '/' | '[' | '\u0600' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+ | '\u06FF' | ']' | '+' | '/' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | 0 | 0 | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ Camara Expires January 19, 2018 [Page 28] Internet-Draft .0 format July 2017 (continuation) +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ................................................................. ................................................................. ................................................................. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ (size = 4096 octets = 32768 bits) Base64 encoding (64 characters per line): bG1fZGF0YQABAAAAAAAAAAAQAAAEAAAAXAAAABQAGAAwAAAASAAAAP////8UAAAA LgA6ADoAdgBlAHIAcwBpAG8AbgAAAAAACAAMAFAAAAB2ADEALgAyAAAAAAC0AAAA CAAMAHQAAACAAAAA/////zQAAABMAGEAdABuAAAAAAAoACwAiAAAAC8AWwBBAC0A WgBhAC0AegDAAC0A/wAAAS0AfwEA+y0ABvtdACsALwAAAAAA9AAAAAgADADMAAAA 2AAAAP////8cAAAASABlAGIAcgAAAAAAEAAUAOAAAAAvAFsA0AUtAOoFXQArAC8A AAAAAAAAAAAIAAwADAEAABgBAAD/////HAAAAEEAcgBhAGIAAAAAABAAFAAgAQAA LwBbAAAGLQD/Bl0AKwAvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Camara Expires January 19, 2018 [Page 29] Internet-Draft .0 format July 2017 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA== Appendix A.2. Algorithm B result example This is the result of encoding the JSON data: Camara Expires January 19, 2018 [Page 30] Internet-Draft .0 format July 2017 {"Latn": "/[A-Za-z\u00C0-\u00FF\u0100-\u017F\uFB00-\uFB06]+/", "Hebr": "/[\u05D0-\u05EA]+/", "Arab": "/[\u0600-\u06FF]+/"} using the .0 format. ".::version" is added with a value of v1.2. This is the same as Appendix A.1, but using Algorithm B. Octets 0 1 2 3 4 5 6 7 +-------+-------+-------+-------+-------+-------+-------+-------+ | Magic ('lm_data\0') | +-------+-------+-------+-------+-------+-------+-------+-------+ | Mode = 1 | Reserved2 = 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Size = 308 | Count = 4 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Next = 0x5C | Length = 20 |BufferLength=24| +-------+-------+-------+-------+-------+-------+-------+-------+ | Buffer = 0x30 | Value = 0x48 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Type = 0xFFFFFFFF (String) | Length = 20 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '.' | ':' | ':' | 'v' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'e' | 'r' | 's' | 'i' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'o' | 'n' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x50 | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'v' | '1' | '.' | '2' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | Next = 0x00B4 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x74 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Value = 0x80 | Type = 0xFFFFFFFF (String) | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 52 | 'L' | 'a' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 't' | 'n' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 40 |BufferLength=44| Buffer = 0x88 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '/' | '[' | 'A' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'Z' | 'a' | '-' | 'z' | +-------+-------+-------+-------+-------+-------+-------+-------+ Camara Expires January 19, 2018 [Page 31] Internet-Draft .0 format July 2017 (continuation) +-------+-------+-------+-------+-------+-------+-------+-------+ | '\u00C0' | '-' | '\u00FF' | '\u0100' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '-' | '\u017F' | '\uFB00' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '\uFB06' | ']' | '+' | '/' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | Next = 0x00F4 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x00CC | +-------+-------+-------+-------+-------+-------+-------+-------+ | Value = 0x00D8 | Type = 0xFFFFFFFF (String) | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 28 | 'H' | 'e' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'b' | 'r' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 16 |BufferLength=20| Buffer = 0x00E0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '/' | '[' | '\u05D0' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '\u05EA' | ']' | '+' | '/' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | Next = 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 8 |BufferLength=12| Buffer = 0x010C | +-------+-------+-------+-------+-------+-------+-------+-------+ | Value = 0x0118 | Type = 0xFFFFFFFF (String) | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 28 | 'A' | 'r' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 'a' | 'b' | 0 | 0 | +-------+-------+-------+-------+-------+-------+-------+-------+ | Length = 16 |BufferLength=20| Buffer = 0x0120 | +-------+-------+-------+-------+-------+-------+-------+-------+ | '/' | '[' | '\u0600' | '-' | +-------+-------+-------+-------+-------+-------+-------+-------+ | '\u06FF' | ']' | '+' | '/' | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | +-------+-------+-------+-------+ (size = 308 octets = 2464 bits) Base64 encoding (64 characters per line): bG1fZGF0YQABAAAAAAAAADQBAAAEAAAAXAAAABQAGAAwAAAASAAAAP////8UAAAA LgA6ADoAdgBlAHIAcwBpAG8AbgAAAAAACAAMAFAAAAB2ADEALgAyAAAAAAC0AAAA CAAMAHQAAACAAAAA/////zQAAABMAGEAdABuAAAAAAAoACwAiAAAAC8AWwBBAC0A WgBhAC0AegDAAC0A/wAAAS0AfwEA+y0ABvtdACsALwAAAAAA9AAAAAgADADMAAAA 2AAAAP////8cAAAASABlAGIAcgAAAAAAEAAUAOAAAAAvAFsA0AUtAOoFXQArAC8A Camara Expires January 19, 2018 [Page 32] Internet-Draft .0 format July 2017 AAAAAAAAAAAIAAwADAEAABgBAAD/////HAAAAEEAcgBhAGIAAAAAABAAFAAgAQAA LwBbAAAGLQD/Bl0AKwAvAAAAAAA= Appendix A.3. About the examples The two resulting structures are .0 data encoding the same JSON structure. Algorithm A does not reuse strings and aligns data to 4096 octets. Algorithm B, in the other hand, reuses strings whenever possible and does not align data to 4096 octets. Therefore, Algorithm B cannot result in larger sizes and with over 99.6% of probability results in smaller sizes than Algorithm A. String reuse was not demonstrated in the Algorithm B example, as there were no duplicate strings in the data (including ".::version" and "v1.2"). Appendix B. Writing related documents A good way to add examples to this specification is to create RFCs updating this document. No restrictions are posed on the status of those RFCs. For instance, best current practices for this document have a status of BCP and may contain examples; and documents whose only purpose is to provide examples have a status of Informational. Standards track documents designed to update the format MUST NOT be published in any circumstances. Best Current Practice (BCP) documents describing best current practices for the use of this format or formats using it can be written, but cannot be used to extend the format (See RFC 2026). Despite this, BCP documents can be used to provide further security considerations on the use of this format, and standards track documents can be used to provide conversions from other formats to .0 and in the inverse direction. Appendix C. Data leakage using a buffer underflow An attacker could construct .0 data that is only 124 octets, but claims to require a buffer of N octets in size and to contain a binary value of (N - 124) octets, where N is arbitrarily large. By sending this structure to a system not compliant with the first sentence of Section 7, the attacker may be able to leak up to N octets of data from the system, that may include sensitive information such as passwords, private keys, identifying information and credit card numbers. This assumes the system does not alter the data other than replacing parts of the binary value such that a sufficient amount of leaked data remains and sends the result as the response, or that it puts the original data or parts of it into the response. Camara Expires January 19, 2018 [Page 33] Internet-Draft .0 format July 2017 A way this vulnerability could be introduced is by allocating a buffer in the heap with its size indicated by the Root.Size field of the .0 data, without validating the .0 data and outside debug mode. If debug mode is used, the heap memory is normally filled with a distinguishing pattern. As of this writing, in Windows 7, 8 or 8.1, the fill pattern is 0xBAADF00D in native platform endianness. This can be enabled via creating/editing the GlobalFlag value in the Image File Execution Options registry key associated with the executable whose process(es) contain(s) the vulnerable implementation to set a flag to enable this fill pattern. For N > 524280, this attack does not work on Microsoft Windows when using the heap APIs (HeapAlloc/RtlAllocateHeap), even with a vulnerable implementation and outside debug mode, because, for these sizes, new virtual memory will be allocated, that is initialised by the operating system to zeroes. This attack could be prevented by setting the HEAP_ZERO_MEMORY (0x00000008) flag in the Flags argument in calls to HeapAlloc (Windows API) or to RtlAllocateHeap (Native API). Camara Expires January 19, 2018 [Page 34]