Skip to main content

JWS Clear Text JSON Signature Option (JWS/CT)
draft-jordan-jws-ct-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Bret Jordan , Samuel Erdtman , Anders Rundgren
Last updated 2021-03-05 (Latest revision 2021-01-26)
RFC stream Independent Submission
Formats
Additional resources
Stream ISE state Submission Received
Consensus boilerplate Unknown
Document shepherd Eliot Lear
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to rfc-ise@rfc-editor.org
draft-jordan-jws-ct-02
Network Working Group                                     B. Jordan, Ed.
Internet-Draft                                                  Broadcom
Intended status: Informational                                S. Erdtman
Expires: 30 July 2021                                         Spotify AB
                                                             A. Rundgren
                                                             Independent
                                                         26 January 2021

             JWS Clear Text JSON Signature Option (JWS/CT)
                         draft-jordan-jws-ct-02

Abstract

   This document describes a method for extending the scope of the JSON
   Web Signature (JWS) standard, called JWS/CT.  By combining the
   detached mode of JWS with the JSON Canonicalization Scheme (JCS),
   JWS/CT enables JSON objects to remain in the JSON format after being
   signed (aka "Clear Text" signing).  In addition to supporting a
   consistent data format, this arrangement also simplifies
   documentation, debugging, and logging.  The ability to embed signed
   JSON objects in other JSON objects, makes the use of counter-
   signatures straightforward.

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 https://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 30 July 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jordan, et al.            Expires 30 July 2021                  [Page 1]
Internet-Draft                   JWS/CT                     January 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Detailed Operation  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Signature Creation  . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Create the JSON Object to be Signed . . . . . . . . .   4
       3.1.2.  Canonicalize the JSON Object to be Signed . . . . . .   4
       3.1.3.  Generate a JWS String . . . . . . . . . . . . . . . .   5
       3.1.4.  Assemble the Signed JSON Object . . . . . . . . . . .   5
     3.2.  Signature Validation  . . . . . . . . . . . . . . . . . .   6
       3.2.1.  Parse the Signed JSON Object  . . . . . . . . . . . .   6
       3.2.2.  Fetch the Signature Property String . . . . . . . . .   6
       3.2.3.  Remove the Signature Property String  . . . . . . . .   6
       3.2.4.  Canonicalize the Remaining JSON Object  . . . . . . .   7
       3.2.5.  Validate the JWS String . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Open-Source Implementations  . . . . . . . . . . . .  10
   Appendix B.  JWS/CT Application Notes . . . . . . . . . . . . . .  10
     B.1.  Counter Signatures  . . . . . . . . . . . . . . . . . . .  10
     B.2.  Detached Signatures . . . . . . . . . . . . . . . . . . .  12
     B.3.  Array of Signatures . . . . . . . . . . . . . . . . . . .  13
   Appendix C.  Test Vector Using the ES256 Algorithm  . . . . . . .  14
   Appendix D.  Enhanced JWS Processing Option . . . . . . . . . . .  15
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
   Document History  . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This specification introduces a method for augmenting data expressed
   in the JSON [RFC8259] notation, with enveloped signatures, similar to
   the scheme used in the XML Signature [XMLDSIG] standard.  For
   interoperability reasons this specification constrains JSON objects
   to the I-JSON [RFC7493] subset.

   To avoid "reinventing the wheel", this specification leverages the
   JSON Web Signature (JWS) [RFC7515] standard.

Jordan, et al.            Expires 30 July 2021                  [Page 2]
Internet-Draft                   JWS/CT                     January 2021

   By building on the detached mode of JWS in combination with the JSON
   Canonicalizion Scheme (JCS) [RFC8785], JSON objects to be signed can
   be kept in the JSON format.  This arrangement is here referred to as
   JWS/CT, where CT stands for "Clear Text" signing.

   The primary motivations for keeping signed JSON objects in the JSON
   format include _simplified documentation_, _debugging_, and
   _logging_, as well as for maintaining a _consistent message
   structure_.

   Another target is HTTP-based signature schemes that currently utilize
   HTTP header values for holding detached signatures.  By rather using
   the method described herein, signed JSON-formatted HTTP requests and
   responses may be self-contained and thus be _serializable_.  The
   latter facilitates such data to be

   *  stored in databases
   *  passed through intermediaries
   *  embedded in other JSON objects
   *  counter-signed

   without losing the ability to (at any time) verify signatures.

   Appendix B outlines different ways to handle multiple signatures
   including counter-signing using JWS/CT.

   The intended audiences of this document are JSON tool vendors as well
   as designers of JSON-based cryptographic solutions.

