draft-ietf-jose-json-web-signature-26.txt   draft-ietf-jose-json-web-signature-27.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: November 1, 2014 Ping Identity Expires: December 12, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
April 30, 2014 June 10, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-26 draft-ietf-jose-json-web-signature-27
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 November 1, 2014. This Internet-Draft will expire on December 12, 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 2, line 28 skipping to change at page 2, line 28
4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Registered Header Parameter Names . . . . . . . . . . . . 9 4.1. Registered Header Parameter Names . . . . . . . . . . . . 9
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 10 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 10
4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 10 4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 10
4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 10 4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 10
4.1.4. "kid" (Key ID) Header Parameter . . . . . . . . . . . 10 4.1.4. "kid" (Key ID) Header Parameter . . . . . . . . . . . 10
4.1.5. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 11 4.1.5. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 11
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 11 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 11
4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header 4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 11 Parameter . . . . . . . . . . . . . . . . . . . . . . 11
4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 12 4.1.8. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 12 Header Parameter . . . . . . . . . . . . . . . . . . . 11
4.1.10. "crit" (Critical) Header Parameter . . . . . . . . . . 13 4.1.9. "typ" (Type) Header Parameter . . . . . . . . . . . . 12
4.1.10. "cty" (Content Type) Header Parameter . . . . . . . . 12
4.1.11. "crit" (Critical) Header Parameter . . . . . . . . . . 13
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 13 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 13
4.3. Private Header Parameter Names . . . . . . . . . . . . . . 14 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 14
5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 14 5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 14
5.1. Message Signature or MAC Computation . . . . . . . . . . . 14 5.1. Message Signature or MAC Computation . . . . . . . . . . . 14
5.2. Message Signature or MAC Validation . . . . . . . . . . . 15 5.2. Message Signature or MAC Validation . . . . . . . . . . . 15
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 16 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 16
6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 16 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 16
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 17 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 17
7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 17 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 17
skipping to change at page 2, line 49 skipping to change at page 3, line 4
7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 17 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 17
7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 17 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 17
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. JSON Web Signature and Encryption Header Parameters 9.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 20 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1.1. Registration Template . . . . . . . . . . . . . . . . 21 9.1.1. Registration Template . . . . . . . . . . . . . . . . 21
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21
9.2. Media Type Registration . . . . . . . . . . . . . . . . . 23 9.2. Media Type Registration . . . . . . . . . . . . . . . . . 23
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10.1. Cryptographic Security Considerations . . . . . . . . . . 24 10.1. Cryptographic Security Considerations . . . . . . . . . . 24
10.2. JSON Security Considerations . . . . . . . . . . . . . . . 25 10.2. JSON Security Considerations . . . . . . . . . . . . . . . 25
10.3. Unicode Comparison Security Considerations . . . . . . . . 26 10.3. Unicode Comparison Security Considerations . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 29
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 29 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 29
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 29 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 29
A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 31 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 31
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 31 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 31
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31
A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 34 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 34
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 34 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 34
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 36 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 36
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 37 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 37
skipping to change at page 9, line 33 skipping to change at page 9, line 33
Parameter names or use a JSON parser that returns only the lexically Parameter names or use a JSON parser that returns only the lexically
last duplicate member name, as specified in Section 15.12 (The JSON last duplicate member name, as specified in Section 15.12 (The JSON
Object) of ECMAScript 5.1 [ECMAScript]. 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
Section 4.1.10, all Header Parameters not defined by this Section 4.1.11, all Header Parameters not defined by this
specification MUST be ignored when not understood. specification MUST be ignored when not understood.
There are three classes of Header Parameter names: Registered Header There are three classes of Header Parameter names: Registered Header
Parameter names, Public Header Parameter names, and Private Header Parameter names, Public Header Parameter names, and Private Header
Parameter names. Parameter names.
4.1. Registered Header Parameter Names 4.1. Registered Header Parameter Names
The following Header Parameter names are registered in the IANA JSON The following Header Parameter names are registered in the IANA JSON
Web Signature and Encryption Header Parameters registry defined in Web Signature and Encryption Header Parameters registry defined in
skipping to change at page 11, line 49 skipping to change at page 11, line 49
See Appendix B for an example "x5c" value. See Appendix B for an example "x5c" value.
4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter 4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter
The "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter is a The "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter is a
base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER
encoding of the X.509 certificate [RFC5280] corresponding to the key encoding of the X.509 certificate [RFC5280] corresponding to the key
used to digitally sign the JWS. Use of this Header Parameter is used to digitally sign the JWS. Use of this Header Parameter is
OPTIONAL. OPTIONAL.
If, in the future, certificate thumbprints need to be computed using 4.1.8. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header
hash functions other than SHA-1, it is suggested that additional Parameter
related Header Parameters be defined for that purpose. For example,
it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint
using SHA-256) Header Parameter could be defined by registering it in
the IANA JSON Web Signature and Encryption Header Parameters registry
defined in Section 9.1.
4.1.8. "typ" (Type) Header Parameter The "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header
Parameter is a base64url encoded SHA-256 thumbprint (a.k.a. digest)
of the DER encoding of the X.509 certificate [RFC5280] corresponding
to the key used to digitally sign the JWS. Use of this Header
Parameter is OPTIONAL.
4.1.9. "typ" (Type) Header Parameter
The "typ" (type) Header Parameter is used to declare the MIME Media The "typ" (type) Header Parameter is used to declare the MIME Media
Type [IANA.MediaTypes] of this complete JWS object in contexts where Type [IANA.MediaTypes] of this complete JWS object in contexts where
this is useful to the application. This parameter has no effect upon this is useful to the application. This parameter has no effect upon
the JWS processing. Use of this Header Parameter is OPTIONAL. the JWS processing. Use of this Header Parameter is OPTIONAL.
Per [RFC2045], all media type values, subtype values, and parameter Per [RFC2045], all media type values, subtype values, and parameter
names are case-insensitive. However, parameter values are case- names are case-insensitive. However, parameter values are case-
sensitive unless otherwise specified for the specific parameter. sensitive unless otherwise specified for the specific parameter.
skipping to change at page 12, line 36 skipping to change at page 12, line 37
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"".
The "typ" value "JOSE" can be used by applications to indicate that The "typ" value "JOSE" can be used by applications to indicate that
this object is a JWS or JWE using the JWS Compact Serialization or this object is a JWS or JWE using the JWS Compact Serialization or
the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be
used by applications to indicate that this object is a JWS or JWE used by applications to indicate that this object is a JWS or JWE
using the JWS JSON Serialization or the JWE JSON Serialization. using the JWS JSON Serialization or the JWE JSON Serialization.
Other type values can also be used by applications. Other type values can also be used by applications.
4.1.9. "cty" (Content Type) Header Parameter 4.1.10. "cty" (Content Type) Header Parameter
The "cty" (content type) Header Parameter is used to declare the MIME The "cty" (content type) Header Parameter is used to declare the MIME
Media Type [IANA.MediaTypes] of the secured content (the payload) in Media Type [IANA.MediaTypes] of the secured content (the payload) in
contexts where this is useful to the application. This parameter has contexts where this is useful to the application. This parameter has
no effect upon the JWS processing. Use of this Header Parameter is no effect upon the JWS processing. Use of this Header Parameter is
OPTIONAL. OPTIONAL.
Per [RFC2045], all media type values, subtype values, and parameter Per [RFC2045], all media type values, subtype values, and parameter
names are case-insensitive. However, parameter values are case- names are case-insensitive. However, parameter values are case-
sensitive unless otherwise specified for the specific parameter. sensitive unless otherwise specified for the specific parameter.
skipping to change at page 13, line 10 skipping to change at page 13, line 11
To keep messages compact in common situations, it is RECOMMENDED that To keep messages compact in common situations, it is RECOMMENDED that
senders omit an "application/" prefix of a media type value in a senders omit an "application/" prefix of a media type value in a
"cty" Header Parameter when no other '/' appears in the media type "cty" Header Parameter when no other '/' appears in the media type
value. A recipient using the media type value MUST treat it as if value. A recipient using the media type value MUST treat it as if
"application/" were prepended to any "cty" value not containing a "application/" were prepended to any "cty" value not containing a
'/'. For instance, a "cty" value of "example" SHOULD be used to '/'. For instance, a "cty" value of "example" SHOULD be used to
represent the "application/example" media type; whereas, the media represent the "application/example" media type; whereas, the media
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.10. "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 JWS Header array listing the Header Parameter names present in the JWS 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 receiver, it MUST Parameters are not understood and supported by the receiver, it MUST
reject the JWS. Senders MUST NOT include Header Parameter names reject the JWS. Senders MUST NOT include Header Parameter names
defined by the initial RFC versions of [[ this specification ]] or defined by the initial RFC versions of [[ this specification ]] or
[JWA] for use with JWS, duplicate names, or names that do not occur [JWA] for use with JWS, duplicate names, or names that do not occur
skipping to change at page 16, line 47 skipping to change at page 16, line 47
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
outside the scope of this specification. Specifically, the Header outside the scope of this specification. Specifically, the Header
Parameters "jku", "jwk", "kid", "x5u", "x5c", and "x5t" can be used Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256"
to identify the key used. These Header Parameters MUST be integrity can be used to identify the key used. These Header Parameters MUST
protected if the information that they convey is to be utilized in a be integrity protected if the information that they convey is to be
trust decision. utilized in a trust decision.
The sender SHOULD include sufficient information in the Header The sender SHOULD include sufficient information in the Header
Parameters to identify the key used, unless the application uses Parameters to identify the key used, unless the application uses
another means or convention to determine the key used. Validation of another means or convention to determine the key used. Validation of
the signature or MAC fails when the algorithm used requires a key the signature or MAC fails when the algorithm used requires a key
(which is true of all algorithms except for "none") and the key used (which is true of all algorithms except for "none") and the key used
cannot be determined. cannot be determined.
The means of exchanging any shared symmetric keys used is outside the The means of exchanging any shared symmetric keys used is outside the
scope of this specification. scope of this specification.
skipping to change at page 19, line 32 skipping to change at page 19, line 32
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. TLS Requirements 8. TLS Requirements
Implementations MUST support TLS. Which version(s) ought to be Implementations MUST support TLS. Which version(s) ought to be
implemented will vary over time, and depend on the widespread implemented will vary over time, and depend on the widespread
deployment and known security vulnerabilities at the time of deployment and known security vulnerabilities at the time of
implementation. At the time of this writing, TLS version 1.2 implementation. At the time of this writing, TLS version 1.2
[RFC5246] is the most recent version, but has very limited actual [RFC5246] is the most recent version.
deployment, and might not be readily available in implementation
toolkits.
To protect against information disclosure and tampering, To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a confidentiality protection MUST be applied using TLS with a
ciphersuite that provides confidentiality and integrity protection. ciphersuite that provides confidentiality and integrity protection.
Whenever TLS is used, the identity of the service provider encoded in Whenever TLS is used, the identity of the service provider encoded in
the TLS server certificate MUST be verified using the procedures the TLS server certificate MUST be verified using the procedures
described in Section 6 of RFC 6125 [RFC6125]. described in Section 6 of RFC 6125 [RFC6125].
9. IANA Considerations 9. IANA Considerations
skipping to change at page 22, line 32 skipping to change at page 22, line 32
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1.6 of [[ this document ]] o Specification Document(s): Section 4.1.6 of [[ this document ]]
o Header Parameter Name: "x5t" o Header Parameter Name: "x5t"
o Header Parameter Description: X.509 Certificate SHA-1 Thumbprint o Header Parameter Description: X.509 Certificate SHA-1 Thumbprint
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1.7 of [[ this document ]] o Specification Document(s): Section 4.1.7 of [[ this document ]]
o Header Parameter Name: "x5t#S256"
o Header Parameter Description: X.509 Certificate SHA-256 Thumbprint
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.8 of [[ this document ]]
o Header Parameter Name: "typ" o Header Parameter Name: "typ"
o Header Parameter Description: Type o Header Parameter Description: Type
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1.8 of [[ this document ]] o Specification Document(s): Section 4.1.9 of [[ this document ]]
o Header Parameter Name: "cty" o Header Parameter Name: "cty"
o Header Parameter Description: Content Type o Header Parameter Description: Content Type
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1.9 of [[ this document ]] o Specification Document(s): Section 4.1.10 of [[ this document ]]
o Header Parameter Name: "crit" o Header Parameter Name: "crit"
o Header Parameter Description: Critical o Header Parameter Description: Critical
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1.10 of [[ this document ]] o Specification Document(s): Section 4.1.11 of [[ this document ]]
9.2. Media Type Registration 9.2. Media Type Registration
9.2.1. Registry Contents 9.2.1. Registry Contents
This specification registers the "application/jose" Media Type This specification registers the "application/jose" Media Type
[RFC2046] in the MIME Media Types registry [IANA.MediaTypes], which [RFC2046] in the MIME Media Types registry [IANA.MediaTypes], which
can be used to indicate that the content is a JWS or JWE object using can be used to indicate that the content is a JWS or JWE object using
the JWS Compact Serialization or the JWE Compact Serialization and the JWS Compact Serialization or the JWE Compact Serialization and
the "application/jose+json" Media Type in the MIME Media Types the "application/jose+json" Media Type in the MIME Media Types
skipping to change at page 25, line 7 skipping to change at page 25, line 13
When utilizing TLS to retrieve information, the authority providing When utilizing TLS to retrieve information, the authority providing
the resource MUST be authenticated and the information retrieved MUST the resource MUST be authenticated and the information retrieved MUST
be free from modification. be free from modification.
When cryptographic algorithms are implemented in such a way that When cryptographic algorithms are implemented in such a way that
successful operations take a different amount of time than successful operations take a different amount of time than
unsuccessful operations, attackers may be able to use the time unsuccessful operations, attackers may be able to use the time
difference to obtain information about the keys employed. Therefore, difference to obtain information about the keys employed. Therefore,
such timing differences must be avoided. such timing differences must be avoided.
A SHA-1 hash is used when computing "x5t" (x.509 certificate A SHA-1 hash is used when computing "x5t" (X.509 Certificate SHA-1
thumbprint) values, for compatibility reasons. Should an effective Thumbprint) values, for compatibility reasons. Should an effective
means of producing SHA-1 hash collisions be developed, and should an means of producing SHA-1 hash collisions be developed, and should an
attacker wish to interfere with the use of a known certificate on a attacker wish to interfere with the use of a known certificate on a
given system, this could be accomplished by creating another given system, this could be accomplished by creating another
certificate whose SHA-1 hash value is the same and adding it to the certificate whose SHA-1 hash value is the same and adding it to the
certificate store used by the intended victim. A prerequisite to certificate store used by the intended victim. A prerequisite to
this attack succeeding is the attacker having write access to the this attack succeeding is the attacker having write access to the
intended victim's certificate store. intended victim's certificate store.
If, in the future, certificate thumbprints need to be computed using Alternatively, the "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
hash functions other than SHA-1, it is suggested that additional Header Parameter could be used instead of "x5t". However, at the
related Header Parameters be defined for that purpose. For example, time of this writing, no development platform is known to support
it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint SHA-256 certificate thumbprints.
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 [RFC7159] validation is a security requirement. If
is received, then the intent of the sender is impossible to reliably malformed JSON is received, then the intent of the sender is
discern. Ambiguous and potentially exploitable situations could impossible to reliably discern. Ambiguous and potentially
arise if the JSON parser used does not reject malformed JSON syntax. exploitable situations could arise if the JSON parser used does not
reject malformed JSON syntax. In particular, any JSON inputs not
conforming to the JSON-text syntax defined in RFC 7159 input MUST be
rejected in their entirety.
Section 4 of the JSON Data Interchange Format specification [RFC7159] 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
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 object followed by the "{"tag":"value"}ABCD" contains a valid JSON-text object followed by
extra characters "ABCD". Such input MUST be rejected in its the 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 [RFC7159]). 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
skipping to change at page 26, line 45 skipping to change at page 26, line 51
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", [JWA] Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms (work in progress), draft-ietf-jose-json-web-algorithms (work in progress),
April 2014. June 2014.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), draft-ietf-jose-json-web-key (work in progress),
April 2014. June 2014.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, February 1993. Procedures", RFC 1421, February 1993.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
skipping to change at page 28, line 15 skipping to change at page 28, line 19
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. 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),
April 2014. June 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), April 2014. progress), June 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
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
skipping to change at page 48, line 27 skipping to change at page 48, line 27
Paul Tarjan, 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, 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 ]]
-27
o Added the "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) header
parameter.
o Stated that any JSON inputs not conforming to the JSON-text syntax
defined in RFC 7159 input MUST be rejected in their entirety.
o Simplified the TLS requirements.
-26 -26
o Referenced Section 6 of RFC 6125 for TLS server certificate o Referenced Section 6 of RFC 6125 for TLS server certificate
identity validation. identity validation.
o Described potential sources of ambiguity in representing the JSON o Described potential sources of ambiguity in representing the JSON
objects used in the examples. The octets of the actual UTF-8 objects used in the examples. The octets of the actual UTF-8
representations of the JSON objects used in the examples are representations of the JSON objects used in the examples are
included to remove these ambiguities. included to remove these ambiguities.
 End of changes. 27 change blocks. 
47 lines changed or deleted 66 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/