idnits 2.17.1 draft-rundgren-comparable-json-00.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([JCS], [RFC8259]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2019) is 1874 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ECMASCRIPT' is mentioned on line 166, but not defined == Outdated reference: A later version (-17) exists of draft-rundgren-json-canonicalization-scheme-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Rundgren 3 Internet-Draft Independent 4 Intended status: Informational February 9, 2019 5 Expires: August 13, 2019 7 "Comparable" JSON (JSONCOMP) 8 draft-rundgren-comparable-json-00 10 Abstract 12 This application note describes how JCS [JCS] can be utilized to 13 support applications needing canonicalization beyond the core JSON 14 [RFC8259] level, with comparisons as the primary target. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 13, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. String Subtype Normalization . . . . . . . . . . . . . . . . 2 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 58 7.2. Informal References . . . . . . . . . . . . . . . . . . . 4 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1. Introduction 63 The purpose of JCS [JCS] is creating "Hashable" JSON [RFC8259] data 64 intended for cryptographic solutions. JCS accomplishes this by 65 combining normalization of the native JSON String and Number 66 primitives with a deterministic property sorting scheme. That is, 67 JCS provides canonicalization at the core JSON level. For 68 interoperability reasons JCS also constrains data to the I-JSON 69 [RFC7493] subset. 71 However, if you rather would like to compare JSON data from different 72 sources or runs, JCS would in many cases be inadequate since the JSON 73 String type is commonly used for holding subtypes like "DateTime" or 74 "BigNumber" objects. 76 This application note outlines how JCS in spite of having a limited 77 canonicalization scope still may be utilized by applications like 78 above. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in BCP 85 14 [RFC2119] [RFC8174] when, and only when, they appear in all 86 capitals, as shown here. 88 3. String Subtype Normalization 90 Assume you want to compare productions of JSON data where the schema 91 designer assigned the property "big" for holding a "BigInteger" 92 subtype and "time" for holding a "DateTime" subtype, while "val" is 93 supposed to be a JSON Number compliant with JCS. The example below 94 shows such a string: 96 {"time": "2019-01-28T07:45:10Z", "big": "055", "val": 3.5} 98 A problem here is that "055" clearly is not a canonical form for a 99 "BigInteger" while a "DateTme" object like "2019-01-28T07:45:10Z" 100 might as well be expressed as "2019-01-28T08:45:10.000+01:00" making 101 comparisons based on JCS canonicalization fail. 103 To resolve this issue using JCS the following measures MUST be taken: 105 o The community or standard utilizing a specific JSON schema defines 106 a strict normalized form for each of the used subtypes. 108 o Compatible serializers are created for each subtype. 110 A positive side effect of this arrangement is that it enforces strict 111 definitions of subtypes which improves interoperability in general as 112 well. 114 Below is an example how such a serializer could be expressed in 115 ECMAScript [ECMASCRIPT] for a "DateTime" subtype: 117 Date.prototype.toJSON = function() { 118 let date = this.toISOString(); 119 // In this particular case we selected a UTC notation 120 // yyyy-mm-ddThh:mm:ssZ 121 return date.substring(0, date.indexOf('.')) + 'Z'; 122 }; 124 Defining specific subtypes and their normalized form is out of scope 125 for this application note. 127 4. IANA Considerations 129 This document has no IANA actions. 131 5. Security Considerations 133 TBD. 135 6. Acknowledgements 137 TBD. 139 7. References 140 7.1. Normative References 142 [JCS] A. Rundgren, B. Jordan, S. Erdtman, "JSON Canonicalization 143 Scheme - Work in progress", . 146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 147 Requirement Levels", BCP 14, RFC 2119, 148 DOI 10.17487/RFC2119, March 1997, 149 . 151 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 152 DOI 10.17487/RFC7493, March 2015, 153 . 155 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 156 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 157 May 2017, . 159 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 160 Interchange Format", STD 90, RFC 8259, 161 DOI 10.17487/RFC8259, December 2017, 162 . 164 7.2. Informal References 166 [ECMASCRIPT] 167 Ecma International, "ECMAScript 2015 Language 168 Specification", . 171 Author's Address 173 Anders Rundgren 174 Independent 175 Montpellier 176 France 178 Email: anders.rundgren.net@gmail.com 179 URI: https://www.linkedin.com/in/andersrundgren/