2.  Terminology

   Note that this document is not on the IETF standards track.  However,
   a conformant implementation is supposed to adhere to the specified
   behavior for security and interoperability reasons.  This text uses
   BCP 14 to describe that necessary behavior.

   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.

3.  Detailed Operation

   This section describes the details related to signing and validating
   signatures based on this specification.

Jordan, et al.            Expires 30 July 2021                  [Page 3]
Internet-Draft                   JWS/CT                     January 2021

   The following characteristics are vital to know for prospective JWS/
   CT implementers and users:

   *  With the exception of the reliance on the detached mode described
      in Appendix F (https://tools.ietf.org/html/rfc7515#appendix-F) of
      JWS, JWS/CT does not alter the JWS signature creation process,
      validation process, or format.  This means that the contents of
      JWS headers as well as things related to signature algorithms and
      cryptographic keys are out of scope for this specification.  A
      slightly enhanced processing option is outlined in Appendix D.

   *  JWS/CT exclusively depends on the JWS _Compact Serialization_
      mode.

   *  JCS [RFC8785] constrains JSON objects to the I-JSON [RFC7493]
      subset.

   The signature creation and signature validation sections feature
   samples using the "HS256" JOSE algorithm [RFC7518] with a 256-bit key
   having the following value, here expressed as hexadecimal bytes:

   7f dd 85 1a 3b 9d 2d af c5 f0 d0 00 30 e2 2b 93
   43 90 0c d4 2e de 49 48 56 8a 4a 2e e6 55 29 1a

3.1.  Signature Creation

   The following sub-sections describe how JSON objects can be signed
   according to the JWS/CT specification.

3.1.1.  Create the JSON Object to be Signed

   Create or parse the JSON object to be signed.

   For illustrating the subsequent operations the following sample
   object is used:

   {
     "statement": "Hello signed world!",
     "otherProperties": [2000, true]
   }

3.1.2.  Canonicalize the JSON Object to be Signed

   Use the result of the previous step as input to the canonicalization
   process described in JCS [RFC8785].

   Applied to the sample, the following JSON string should be generated:

Jordan, et al.            Expires 30 July 2021                  [Page 4]
Internet-Draft                   JWS/CT                     January 2021

   {"otherProperties":[2000,true],"statement":"Hello signed world!"}

   After encoding the string above in the UTF-8 [UNICODE] format, the
   following bytes (here in hexadecimal notation) should be generated:

   7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30
   30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22
   48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d

3.1.3.  Generate a JWS String

   Use the result of the previous step as "JWS Payload" to the signature
   process described in https://tools.ietf.org/html/rfc7515#appendix-F
   of JWS.

   For the sample, the JWS header is assumed to be:

   {"alg":"HS256"}

   The resulting JWS string should then after payload removal and using
   the key specified in Section 3, read as follows:

   eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4

3.1.4.  Assemble the Signed JSON Object

   Before a complete signed object can be created, a dedicated top-level
   property for holding the JWS signature string needs to be defined.
   The only requirement is that this property MUST NOT clash with any
   other top-level property name.  The JWS string itself MUST be
   supplied as a JSON string argument ("") to the signature property.

   For the sample, the property name "signature" is assumed to be the
   designated holder of the JWS string.  Equipped with a signature
   property, the JWS string from the previous section, and the original
   JSON sample, the process above should result in the following, now
   signed JSON object (with a line break in the "signature" property for
   display purposes only):

   {
     "statement": "Hello signed world!",
     "otherProperties": [2000, true],
     "signature": "eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar
   DtJeSxH2uLU0DhqQP5Zjw4"
   }

Jordan, et al.            Expires 30 July 2021                  [Page 5]
Internet-Draft                   JWS/CT                     January 2021

   Note: one could equally well apply the signature to the canonicalized
   version of the JSON object.  However, the rearrangement of properties
   (performed by JCS), may sometimes be considered an issue from a
   "human" point of view, while computing-wise the order of JSON
   properties has no impact on the outcome.

3.2.  Signature Validation

   The following sub-sections describe how JSON objects signed according
   to the JWS/CT specification can be validated.

3.2.1.  Parse the Signed JSON Object

   Parse the JSON object that is anticipated to be signed.  If the
   parsing is unsuccessful, the operation MUST cause a compliant
   implementation to terminate with an appropriate error.

   To illustrate the subsequent operations the signed JSON object
   featured in Section 3.1.4 is used as sample.

3.2.2.  Fetch the Signature Property String

   After successful parsing, retrieve the designated JSON top-level
   property holding the JWS string.  If the property is missing or its
   argument is not a JSON string (""), the operation MUST cause a
   compliant implementation to terminate with an appropriate error.

   For the sample, where the property named "signature" is assumed to
   hold the JWS string, the operation above should return the following
   string:

   eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4

3.2.3.  Remove the Signature Property String

   Since the signature is calculated over the actual JSON object data,
   the designated signature property and its argument MUST be removed
   from the signed JSON object.

   If applied to the sample the resulting JSON object should read as
   follows:

   {
     "statement": "Hello signed world!",
     "otherProperties": [2000, true]
   }

Jordan, et al.            Expires 30 July 2021                  [Page 6]
Internet-Draft                   JWS/CT                     January 2021

   Note: JSON tools usually by default remove whitespace.  In addition,
   the original ordering of properties may not always be honored.
   However, none of this has (due to the canonicalization performed by
   JCS), any impact on the result.

3.2.4.  Canonicalize the Remaining JSON Object

   Use the result of the previous step as input to the canonicalization
   process described in JCS [RFC8785].

   If applied to the sample the result of the process above should read
   as follows:

   {"otherProperties":[2000,true],"statement":"Hello signed world!"}

   After encoding the string above in the UTF-8 [UNICODE] format, the
   following bytes (here in hexadecimal notation) should be generated:

   7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30
   30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22
   48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d

3.2.5.  Validate the JWS String

   After extracting the detached mode JWS string and canonicalizing the
   JSON object (to retrieve the "JWS Payload"), the JWS string MUST be
   restored as described in https://tools.ietf.org/html/
   rfc7515#appendix-F of JWS [RFC7515].  The actual JWS validation
   procedure is not specified here because it is covered by [RFC7515]
   and also depends on application-specific policies like:

   *  Accepted JWS signature algorithms
   *  Accepted and/or required JWS header elements
   *  Signature key lookup methods

   If the validation process for some reason fails, the operation MUST
   cause a compliant implementation to terminate with an appropriate
   error.

   For the sample, validation is straightforward since both the
   algorithm and the key to use are predefined (see Section 3).  The
   input string to a JWS validator should after the process step above
   read as follows (with line breaks for display purposes only):

   eyJhbGciOiJIUzI1NiJ9.eyJvdGhlclByb3BlcnRpZXMiOlsyMDAwLHRydWVdLCJzdGF0
   ZW1lbnQiOiJIZWxsbyBzaWduZWQgd29ybGQhIn0.VHVItCBCb8Q5CI-49imarDtJeSxH2
   uLU0DhqQP5Zjw4

Jordan, et al.            Expires 30 July 2021                  [Page 7]
Internet-Draft                   JWS/CT                     January 2021

4.  IANA Considerations

   This document has no IANA actions.

5.  Security Considerations

   This specification inherits all the security considerations of JWS
   [RFC7515] and JCS [RFC8785].

   In similarity to any other signature specification, it is crucial
   that signatures are verified before acting on the signed payload.

   However, poorly tested software components may also introduce
   security issues.  Consider the following JSON example:

   {
     "fromAccount": "1234",
     "toAccount": "4567",
     "amount": {
       "value": 100,
       "currency":"USD"
     }
   }

   A non-compliant JCS implementation could return

   {"amount":{},"fromAccount":"1234","toAccount":"4567"}

   giving an attacker the ability to change "amount" to whatever it
   wants.  Note though that this attack presumes that the consumer and
   producer use implementations broken in the same way, otherwise the
   signature would not validate.

   For usage in a wider community, the name of the designated signature
   property becomes a critical factor that MUST be documented and
   communicated.  However, in a properly designed system, a faulty or
   missing signature MUST "only" lead to failed operation, and not to a
   security breach.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Jordan, et al.            Expires 30 July 2021                  [Page 8]
Internet-Draft                   JWS/CT                     January 2021

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <https://www.rfc-editor.org/info/rfc7493>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/info/rfc7518>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
              <https://www.unicode.org/versions/latest/>.

6.2.  Informative References

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7797]  Jones, M., "JSON Web Signature (JWS) Unencoded Payload
              Option", RFC 7797, DOI 10.17487/RFC7797, February 2016,
              <https://www.rfc-editor.org/info/rfc7797>.

   [SHS]      NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August
              2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

