idnits 2.17.1 draft-jordan-jws-ct-03.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 (23 March 2021) is 1130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Jordan, Ed. 3 Internet-Draft Broadcom 4 Intended status: Informational S. Erdtman 5 Expires: 24 September 2021 Spotify AB 6 A. Rundgren 7 Independent 8 23 March 2021 10 JWS Clear Text JSON Signature Option (JWS/CT) 11 draft-jordan-jws-ct-03 13 Abstract 15 This document describes a method for extending the scope of the JSON 16 Web Signature (JWS) standard, called JWS/CT. By combining the 17 detached mode of JWS with the JSON Canonicalization Scheme (JCS), 18 JWS/CT enables JSON objects to remain in the JSON format after being 19 signed (also known as "Clear Text" signing). In addition to 20 supporting a consistent data format, this arrangement also simplifies 21 documentation, debugging, and logging. The ability to embed signed 22 JSON objects in other JSON objects, makes the use of counter- 23 signatures straightforward. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 24 September 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Detailed Operation . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Signature Creation . . . . . . . . . . . . . . . . . . . 4 59 3.1.1. Create the JSON Object to be Signed . . . . . . . . . 4 60 3.1.2. Canonicalize the JSON Object to be Signed . . . . . . 4 61 3.1.3. Generate a JWS String . . . . . . . . . . . . . . . . 5 62 3.1.4. Assemble the Signed JSON Object . . . . . . . . . . . 5 63 3.2. Signature Validation . . . . . . . . . . . . . . . . . . 6 64 3.2.1. Parse the Signed JSON Object . . . . . . . . . . . . 6 65 3.2.2. Fetch the Signature Property String . . . . . . . . . 6 66 3.2.3. Remove the Signature Property String . . . . . . . . 6 67 3.2.4. Canonicalize the Remaining JSON Object . . . . . . . 7 68 3.2.5. Validate the JWS String . . . . . . . . . . . . . . . 7 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 6.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. Open-Source Implementations . . . . . . . . . . . . 10 75 Appendix B. JWS/CT Application Notes . . . . . . . . . . . . . . 10 76 B.1. Counter Signatures . . . . . . . . . . . . . . . . . . . 10 77 B.2. Detached Signatures . . . . . . . . . . . . . . . . . . . 11 78 B.3. Array of Signatures . . . . . . . . . . . . . . . . . . . 13 79 Appendix C. Test Vector Using the ES256 Algorithm . . . . . . . 14 80 Appendix D. Enhanced JWS Processing Option . . . . . . . . . . . 15 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Document History . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 This specification introduces a method for augmenting data expressed 88 in the JSON [RFC8259] notation, with enveloped signatures, similar to 89 the scheme used in the XML Signature [XMLDSIG] standard. For 90 interoperability reasons this specification constrains JSON objects 91 to the I-JSON [RFC7493] subset. 93 To avoid "reinventing the wheel", this specification leverages the 94 JSON Web Signature (JWS) [RFC7515] standard. 96 By building on the detached mode of JWS in combination with the JSON 97 Canonicalizion Scheme (JCS) [RFC8785], JSON objects to be signed can 98 be kept in the JSON format. This arrangement is here referred to as 99 JWS/CT, where CT stands for "Clear Text" signing. 101 The primary motivations for keeping signed JSON objects in the JSON 102 format include simplified documentation, debugging, and logging, as 103 well as for maintaining a consistent message structure. 105 Another target is HTTP-based signature schemes that currently utilize 106 HTTP header values for holding detached signatures. By rather using 107 the method described herein, signed JSON-formatted HTTP requests and 108 responses may be self-contained and thus be serializable. The latter 109 facilitates such data to be 111 * stored in databases 112 * passed through intermediaries 113 * embedded in other JSON objects 114 * counter-signed 116 without losing the ability to (at any time) verify signatures. 118 Appendix B outlines different ways to handle multiple signatures 119 including counter-signing using JWS/CT. 121 The intended audiences of this document are JSON tool vendors as well 122 as designers of JSON-based cryptographic solutions. 124 2. Terminology 126 Note that this document is not on the IETF standards track. However, 127 a conformant implementation is supposed to adhere to the specified 128 behavior for security and interoperability reasons. This text uses 129 BCP 14 to describe that necessary behavior. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. Detailed Operation 139 This section describes the details related to signing and validating 140 signatures based on this specification. 142 The following characteristics are vital to know for prospective JWS/ 143 CT implementers and users: 145 * With the exception of the reliance on the detached mode described 146 in Appendix F of JWS [RFC7515], JWS/CT does not alter the JWS 147 signature creation process, validation process, or format. This 148 means that the contents of JWS headers as well as things related 149 to signature algorithms and cryptographic keys are out of scope 150 for this specification. A slightly enhanced processing option is 151 outlined in Appendix D. 153 * JWS/CT exclusively depends on the JWS Compact Serialization mode. 155 * JCS [RFC8785] constrains JSON objects to the I-JSON [RFC7493] 156 subset. 158 The signature creation and signature validation sections feature 159 examples using the "HS256" JOSE algorithm [RFC7518] with a 256-bit 160 key having the following value, here expressed as hexadecimal bytes: 162 7f dd 85 1a 3b 9d 2d af c5 f0 d0 00 30 e2 2b 93 163 43 90 0c d4 2e de 49 48 56 8a 4a 2e e6 55 29 1a 165 3.1. Signature Creation 167 The following sub-sections describe how JSON objects can be signed 168 according to the JWS/CT specification. 170 3.1.1. Create the JSON Object to be Signed 172 Create or parse the JSON object to be signed. 174 For illustrating the subsequent operations the following example 175 object is used: 177 { 178 "statement": "Hello signed world!", 179 "otherProperties": [2000, true] 180 } 182 3.1.2. Canonicalize the JSON Object to be Signed 184 Use the result of the previous step as input to the canonicalization 185 process described in JCS [RFC8785]. 187 Applied to the example, the following JSON string should be 188 generated: 190 {"otherProperties":[2000,true],"statement":"Hello signed world!"} 191 After encoding the string above in the UTF-8 [UNICODE] format, the 192 following bytes (here in hexadecimal notation) should be generated: 194 7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30 195 30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22 196 48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d 198 3.1.3. Generate a JWS String 200 Use the result of the previous step as "JWS Payload" to the signature 201 process described in Appendix F of JWS [RFC7515]. 203 For the example, the JWS header is assumed to be: 205 {"alg":"HS256"} 207 The resulting JWS string should then after payload removal and using 208 the key specified in Section 3, reads as follows: 210 eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 212 3.1.4. Assemble the Signed JSON Object 214 Before a complete signed object can be created, a dedicated top-level 215 property for holding the JWS signature string needs to be defined. 216 The only requirement is that this property MUST NOT clash with any 217 other top-level property name. The JWS string itself MUST be 218 supplied as a JSON string argument to the signature property. 220 For the example, the property name "signature" is assumed to be the 221 designated holder of the JWS string. Equipped with a signature 222 property, the JWS string from the previous section, and the original 223 JSON example, the process above should result in the following, now 224 signed JSON object (with a line break in the "signature" property for 225 display purposes only): 227 { 228 "statement": "Hello signed world!", 229 "otherProperties": [2000, true], 230 "signature": "eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar 231 DtJeSxH2uLU0DhqQP5Zjw4" 232 } 234 Note: one could equally well apply the signature to the canonicalized 235 version of the JSON object. However, the rearrangement of properties 236 (performed by JCS), may sometimes be considered an issue from a 237 "human" point of view, while computing-wise the order of JSON 238 properties has no impact on the outcome. 240 3.2. Signature Validation 242 The following sub-sections describe how JSON objects signed according 243 to the JWS/CT specification can be validated. 245 3.2.1. Parse the Signed JSON Object 247 Parse the JSON object that is anticipated to be signed. If the 248 parsing is unsuccessful, the operation MUST cause a compliant 249 implementation to terminate with an appropriate error. 251 To illustrate the subsequent operations the signed JSON object 252 featured in Section 3.1.4 is used as example. 254 3.2.2. Fetch the Signature Property String 256 After successful parsing, retrieve the designated JSON top-level 257 property holding the JWS string. If the property is missing or its 258 argument is not a JSON string value, the operation MUST cause a 259 compliant implementation to terminate with an appropriate error. 261 For the example, where the property named "signature" is assumed to 262 hold the JWS string, the operation above should return the following 263 string: 265 eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 267 3.2.3. Remove the Signature Property String 269 Since the signature is calculated over the actual JSON object data, 270 the designated signature property and its argument MUST be removed 271 from the signed JSON object. 273 If applied to the example the resulting JSON object should read as 274 follows: 276 { 277 "statement": "Hello signed world!", 278 "otherProperties": [2000, true] 279 } 281 Note: JSON tools usually by default remove whitespace. In addition, 282 the original ordering of properties may not always be honored. 283 However, none of this has (due to the canonicalization performed by 284 JCS), any impact on the result. 286 3.2.4. Canonicalize the Remaining JSON Object 288 Use the result of the previous step as input to the canonicalization 289 process described in JCS [RFC8785]. 291 If applied to the example the result of the process above should read 292 as follows: 294 {"otherProperties":[2000,true],"statement":"Hello signed world!"} 296 After encoding the string above in the UTF-8 [UNICODE] format, the 297 following bytes (here in hexadecimal notation) should be generated: 299 7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30 300 30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22 301 48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d 303 3.2.5. Validate the JWS String 305 After extracting the detached mode JWS string and canonicalizing the 306 JSON object (to retrieve the "JWS Payload"), the JWS string MUST be 307 restored as described in https://tools.ietf.org/html/ 308 rfc7515#appendix-F of JWS [RFC7515]. The actual JWS validation 309 procedure is not specified here because it is covered by [RFC7515] 310 and also depends on application-specific policies like: 312 * Accepted JWS signature algorithms 313 * Accepted and/or required JWS header elements 314 * Signature key lookup methods 316 If the validation process for some reason fails, the operation MUST 317 cause a compliant implementation to terminate with an appropriate 318 error. 320 For the example, validation is straightforward since both the 321 algorithm and the key to use are predefined (see Section 3). The 322 input string to a JWS validator should after the process step above 323 read as follows (with line breaks for display purposes only): 325 eyJhbGciOiJIUzI1NiJ9.eyJvdGhlclByb3BlcnRpZXMiOlsyMDAwLHRydWVdLCJzdGF0 326 ZW1lbnQiOiJIZWxsbyBzaWduZWQgd29ybGQhIn0.VHVItCBCb8Q5CI-49imarDtJeSxH2 327 uLU0DhqQP5Zjw4 329 4. IANA Considerations 331 This document has no IANA actions. 333 5. Security Considerations 335 This specification inherits all the security considerations of JWS 336 [RFC7515] and JCS [RFC8785]. 338 In similarity to any other signature specification, it is crucial 339 that signatures are verified before acting on the signed payload. 341 However, poorly tested software components may also introduce 342 security issues. Consider the following JSON example: 344 { 345 "fromAccount": "1234", 346 "toAccount": "4567", 347 "amount": { 348 "value": 100, 349 "currency":"USD" 350 } 351 } 353 A non-compliant JCS implementation could return 355 {"amount":{},"fromAccount":"1234","toAccount":"4567"} 357 giving an attacker the ability to change "amount" to whatever it 358 wants. Note though that this attack presumes that the consumer and 359 producer use implementations broken in the same way, otherwise the 360 signature would not validate. 362 For usage in a wider community, the name of the designated signature 363 property becomes a critical factor that MUST be documented and 364 communicated. However, in a properly designed system, a faulty or 365 missing signature MUST "only" lead to failed operation, and not to a 366 security breach. 368 6. References 370 6.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 378 DOI 10.17487/RFC7493, March 2015, 379 . 381 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 382 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 383 2015, . 385 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 386 DOI 10.17487/RFC7518, May 2015, 387 . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 394 Interchange Format", STD 90, RFC 8259, 395 DOI 10.17487/RFC8259, December 2017, 396 . 398 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON 399 Canonicalization Scheme (JCS)", RFC 8785, 400 DOI 10.17487/RFC8785, June 2020, 401 . 403 [UNICODE] The Unicode Consortium, "The Unicode Standard", 404 . 406 6.2. Informative References 408 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 409 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 410 . 412 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 413 DOI 10.17487/RFC7517, May 2015, 414 . 416 [RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload 417 Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, 418 . 420 [SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 421 2015, . 424 [XMLDSIG] W3C, "XML Signature Syntax and Processing Version 1.1", 425 W3C Recommendation, April 2013, 426 . 428 Appendix A. Open-Source Implementations 430 Due to the simplicity of this specification, there is hardly a need 431 for specific support software. However, JCS which is (at the time of 432 writing), a relatively new design, may be fetched as a separate 433 component for multiple platforms. The following open-source 434 implementations have been verified to be compatible with JCS: 436 * JavaScript: 438 * Java: 441 * Go: 444 * .NET/C#: 447 * Python: 450 Appendix B. JWS/CT Application Notes 452 The following application notes are not a part of the JWS/CT core; 453 they show how JWS/CT can be used in contexts involving multiple 454 signatures. 456 B.1. Counter Signatures 458 Consider the following JWS/CT object showing an imaginary real estate 459 business record (with a line break in the "signature" property for 460 display purposes only): 462 { 463 "gps": [38.89768255588178, -77.03658644893932], 464 "object": { 465 "type": "house", 466 "price": "$635,000" 467 }, 468 "role": "buyer", 469 "name": "John Smith", 470 "timeStamp": "2020-11-08T13:56:08Z", 471 "signature": "eyJhbGciOiJIUzI1NiJ9..zlPMniQiz4Eie86oK4xo25z 472 uyW92csiDqyiQrF6R5ug" 473 } 475 The signature above was created using the example key from Section 3. 477 Adding a notary signature on top of this could be performed by 478 embedding the former object as follows (with line breaks in the 479 "signature" properties for display purposes only): 481 { 482 "attesting": { 483 "gps": [38.89768255588178, -77.03658644893932], 484 "object": { 485 "type": "house", 486 "price": "$635,000" 487 }, 488 "role": "buyer", 489 "name": "John Smith", 490 "timeStamp": "2020-11-08T13:56:08Z", 491 "signature": "eyJhbGciOiJIUzI1NiJ9..zlPMniQiz4Eie86oK4xo25z 492 uyW92csiDqyiQrF6R5ug" 493 }, 494 "role": "notary", 495 "name": "Carol Lombardi-Jones", 496 "timeStamp": "2020-11-08T13:58:42Z", 497 "signature": "eyJhbGciOiJFUzI1NiJ9..AVmJGUWp1JD0pf2j1_UQWXbf- 498 qj-2RWxOnyAXihd4POKbnjWqqSBmHPNfgMQFH_s5sXHkIOkDZe2nShqEJOEVA" 499 } 501 A side effect of this arrangement is that the notary's signature 502 signs not only the notary data, but the buyer's data and signature as 503 well. In most cases this way of adding signatures is advantageous 504 since it maintains the actual order of signing events which also 505 cannot be tampered with without invalidating the outermost signature. 507 Note that all properties above including "signature" are application 508 specific. 510 The notary's signature was created using the example key from 511 Appendix C. 513 B.2. Detached Signatures 515 In the case the signing entities are "peers" or are unrelated to each 516 other, counter-signatures like described in Appendix B.1 are not 517 applicable since they presume a specific flow. For supporting 518 independent or asynchronous signers targeting a common document or 519 data object, an imaginable solution is using a scheme where each 520 signer calculates a hash of the target document/data and includes the 521 hash together with signer-specific meta data like the following: 523 { 525 <> 527 "signers": [{ 528 "sha256": "<>", 530 <> 532 "signature": "<>" 533 },{ 534 "sha256": "<>", 536 <> 538 "signature": "<>" 539 }] 540 } 542 In this case the object to sign would not be limited to JSON; it 543 could for example be a PDF document hosted on a specific URL. Note 544 that the relying party would have to update the structure for each 545 signature received. In some cases a database would probably be more 546 useful for holding individual signatures since a database can cope 547 with any number of signers as well as keeping track of who have 548 actually signed. The latter is crucial for things like international 549 treaties and company board statements. 551 Note that although "signers", "sha256", and "signature" are 552 application specific property names, the objects in the "signers" 553 array are assumed to be fully conformant with the JWS/CT 554 specification. 556 The following example shows a possible detached signature solution 557 (with line breaks in the "signature" properties for display purposes 558 only): 560 { 561 "statement": "Hello signed world!", 562 "otherProperties": [2000, true], 563 "signers": [{ 564 "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70", 565 "timeStamp": "2020-11-18T07:45:28Z", 566 "name": "Alice", 567 "signature": "eyJhbGciOiJIUzI1NiJ9..AE7CnzSYsaspE3yrdsAwi 568 avd3IdWtdAmDE8FRMwYLA8" 569 },{ 570 "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70", 571 "timeStamp": "2020-11-18T08:03:40Z", 572 "name": "Bob", 573 "signature": "eyJhbGciOiJFUzI1NiJ9..0tNLy0pLcHUjPhhorpKd5 574 7a8zTPeqlrOjATiSlPQ1vciE99x6mHmow04tPbJS8dqSqO9c4RkKW6jeL4ZyWpXLA" 575 }] 576 } 578 Notes: 580 * "Alice" used the example key from Section 3 while "Bob" used the 581 example key specified in Appendix C. 583 * The "sha256" properties hold base64url-encoded [RFC4648], 584 SHA256-hashes [SHS] of the canonicalized data created in 585 Section 3.1.2. 587 * This arrangement requires a two-step validation process where each 588 JWS/CT object in the "signers" array is individually validated, as 589 well as having its "sha256" property compared with the actual hash 590 of the canonicalized common data. 592 B.3. Array of Signatures 594 Another possibility supporting multiple and independent signatures is 595 collecting JWS signature strings in a JSON array object according to 596 the following scheme: 598 { 600 <> 602 "<>": ["<>", 603 "<>", 604 . 605 "<>"] 606 } 607 Processing would follow Section 3, with the addition that each 608 signature is dealt with individually. 610 Compared to Appendix B.2, signature arrays imply that possible 611 signer-specific meta-data is supplied as JWS extensions in the 612 associated signature's base64url-encoded header. 614 By combining the example used in Section 3 with the test vector in 615 Appendix C, a valid signature array object could be as follows (with 616 line breaks in the "signatures" property for display purposes only): 618 { 619 "statement": "Hello signed world!", 620 "otherProperties": [2000, true], 621 "signatures": ["eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar 622 DtJeSxH2uLU0DhqQP5Zjw4", 623 "eyJhbGciOiJFUzI1NiJ9..ENP0j0-QPsA7N_Mg1-RMN 624 9IxapeTWtQwR7sPUqEiSNHPuV_fqSdRqqkLOlBdV01cc4lSJdn1XCv-ZHYdZ9t3kA"] 625 } 627 Note that "signatures" is not a keyword, it was only selected to 628 highlight the fact that there are multiple signatures. 630 Appendix C. Test Vector Using the ES256 Algorithm 632 This appendix shows how a signed version of the JSON example object 633 in Section 3.1.1 would look like if applying the "ES256" JOSE 634 algorithm [RFC7518] (with a line break in the "signature" property 635 for display purposes only): 637 { 638 "statement": "Hello signed world!", 639 "otherProperties": [2000, true], 640 "signature": "eyJhbGciOiJFUzI1NiJ9..ENP0j0-QPsA7N_Mg1-RMN 641 9IxapeTWtQwR7sPUqEiSNHPuV_fqSdRqqkLOlBdV01cc4lSJdn1XCv-ZHYdZ9t3kA" 642 } 644 The example above depends on a JWS header holding the algorithm 645 {"alg":"ES256"}, and the following private key, here expressed in the 646 JWK [RFC7517] format: 648 { 649 "kty": "EC", 650 "crv": "P-256", 651 "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", 652 "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg", 653 "d": "6XxMFXhcYT5QN9w5TIg2aSKsbcj-pj4BnZkK7ZOt4B8" 654 } 655 Note that signing with the "ES256" algorithm returns different 656 results for each signature due to a randomization step in the 657 signature computation process. 659 Appendix D. Enhanced JWS Processing Option 661 By default, JWS/CT uses the JWS compact serialization mode "as is". 662 As a consequence, a technically redundant, internal-only, base64url 663 encoding step is performed over the "JWS Payload". Although the 664 performance hit should be marginal for most real-world applications, 665 a possibility is using the "Unencoded Payload" mode of RFC7797 666 [RFC7797]. However, this requires that the JWS implementation 667 supports the "b64":false and "crit":["b64"] header elements implied 668 by RFC7797, effectively rendering the RFC7797 mode as an implementer 669 option for specific communities. 671 Acknowledgements 673 People who have contributed directly and indirectly with valuable 674 input to this specification include Vladimir Dzhuvinov, Freddi Gyara, 675 and Filip Skokan. 677 Document History 679 [[ This section to be removed by the RFC Editor before publication as 680 an RFC ]] 682 Version 00: 684 * Initial publication. 686 Version 01: 688 * Added paragraph to Abstract. 690 * Updated Security Considerations. 692 Version 02: 694 * Changed alternative test key to ES256/P-256. 696 * Moved RFC7797 to an appendix. 698 * Changed to only be used on keywords. 700 * Added some clarity to detached signatures. 702 Version 03: 704 * Language changes suggested by ISE. 706 Authors' Addresses 708 Bret Jordan (editor) 709 Broadcom 710 1320 Ridder Park Drive 711 San Jose, CA 95131 712 United States of America 714 Email: bret.jordan@broadcom.com 716 Samuel Erdtman 717 Spotify AB 718 Birger Jarlsgatan 61, 4tr 719 SE-113 56 Stockholm 720 Sweden 722 Email: erdtman@spotify.com 724 Anders Rundgren 725 Independent 726 Montpellier 727 France 729 Email: anders.rundgren.net@gmail.com 730 URI: https://www.linkedin.com/in/andersrundgren/