draft-ietf-jose-json-web-signature-27.txt   draft-ietf-jose-json-web-signature-28.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: December 12, 2014 Ping Identity Expires: December 22, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
June 10, 2014 June 20, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-27 draft-ietf-jose-json-web-signature-28
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 December 12, 2014. This Internet-Draft will expire on December 22, 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 33 skipping to change at page 2, line 33
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. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) 4.1.8. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Header Parameter . . . . . . . . . . . . . . . . . . . 11 Header Parameter . . . . . . . . . . . . . . . . . . . 11
4.1.9. "typ" (Type) Header Parameter . . . . . . . . . . . . 12 4.1.9. "typ" (Type) Header Parameter . . . . . . . . . . . . 12
4.1.10. "cty" (Content Type) Header Parameter . . . . . . . . 12 4.1.10. "cty" (Content Type) Header Parameter . . . . . . . . 12
4.1.11. "crit" (Critical) Header Parameter . . . . . . . . . . 13 4.1.11. "crit" (Critical) Header Parameter . . . . . . . . . . 13
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 13 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . 18
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
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. Key Entropy . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. JSON Security Considerations . . . . . . . . . . . . . . . 25 10.2. Chosen Plaintext Attacks . . . . . . . . . . . . . . . . . 25
10.3. Unicode Comparison Security Considerations . . . . . . . . 26 10.3. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.4. Differences between Digital Signatures and MACs . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.5. SHA-1 Certificate Thumbprints . . . . . . . . . . . . . . 25
10.6. JSON Security Considerations . . . . . . . . . . . . . . . 26
10.7. Unicode Comparison Security Considerations . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . 32
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 31 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 32
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 32
A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 34 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 34 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 35
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 35
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 36 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 37
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 37 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 37
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 37 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 37
A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 39 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 39
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 39 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 40
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 40 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 40
A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 40 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 41
A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 41 A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 41
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 . . . . 42
Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 42 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 . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix D. Notes on Key Selection . . . . . . . . . . . . . . . 45 Appendix D. Notes on Key Selection . . . . . . . . . . . . . . . 45
Appendix E. Negative Test Case for "crit" Header Parameter . . . 46 Appendix E. Negative Test Case for "crit" Header Parameter . . . 47
Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 47 Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 48
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 47 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 48
Appendix H. Document History . . . . . . . . . . . . . . . . . . 48 Appendix H. Document History . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
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) [RFC7159] 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
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Parameter Parameter
The "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header The "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header
Parameter is a base64url encoded SHA-256 thumbprint (a.k.a. digest) Parameter is a base64url encoded SHA-256 thumbprint (a.k.a. digest)
of the DER encoding of the X.509 certificate [RFC5280] corresponding of the DER encoding of the X.509 certificate [RFC5280] corresponding
to the key used to digitally sign the JWS. Use of this Header to the key used to digitally sign the JWS. Use of this Header
Parameter is OPTIONAL. Parameter is OPTIONAL.
4.1.9. "typ" (Type) Header Parameter 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 by JWS applications to
Type [IANA.MediaTypes] of this complete JWS object in contexts where declare the MIME Media Type [IANA.MediaTypes] of this complete JWS
this is useful to the application. This parameter has no effect upon object. This is intended for use by the application when more than
the JWS processing. Use of this Header Parameter is OPTIONAL. one kind of object could be present in an application data structure
that can contain a JWS object; the application can use this value to
disambiguate among the different kinds of objects that might be
present. It will typically not be used by applications when the kind
of object is already known. This parameter has no effect upon 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.
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
"typ" Header Parameter when no other '/' appears in the media type "typ" 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 "typ" value not containing a "application/" were prepended to any "typ" value not containing a
skipping to change at page 12, line 39 skipping to change at page 12, line 44
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.10. "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 by JWS applications
Media Type [IANA.MediaTypes] of the secured content (the payload) in to declare the MIME Media Type [IANA.MediaTypes] of the secured
contexts where this is useful to the application. This parameter has content (the payload). This is intended for use by the application
no effect upon the JWS processing. Use of this Header Parameter is when more than one kind of object could be present in the JWS
OPTIONAL. payload; the application can use this value to disambiguate among the
different kinds of objects that might be present. It will typically
not be used by applications when the kind of object is already known.
This parameter has no effect upon 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.
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
skipping to change at page 16, line 37 skipping to change at page 16, line 48
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 [RFC7159]. of [RFC7159].
Also, see the JSON security considerations in Section 10.2 and the Also, see the JSON security considerations in Section 10.6 and the
Unicode security considerations in Section 10.3. Unicode security considerations in Section 10.7.
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", "x5t", and "x5t#S256" Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256"
can be used to identify the key used. These Header Parameters MUST can be used to identify the key used. These Header Parameters MUST
skipping to change at page 24, line 23 skipping to change at page 24, line 29
n/a, Macintosh file type code(s): n/a n/a, Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael o Person & email address to contact for further information: Michael
B. Jones, mbj@microsoft.com B. Jones, mbj@microsoft.com
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: none o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG o Change Controller: IESG
10. Security Considerations 10. Security Considerations
10.1. Cryptographic Security Considerations
All of the security issues faced by any cryptographic application All of the security issues faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are must be faced by a JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's asymmetric private and symmetric secret keys,
attacks, and helping the user avoid mistakes such as inadvertently preventing various attacks, and helping avoid mistakes such as
encrypting a message for the wrong recipient. The entire list of inadvertently encrypting a message to the wrong recipient. The
security considerations is beyond the scope of this document, but entire list of security considerations is beyond the scope of this
some significant concerns are listed here. document, but some significant concerns are listed here.
All the security considerations in XML DSIG 2.0 All the security considerations in XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411], also apply to this specification, [W3C.NOTE-xmldsig-core2-20130411], also apply to this specification,
other than those that are XML specific. Likewise, many of the best other than those that are XML specific. Likewise, many of the best
practices documented in XML Signature Best Practices practices documented in XML Signature Best Practices
[W3C.NOTE-xmldsig-bestpractices-20130411] also apply to this [W3C.NOTE-xmldsig-bestpractices-20130411] also apply to this
specification, other than those that are XML specific. specification, other than those that are XML specific.
10.1. Key Entropy
Keys are only as strong as the amount of entropy used to generate Keys are only as strong as the amount of entropy used to generate
them. A minimum of 128 bits of entropy should be used for all keys, them. A minimum of 128 bits of entropy should be used for all keys,
and depending upon the application context, more may be required. In and depending upon the application context, more may be required. In
particular, it may be difficult to generate sufficiently random particular, it may be difficult to generate sufficiently random
values in some browsers and application environments. values in some browsers and application environments.
10.2. Chosen Plaintext Attacks
Creators of JWSs should not allow third parties to insert arbitrary Creators of JWSs should not allow third parties to insert arbitrary
content into the message without adding entropy not controlled by the content into the message without adding entropy not controlled by the
third party. third party.
When utilizing TLS to retrieve information, the authority providing 10.3. Timing Attacks
the resource MUST be authenticated and the information retrieved MUST
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.
10.4. Differences between Digital Signatures and MACs
While MACs and digital signatures can both be used for integrity
checking, there are some significant differences between the security
properties that each of them provides. These need to be taken into
consideration when designing protocols and selecting the algorithms
to be used in protocols.
Both signatures and MACs provide for integrity checking -- verifying
that the message has not been modified since the integrity value was
computed. However, MACs provide for origination identification only
under specific circumstances. It can normally be assumed that a
private key used for a signature is only in the hands of a single
entity (although perhaps a distributed entity, in the case of
replicated servers); however, a MAC key needs to be in the hands of
all the entities that use it for integrity computation and checking.
This means that origination can only be determined if a MAC key is
known only to two entities and the receiver knows that it did not
create the message. MAC validation cannot be used to prove
origination to a third party.
10.5. SHA-1 Certificate Thumbprints
A SHA-1 hash is used when computing "x5t" (X.509 Certificate SHA-1 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.
Alternatively, the "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Alternatively, the "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Header Parameter could be used instead of "x5t". However, at the Header Parameter could be used instead of "x5t". However, at the
time of this writing, no development platform is known to support time of this writing, no development platform is known to support
SHA-256 certificate thumbprints. SHA-256 certificate thumbprints.
10.2. JSON Security Considerations 10.6. JSON Security Considerations
Strict JSON [RFC7159] validation is a security requirement. If Strict JSON [RFC7159] validation is a security requirement. If
malformed JSON is received, then the intent of the sender is malformed JSON is received, then the intent of the sender is
impossible to reliably discern. Ambiguous and potentially impossible to reliably discern. Ambiguous and potentially
exploitable situations could arise if the JSON parser used does not exploitable situations could arise if the JSON parser used does not
reject malformed JSON syntax. In particular, any JSON inputs not reject malformed JSON syntax. In particular, any JSON inputs not
conforming to the JSON-text syntax defined in RFC 7159 input MUST be conforming to the JSON-text syntax defined in RFC 7159 input MUST be
rejected in their entirety. rejected in their entirety.
Section 4 of the JSON Data Interchange Format specification [RFC7159] Section 4 of the JSON Data Interchange Format specification [RFC7159]
skipping to change at page 26, line 11 skipping to change at page 26, line 38
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". Such input MUST be rejected in its
entirety. entirety.
10.3. Unicode Comparison Security Considerations 10.7. 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
("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
skipping to change at page 48, line 27 skipping to change at page 49, line 13
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 ]]
-28
o Revised the introduction to the Security Considerations section.
Also introduced additional subsection headings for security
considerations items and also moved a security consideration item
here from the JWA draft.
o Added text about when applications typically would and would not
use "typ" and "cty" header parameters.
-27 -27
o Added the "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) header o Added the "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) header
parameter. parameter.
o Stated that any JSON inputs not conforming to the JSON-text syntax o Stated that any JSON inputs not conforming to the JSON-text syntax
defined in RFC 7159 input MUST be rejected in their entirety. defined in RFC 7159 input MUST be rejected in their entirety.
o Simplified the TLS requirements. o Simplified the TLS requirements.
 End of changes. 26 change blocks. 
51 lines changed or deleted 97 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/