draft-ietf-jose-json-web-signature-40.txt   draft-ietf-jose-json-web-signature-41.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: July 17, 2015 Ping Identity Expires: July 20, 2015 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
January 13, 2015 January 16, 2015
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-40 draft-ietf-jose-json-web-signature-41
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 July 17, 2015. This Internet-Draft will expire on July 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 14, line 43 skipping to change at page 14, line 43
type "application/example;part="1/2"" cannot be shortened to type "application/example;part="1/2"" cannot be shortened to
"example;part="1/2"". "example;part="1/2"".
4.1.11. "crit" (Critical) Header Parameter 4.1.11. "crit" (Critical) Header Parameter
The "crit" (critical) Header Parameter indicates that extensions to The "crit" (critical) Header Parameter indicates that extensions to
the initial RFC versions of [[ this specification ]] and [JWA] are the initial RFC versions of [[ this specification ]] and [JWA] are
being used that MUST be understood and processed. Its value is an being used that MUST be understood and processed. Its value is an
array listing the Header Parameter names present in the JOSE Header array listing the Header Parameter names present in the JOSE Header
that use those extensions. If any of the listed extension Header that use those extensions. If any of the listed extension Header
Parameters are not understood and supported by the recipient, it MUST Parameters are not understood and supported by the recipient, then
reject the JWS. Producers MUST NOT include Header Parameter names the JWS is invalid. Producers MUST NOT include Header Parameter
defined by the initial RFC versions of [[ this specification ]] or names defined by the initial RFC versions of [[ this specification ]]
[JWA] for use with JWS, duplicate names, or names that do not occur or [JWA] for use with JWS, duplicate names, or names that do not
as Header Parameter names within the JOSE Header in the "crit" list. occur as Header Parameter names within the JOSE Header in the "crit"
Producers MUST NOT use the empty list "[]" as the "crit" value. list. Producers MUST NOT use the empty list "[]" as the "crit"
Recipients MAY reject the JWS if the critical list contains any value. Recipients MAY consider the JWS to be invalid if the critical
Header Parameter names defined by the initial RFC versions of [[ this list contains any Header Parameter names defined by the initial RFC
specification ]] or [JWA] for use with JWS, or any other constraints versions of [[ this specification ]] or [JWA] for use with JWS, or
on its use are violated. When used, this Header Parameter MUST be any other constraints on its use are violated. When used, this
integrity protected; therefore, it MUST occur only within the JWS Header Parameter MUST be integrity protected; therefore, it MUST
Protected Header. Use of this Header Parameter is OPTIONAL. This occur only within the JWS Protected Header. Use of this Header
Header Parameter MUST be understood and processed by implementations. Parameter is OPTIONAL. This Header Parameter MUST be understood and
processed by implementations.
An example use, along with a hypothetical "exp" (expiration-time) An example use, along with a hypothetical "exp" (expiration-time)
field is: field is:
{"alg":"ES256", {"alg":"ES256",
"crit":["exp"], "crit":["exp"],
"exp":1363284000 "exp":1363284000
} }
4.2. Public Header Parameter Names 4.2. Public Header Parameter Names
skipping to change at page 16, line 8 skipping to change at page 16, line 8
To create a JWS, the following steps are performed. The order of the To create a JWS, the following steps are performed. The order of the
steps is not significant in cases where there are no dependencies steps is not significant in cases where there are no dependencies
between the inputs and outputs of the steps. between the inputs and outputs of the steps.
1. Create the content to be used as the JWS Payload. 1. Create the content to be used as the JWS Payload.
2. Compute the encoded payload value BASE64URL(JWS Payload). 2. Compute the encoded payload value BASE64URL(JWS Payload).
3. Create the JSON object(s) containing the desired set of Header 3. Create the JSON object(s) containing the desired set of Header
Parameters, which together comprise the JOSE Header: if the JWS Parameters, which together comprise the JOSE Header: the JWS
Compact Serialization is being used, the JWS Protected Header, or Protected Header and/or the JWS Unprotected Header.
if the JWS JSON Serialization is being used, the JWS Protected
Header and/or the JWS Unprotected Header.
4. Compute the encoded header value BASE64URL(UTF8(JWS Protected 4. Compute the encoded header value BASE64URL(UTF8(JWS Protected
Header)). If the JWS Protected Header is not present (which can Header)). If the JWS Protected Header is not present (which can
only happen when using the JWS JSON Serialization and no only happen when using the JWS JSON Serialization and no
"protected" member is present), let this value be the empty "protected" member is present), let this value be the empty
string. string.
5. Compute the JWS Signature in the manner defined for the 5. Compute the JWS Signature in the manner defined for the
particular algorithm being used over the JWS Signing Input particular algorithm being used over the JWS Signing Input
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
skipping to change at page 32, line 32 skipping to change at page 32, line 32
specification requires that the Section 4 "SHOULD" be treated as a specification requires that the Section 4 "SHOULD" be treated as a
"MUST" by producers and that it be either treated as a "MUST" or in "MUST" by producers and that it be either treated as a "MUST" or in
the manner specified in ECMAScript 5.1 by consumers. Ambiguous and the manner specified in ECMAScript 5.1 by consumers. Ambiguous and
potentially exploitable situations could arise if the JSON parser potentially exploitable situations could arise if the JSON parser
used does not enforce the uniqueness of member names or returns an used does not enforce the uniqueness of member names or returns an
unpredictable value for duplicate member names. 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-text object followed by "{"tag":"value"}ABCD" contains a valid JSON-text object followed by
the extra characters "ABCD". Such input MUST be rejected in its the extra characters "ABCD". Implementations MUST consider JWSs
entirety. containing such input to be invalid.
10.13. Unicode Comparison Security Considerations 10.13. 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 RFC 7159 [RFC7159]). This means, for instance, that these JSON of RFC 7159 [RFC7159]). This means, for instance, that these JSON
strings must compare as being equal ("sig", "\u0073ig"), whereas strings must compare as being equal ("sig", "\u0073ig"), whereas
these must all compare as being not equal to the first set or to each these must all compare as being not equal to the first set or to each
other ("SIG", "Sig", "si\u0047"). other ("SIG", "Sig", "si\u0047").
skipping to change at page 35, line 11 skipping to change at page 35, line 11
[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. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress), draft-ietf-jose-json-web-encryption (work in progress),
January 2015. January 2015.
[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), December 2014. progress), January 2015.
[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.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
skipping to change at page 56, line 21 skipping to change at page 56, line 21
Tschofenig, and Sean Turner. 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, Stephen Farrell, and Kathleen Moriarty served as Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors 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 ]]
-41
o Changed more instances of "reject" to "consider to be invalid".
o Simplified the wording of a Message Signature or MAC Computation
step.
-40 -40
o Clarified the definitions of UTF8(STRING) and ASCII(STRING). o Clarified the definitions of UTF8(STRING) and ASCII(STRING).
o Stated that line breaks are for display purposes only in places o Stated that line breaks are for display purposes only in places
where this disclaimer was needed and missing. where this disclaimer was needed and missing.
-39 -39
o Updated the reference to draft-ietf-uta-tls-bcp. o Updated the reference to draft-ietf-uta-tls-bcp.
 End of changes. 9 change blocks. 
24 lines changed or deleted 30 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/