Jordan, et al.            Expires 30 July 2021                  [Page 9]
Internet-Draft                   JWS/CT                     January 2021

   [XMLDSIG]  W3C, "XML Signature Syntax and Processing Version 1.1",
              W3C Recommendation, April 2013,
              <https://www.w3.org/TR/xmldsig-core1/>.

Appendix A.  Open-Source Implementations

   Due to the simplicity of this specification, there is hardly a need
   for specific support software.  However, JCS which is (at the time of
   writing), a relatively new design, may be fetched as a separate
   component for multiple platforms.  The following open-source
   implementations have been verified to be compatible with JCS:

   *  JavaScript: <https://www.npmjs.com/package/canonicalize>

   *  Java: <https://mvnrepository.com/artifact/io.github.erdtman/java-
      json-canonicalization>

   *  Go: <https://github.com/cyberphone/json-
      canonicalization/tree/master/go>

   *  .NET/C#: <https://github.com/cyberphone/json-
      canonicalization/tree/master/dotnet>

   *  Python: <https://github.com/cyberphone/json-
      canonicalization/tree/master/python3>

Appendix B.  JWS/CT Application Notes

   The following application notes are not a part of the JWS/CT core;
   they show how JWS/CT can be used in contexts involving multiple
   signatures.

B.1.  Counter Signatures

   Consider the following JWS/CT object showing an imaginary real estate
   business record (with a line break in the "signature" property for
   display purposes only):

