idnits 2.17.00 (12 Aug 2021) /tmp/idnits28469/draft-bormann-jose-cose-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2014) is 2756 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 254 == Outdated reference: draft-ietf-jose-json-web-algorithms has been published as RFC 7518 == Outdated reference: draft-ietf-jose-json-web-encryption has been published as RFC 7516 == Outdated reference: draft-ietf-jose-json-web-key has been published as RFC 7517 == Outdated reference: draft-ietf-jose-json-web-signature has been published as RFC 7515 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: draft-ietf-jose-cookbook has been published as RFC 7520 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JOSE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational October 27, 2014 5 Expires: April 30, 2015 7 Constrained Object Signing and Encryption (COSE) 8 draft-bormann-jose-cose-00 10 Abstract 12 COSE provides services similar to JSON Web Signature (JWS), JSON Web 13 Encryption (JWE), and JSON Web Key (JWK), making use of JSON Web 14 Algorithms (JWA), for data encoded in the Concise Binary Object 15 Representation (CBOR). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 30, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 5 63 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Constrained nodes and networks of constrained nodes [RFC7228] pose 69 some specific requirements on data representation that may make it 70 difficult to apply existing object security standards to this space. 72 In constrained node networks, message payloads are often small (by 73 nature of the data exchanged), and both transmission systems (e.g., 74 [RFC4944]) and application protocols (e.g., [RFC7252]) are optimized 75 for these small interchanges. As a result, fixed-size overheads 76 introduced by security protocols may be much more detrimental than in 77 a traditional Web environment. Transmission/reception of messages 78 requires power, turning a system that on average might consume 79 ~100 [micro]W into a 50 mW consumer while communicating. This is a 80 strong incentive to keep message sizes reasonably small. It is not 81 often possible to rely on compression to achieve this, as compression 82 requires CPU power, RAM, and code space, which all are rather 83 constrained in these environments; compression also works better for 84 larger messages. 86 Handling messages requires RAM, the total available size of which on 87 a constrained node may be on the order of 10 KiB (note that apart 88 from security, most of this RAM is already needed for operating 89 system, network stack, sensor management, application processing, 90 etc.). Protocols that require copying data, or, worse, re-encoding 91 and escape processing, can double or triple those RAM requirements. 93 All the processing that is to be performed in a constrained node 94 requires code space in Flash, the total available size of which on a 95 constrained node may be on the order of 100 KiB (with the same note 96 applying as above). This leads to a strong requirement to minimize 97 code complexity, and in particular to avoid having to implement 98 multiple different ways to do the same thing. 100 Still, security is not optional. 102 1.1. Objectives 104 The JOSE set of specifications provides an attractive set of 105 functions for the constrained space, even if its breadth of optional 106 functionality may go beyond what is required there. The present 107 specification aims to make use of the substantial amount of work that 108 went into making JOSE such a comprehensive specification. 110 JOSE makes use of JSON [RFC7159], a text based data representation 111 format. For applications in constrained nodes, the Concise Binary 112 Object Representation format (CBOR) provides a more compact 113 representation that is still largely based on the same principles. 115 By using CBOR, the present specification can: 117 o avoid the use of base64 coding of binary data. Base64 coding 118 causes message expansion, which is detrimental to energy 119 requirements. In an implementation, it also causes the 120 requirement for creating copies of some data, which increases RAM 121 requirements. 123 o avoid JSON-encoding of data. Again, this causes some message 124 expansion, requires creating copies for escape processing, but 125 also requires considerable code size, including for binary-to- 126 decimal conversion. 128 o potentially make use of CBOR's capability to minimize strings by 129 enumerating frequently occurring member names. This again helps 130 to reduce message sizes, but also can save some code space. (This 131 is a secondary, but useful objective.) 133 1.2. COSE 135 COSE provides services similar to JSON Web Signature (JWS) 136 [I-D.ietf-jose-json-web-signature], JSON Web Encryption (JWE) 137 [I-D.ietf-jose-json-web-encryption], and JSON Web Key (JWK) 138 [I-D.ietf-jose-json-web-key], making use of JSON Web Algorithms (JWA) 139 [I-D.ietf-jose-json-web-algorithms], in conjunction with data 140 encoding in the Concise Binary Object Representation (CBOR) 141 [RFC7049]. 143 1.3. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in RFC 148 2119 [RFC2119]. 150 The term "byte" is used in its now customary sense as a synonym for 151 "octet". 153 2. Specification 155 Presently, we believe the entire specification of COSE can be reduced 156 to the following: 158 COSE is exactly like JOSE, except that: 160 o each use of JSON is replaced by the equivalent use of CBOR; 162 o base64-encoding is never done: 164 * where the output of the base64url function was to be used as a 165 JSON string, instead the input to the base64url function is 166 represented as a byte string in CBOR 168 * where the output of the base64url function was to be used as an 169 input to a cryptographic algorithm, instead the input is used 170 directly 172 * where the output of the base64url function was to be joined by 173 ASCII dots (".") with other such outputs, CBOR encoding of an 174 array built from the inputs, each represented as a byte string, 175 is used. 177 o (probably:) certain member names ("alg"...) are replaced by a 178 number of predefined numeric replacements only in the key 179 positions of maps (JSON objects) defined by JOSE. Only the names 180 most likely to be frequently occurring in constrained node 181 networks are entered into a static table to be defined in this 182 specification. (There is no future extension planned for this 183 table.) 185 3. Examples 187 (TBD, to cover large parts of [I-D.ietf-jose-cookbook]). 189 4. IANA considerations 191 (TBD) 193 5. Security considerations 195 (TBD) 197 6. Acknowledgments 199 This document obviously owes a lot to the work of the entire JOSE 200 working group, including the feedback during an initial presentation 201 at IETF 90 [1]. Richard Barnes' Python implementation of JOSE was 202 instrumental in confirming the feasibility of the COSE approach. 204 7. References 206 7.1. Normative References 208 [I-D.ietf-jose-json-web-algorithms] 209 Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose- 210 json-web-algorithms-36 (work in progress), October 2014. 212 [I-D.ietf-jose-json-web-encryption] 213 Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 214 draft-ietf-jose-json-web-encryption-36 (work in progress), 215 October 2014. 217 [I-D.ietf-jose-json-web-key] 218 Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- 219 key-36 (work in progress), October 2014. 221 [I-D.ietf-jose-json-web-signature] 222 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 223 Signature (JWS)", draft-ietf-jose-json-web-signature-36 224 (work in progress), October 2014. 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, March 1997. 229 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 230 Representation (CBOR)", RFC 7049, October 2013. 232 7.2. Informative References 234 [I-D.ietf-jose-cookbook] 235 Miller, M., "Examples of Protecting Content using 236 JavaScript Object Signing and Encryption (JOSE)", draft- 237 ietf-jose-cookbook-05 (work in progress), October 2014. 239 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 240 "Transmission of IPv6 Packets over IEEE 802.15.4 241 Networks", RFC 4944, September 2007. 243 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 244 Interchange Format", RFC 7159, March 2014. 246 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 247 Constrained-Node Networks", RFC 7228, May 2014. 249 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 250 Application Protocol (CoAP)", RFC 7252, June 2014. 252 7.3. URIs 254 [1] http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf 256 Author's Address 258 Carsten Bormann 259 Universitaet Bremen TZI 260 Postfach 330440 261 Bremen D-28359 262 Germany 264 Phone: +49-421-218-63921 265 Email: cabo@tzi.org