draft-ietf-jose-json-web-signature-12.txt   draft-ietf-jose-json-web-signature-13.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: January 12, 2014 Ping Identity Expires: January 16, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
July 11, 2013 July 15, 2013
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-12 draft-ietf-jose-json-web-signature-13
Abstract Abstract
JSON Web Signature (JWS) is a means of representing content secured JSON Web Signature (JWS) is a means of representing content secured
with digital signatures or Message Authentication Codes (MACs) using with digital signatures or Message Authentication Codes (MACs) using
JavaScript Object Notation (JSON) based data structures. JavaScript Object Notation (JSON) based data structures.
Cryptographic algorithms and identifiers for use with this Cryptographic algorithms and identifiers for use with this
specification are described in the separate JSON Web Algorithms (JWA) specification are described in the separate JSON Web Algorithms (JWA)
specification. Related encryption capabilities are described in the specification. Related encryption capabilities are described in the
separate JSON Web Encryption (JWE) specification. separate JSON Web Encryption (JWE) specification.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2014. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 12 5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 12
5.1. Message Signing or MACing . . . . . . . . . . . . . . . . 12 5.1. Message Signing or MACing . . . . . . . . . . . . . . . . 12
5.2. Message Signature or MAC Validation . . . . . . . . . . . 13 5.2. Message Signature or MAC Validation . . . . . . . . . . . 13
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 15 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 15
6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 15 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 15
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 16 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 16
7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 16 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. JSON Web Signature and Encryption Header Parameters 8.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 19 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.1. Registration Template . . . . . . . . . . . . . . . . 19 8.1.1. Registration Template . . . . . . . . . . . . . . . . 19
8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 19 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 19
8.2. JSON Web Signature and Encryption Type Values Registry . . 21 8.2. JSON Web Signature and Encryption Type Values Registry . . 20
8.2.1. Registration Template . . . . . . . . . . . . . . . . 21 8.2.1. Registration Template . . . . . . . . . . . . . . . . 20
8.2.2. Initial Registry Contents . . . . . . . . . . . . . . 21 8.2.2. Initial Registry Contents . . . . . . . . . . . . . . 21
8.3. Media Type Registration . . . . . . . . . . . . . . . . . 22 8.3. Media Type Registration . . . . . . . . . . . . . . . . . 21
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Cryptographic Security Considerations . . . . . . . . . . 23 9.1. Cryptographic Security Considerations . . . . . . . . . . 23
9.2. JSON Security Considerations . . . . . . . . . . . . . . . 24 9.2. JSON Security Considerations . . . . . . . . . . . . . . . 24
9.3. Unicode Comparison Security Considerations . . . . . . . . 25 9.3. Unicode Comparison Security Considerations . . . . . . . . 24
9.4. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 25 9.4. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 27
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28
A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 30 A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 30
A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 30 A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 30
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 30 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 30
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30
A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 33 A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 33
A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 33 A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 33
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 34 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 33
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33
A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 35
A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 36 A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 36
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 36 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 36
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 38 A.4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 38
A.4.3. Validating . . . . . . . . . . . . . . . . . . . . . . 39 A.4.3. Validating . . . . . . . . . . . . . . . . . . . . . . 38
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 39 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 39
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 40 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 40
A.6.1. JWS Protected Header . . . . . . . . . . . . . . . . . 40 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 40
A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 40 A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 40
A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 41 A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 41
A.6.4. Complete JWS JSON Serialization Representation . . . . 41 A.6.4. Complete JWS JSON Serialization Representation . . . . 41
A.6.5. RSA Key Used for Second Signature . . . . . . . . . . 42 Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 41
Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 42
Appendix C. Notes on implementing base64url encoding without Appendix C. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . . 44 padding . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix D. Negative Test Case for "crit" Header Parameter . . . 45 Appendix D. Negative Test Case for "crit" Header Parameter . . . 44
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 45 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 45
Appendix F. Document History . . . . . . . . . . . . . . . . . . 46 Appendix F. Document History . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
JSON Web Signature (JWS) is a means of representing content secured JSON Web Signature (JWS) is a means of representing content secured
with digital signatures or Message Authentication Codes (MACs) using with digital signatures or Message Authentication Codes (MACs) using
JavaScript Object Notation (JSON) [RFC4627] based data structures. JavaScript Object Notation (JSON) [RFC4627] based data structures.
The JWS cryptographic mechanisms provide integrity protection for The JWS cryptographic mechanisms provide integrity protection for
arbitrary sequences of octets. arbitrary sequences of octets.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
This computation is illustrated in more detail in Appendix A.1. See This computation is illustrated in more detail in Appendix A.1. See
Appendix A for additional examples. Appendix A for additional examples.
4. JWS Header 4. JWS Header
The members of the JSON object(s) representing the JWS Header The members of the JSON object(s) representing the JWS Header
describe the digital signature or MAC applied to the Encoded JWS describe the digital signature or MAC applied to the Encoded JWS
Header and the Encoded JWS Payload and optionally additional Header and the Encoded JWS Payload and optionally additional
properties of the JWS. The Header Parameter Names within the JWS properties of the JWS. The Header Parameter Names within the JWS
Header MUST be unique; receipients MUST either reject JWSs with Header MUST be unique; recipients MUST either reject JWSs with
duplicate Header Parameter Names or use a JSON parser that returns duplicate Header Parameter Names or use a JSON parser that returns
only the lexically last duplicate member name, as specified in only the lexically last duplicate member name, as specified in
Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].
Implementations are required to understand the specific header Implementations are required to understand the specific header
parameters defined by this specification that are designated as "MUST parameters defined by this specification that are designated as "MUST
be understood" and process them in the manner defined in this be understood" and process them in the manner defined in this
specification. All other header parameters defined by this specification. All other header parameters defined by this
specification that are not so designated MUST be ignored when not specification that are not so designated MUST be ignored when not
understood. Unless listed as a critical header parameter, per understood. Unless listed as a critical header parameter, per
skipping to change at page 14, line 20 skipping to change at page 14, line 20
3. Let the JWS Protected Header value be the result of base64url 3. Let the JWS Protected Header value be the result of base64url
decoding the Encoded JWS Header. decoding the Encoded JWS Header.
4. The resulting JWS Protected Header MUST be a completely valid 4. The resulting JWS Protected Header MUST be a completely valid
JSON object conforming to RFC 4627 [RFC4627]. JSON object conforming to RFC 4627 [RFC4627].
5. If using the JWS Compact Serialization, let the JWS Header be 5. If using the JWS Compact Serialization, let the JWS Header be
the JWS Protected Header; otherwise, when using the JWS JSON the JWS Protected Header; otherwise, when using the JWS JSON
Serialization, let the JWS Header be the union of the members of Serialization, let the JWS Header be the union of the members of
the JWS Protected Header, the members of the "unprotected" the corresponding "protected" and "header" header parameter
value, and the members of the corresponding "header" value, all values, all of which must be completely valid JSON objects.
of which must be completely valid JSON objects.
6. The resulting JWS Header MUST NOT contain duplicate Header 6. The resulting JWS Header MUST NOT contain duplicate Header
Parameter Names. When using the JWS JSON Serialization, this Parameter Names. When using the JWS JSON Serialization, this
restriction includes that the same Header Parameter Name also restriction includes that the same Header Parameter Name also
MUST NOT occur in distinct JSON Text Object values that together MUST NOT occur in distinct JSON Text Object values that together
comprise the JWS Header. comprise the JWS Header.
7. The resulting JWS Header MUST be validated to only include 7. The resulting JWS Header MUST be validated to only include
parameters and values whose syntax and semantics are both parameters and values whose syntax and semantics are both
understood and supported or that are specified as being ignored understood and supported or that are specified as being ignored
skipping to change at page 16, line 37 skipping to change at page 16, line 37
The representation is closely related to that used in the JWS Compact The representation is closely related to that used in the JWS Compact
Serialization, with the following differences for the JWS JSON Serialization, with the following differences for the JWS JSON
Serialization: Serialization:
o Values in the JWS JSON Serialization are represented as members of o Values in the JWS JSON Serialization are represented as members of
a JSON object, rather than as base64url encoded strings separated a JSON object, rather than as base64url encoded strings separated
by period ('.') characters. (However binary values and values by period ('.') characters. (However binary values and values
that are integrity protected are still base64url encoded.) that are integrity protected are still base64url encoded.)
o The Encoded JWS Header value, if non-empty, is stored in the
"protected" member.
o The Encoded JWS Payload value is stored in the "payload" member. o The Encoded JWS Payload value is stored in the "payload" member.
o There can be multiple signature and/or MAC values, rather than o There can be multiple signature and/or MAC values, rather than
just one. A JSON array in the "signatures" member is used to hold just one. A JSON array in the "signatures" member is used to hold
values that are specific to a particular signature or MAC values that are specific to a particular signature or MAC
computation, with one array element per signature/MAC represented. computation, with one array element per signature/MAC represented.
These array elements are JSON objects. These array elements are JSON objects.
o Each Encoded JWS Signature value is stored in the "signature" o Each Encoded JWS Signature value is stored in the "signature"
member of a JSON object that is an element of the "signatures" member of a JSON object that is an element of the "signatures"
array. array.
o Some header parameter values, such as the "alg" value and o Each Encoded JWS Header value, which is a base64url encoded set of
parameters used for selecting keys, can also differ for different header parameter values that are included in the signature/MAC
signature/MAC computations. Per-signature/MAC header parameter computation, if non-empty, is stored in the "protected" member of
values are stored in the "header" members of the same JSON objects the corresponding element of the "signatures" array.
that are elements of the "signatures" array.
o Some header parameters, including the "alg" parameter, can be
shared among all signature/MAC computations. These header
parameters are stored in either of two top-level member(s) of the
JSON object: the "protected" member and the "unprotected" member.
The values of these members are JSON Text Objects containing
Header Parameters.
o Not all header parameters are integrity protected. The shared o Unlike the JWS Compact Serialization, in the JWS JSON
header parameters in the "protected" member are integrity Serialization there can also be header parameter values that are
protected, and are base64url encoded. The per-signature/MAC not included in the signature/MAC computation. If present,
header parameters in the "header" array element members and the unprotected header parameter values are represented as an
shared header parameters in the "unprotected" member are not unencoded JSON Text Object in the "header" member of the
integrity protected. These JSON Text Objects containing header corresponding element of the "signatures" array.
parameters that are not integrity protected are not base64url
encoded.
o The header parameter values used when creating or validating o The header parameter values used when creating or validating
individual signature or MAC values are the union of the three sets individual signature or MAC values are the union of the two sets
of header parameter values that may be present: (1) the per- of header parameter values that may be present: (1) the integrity-
signature/MAC values in the "header" member of the signature/MAC's protected per-signature/MAC values represented in the "protected"
array element, (2) the shared integrity-protected values in the member of the signature/MAC's array element, and (2) the non-
"protected" member, and (3) the shared non-integrity-protected integrity-protected per-signature/MAC values in the "header"
values in the "unprotected" member. The union of these sets of member of the signature/MAC's array element. The union of these
header parameters comprises the JWS Header. The header parameter sets of header parameters comprises the JWS Header. The header
names in the three locations MUST be disjoint. parameter names in the two locations MUST be disjoint.
The syntax of a JWS using the JWS JSON Serialization is as follows: The syntax of a JWS using the JWS JSON Serialization is as follows:
{"protected":<integrity-protected shared header contents>", {
"unprotected":<non-integrity-protected shared header contents>",
"payload":"<payload contents>" "payload":"<payload contents>"
"signatures":[ "signatures":[
{"header":"<per-signature unprotected header 1 contents>", {"protected":<integrity-protected header 1 contents>",
"header":"<non-integrity-protected header 1 contents>",
"signature":"<signature 1 contents>"}, "signature":"<signature 1 contents>"},
... ...
{"header":"<per-signature unprotected header N contents>", {"protected":<integrity-protected header N contents>",
"header":"<non-integrity-protected header N contents>",
"signature":"<signature N contents>"}], "signature":"<signature N contents>"}],
} }
Of these members, only the "payload", "signatures", and "signature" Of these members, only the "payload", "signatures", and "signature"
members MUST be present. At least one of the "header", "protected", members MUST be present. At least one of the "protected" and
and "unprotected" members MUST be present so that an "alg" header "header" members MUST be present for each signature/MAC computation
parameter value is conveyed for each signature/MAC computation. so that an "alg" header parameter value is conveyed.
The contents of the Encoded JWS Payload and Encoded JWS Signature The contents of the Encoded JWS Payload and Encoded JWS Signature
values are exactly as defined in the rest of this specification. values are exactly as defined in the rest of this specification.
They are interpreted and validated in the same manner, with each They are interpreted and validated in the same manner, with each
corresponding Encoded JWS Signature and set of header parameter corresponding Encoded JWS Signature and set of header parameter
values being created and validated together. The JWS Header values values being created and validated together. The JWS Header values
used are the union of the header parameters in the "protected", used are the union of the header parameters in the corresponding
"unprotected", and corresponding "header" members, as described "protected" and "header" members, as described earlier.
earlier.
Each JWS Signature value is computed on the JWS Signing Input using Each JWS Signature value is computed on the JWS Signing Input using
the parameters of the corresponding JWS Header value in the same the parameters of the corresponding JWS Header value in the same
manner as for the JWS Compact Serialization. This has the desirable manner as for the JWS Compact Serialization. This has the desirable
property that each Encoded JWS Signature value in the "signatures" property that each Encoded JWS Signature value in the "signatures"
array is identical to the value that would have been computed for the array is identical to the value that would have been computed for the
same parameter in the JWS Compact Serialization, provided that the same parameter in the JWS Compact Serialization, provided that the
Encoded JWS Header value (which represents the integrity-protected Encoded JWS Header value for that signature/MAC computation (which
header parameter values) matches that used in the JWS Compact represents the integrity-protected header parameter values) matches
Serialization. that used in the JWS Compact Serialization.
See Appendix A.6 for an example of computing a JWS using the JWS JSON See Appendix A.6 for an example of computing a JWS using the JWS JSON
Serialization. Serialization.
8. IANA Considerations 8. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered with a Specification Required [RFC5226] after a Values are registered with a Specification Required [RFC5226] after a
skipping to change at page 24, line 37 skipping to change at page 24, line 19
9.2. JSON Security Considerations 9.2. JSON Security Considerations
Strict JSON validation is a security requirement. If malformed JSON Strict JSON validation is a security requirement. If malformed JSON
is received, then the intent of the sender is impossible to reliably is received, then the intent of the sender is impossible to reliably
discern. Ambiguous and potentially exploitable situations could discern. Ambiguous and potentially exploitable situations could
arise if the JSON parser used does not reject malformed JSON syntax. arise if the JSON parser used does not reject malformed JSON syntax.
Section 2.2 of the JavaScript Object Notation (JSON) specification Section 2.2 of the JavaScript Object Notation (JSON) specification
[RFC4627] states "The names within an object SHOULD be unique", [RFC4627] states "The names within an object SHOULD be unique",
whereas this specification states that "Header Parameter Names within whereas this specification states that "Header Parameter Names within
this object MUST be unique; receipients MUST either reject JWSs with this object MUST be unique; recipients MUST either reject JWSs with
duplicate Header Parameter Names or use a JSON parser that returns duplicate Header Parameter Names or use a JSON parser that returns
only the lexically last duplicate member name, as specified in only the lexically last duplicate member name, as specified in
Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]". Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]".
Thus, this specification requires that the Section 2.2 "SHOULD" be Thus, this specification requires that the Section 2.2 "SHOULD" be
treated as a "MUST" by senders and that it be either treated as a treated as a "MUST" by senders and that it be either treated as a
"MUST" or in the manner specfied in ECMAScript 5.1 by receivers. "MUST" or in the manner specified in ECMAScript 5.1 by receivers.
Ambiguous and potentially exploitable situations could arise if the Ambiguous and potentially exploitable situations could arise if the
JSON parser used does not enforce the uniqueness of member names or JSON parser used does not enforce the uniqueness of member names or
returns an unpredictable value for duplicate member names. returns an unpredictable value for duplicate member names.
Some JSON parsers might not reject input that contains extra Some JSON parsers might not reject input that contains extra
significant characters after a valid input. For instance, the input significant characters after a valid input. For instance, the input
"{"tag":"value"}ABCD" contains a valid JSON object followed by the "{"tag":"value"}ABCD" contains a valid JSON object followed by the
extra characters "ABCD". Such input MUST be rejected in its extra characters "ABCD". Such input MUST be rejected in its
entirety. entirety.
skipping to change at page 36, line 41 skipping to change at page 36, line 33
specification, the use of the K value in ECDSA means that we cannot specification, the use of the K value in ECDSA means that we cannot
validate the correctness of the digital signature in the same way we validate the correctness of the digital signature in the same way we
validated the correctness of the HMAC. Instead, implementations MUST validated the correctness of the HMAC. Instead, implementations MUST
use an ECDSA validator to validate the digital signature. use an ECDSA validator to validate the digital signature.
A.4. Example JWS using ECDSA P-521 SHA-512 A.4. Example JWS using ECDSA P-521 SHA-512
A.4.1. Encoding A.4.1. Encoding
The JWS Header for this example differs from the previous example The JWS Header for this example differs from the previous example
because a different ECDSA curve and hash function are used. The JWS because different ECDSA curves and hash functions are used. The JWS
Header used is: Header used is:
{"alg":"ES512"} {"alg":"ES512"}
The following octet sequence contains the UTF-8 representation of the The following octet sequence contains the UTF-8 representation of the
JWS Header: JWS Header:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125] [123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
Base64url encoding these octets yields this Encoded JWS Header value: Base64url encoding these octets yields this Encoded JWS Header value:
skipping to change at page 40, line 18 skipping to change at page 40, line 12
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
A.6. Example JWS Using JWS JSON Serialization A.6. Example JWS Using JWS JSON Serialization
This section contains an example using the JWS JSON Serialization. This section contains an example using the JWS JSON Serialization.
This example demonstrates the capability for conveying multiple This example demonstrates the capability for conveying multiple
digital signatures and/or MACs for the same payload. digital signatures and/or MACs for the same payload.
The Encoded JWS Payload used in this example is the same as that used The Encoded JWS Payload used in this example is the same as that used
in the examples in Appendix A.2 (with line breaks for display in the examples in Appendix A.2 and Appendix A.3 (with line breaks
purposes only): for display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Two digital signatures are used in this example: both using RSASSA- Two digital signatures are used in this example: the first using
PKCS-v1_5 SHA-256. For the first, the JWS Protected Header and key RSASSA-PKCS-v1_5 SHA-256 and the second using ECDSA P-256 SHA-256.
are the same as in Appendix A.2, resulting in the same JWS Signature For the first, the JWS Protected Header and key are the same as in
value; therefore, its computation is not repeated here. For the Appendix A.2, resulting in the same JWS Signature value; therefore,
second a different key is used, which is provided in Appendix A.6.5; its computation is not repeated here. For the second, the JWS
its computation follows the same procedure as the first, so it is not Protected Header and key are the same as in Appendix A.3, resulting
detailed here either, other than including the resulting Encoded JWS in the same JWS Signature value; therefore, its computation is not
Signature value. repeated here.
A.6.1. JWS Protected Header A.6.1. JWS Per-Signature Protected Headers
The JWS Protected Header value used for both computations is: The JWS Protected Header value used for the first signature is:
{"alg":"RS256"} {"alg":"RS256"}
Base64url encoding these octets yields this Encoded JWS Header value: Base64url encoding these octets yields this Encoded JWS Header value:
eyJhbGciOiJSUzI1NiJ9 eyJhbGciOiJSUzI1NiJ9
The JWS Protected Header value used for the second signature is:
{"alg":"ES256"}
Base64url encoding these octets yields this Encoded JWS Header value:
eyJhbGciOiJFUzI1NiJ9
A.6.2. JWS Per-Signature Unprotected Headers A.6.2. JWS Per-Signature Unprotected Headers
Key ID values are supplied for both keys using per-signature header Key ID values are supplied for both keys using per-signature header
parameters. The two values used to represent these Key IDs are: parameters. The two values used to represent these Key IDs are:
{"kid":"2010-12-29"} {"kid":"2010-12-29"}
and: and:
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"} {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.3. Complete JWS Header Values A.6.3. Complete JWS Header Values
Combining the protected and per-signature header values supplied, the Combining the protected and unprotected header values supplied, the
JWS Header values used for the first and second signatures JWS Header values used for the first and second signatures
respectively are: respectively are:
{"alg":"RS256", {"alg":"RS256",
"kid":"2010-12-29"} "kid":"2010-12-29"}
and: and:
{"alg":"RS256", {"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"} "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.4. Complete JWS JSON Serialization Representation A.6.4. Complete JWS JSON Serialization Representation
The complete JSON Web Signature JSON Serialization for these values The complete JSON Web Signature JSON Serialization for these values
is as follows (with line breaks for display purposes only): is as follows (with line breaks for display purposes only):
{"protected":"eyJhbGciOiJSUzI1NiJ9", {"payload":
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ", tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[ "signatures":[
{"header": {"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"}, {"kid":"2010-12-29"},
"signature": "signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"}, LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"header": {"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}, {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature": "signature":
"m2nhGPQGjPEDIotJnzcnlhUZnXeg0xzLVbh6NZzthY8yU3klJYaENE1aLAUtL "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
cq-TmEeYIr30ruGH2kNFqW4-oc7LcTQu9-7ItRhfi0kKeN1zNAAUemfNYXaXA lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
1JayiiCl7m9ylhLKIsvdXhFvV7XDSbUMnVoO9Yu5_ROKOJMkeU6ywR8DDcHmu
B2KcLMfpHn1FqnUnojxwfOg1Eqyb_ppeDTm9t_h8FoQgHqRpNgsTTvxI9vSPE
ZrWTkSf_D4ci6p06DM_nE6FbptYF3ENHF8NpGgncv_D_h9AIrZU5-6ee2HB24
jtN9qOHw2pkVrvhtxdsSJdeG6uJqiFs0ArwQQ"}]
}
A.6.5. RSA Key Used for Second Signature
The second signature in this example uses the RSA key represented in
JSON Web Key [JWK] format below (with line breaks for display
purposes only):
{"kty":"RSA",
"n":"oHiJbb8NGB0P2UQjpJghsz4WM4Y85HCsCz45EBqi1frHtzhnZawUsuJ8dI
fDw3xbrkHaxHFShKGRRwh18G10KMQarocrryim350FvFwHNNsLnWBjGUGX
bBlozpM_AZ2aOm_I-zbKYNwqxBX8wTrNLFnZOqRjA0zDtEwTZ24aAnqt0y
3ahtQaxpxu1Ysfh-MrAC3AJ86wwprZCrnjj46zdavuu1gMuSRuZEwiJxSR
uCwOZBVND1KWNZwuxOecmJhVkbjD1YZrSwp16UzXPs1fqgbq3YsE8e_LHC
BfwBikrIQKwe8tjJnGjHUR3wwaBS_f05d4D-Y8KjNody4p8rFMIQ",
"e":"AQAB",
"d":"djLy_3x3V6iocN-o5WcNg6qazc718Uow34MwovULtlOnYgTQ3GoZQP5kr6
0E_GwQV9W4H3RdVMZxbQIFZVgp9JEmGiIEgluONy3A-NJMmJkz__Lsa8EN
mRlKQsbg5P7CiIKoZqof_aKOeaq8Z1Q5po5z3KcTK24SxS44KLpHvESYK5
9Re4Bnp_OLvFokjpfZ1fSVtwkQlXfpoclrl7mdfO6TMjOqvL6aXO8uJbIx
StHcOBO6IjSYglY47QG64fQd-DkVAQo3sG6RlQSJDXnsV7ow2gNO2gL0X6
ja2ff8UQ0W0tsalSDZ05DnaPBFSe0BDhyhyt7RnGwbz34oTWZdAQ"
} }
Appendix B. "x5c" (X.509 Certificate Chain) Example Appendix B. "x5c" (X.509 Certificate Chain) Example
The JSON array below is an example of a certificate chain that could The JSON array below is an example of a certificate chain that could
be used as the value of an "x5c" (X.509 Certificate Chain) header be used as the value of an "x5c" (X.509 Certificate Chain) header
parameter, per Section 4.1.6. Note that since these strings contain parameter, per Section 4.1.6. Note that since these strings contain
base64 encoded (not base64url encoded) values, they are allowed to base64 encoded (not base64url encoded) values, they are allowed to
contain white space and line breaks. contain white space and line breaks.
skipping to change at page 46, line 20 skipping to change at page 46, line 4
Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad, Paul Tarjan, Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad, Paul Tarjan,
Hannes Tschofenig, and Sean Turner. Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner and Stephen Farrell served as Security area directors Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix F. Document History Appendix F. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-13
o Made all header parameter values be per-signature/MAC, addressing
issue #24.
-12 -12
o Clarified that the "typ" and "cty" header parameters are used in o Clarified that the "typ" and "cty" header parameters are used in
an application-specific manner and have no effect upon the JWS an application-specific manner and have no effect upon the JWS
processing. processing.
o Replaced the MIME types "application/jws+json" and o Replaced the MIME types "application/jws+json" and
"application/jws" with "application/jose+json" and "application/jws" with "application/jose+json" and
"application/jose". "application/jose".
o Stated that receipients MUST either reject JWSs with duplicate o Stated that recipients MUST either reject JWSs with duplicate
Header Parameter Names or use a JSON parser that returns only the Header Parameter Names or use a JSON parser that returns only the
lexically last duplicate member name. lexically last duplicate member name.
o Added a Serializations section with parallel treatment of the JWS o Added a Serializations section with parallel treatment of the JWS
Compact Serialization and the JWS JSON Serialization and also Compact Serialization and the JWS JSON Serialization and also
moved the former Implementation Considerations content there. moved the former Implementation Considerations content there.
-11 -11
o Added Key Identification section. o Added Key Identification section.
 End of changes. 44 change blocks. 
121 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/