Jordan, et al.            Expires 30 July 2021                 [Page 10]
Internet-Draft                   JWS/CT                     January 2021

   {
     "gps": [38.89768255588178, -77.03658644893932],
     "object": {
       "type": "house",
       "price": "$635,000"
     },
     "role": "buyer",
     "name": "John Smith",
     "timeStamp": "2020-11-08T13:56:08Z",
     "signature": "eyJhbGciOiJIUzI1NiJ9..zlPMniQiz4Eie86oK4xo25z
   uyW92csiDqyiQrF6R5ug"
   }

   The signature above was created using the sample key from Section 3.

   Adding a notary signature on top of this could be performed by
   embedding the former object as follows (with line breaks in the
   "signature" properties for display purposes only):

   {
     "attesting": {
       "gps": [38.89768255588178, -77.03658644893932],
       "object": {
         "type": "house",
         "price": "$635,000"
       },
       "role": "buyer",
       "name": "John Smith",
       "timeStamp": "2020-11-08T13:56:08Z",
       "signature": "eyJhbGciOiJIUzI1NiJ9..zlPMniQiz4Eie86oK4xo25z
   uyW92csiDqyiQrF6R5ug"
     },
     "role": "notary",
     "name": "Carol Lombardi-Jones",
     "timeStamp": "2020-11-08T13:58:42Z",
     "signature": "eyJhbGciOiJFUzI1NiJ9..AVmJGUWp1JD0pf2j1_UQWXbf-
   qj-2RWxOnyAXihd4POKbnjWqqSBmHPNfgMQFH_s5sXHkIOkDZe2nShqEJOEVA"
   }

   A side effect of this arrangement is that the notary's signature
   signs not only the notary data, but the buyer's data and signature as
   well.  In most cases this way of adding signatures is advantageous
   since it maintains the actual order of signing events which also
   cannot be tampered with without invalidating the outermost signature.

   Note that all properties above including "signature" are application
   specific.

