draft-ietf-jose-json-web-signature-23.txt   draft-ietf-jose-json-web-signature-24.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: September 4, 2014 Ping Identity Expires: September 19, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
March 3, 2014 March 18, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-23 draft-ietf-jose-json-web-signature-24
Abstract Abstract
JSON Web Signature (JWS) represents content secured with digital JSON Web Signature (JWS) represents content secured with digital
signatures or Message Authentication Codes (MACs) using JavaScript signatures or Message Authentication Codes (MACs) using JavaScript
Object Notation (JSON) based data structures. Cryptographic Object Notation (JSON) based data structures. Cryptographic
algorithms and identifiers for use with this specification are algorithms and identifiers for use with this specification are
described in the separate JSON Web Algorithms (JWA) specification and described in the separate JSON Web Algorithms (JWA) specification and
an IANA registry defined by that specification. Related encryption an IANA registry defined by that specification. Related encryption
capabilities are described in the separate JSON Web Encryption (JWE) capabilities are described in the separate JSON Web Encryption (JWE)
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 4, 2014. This Internet-Draft will expire on September 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 4, line 9 skipping to change at page 4, line 9
Appendix E. Negative Test Case for "crit" Header Parameter . . . 46 Appendix E. Negative Test Case for "crit" Header Parameter . . . 46
Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 46 Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 46
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 47 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 47
Appendix H. Document History . . . . . . . . . . . . . . . . . . 47 Appendix H. Document History . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
JSON Web Signature (JWS) represents content secured with digital JSON Web Signature (JWS) represents content secured with digital
signatures or Message Authentication Codes (MACs) using JavaScript signatures or Message Authentication Codes (MACs) using JavaScript
Object Notation (JSON) [RFC7158] based data structures. The JWS Object Notation (JSON) [RFC7159] based data structures. The JWS
cryptographic mechanisms provide integrity protection for an cryptographic mechanisms provide integrity protection for an
arbitrary sequence of octets. arbitrary sequence of octets.
Two closely related serializations for JWS objects are defined. The Two closely related serializations for JWS objects are defined. The
JWS Compact Serialization is a compact, URL-safe representation JWS Compact Serialization is a compact, URL-safe representation
intended for space constrained environments such as HTTP intended for space constrained environments such as HTTP
Authorization headers and URI query parameters. The JWS JSON Authorization headers and URI query parameters. The JWS JSON
Serialization represents JWS objects as JSON objects and enables Serialization represents JWS objects as JSON objects and enables
multiple signatures and/or MACs to be applied to the same content. multiple signatures and/or MACs to be applied to the same content.
Both share the same cryptographic underpinnings. Both share the same cryptographic underpinnings.
skipping to change at page 15, line 36 skipping to change at page 15, line 36
Unprotected Header value. When using the JWS Compact Unprotected Header value. When using the JWS Compact
Serialization, the JWS Protected Header, the JWS Payload, and Serialization, the JWS Protected Header, the JWS Payload, and
the JWS Signature are represented as base64url encoded values in the JWS Signature are represented as base64url encoded values in
that order, separated by two period ('.') characters. The JWS that order, separated by two period ('.') characters. The JWS
JSON Serialization is described in Section 7.2. JSON Serialization is described in Section 7.2.
2. The encoded representation of the JWS Protected Header MUST be 2. The encoded representation of the JWS Protected Header MUST be
successfully base64url decoded following the restriction that no successfully base64url decoded following the restriction that no
padding characters have been used. padding characters have been used.
3. The resulting octet sequence MUST be a UTF-8 encoded 3. The resulting octet sequence MUST be a UTF-8 encoded
representation of a completely valid JSON object conforming to representation of a completely valid JSON object conforming to
[RFC7158], which is the JWS Protected Header. [RFC7159], which is the JWS Protected Header.
4. If using the JWS Compact Serialization, let the JWS Header be 4. 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 corresponding JWS Protected Header and JWS Unprotected the corresponding JWS Protected Header and JWS Unprotected
Header, all of which must be completely valid JSON objects. Header, all of which must be completely valid JSON objects.
5. The resulting JWS Header MUST NOT contain duplicate Header 5. 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 object values that together MUST NOT occur in distinct JSON object values that together
comprise the JWS Header. comprise the JWS Header.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
the algorithm is, the Unicode string "alg" will be checked against the algorithm is, the Unicode string "alg" will be checked against
the member names in the JWS Header to see if there is a matching the member names in the JWS Header to see if there is a matching
Header Parameter name. The same process is then used to determine if Header Parameter name. The same process is then used to determine if
the value of the "alg" Header Parameter represents a supported the value of the "alg" Header Parameter represents a supported
algorithm. algorithm.
Since the only string comparison operations that are performed are Since the only string comparison operations that are performed are
equality and inequality, the same rules can be used for comparing equality and inequality, the same rules can be used for comparing
both member names and member values against known strings. The JSON both member names and member values against known strings. The JSON
rules for doing member name comparison are described in Section 8.3 rules for doing member name comparison are described in Section 8.3
of [RFC7158]. of [RFC7159].
Also, see the JSON security considerations in Section 10.2 and the Also, see the JSON security considerations in Section 10.2 and the
Unicode security considerations in Section 10.3. Unicode security considerations in Section 10.3.
6. Key Identification 6. Key Identification
It is necessary for the recipient of a JWS to be able to determine It is necessary for the recipient of a JWS to be able to determine
the key that was employed for the digital signature or MAC operation. the key that was employed for the digital signature or MAC operation.
The key employed can be identified using the Header Parameter methods The key employed can be identified using the Header Parameter methods
described in Section 4.1 or can be identified using methods that are described in Section 4.1 or can be identified using methods that are
skipping to change at page 25, line 30 skipping to change at page 25, line 30
it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint
using SHA-256) Header Parameter could be defined and used. using SHA-256) Header Parameter could be defined and used.
10.2. JSON Security Considerations 10.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 4 of the JSON Data Interchange Format specification [RFC7158] Section 4 of the JSON Data Interchange Format specification [RFC7159]
states "The names within an object SHOULD be unique", whereas this states "The names within an object SHOULD be unique", whereas this
specification states that "Header Parameter names within this object specification states that "Header Parameter names within this object
MUST be unique; recipients MUST either reject JWSs with duplicate MUST be unique; 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, as specified in Section 15.12 lexically last duplicate member name, as specified in Section 15.12
(The JSON Object) of ECMAScript 5.1 [ECMAScript]". Thus, this (The JSON Object) of ECMAScript 5.1 [ECMAScript]". Thus, this
specification requires that the Section 4 "SHOULD" be treated as a specification requires that the Section 4 "SHOULD" be treated as a
"MUST" by senders and that it be either treated as a "MUST" or in the "MUST" by senders and that it be either treated as a "MUST" or in the
manner specified in ECMAScript 5.1 by receivers. Ambiguous and manner specified in ECMAScript 5.1 by receivers. Ambiguous and
potentially exploitable situations could arise if the JSON parser potentially exploitable situations could arise if the JSON parser
skipping to change at page 26, line 10 skipping to change at page 26, line 10
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.
10.3. Unicode Comparison Security Considerations 10.3. Unicode Comparison Security Considerations
Header Parameter names and algorithm names are Unicode strings. For Header Parameter names and algorithm names are Unicode strings. For
security reasons, the representations of these names must be compared security reasons, the representations of these names must be compared
verbatim after performing any escape processing (as per Section 8.3 verbatim after performing any escape processing (as per Section 8.3
of [RFC7158]). This means, for instance, that these JSON strings of [RFC7159]). This means, for instance, that these JSON strings
must compare as being equal ("sig", "\u0073ig"), whereas these must must compare as being equal ("sig", "\u0073ig"), whereas these must
all compare as being not equal to the first set or to each other all compare as being not equal to the first set or to each other
("SIG", "Sig", "si\u0047"). ("SIG", "Sig", "si\u0047").
JSON strings can contain characters outside the Unicode Basic JSON strings can contain characters outside the Unicode Basic
Multilingual Plane. For instance, the G clef character (U+1D11E) may Multilingual Plane. For instance, the G clef character (U+1D11E) may
be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS
implementations SHOULD ensure that characters outside the Basic implementations SHOULD ensure that characters outside the Basic
Multilingual Plane are preserved and compared correctly; Multilingual Plane are preserved and compared correctly;
alternatively, if this is not possible due to these characters alternatively, if this is not possible due to these characters
skipping to change at page 27, line 44 skipping to change at page 27, line 44
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC7158] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7158, March 2014. Interchange Format", RFC 7159, March 2014.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
11.2. Informative References 11.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign",
September 2010. September 2010.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
Encryption (JWE)", draft-ietf-jose-json-web-encryption draft-ietf-jose-json-web-encryption (work in progress),
(work in progress), March 2014. March 2014.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in (JWT)", draft-ietf-oauth-json-web-token (work in
progress), March 2014. progress), March 2014.
[MagicSignatures] [MagicSignatures]
Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011. Signatures", January 2011.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
skipping to change at page 47, line 21 skipping to change at page 47, line 21
Thanks to Axel Nennker for his early implementation and feedback on Thanks to Axel Nennker for his early implementation and feedback on
the JWS and JWE specifications. the JWS and JWE specifications.
This specification is the work of the JOSE Working Group, which This specification is the work of the JOSE Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that influenced this specification: that influenced this specification:
Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick
Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben
Laurie, James Manger, Matt Miller, Tony Nadalin, Axel Nennker, John Laurie, James Manger, Matt Miller, Tony Nadalin, Hideki Nara, Axel
Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad, Paul Tarjan, Nennker, John Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad,
Hannes Tschofenig, and Sean Turner. Paul Tarjan, 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 H. Document History Appendix H. 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 ]]
-24
o Updated the JSON reference to RFC 7159.
-23 -23
o Clarified that the base64url encoding includes no line breaks, o Clarified that the base64url encoding includes no line breaks,
white space, or other additional characters. white space, or other additional characters.
-22 -22
o Corrected RFC 2119 terminology usage. o Corrected RFC 2119 terminology usage.
o Replaced references to draft-ietf-json-rfc4627bis with RFC 7158. o Replaced references to draft-ietf-json-rfc4627bis with RFC 7158.
 End of changes. 13 change blocks. 
17 lines changed or deleted 21 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/