draft-ietf-jose-json-web-signature-20.txt   draft-ietf-jose-json-web-signature-21.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 24, 2014 Ping Identity Expires: August 18, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
January 20, 2014 February 14, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-20 draft-ietf-jose-json-web-signature-21
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 24, 2014. This Internet-Draft will expire on August 18, 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 3, line 4 skipping to change at page 3, line 4
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 . . . . . . . . . . . . . . . . 20 9.1.1. Registration Template . . . . . . . . . . . . . . . . 20
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21
9.2. Media Type Registration . . . . . . . . . . . . . . . . . 22 9.2. Media Type Registration . . . . . . . . . . . . . . . . . 22
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Cryptographic Security Considerations . . . . . . . . . . 23 10.1. Cryptographic Security Considerations . . . . . . . . . . 23
10.2. JSON Security Considerations . . . . . . . . . . . . . . . 25 10.2. JSON Security Considerations . . . . . . . . . . . . . . . 24
10.3. Unicode Comparison Security Considerations . . . . . . . . 25 10.3. Unicode Comparison Security Considerations . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28
A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 30 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 30
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 31 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 30
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31
A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 33 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 33
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 33 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 33
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 36 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 36
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 38 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 38
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 39 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 39
skipping to change at page 17, line 32 skipping to change at page 17, line 32
7.2. JWS JSON Serialization 7.2. JWS JSON Serialization
The JWS JSON Serialization represents digitally signed or MACed The JWS JSON Serialization represents digitally signed or MACed
content as a JSON object. Content using the JWS JSON Serialization content as a JSON object. Content using the JWS JSON Serialization
can be secured with more than one digital signature and/or MAC can be secured with more than one digital signature and/or MAC
operation. This representation is neither optimized for compactness operation. This representation is neither optimized for compactness
nor URL-safe. nor URL-safe.
The following members are defined for use in top-level JSON objects The following members are defined for use in top-level JSON objects
used for the JWS JSON Serialization: used for the JWS JSON Serialization:
payload The value BASE64URL(JWS Payload) is stored in the "payload" payload The "payload" member MUST be present and contain the value
member. BASE64URL(JWS Payload).
signatures A JSON array in the "signatures" member is used to hold signatures The "signatures" member value MUST be an array of JSON
values that are specific to a particular signature or MAC objects. Each object represents a signature or MAC over the JWS
computation, with one array element per signature/MAC represented. Payload and the JWS Protected Header.
These array elements are JSON objects, as specified below.
The following members are defined for use in the JSON objects that The following members are defined for use in the JSON objects that
are elements of the "signatures" array: are elements of the "signatures" array:
protected Each value BASE64URL(UTF8(JWS Protected Header)), if non- protected The "protected" member MUST be present and contain the
empty, is stored in the "protected" member. value BASE64URL(UTF8(JWS Protected Header)) when the JWS Protected
header Each JWS Unprotected Header value, if non-empty, is stored in Header value is non-empty; otherwise, it MUST be absent. These
the "header" member. If present, a JWS Unprotected Header value Header Parameter values are integrity protected.
is represented as an unencoded JSON object, rather than as a header The "header" member MUST be present and contain the value JWS
string. Unprotected Header when the JWS Unprotected Header value is non-
signature Each value BASE64URL(JWS Signature) is stored in the empty; otherwise, it MUST be absent. This value is represented as
"signature" member. an unencoded JSON object, rather than as a string. These Header
Parameter values are not integrity protected.
Of these members of the two JSON objects defined above, only the signature The "signature" member MUST be present and contain the
"payload", "signatures", and "signature" members MUST be present. At value BASE64URL(JWS Signature).
least one of the "protected" and "header" members MUST be present for
each signature/MAC computation so that an "alg" Header Parameter At least one of the "protected" and "header" members MUST be present
for each signature/MAC computation so that an "alg" Header Parameter
value is conveyed. value is conveyed.
Additional members can be present in both the JSON objects defined Additional members can be present in both the JSON objects defined
above; if not understood by implementations encountering them, they above; if not understood by implementations encountering them, they
MUST be ignored. MUST be ignored.
The Header Parameter values used when creating or validating The Header Parameter values used when creating or validating
individual signature or MAC values are the union of the two sets of individual signature or MAC values are the union of the two sets of
Header Parameter values that may be present: (1) the JWS Protected Header Parameter values that may be present: (1) the JWS Protected
Header values represented in the "protected" member of the signature/ Header represented in the "protected" member of the signature/MAC's
MAC's array element, and (2) the JWS Unprotected Header values in the array element, and (2) the JWS Unprotected Header in the "header"
"header" member of the signature/MAC's array element. The union of member of the signature/MAC's array element. The union of these sets
these sets of Header Parameters comprises the JWS Header. The Header of Header Parameters comprises the JWS Header. The Header Parameter
Parameter names in the two locations MUST be disjoint. names in the two locations MUST be disjoint.
The contents of the JWS Payload and JWS Signature values are exactly
as defined in the rest of this specification. They are interpreted
and validated in the same manner, with each corresponding JWS
Signature and set of Header Parameter values being created and
validated together.
Each JWS Signature value is computed on the JWS Signing Input using Each JWS Signature value is computed using the parameters of the
the parameters of the corresponding JWS Header value in the same corresponding JWS Header value in the same manner as for the JWS
manner as for the JWS Compact Serialization. This has the desirable Compact Serialization. This has the desirable property that each JWS
property that each JWS Signature value represented in the Signature value represented in the "signatures" array is identical to
"signatures" array is identical to the value that would have been the value that would have been computed for the same parameter in the
computed for the same parameter in the JWS Compact Serialization, JWS Compact Serialization, provided that the JWS Protected Header
provided that the JWS Protected Header value for that signature/MAC value for that signature/MAC computation (which represents the
computation (which represents the integrity-protected Header integrity-protected Header Parameter values) matches that used in the
Parameter values) matches that used in the JWS Compact Serialization. JWS Compact Serialization.
In summary, the syntax of a JWS using the JWS JSON Serialization is In summary, the syntax of a JWS using the JWS JSON Serialization is
as follows: as follows:
{ {
"payload":"<payload contents>", "payload":"<payload contents>",
"signatures":[ "signatures":[
{"protected":"<integrity-protected header 1 contents>", {"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>, "header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"}, "signature":"<signature 1 contents>"},
skipping to change at page 26, line 31 skipping to change at page 26, line 28
[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),
January 2014. February 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),
January 2014. February 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 27, line 18 skipping to change at page 27, line 17
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
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.
[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.
[W3C.WD-xmldsig-bestpractices-20110809]
Datta, P. and F. Hirsch, "XML Signature Best Practices",
World Wide Web Consortium WD WD-xmldsig-bestpractices-
20110809, August 2011, <http://www.w3.org/TR/2011/
WD-xmldsig-bestpractices-20110809>.
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., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption Encryption (JWE)", draft-ietf-jose-json-web-encryption
(work in progress), January 2014. (work in progress), February 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), January 2014. progress), February 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
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle, Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle,
J., Solo, D., Datta, P., and F. Hirsch, "XML Signature J., Solo, D., Datta, P., and F. Hirsch, "XML Signature
Syntax and Processing Version 2.0", World Wide Web Syntax and Processing Version 2.0", World Wide Web
Consortium CR CR-xmldsig-core2-20120124, January 2012, Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
[W3C.WD-xmldsig-bestpractices-20110809]
Datta, P. and F. Hirsch, "XML Signature Best Practices",
World Wide Web Consortium WD WD-xmldsig-bestpractices-
20110809, August 2011, <http://www.w3.org/TR/2011/
WD-xmldsig-bestpractices-20110809>.
Appendix A. JWS Examples Appendix A. JWS Examples
This section provides several examples of JWSs. While the first This section provides several examples of JWSs. While the first
three examples all represent JSON Web Tokens (JWTs) [JWT], the three examples all represent JSON Web Tokens (JWTs) [JWT], the
payload can be any octet sequence, as shown in Appendix A.4. payload can be any octet sequence, as shown in Appendix A.4.
A.1. Example JWS using HMAC SHA-256 A.1. Example JWS using HMAC SHA-256
A.1.1. Encoding A.1.1. Encoding
skipping to change at page 44, line 24 skipping to change at page 44, line 24
This appendix describes a set of possible algorithms for selecting This appendix describes a set of possible algorithms for selecting
the key to be used to validate the digital signature or MAC of a JWS the key to be used to validate the digital signature or MAC of a JWS
object or for selecting the key to be used to decrypt a JWE object. object or for selecting the key to be used to decrypt a JWE object.
This guidance describes a family of possible algorithms, rather than This guidance describes a family of possible algorithms, rather than
a single algorithm, because in different contexts, not all the a single algorithm, because in different contexts, not all the
sources of keys will be used, they can be tried in different orders, sources of keys will be used, they can be tried in different orders,
and sometimes not all the collected keys will be tried; hence, and sometimes not all the collected keys will be tried; hence,
different algorithms will be used in different application contexts. different algorithms will be used in different application contexts.
These algorithms use some or all of the steps described below; the The steps below are described for illustration purposes only;
order and inclusion of the steps does not mean that they need to be specific applications can and are likely to use different algorithms
performed in this order or that they are all required in all or perform some of the steps in different orders. Specific
contexts. The steps below are described for illustration purposes applications will frequently have a much simpler method of
only; specific applications can and are likely to use different determining the keys to use, as there may be one or two key selection
algorithms. Specific applications will frequently have a much methods that are profiled for the application's use. This appendix
simpler method of determining the keys to use, as there may be one or supplements the normative information on key location in Section 6.
two key selection methods that are profiled for the application's
use. This appendix supplements the normative information on key
location in Section 6.
Algorithm steps may include: These algorithms include the following steps. Note that the steps
can be performed in any order and do not need to be treated as
distinct. For example, keys can be tried as soon as they are found,
rather than collecting all the keys before trying any.
1. Collect a set of potentially applicable keys. Sources of keys 1. Collect the set of potentially applicable keys. Sources of keys
may include: may include:
* Keys supplied by the application protocol being used. * Keys supplied by the application protocol being used.
* Keys referenced by the "jku" (JWK Set URL) Header Parameter. * Keys referenced by the "jku" (JWK Set URL) Header Parameter.
* The key provided by the "jwk" (JSON Web Key) Header Parameter. * The key provided by the "jwk" (JSON Web Key) Header Parameter.
* Keys referenced by the "x5u" (X.509 URL) Header Parameter. * The key referenced by the "x5u" (X.509 URL) Header Parameter.
* The key provided by the "x5c" (X.509 Certificate Chain) Header * The key provided by the "x5c" (X.509 Certificate Chain) Header
Parameter. Parameter.
* Other applicable keys available to the application. * Other applicable keys available to the application.
2. Order the set of collected keys. For instance, keys referenced The order for collecting and trying keys from different key
sources is typically application dependent. For example,
frequently all keys from a one set of locations, such as local
caches, will be tried before collecting and trying keys from
other locations.
2. Filter the set of collected keys. For instance, some
applications will use only keys referenced by "kid" (key ID) or
"x5t" (X.509 certificate SHA-1 thumbprint) parameters. If the
application uses the "alg" (algorithm), "use" (public key use),
or "key_ops" (key operations) parameters, keys with keys with
inappropriate values of those parameters would be excluded.
Additionally, keys might be filtered to include or exclude keys
with certain other member values in an application specific
manner. For some applications, no filtering will be applied.
3. Order the set of collected keys. For instance, keys referenced
by "kid" (Key ID) or "x5t" (X.509 Certificate SHA-1 Thumbprint) by "kid" (Key ID) or "x5t" (X.509 Certificate SHA-1 Thumbprint)
parameters might be tried before other keys. Likewise, keys with parameters might be tried before keys with neither of these
certain "kty" (Key Type) values, "alg" (Algorithm) values, or values. Likewise, keys with certain member values might be
other member values might be ordered before keys with other "kty" ordered before keys with other member values. For some
values, "alg" values, or other member values. applications, no ordering will be applied.
3. Filter the set of collected keys. For instance, only keys 4. Make trust decisions about the keys. Signatures made with keys
referenced by "kid" (key ID) or "x5t" (X.509 certificate SHA-1 not meeting the application's trust criteria would not be
thumbprint) parameters might be tried by the application. Keys accepted. Such criteria might include, but is not limited to the
with an invalid certificate chain would typically be excluded. source of the key, whether the TLS certificate validates for keys
Keys with inappropriate "alg" (algorithm), "use" (public key retrieved from URLs, whether a key in an X.509 certificate is
use), or "key_ops" (key operations) values would likewise backed by a valid certificate chain, and other information known
typically be excluded. Keys might be filtered to include or by the application.
exclude keys with certain "kty" (key type) values or other member
values. A limit on the number of keys to be tried might also be
applied.
4. Attempt signature or MAC validation for a JWS object or 5. Attempt signature or MAC validation for a JWS object or
decryption of a JWE object with some or all of the collected and decryption of a JWE object with some or all of the collected and
possibly ordered and/or filtered keys. This process will possibly filtered and/or ordered keys. A limit on the number of
normally terminate following a successful validation or keys to be tried might be applied. This process will normally
decryption. terminate following a successful validation or decryption.
Note that it is reasonable for some applications to perform signature
or MAC validation prior to making a trust decision about a key, since
keys for which the validation fails need no trust decision.
Appendix E. Negative Test Case for "crit" Header Parameter Appendix E. Negative Test Case for "crit" Header Parameter
Conforming implementations must reject input containing critical Conforming implementations must reject input containing critical
extensions that are not understood or cannot be processed. The extensions that are not understood or cannot be processed. The
following JWS must be rejected by all implementations, because it following JWS must be rejected by all implementations, because it
uses an extension Header Parameter name uses an extension Header Parameter name
"http://example.invalid/UNDEFINED" that they do not understand. Any "http://example.invalid/UNDEFINED" that they do not understand. Any
other similar input, in which the use of the value other similar input, in which the use of the value
"http://example.invalid/UNDEFINED" is substituted for any other "http://example.invalid/UNDEFINED" is substituted for any other
skipping to change at page 47, line 13 skipping to change at page 47, line 27
Hannes Tschofenig, and Sean Turner. Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner and Stephen Farrell served as Security area directors Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix 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 ]]
-21
o Applied review comments to the appendix "Notes on Key Selection",
addressing issue #93.
o Changed some references from being normative to informative,
addressing issue #90.
o Applied review comments to the JSON Serialization section,
addressing issue #121.
-20 -20
o Made terminology definitions more consistent, addressing issue o Made terminology definitions more consistent, addressing issue
#165. #165.
o Restructured the JSON Serialization section to call out the o Restructured the JSON Serialization section to call out the
parameters used in hanging lists, addressing issue #121. parameters used in hanging lists, addressing issue #121.
o Described key filtering and refined other aspects of the text in o Described key filtering and refined other aspects of the text in
the appendix "Notes on Key Selection", addressing issue #93. the appendix "Notes on Key Selection", addressing issue #93.
 End of changes. 29 change blocks. 
90 lines changed or deleted 113 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/