idnits 2.17.1 draft-jones-jose-jws-json-serialization-01.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 date (July 16, 2012) is 4273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'JWA' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWS' ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JOSE Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track J. Bradley 5 Expires: January 17, 2013 independent 6 N. Sakimura 7 Nomura Research Institute 8 July 16, 2012 10 JSON Web Signature JSON Serialization (JWS-JS) 11 draft-jones-jose-jws-json-serialization-01 13 Abstract 15 The JSON Web Signature JSON Serialization (JWS-JS) is a means of 16 representing content secured with digital signatures or Message 17 Authentication Codes (MACs) using JavaScript Object Notation (JSON) 18 data structures. This specification describes a means of 19 representing secured content as a JSON data object (as opposed to the 20 JWS specification, which uses a compact serialization with a URL-safe 21 representation). It enables multiple digital signatures and/or MACs 22 to be applied to the same content (unlike JWS). Cryptographic 23 algorithms and identifiers used with this specification are described 24 in the separate JSON Web Algorithms (JWA) specification. The JSON 25 Serialization for related encryption functionality is described in 26 the separate JSON Web Encryption JSON Serialization (JWE-JS) 27 specification. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 17, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. JSON Serialization . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Example JWS-JS . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 70 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 75 Appendix B. Document History . . . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 The JSON Web Signature JSON Serialization (JWS-JS) is a format for 81 representing content secured with digital signatures or Message 82 Authentication Codes (MACs) as a JavaScript Object Notation (JSON) 83 [RFC4627] object. It enables multiple digital signatures and/or MACs 84 to be applied to the same content (unlike JWS [JWS]). The digital 85 signature and MAC mechanisms used are independent of the type of 86 content being secured, allowing arbitrary content to be secured. 87 Cryptographic algorithms and identifiers used with this specification 88 are described in the separate JSON Web Algorithms (JWA) [JWA] 89 specification. The JSON Serialization for related encryption 90 functionality is described in the separate JSON Web Encryption JSON 91 Serialization (JWE-JS) [JWE-JS] specification. 93 1.1. Notational Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in Key words for use in 98 RFCs to Indicate Requirement Levels [RFC2119]. 100 2. Terminology 102 This specification uses the same terminology as the JSON Web 103 Signature (JWS) [JWS] specification. 105 3. JSON Serialization 107 The JSON Serialization represents secured content as a JSON object 108 with members for each of three constituent parts: a "headers" member 109 whose value is a non-empty array of Encoded JWS Header values, a 110 "payload" member whose value is an Encoded JWS Payload value, and a 111 "signatures" member whose value is a non-empty array of Encoded JWS 112 Signature values, where the number of elements in both arrays is the 113 same. 115 Unlike the compact serialization used by JWSs, content using the JSON 116 Serialization MAY be secured with more than one digital signature 117 and/or MAC value. Each is represented as an Encoded JWS Signature in 118 the "signatures" member array. For each, there is a corresponding 119 "headers" member array element that is an Encoded JWS Header 120 specifying the digital signature or MAC applied to the Encoded JWS 121 Header value and the Encoded JWS Payload value to create the JWS 122 Signature value. Therefore, the syntax is: 124 {"headers":["
",...,"
"], 125 "payload":"", 126 "signatures":["",...,""] 127 } 129 The contents of the Encoded JWS Header, Encoded JWS Payload, and 130 Encoded JWS Signature values are exactly as specified in JSON Web 131 Signature (JWS) [JWS]. They are interpreted and validated in the 132 same manner, with each corresponding "headers" and "signatures" value 133 being created or validated together. The arrays MUST have the same 134 number of elements. 136 The i'th JWS Signature value is computed on the JWS Secured Input 137 corresponding to the concatenation of the i'th Encoded JWS Header, a 138 period ('.') character, and the Encoded JWS Payload in the same 139 manner described in the JWS specification. This has the desirable 140 result that each Encoded JWS signature value in the "signatures" 141 array is identical to the value that would be used for the same 142 header and payload in a JWS. 144 4. Example JWS-JS 146 This section contains an example using the JWS JSON Serialization. 147 This example demonstrates the capability for conveying multiple 148 digital signatures and/or MACs for the same payload. 150 The Encoded JWS Payload used in this example is the same as used in 151 the examples in Appendix A of JWS (with line breaks for display 152 purposes only): 154 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt 155 cGxlLmNvbS9pc19yb290Ijp0cnVlfQ 157 Two digital signatures are used in this example: an RSA SHA-256 158 signature, for which the header and signature values are the same as 159 in Appendix A.2 of JWS, and an ECDSA P-256 SHA-256 signature, for 160 which the header and signature values are the same as in Appendix A.3 161 of JWS. The two Decoded JWS Header Segments used are: 163 {"alg":"RS256"} 165 and: 167 {"alg":"ES256"} 169 Since the computations of the JWS Header and JWS Signature values are 170 the same as in Appendix A.2 and Appendix A.3 of JWS, they are not 171 repeated here. 173 The complete JSON Web Signature JSON Serialization (JWS-JS) for these 174 values is as follows (with line breaks for display purposes only): 176 {"headers":[ 177 "eyJhbGciOiJSUzI1NiJ9", 178 "eyJhbGciOiJFUzI1NiJ9"], 179 "payload":"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0 180 dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ", 181 "signatures":[ 182 "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ 183 mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBY 184 NX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Q 185 e7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noO 186 PqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmt 187 VrBp0igcN_IoypGlUPQGe77Rw", 188 "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS 189 lSApmWQxfKTUJqPP3-Kg6NU1Q"] 190 } 192 5. IANA Considerations 194 This specification makes no requests of IANA. 196 6. Security Considerations 198 The security considerations for this specification are the same as 199 those for the JSON Web Signature (JWS) [JWS] specification. 201 7. Open Issues 203 [[ to be removed by the RFC editor before publication as an RFC ]] 205 The following items remain to be considered or done in this draft: 207 o Track changes that occur in the JWS spec. 209 8. References 211 8.1. Normative References 213 [JWA] Jones, M., "JSON Web Algorithms (JWA)", July 2012. 215 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 216 Signature (JWS)", July 2012. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC4627] Crockford, D., "The application/json Media Type for 222 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 224 8.2. Informative References 226 [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", 227 September 2010. 229 [JWE-JS] Jones, M., "JSON Web Encryption JSON Serialization 230 (JWE-JS)", July 2012. 232 [MagicSignatures] 233 Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic 234 Signatures", January 2011. 236 Appendix A. Acknowledgements 238 JSON serializations for secured content were previously explored by 239 Magic Signatures [MagicSignatures] and JSON Simple Sign [JSS]. 241 Appendix B. Document History 243 [[ to be removed by the RFC editor before publication as an RFC ]] 245 -01 247 o Generalized language to refer to Message Authentication Codes 248 (MACs) rather than Hash-based Message Authentication Codes 249 (HMACs). 251 -00 253 o Renamed draft-jones-json-web-signature-json-serialization to 254 draft-jones-jose-jws-json-serialization to have "jose" be in the 255 document name so it can be included in the Related Documents list 256 at http://datatracker.ietf.org/wg/jose/. No normative changes. 258 draft-jones-json-web-signature-json-serialization-02 259 o Tracked editorial changes made to the JWS spec. 261 draft-jones-json-web-signature-json-serialization-01 263 o Corrected the Magic Signatures reference. 265 draft-jones-json-web-signature-json-serialization-00 267 o Created the initial version incorporating JOSE working group input 268 and drawing from the JSON Serialization previously proposed in 269 draft-jones-json-web-token-01. 271 Authors' Addresses 273 Michael B. Jones 274 Microsoft 276 Email: mbj@microsoft.com 277 URI: http://self-issued.info/ 279 John Bradley 280 independent 282 Email: ve7jtb@ve7jtb.com 284 Nat Sakimura 285 Nomura Research Institute 287 Email: n-sakimura@nri.co.jp