Jordan, et al.            Expires 30 July 2021                 [Page 11]
Internet-Draft                   JWS/CT                     January 2021

   The notary's signature was created using the sample key from
   Appendix C.

B.2.  Detached Signatures

   In the case the signing entities are "peers" or are unrelated to each
   other, counter-signatures like described in Appendix B.1 are not
   applicable since they presume a specific flow.  For supporting
   _independent_ or _asynchronous_ signers targeting a common document
   or data object, an imaginable solution is using a scheme where each
   signer calculates a hash of the target document/data and includes the
   hash together with signer-specific meta data like the following:

   {

     <<Common Document/Data to Sign...>>

     "signers": [{
       "sha256": "<<Hash of Document/Data to Sign>>",

       <<Signer-related meta data...>>

       "signature": "<<Signer JWS Signature>>"
     },{
       "sha256": "<<Hash of Document/Data to Sign>>",

       <<Signer-related meta data...>>

       "signature": "<<Signer JWS Signature>>"
     }]
   }

   In this case the object to sign would not be limited to JSON; it
   could for example be a PDF document hosted on a specific URL.  Note
   that the relying party would have to update the structure for each
   signature received.  In some cases a database would probably be more
   useful for holding individual signatures since a database can cope
   with any number of signers as well as keeping track of who have
   actually signed.  The latter is crucial for things like international
   treaties and company board statements.

   Note that although "signers", "sha256", and "signature" are
   application specific property names, the objects in the "signers"
   array are assumed to be fully conformant with the JWS/CT
   specification.

Jordan, et al.            Expires 30 July 2021                 [Page 12]
Internet-Draft                   JWS/CT                     January 2021

   The following sample shows a possible detached signature solution
   (with line breaks in the "signature" properties for display purposes
   only):

   {
     "statement": "Hello signed world!",
     "otherProperties": [2000, true],
     "signers": [{
       "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70",
       "timeStamp": "2020-11-18T07:45:28Z",
       "name": "Alice",
       "signature": "eyJhbGciOiJIUzI1NiJ9..AE7CnzSYsaspE3yrdsAwi
   avd3IdWtdAmDE8FRMwYLA8"
     },{
       "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70",
       "timeStamp": "2020-11-18T08:03:40Z",
       "name": "Bob",
       "signature": "eyJhbGciOiJFUzI1NiJ9..0tNLy0pLcHUjPhhorpKd5
   7a8zTPeqlrOjATiSlPQ1vciE99x6mHmow04tPbJS8dqSqO9c4RkKW6jeL4ZyWpXLA"
     }]
   }

   Notes:

   *  "Alice" used the sample key from Section 3 while "Bob" used the
      sample key specified in Appendix C.

   *  The "sha256" properties hold base64url-encoded [RFC4648],
      SHA256-hashes [SHS] of the canonicalized data created in
      Section 3.1.2.

   *  This arrangement requires a _two-step validation process_ where
      each JWS/CT object in the "signers" array is individually
      validated, as well as having its "sha256" property compared to the
      hash of the canonicalized common data.

B.3.  Array of Signatures

   Another possibility supporting _multiple and independent_ signatures
   is collecting JWS signature strings in a JSON array object according
   to the following scheme:

Jordan, et al.            Expires 30 July 2021                 [Page 13]
Internet-Draft                   JWS/CT                     January 2021

   {

     <<Common Document/Data to Sign...>>

     "<<Signature property>>": ["<<Signature-1>>",
                                "<<Signature-2>>",
                                          .
                                "<<Signature-n>>"]
   }

   Processing would follow Section 3, with the addition that each
   signature is dealt with individually.

   Compared to Appendix B.2, signature arrays imply that possible
   signer-specific meta-data is supplied as JWS extensions in the
   associated signature's base64url-encoded header.

   By combining the sample used in Section 3 with the test vector in
   Appendix C, a valid signature array object could be as follows (with
   line breaks in the "signatures" property for display purposes only):

   {
     "statement": "Hello signed world!",
     "otherProperties": [2000, true],
     "signatures": ["eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar
   DtJeSxH2uLU0DhqQP5Zjw4",
                    "eyJhbGciOiJFUzI1NiJ9..ENP0j0-QPsA7N_Mg1-RMN
   9IxapeTWtQwR7sPUqEiSNHPuV_fqSdRqqkLOlBdV01cc4lSJdn1XCv-ZHYdZ9t3kA"]
   }

   Note that "signatures" is not a keyword, it was only selected to
   highlight the fact that there are multiple signatures.

Appendix C.  Test Vector Using the ES256 Algorithm

   This appendix shows how a signed version of the JSON sample object in
   Section 3.1.1 would look like if applying the "ES256" JOSE algorithm
   [RFC7518] (with a line break in the "signature" property for display
   purposes only):

   {
     "statement": "Hello signed world!",
     "otherProperties": [2000, true],
     "signature": "eyJhbGciOiJFUzI1NiJ9..ENP0j0-QPsA7N_Mg1-RMN
   9IxapeTWtQwR7sPUqEiSNHPuV_fqSdRqqkLOlBdV01cc4lSJdn1XCv-ZHYdZ9t3kA"
   }

Jordan, et al.            Expires 30 July 2021                 [Page 14]
Internet-Draft                   JWS/CT                     January 2021

   The sample above depends on a JWS header holding the algorithm
   {"alg":"ES256"}, and the following private key, here expressed in the
   JWK [RFC7517] format:

   {
     "kty": "EC",
     "crv": "P-256",
     "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU",
     "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg",
     "d": "6XxMFXhcYT5QN9w5TIg2aSKsbcj-pj4BnZkK7ZOt4B8"
   }

   Note that signing with the "ES256" algorithm _returns different
   results for each signature_ due to a randomization step in the
   signature computation process.

Appendix D.  Enhanced JWS Processing Option

   By default, JWS/CT uses the JWS compact serialization mode "as is".
   As a consequence, a _technically redundant_, _internal-only_,
   base64url encoding step is performed over the "JWS Payload".
   Although the performance hit should be marginal for most real-world
   applications, a possibility is using the "Unencoded Payload" mode of
   RFC7797 [RFC7797].  However, this requires that the JWS
   implementation supports the "b64":false and "crit":["b64"] header
   elements implied by RFC7797, effectively rendering the RFC7797 mode
   as an _implementer option_ for specific communities.

Acknowledgements

   People who have contributed directly and indirectly with valuable
   input to this specification include Vladimir Dzhuvinov, Freddi Gyara,
   and Filip Skokan.

Document History

   [[ This section to be removed by the RFC Editor before publication as
   an RFC ]]

   Version 00:

   *  Initial publication.

   Version 01:

   *  Added paragraph to Abstract.

   *  Updated Security Considerations.

Jordan, et al.            Expires 30 July 2021                 [Page 15]
Internet-Draft                   JWS/CT                     January 2021

   Version 02:

   *  Changed alternative test key to ES256/P-256.

   *  Moved RFC7797 to an appendix.

   *  Changed <tt> to only be used on keywords.

   *  Added some clarity to detached signatures.

Authors' Addresses

   Bret Jordan (editor)
   Broadcom
   1320 Ridder Park Drive
   San Jose, CA 95131
   United States of America

   Email: bret.jordan@broadcom.com

   Samuel Erdtman
   Spotify AB
   Birger Jarlsgatan 61, 4tr
   SE-113 56 Stockholm
   Sweden

   Email: erdtman@spotify.com

   Anders Rundgren
   Independent
   Montpellier
   France

   Email: anders.rundgren.net@gmail.com
   URI:   https://www.linkedin.com/in/andersrundgren/

Jordan, et al.            Expires 30 July 2021                 [Page 16]