draft-ietf-jose-json-web-signature-33.txt   draft-ietf-jose-json-web-signature-34.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: March 29, 2015 Ping Identity Expires: April 17, 2015 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
September 25, 2014 October 14, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-33 draft-ietf-jose-json-web-signature-34
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 March 29, 2015. This Internet-Draft will expire on April 17, 2015.
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.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. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) 4.1.8. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Header Parameter . . . . . . . . . . . . . . . . . . . 12 Header Parameter . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . 13
4.1.11. "crit" (Critical) Header Parameter . . . . . . . . . . 13 4.1.11. "crit" (Critical) Header Parameter . . . . . . . . . . 13
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 17 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 17
6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 17 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 17
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 18 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 18
7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . 18 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . 18
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 20 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. JSON Web Signature and Encryption Header Parameters 9.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . 21 Registry . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1.1. Registration Template . . . . . . . . . . . . . . . . 22 9.1.1. Registration Template . . . . . . . . . . . . . . . . 22
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 23
9.2. Media Type Registration . . . . . . . . . . . . . . . . . 24 9.2. Media Type Registration . . . . . . . . . . . . . . . . . 24
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 24 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10.1. Key Entropy and Random Values . . . . . . . . . . . . . . 25 10.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26
10.2. Key Protection . . . . . . . . . . . . . . . . . . . . . 26 10.2. Key Protection . . . . . . . . . . . . . . . . . . . . . 26
10.3. Key Origin Authentication . . . . . . . . . . . . . . . . 26 10.3. Key Origin Authentication . . . . . . . . . . . . . . . . 27
10.4. Cryptographic Agility . . . . . . . . . . . . . . . . . . 26 10.4. Cryptographic Agility . . . . . . . . . . . . . . . . . . 27
10.5. Differences between Digital Signatures and MACs . . . . . 26 10.5. Differences between Digital Signatures and MACs . . . . . 27
10.6. Algorithm Validation . . . . . . . . . . . . . . . . . . 27 10.6. Algorithm Validation . . . . . . . . . . . . . . . . . . 27
10.7. Algorithm Protection . . . . . . . . . . . . . . . . . . 27 10.7. Algorithm Protection . . . . . . . . . . . . . . . . . . 28
10.8. Chosen Plaintext Attacks . . . . . . . . . . . . . . . . 28 10.8. Chosen Plaintext Attacks . . . . . . . . . . . . . . . . 28
10.9. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 28 10.9. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 29
10.10. Replay Protection . . . . . . . . . . . . . . . . . . . . 28 10.10. Replay Protection . . . . . . . . . . . . . . . . . . . . 29
10.11. SHA-1 Certificate Thumbprints . . . . . . . . . . . . . . 28 10.11. SHA-1 Certificate Thumbprints . . . . . . . . . . . . . . 29
10.12. JSON Security Considerations . . . . . . . . . . . . . . 28 10.12. JSON Security Considerations . . . . . . . . . . . . . . 29
10.13. Unicode Comparison Security Considerations . . . . . . . 29 10.13. Unicode Comparison Security Considerations . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 32 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 33
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . 33 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . 33
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34
A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 36
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . 35 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . 36
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 35 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 39
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 38 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 39
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 38 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 39
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 40 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 41
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 41 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 42
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 41 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 42
A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 43 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 44
A.5. Example Unsecured JWS . . . . . . . . . . . . . . . . . . 43 A.5. Example Unsecured JWS . . . . . . . . . . . . . . . . . . 44
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . 44 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . 45
A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 44 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 45
A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 45 A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 46
A.6.3. Complete JOSE Header Values . . . . . . . . . . . . . 45 A.6.3. Complete JOSE Header Values . . . . . . . . . . . . . 46
A.6.4. Complete JWS JSON Serialization Representation . . . . 45 A.6.4. Complete JWS JSON Serialization Representation . . . . 46
Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 46 Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 47
Appendix C. Notes on implementing base64url encoding without Appendix C. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . . 48 padding . . . . . . . . . . . . . . . . . . . . . . . 49
Appendix D. Notes on Key Selection . . . . . . . . . . . . . . . 49 Appendix D. Notes on Key Selection . . . . . . . . . . . . . . . 50
Appendix E. Negative Test Case for "crit" Header Parameter . . . 50 Appendix E. Negative Test Case for "crit" Header Parameter . . . 51
Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 51 Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 52
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 51 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 52
Appendix H. Document History . . . . . . . . . . . . . . . . . . 52 Appendix H. Document History . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
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. See Section 10.5 for a discussion on arbitrary sequence of octets. See Section 10.5 for a discussion on
the differences between Digital Signatures and MACs. the differences between Digital Signatures and MACs.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
JWS Unprotected Header JWS Unprotected Header
JSON object that contains the Header Parameters that are not JSON object that contains the Header Parameters that are not
integrity protected. This can only be present when using the JWS integrity protected. This can only be present when using the JWS
JSON Serialization. JSON Serialization.
Base64url Encoding Base64url Encoding
Base64 encoding using the URL- and filename-safe character set Base64 encoding using the URL- and filename-safe character set
defined in Section 5 of RFC 4648 [RFC4648], with all trailing '=' defined in Section 5 of RFC 4648 [RFC4648], with all trailing '='
characters omitted (as permitted by Section 3.2) and without the characters omitted (as permitted by Section 3.2) and without the
inclusion of any line breaks, white space, or other additional inclusion of any line breaks, white space, or other additional
characters. (See Appendix C for notes on implementing base64url characters. Note that the base64url encoding of the empty octet
encoding without padding.) sequence is the empty string. (See Appendix C for notes on
implementing base64url encoding without padding.)
JWS Signing Input JWS Signing Input
The input to the digital signature or MAC computation. Its value The input to the digital signature or MAC computation. Its value
is ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || is ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload)). BASE64URL(JWS Payload)).
JWS Compact Serialization JWS Compact Serialization
A representation of the JWS as a compact, URL-safe string. A representation of the JWS as a compact, URL-safe string.
JWS JSON Serialization JWS JSON Serialization
A representation of the JWS as a JSON object. Unlike the JWS A representation of the JWS as a JSON object. Unlike the JWS
Compact Serialization, the JWS JSON Serialization enables multiple Compact Serialization, the JWS JSON Serialization enables multiple
digital signatures and/or MACs to be applied to the same content. digital signatures and/or MACs to be applied to the same content.
This representation is neither optimized for compactness nor URL- This representation is neither optimized for compactness nor URL-
safe. safe.
Unsecured JWS Unsecured JWS
A JWS object that provides no integrity protection. A JWS object that provides no integrity protection. Unsecured
JWSs use the "alg" value "none".
Collision-Resistant Name Collision-Resistant Name
A name in a namespace that enables names to be allocated in a A name in a namespace that enables names to be allocated in a
manner such that they are highly unlikely to collide with other manner such that they are highly unlikely to collide with other
names. Examples of collision-resistant namespaces include: Domain names. Examples of collision-resistant namespaces include: Domain
Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
X.670 Recommendation series, and Universally Unique IDentifiers X.670 Recommendation series, and Universally Unique IDentifiers
(UUIDs) [RFC4122]. When using an administratively delegated (UUIDs) [RFC4122]. When using an administratively delegated
namespace, the definer of a name needs to take reasonable namespace, the definer of a name needs to take reasonable
precautions to ensure they are in control of the portion of the precautions to ensure they are in control of the portion of the
skipping to change at page 6, line 38 skipping to change at page 6, line 39
StringOrURI StringOrURI
A JSON string value, with the additional requirement that while A JSON string value, with the additional requirement that while
arbitrary string values MAY be used, any value containing a ":" arbitrary string values MAY be used, any value containing a ":"
character MUST be a URI [RFC3986]. StringOrURI values are character MUST be a URI [RFC3986]. StringOrURI values are
compared as case-sensitive strings with no transformations or compared as case-sensitive strings with no transformations or
canonicalizations applied. canonicalizations applied.
These terms defined by the JSON Web Encryption (JWE) [JWE] These terms defined by the JSON Web Encryption (JWE) [JWE]
specification are incorporated into this specification: "JSON Web specification are incorporated into this specification: "JSON Web
Encryption (JWE)" and "JWE Compact Serialization". Encryption (JWE)", "JWE Compact Serialization", and "JWE JSON
Serialization".
3. JSON Web Signature (JWS) Overview 3. JSON Web Signature (JWS) Overview
JWS represents digitally signed or MACed content using JSON data JWS represents digitally signed or MACed content using JSON data
structures and base64url encoding. These JSON data structures MAY structures and base64url encoding. These JSON data structures MAY
contain white space and/or line breaks. A JWS represents these contain white space and/or line breaks. A JWS represents these
logical values (each of which is defined in Section 2): logical values (each of which is defined in Section 2):
o JOSE Header o JOSE Header
o JWS Payload o JWS Payload
skipping to change at page 7, line 13 skipping to change at page 7, line 17
For a JWS object, the JOSE Header members are the union of the For a JWS object, the JOSE Header members are the union of the
members of these values (each of which is defined in Section 2): members of these values (each of which is defined in Section 2):
o JWS Protected Header o JWS Protected Header
o JWS Unprotected Header o JWS Unprotected Header
This document defines two serializations for JWS objects: a compact, This document defines two serializations for JWS objects: a compact,
URL-safe serialization called the JWS Compact Serialization and a URL-safe serialization called the JWS Compact Serialization and a
JSON serialization called the JWS JSON Serialization. In both JSON serialization called the JWS JSON Serialization. In both
serializations, the JWS Protected Header, JWS Payload, and JWS serializations, the JWS Protected Header, JWS Payload, and JWS
Signature are base64url encoded for transmission, since JSON lacks a Signature are base64url encoded, since JSON lacks a way to directly
way to directly represent arbitrary octet sequences. represent arbitrary octet sequences.
3.1. JWS Compact Serialization Overview 3.1. JWS Compact Serialization Overview
In the JWS Compact Serialization, no JWS Unprotected Header is used. In the JWS Compact Serialization, no JWS Unprotected Header is used.
In this case, the JOSE Header and the JWS Protected Header are the In this case, the JOSE Header and the JWS Protected Header are the
same. same.
In the JWS Compact Serialization, a JWS object is represented as the In the JWS Compact Serialization, a JWS object is represented as the
concatenation: concatenation:
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature) BASE64URL(JWS Signature)
See Section 7.1 for more information about the JWS Compact
Serialization.
3.2. JWS JSON Serialization Overview 3.2. JWS JSON Serialization Overview
In the JWS JSON Serialization, one or both of the JWS Protected In the JWS JSON Serialization, one or both of the JWS Protected
Header and JWS Unprotected Header MUST be present. In this case, the Header and JWS Unprotected Header MUST be present. In this case, the
members of the JOSE Header are the combination of the members of the members of the JOSE Header are the union of the members of the JWS
JWS Protected Header and the JWS Unprotected Header values that are Protected Header and the JWS Unprotected Header values that are
present. present.
In the JWS JSON Serialization, a JWS object is represented as the In the JWS JSON Serialization, a JWS object is represented as the
combination of these four values, combination of these four values,
BASE64URL(UTF8(JWS Protected Header)), BASE64URL(UTF8(JWS Protected Header)),
JWS Unprotected Header, JWS Unprotected Header,
BASE64URL(JWS Payload), and BASE64URL(JWS Payload), and
BASE64URL(JWS Signature), BASE64URL(JWS Signature),
with the three base64url encoding result strings and the JWS with the three base64url encoding result strings and the JWS
Unprotected Header value being represented as members within a JSON Unprotected Header value being represented as members within a JSON
skipping to change at page 9, line 12 skipping to change at page 9, line 15
representation using the JWS Compact Serialization (with line breaks representation using the JWS Compact Serialization (with line breaks
for display purposes only): for display purposes only):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
See Appendix A for additional examples. See Appendix A for additional examples, including an example using
the JWS JSON Serialization in Appendix A.6.
4. JOSE Header 4. JOSE Header
For a JWS object, the members of the JSON object(s) representing the For a JWS object, the members of the JSON object(s) representing the
JOSE Header describe the digital signature or MAC applied to the JWS JOSE Header describe the digital signature or MAC applied to the JWS
Protected Header and the JWS Payload and optionally additional Protected Header and the JWS Payload and optionally additional
properties of the JWS. The Header Parameter names within the JOSE properties of the JWS. The Header Parameter names within the JOSE
Header MUST be unique; recipients MUST either reject JWSs with Header MUST be unique; JWS parsers MUST either reject JWSs with
duplicate Header Parameter names or use a JSON parser that returns duplicate Header Parameter names or use a JSON parser that returns
only the lexically last duplicate member name, as specified in only the lexically last duplicate member name, as specified in
Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. Section 15.12 (The JSON 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
skipping to change at page 10, line 32 skipping to change at page 10, line 34
4.1.2. "jku" (JWK Set URL) Header Parameter 4.1.2. "jku" (JWK Set URL) Header Parameter
The "jku" (JWK Set URL) Header Parameter is a URI [RFC3986] that The "jku" (JWK Set URL) Header Parameter is a URI [RFC3986] that
refers to a resource for a set of JSON-encoded public keys, one of refers to a resource for a set of JSON-encoded public keys, one of
which corresponds to the key used to digitally sign the JWS. The which corresponds to the key used to digitally sign the JWS. The
keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The
protocol used to acquire the resource MUST provide integrity protocol used to acquire the resource MUST provide integrity
protection; an HTTP GET request to retrieve the JWK Set MUST use TLS protection; an HTTP GET request to retrieve the JWK Set MUST use TLS
[RFC2818, RFC5246]; the identity of the server MUST be validated, as [RFC2818, RFC5246]; the identity of the server MUST be validated, as
per Section 6 of RFC 6125 [RFC6125]. Use of this Header Parameter is per Section 6 of RFC 6125 [RFC6125]. Also, see Section 8 on TLS
OPTIONAL. requirements. Use of this Header Parameter is OPTIONAL.
4.1.3. "jwk" (JSON Web Key) Header Parameter 4.1.3. "jwk" (JSON Web Key) Header Parameter
The "jwk" (JSON Web Key) Header Parameter is the public key that The "jwk" (JSON Web Key) Header Parameter is the public key that
corresponds to the key used to digitally sign the JWS. This key is corresponds to the key used to digitally sign the JWS. This key is
represented as a JSON Web Key [JWK]. Use of this Header Parameter is represented as a JSON Web Key [JWK]. Use of this Header Parameter is
OPTIONAL. OPTIONAL.
4.1.4. "kid" (Key ID) Header Parameter 4.1.4. "kid" (Key ID) Header Parameter
The "kid" (key ID) Header Parameter is a hint indicating which key The "kid" (key ID) Header Parameter is a hint indicating which key
was used to secure the JWS. This parameter allows originators to was used to secure the JWS. This parameter allows originators to
explicitly signal a change of key to recipients. The structure of explicitly signal a change of key to recipients. The structure of
the "kid" value is unspecified. Its value MUST be a string. Use of the "kid" value is unspecified. Its value MUST be a case-sensitive
this Header Parameter is OPTIONAL. string. Use of this Header Parameter is OPTIONAL.
When used with a JWK, the "kid" value is used to match a JWK "kid" When used with a JWK, the "kid" value is used to match a JWK "kid"
parameter value. parameter value.
4.1.5. "x5u" (X.509 URL) Header Parameter 4.1.5. "x5u" (X.509 URL) Header Parameter
The "x5u" (X.509 URL) Header Parameter is a URI [RFC3986] that refers The "x5u" (X.509 URL) Header Parameter is a URI [RFC3986] that refers
to a resource for the X.509 public key certificate or certificate to a resource for the X.509 public key certificate or certificate
chain [RFC5280] corresponding to the key used to digitally sign the chain [RFC5280] corresponding to the key used to digitally sign the
JWS. The identified resource MUST provide a representation of the JWS. The identified resource MUST provide a representation of the
certificate or certificate chain that conforms to RFC 5280 [RFC5280] certificate or certificate chain that conforms to RFC 5280 [RFC5280]
in PEM encoded form [RFC1421]. The certificate containing the public in PEM encoded form, with each certificate delimited as specified in
key corresponding to the key used to digitally sign the JWS MUST be Section 6.1 of RFC 4945 [RFC4945]. The certificate containing the
the first certificate. This MAY be followed by additional public key corresponding to the key used to digitally sign the JWS
MUST be the first certificate. This MAY be followed by additional
certificates, with each subsequent certificate being the one used to certificates, with each subsequent certificate being the one used to
certify the previous one. The protocol used to acquire the resource certify the previous one. The protocol used to acquire the resource
MUST provide integrity protection; an HTTP GET request to retrieve MUST provide integrity protection; an HTTP GET request to retrieve
the certificate MUST use TLS [RFC2818, RFC5246]; the identity of the the certificate MUST use TLS [RFC2818, RFC5246]; the identity of the
server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. server MUST be validated, as per Section 6 of RFC 6125 [RFC6125].
Use of this Header Parameter is OPTIONAL. Also, see Section 8 on TLS requirements. Use of this Header
Parameter is OPTIONAL.
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter
The "x5c" (X.509 Certificate Chain) Header Parameter contains the The "x5c" (X.509 Certificate Chain) Header Parameter contains the
X.509 public key certificate or certificate chain [RFC5280] X.509 public key certificate or certificate chain [RFC5280]
corresponding to the key used to digitally sign the JWS. The corresponding to the key used to digitally sign the JWS. The
certificate or certificate chain is represented as a JSON array of certificate or certificate chain is represented as a JSON array of
certificate value strings. Each string in the array is a base64 certificate value strings. Each string in the array is a base64
encoded ([RFC4648] Section 4 -- not base64url encoded) DER encoded ([RFC4648] Section 4 -- not base64url encoded) DER
[ITU.X690.1994] PKIX certificate value. The certificate containing [ITU.X690.1994] PKIX certificate value. The certificate containing
skipping to change at page 12, line 33 skipping to change at page 12, line 34
present. It will typically not be used by applications when the kind present. It will typically not be used by applications when the kind
of object is already known. This parameter is ignored by JWS of object is already known. This parameter is ignored by JWS
implementations; any processing of this parameter is performed by the implementations; any processing of this parameter is performed by the
JWS application. Use of this Header Parameter is OPTIONAL. JWS application. Use of this Header Parameter is OPTIONAL.
Per RFC 2045 [RFC2045], all media type values, subtype values, and Per RFC 2045 [RFC2045], all media type values, subtype values, and
parameter names are case-insensitive. However, parameter values are parameter names are case-insensitive. However, parameter values are
case-sensitive unless otherwise specified for the specific parameter. case-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 producers 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
'/'. For instance, a "typ" value of "example" SHOULD be used to '/'. For instance, a "typ" 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"".
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
skipping to change at page 13, line 18 skipping to change at page 13, line 23
not be used by applications when the kind of object is already known. not be used by applications when the kind of object is already known.
This parameter is ignored by JWS implementations; any processing of This parameter is ignored by JWS implementations; any processing of
this parameter is performed by the JWS application. Use of this this parameter is performed by the JWS application. Use of this
Header Parameter is OPTIONAL. Header Parameter is OPTIONAL.
Per RFC 2045 [RFC2045], all media type values, subtype values, and Per RFC 2045 [RFC2045], all media type values, subtype values, and
parameter names are case-insensitive. However, parameter values are parameter names are case-insensitive. However, parameter values are
case-sensitive unless otherwise specified for the specific parameter. case-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 producers 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.11. "crit" (Critical) Header Parameter 4.1.11. "crit" (Critical) Header Parameter
The "crit" (critical) Header Parameter indicates that extensions to The "crit" (critical) Header Parameter indicates that extensions to
the initial RFC versions of [[ this specification ]] and [JWA] are the initial RFC versions of [[ this specification ]] and [JWA] are
being used that MUST be understood and processed. Its value is an being used that MUST be understood and processed. Its value is an
array listing the Header Parameter names present in the JOSE Header array listing the Header Parameter names present in the JOSE Header
that use those extensions. If any of the listed extension Header that use those extensions. If any of the listed extension Header
Parameters are not understood and supported by the receiver, it MUST Parameters are not understood and supported by the recipient, it MUST
reject the JWS. Senders MUST NOT include Header Parameter names reject the JWS. Producers 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
as Header Parameter names within the JOSE Header in the "crit" list. as Header Parameter names within the JOSE Header in the "crit" list.
Senders MUST NOT use the empty list "[]" as the "crit" value. Producers MUST NOT use the empty list "[]" as the "crit" value.
Recipients MAY reject the JWS if the critical list contains any Recipients MAY reject the JWS if the critical list contains any
Header Parameter names defined by the initial RFC versions of [[ this Header Parameter names defined by the initial RFC versions of [[ this
specification ]] or [JWA] for use with JWS, or any other constraints specification ]] or [JWA] for use with JWS, or any other constraints
on its use are violated. This Header Parameter MUST be integrity on its use are violated. This Header Parameter MUST be integrity
protected, and therefore MUST occur only within the JWS Protected protected, and therefore MUST occur only within the JWS Protected
Header, when used. Use of this Header Parameter is OPTIONAL. This Header, when used. Use of this Header Parameter is OPTIONAL. This
Header Parameter MUST be understood and processed by implementations. Header Parameter MUST be understood and processed by implementations.
An example use, along with a hypothetical "exp" (expiration-time) An example use, along with a hypothetical "exp" (expiration-time)
field is: field is:
skipping to change at page 14, line 46 skipping to change at page 14, line 46
5. Producing and Consuming JWSs 5. Producing and Consuming JWSs
5.1. Message Signature or MAC Computation 5.1. Message Signature or MAC Computation
To create a JWS, one MUST perform these steps. The order of the To create a JWS, one MUST perform these steps. The order of the
steps is not significant in cases where there are no dependencies steps is not significant in cases where there are no dependencies
between the inputs and outputs of the steps. between the inputs and outputs of the steps.
1. Create the content to be used as the JWS Payload. 1. Create the content to be used as the JWS Payload.
2. Compute the encoded payload value BASE64URL(JWS Payload). 2. Compute the encoded payload value BASE64URL(JWS Payload).
3. Create the JSON object(s) containing the desired set of Header 3. Create the JSON object(s) containing the desired set of Header
Parameters, which together comprise the JOSE Header: the JWS Parameters, which together comprise the JOSE Header: if the JWS
Protected Header, and if the JWS JSON Serialization is being Compact Serialization is being used, the JWS Protected Header, or
used, the JWS Unprotected Header. if the JWS JSON Serialization is being used, the JWS Protected
Header and/or the JWS Unprotected Header.
4. Compute the encoded header value BASE64URL(UTF8(JWS Protected 4. Compute the encoded header value BASE64URL(UTF8(JWS Protected
Header)). If the JWS Protected Header is not present (which can Header)). If the JWS Protected Header is not present (which can
only happen when using the JWS JSON Serialization and no only happen when using the JWS JSON Serialization and no
"protected" member is present), let this value be the empty "protected" member is present), let this value be the empty
string. string.
5. Compute the JWS Signature in the manner defined for the 5. Compute the JWS Signature in the manner defined for the
particular algorithm being used over the JWS Signing Input particular algorithm being used over the JWS Signing Input
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload)). The "alg" (algorithm) Header Parameter BASE64URL(JWS Payload)). The "alg" (algorithm) Header Parameter
MUST be present in the JOSE Header, with the algorithm value MUST be present in the JOSE Header, with the algorithm value
accurately representing the algorithm used to construct the JWS accurately representing the algorithm used to construct the JWS
Signature. Signature.
6. Compute the encoded signature value BASE64URL(JWS Signature). 6. Compute the encoded signature value BASE64URL(JWS Signature).
7. These three encoded values are used in both the JWS Compact 7. If the JWS JSON Serialization is being used, repeat this process
Serialization and the JWS JSON Serialization representations. (steps 3-6) for each digital signature or MAC operation being
8. If the JWS JSON Serialization is being used, repeat this process
(steps 3-7) for each digital signature or MAC operation being
performed. performed.
9. Create the desired serialized output. The JWS Compact 8. Create the desired serialized output. The JWS Compact
Serialization of this result is BASE64URL(UTF8(JWS Protected Serialization of this result is BASE64URL(UTF8(JWS Protected
Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS
Signature). The JWS JSON Serialization is described in Signature). The JWS JSON Serialization is described in
Section 7.2. Section 7.2.
5.2. Message Signature or MAC Validation 5.2. Message Signature or MAC Validation
When validating a JWS, the following steps MUST be taken. The order When validating a JWS, the following steps MUST be taken. The order
of the steps is not significant in cases where there are no of the steps is not significant in cases where there are no
dependencies between the inputs and outputs of the steps. If any of dependencies between the inputs and outputs of the steps. If any of
skipping to change at page 16, line 4 skipping to change at page 16, line 5
for the components of the JWS. When using the JWS Compact for the components of the JWS. When using the JWS Compact
Serialization, these components are the base64url encoded Serialization, these components are the base64url encoded
representations of the JWS Protected Header, the JWS Payload, representations of the JWS Protected Header, the JWS Payload,
and the JWS Signature, and when using the JWS JSON and the JWS Signature, and when using the JWS JSON
Serialization, these components also include the unencoded JWS Serialization, these components also include the unencoded JWS
Unprotected Header value. When using the JWS Compact Unprotected Header value. When using the JWS Compact
Serialization, the JWS Protected Header, the JWS Payload, and Serialization, the JWS Protected Header, the JWS Payload, and
the JWS Signature are represented as base64url encoded values in the JWS Signature are represented as base64url encoded values in
that order, separated by two period ('.') characters. The JWS that order, separated by two period ('.') characters. The JWS
JSON Serialization is described in Section 7.2. JSON Serialization is described in Section 7.2.
2. Base64url decode the encoded representation of the JWS Protected
2. The encoded representation of the JWS Protected Header MUST be Header, following the restriction that no line breaks, white
successfully base64url decoded following the restriction that no space, or other additional characters have been used.
padding characters have been used. 3. Verify that the resulting octet sequence is a UTF-8 encoded
3. The resulting octet sequence MUST be a UTF-8 encoded
representation of a completely valid JSON object conforming to representation of a completely valid JSON object conforming to
RFC 7159 [RFC7159], which is the JWS Protected Header. RFC 7159 [RFC7159]; let the JWS Protected Header be this JSON
object.
4. If using the JWS Compact Serialization, let the JOSE Header be 4. If using the JWS Compact Serialization, let the JOSE Header be
the JWS Protected Header. Otherwise, when using the JWS JSON the JWS Protected Header. Otherwise, when using the JWS JSON
Serialization, let the JOSE Header be the union of the members Serialization, let the JOSE Header be the union of the members
of the corresponding JWS Protected Header and JWS Unprotected of the corresponding JWS Protected Header and JWS Unprotected
Header, all of which must be completely valid JSON objects. Header, all of which must be completely valid JSON objects.
5. The resulting JOSE Header MUST NOT contain duplicate Header During this step, verify that the resulting JOSE Header does not
Parameter names. When using the JWS JSON Serialization, this contain duplicate Header Parameter names. When using the JWS
restriction includes that the same Header Parameter name also JSON Serialization, this restriction includes that the same
MUST NOT occur in distinct JSON object values that together Header Parameter name also MUST NOT occur in distinct JSON
comprise the JOSE Header. object values that together comprise the JOSE Header.
6. Verify that the implementation understands and can process all 5. Verify that the implementation understands and can process all
fields that it is required to support, whether required by this fields that it is required to support, whether required by this
specification, by the algorithm being used, or by the "crit" specification, by the algorithm being used, or by the "crit"
Header Parameter value, and that the values of those parameters Header Parameter value, and that the values of those parameters
are also understood and supported. are also understood and supported.
7. The encoded representation of the JWS Payload MUST be 6. Base64url decode the encoded representation of the JWS Payload,
successfully base64url decoded following the restriction that no following the restriction that no line breaks, white space, or
padding characters have been used. other additional characters have been used.
8. The encoded representation of the JWS Signature MUST be 7. Base64url decode the encoded representation of the JWS
successfully base64url decoded following the restriction that no Signature, following the restriction that no line breaks, white
padding characters have been used. space, or other additional characters have been used.
9. Validate the JWS Signature against the JWS Signing Input 8. Validate the JWS Signature against the JWS Signing Input
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload)) in the manner defined for the algorithm BASE64URL(JWS Payload)) in the manner defined for the algorithm
being used, which MUST be accurately represented by the value of being used, which MUST be accurately represented by the value of
the "alg" (algorithm) Header Parameter, which MUST be present. the "alg" (algorithm) Header Parameter, which MUST be present.
See Section 10.6 for security considerations on algorithm See Section 10.6 for security considerations on algorithm
validation. Record whether the validation succeeded or not. validation. Record whether the validation succeeded or not.
10. If the JWS JSON Serialization is being used, repeat this process 9. If the JWS JSON Serialization is being used, repeat this process
(steps 4-9) for each digital signature or MAC value contained in (steps 4-8) for each digital signature or MAC value contained in
the representation. the representation.
11. If none of the validations in step 9 succeeded, then the JWS 10. If none of the validations in step 9 succeeded, then the JWS
MUST be rejected. Otherwise, in the JWS JSON Serialization MUST be rejected. Otherwise, in the JWS JSON Serialization
case, return a result to the application indicating which of the case, return a result to the application indicating which of the
validations succeeded and failed. In the JWS Compact validations succeeded and failed. In the JWS Compact
Serialization case, the result can simply indicate whether the Serialization case, the result can simply indicate whether the
JWS was accepted or rejected. JWS was accepted or rejected.
Finally, note that it is an application decision which algorithms are Finally, note that it is an application decision which algorithms may
acceptable in a given context. Even if a JWS can be successfully be used in a given context. Even if a JWS can be successfully
validated, unless the algorithm(s) used in the JWS are acceptable to validated, unless the algorithm(s) used in the JWS are acceptable to
the application, it SHOULD reject the JWS. the application, it SHOULD reject the JWS.
5.3. String Comparison Rules 5.3. String Comparison Rules
Processing a JWS inevitably requires comparing known strings to Processing a JWS inevitably requires comparing known strings to
members and values in a JSON object. For example, in checking what members and values in JSON objects. For example, in checking what
the algorithm is, the Unicode string "alg" will be checked against the algorithm is, the Unicode string "alg" will be checked against
the member names in the JOSE Header to see if there is a matching the member names in the JOSE Header to see if there is a matching
Header Parameter name. The same process is then used to determine if Header Parameter name. The same process is then used to determine if
the value of the "alg" Header Parameter represents a supported the value of the "alg" Header Parameter represents a supported
algorithm. algorithm.
Since the only string comparison operations that are performed are The JSON rules for doing member name comparison are described in
equality and inequality, the same rules can be used for comparing Section 8.3 of RFC 7159 [RFC7159]. Since the only string comparison
both member names and member values against known strings. The JSON operations that are performed are equality and inequality, the same
rules for doing member name comparison are described in Section 8.3 rules can be used for comparing both member names and member values
of RFC 7159 [RFC7159]. against known strings.
These comparison rules MUST be used for all JSON string comparisons
except in cases where the definition of the member explicitly calls
out that a different comparison rule is to be used for that member
value. Only the "typ" and "cty" member values defined in this
specification do not use these comparison rules.
Some applications may include case-insensitive information in a case-
sensitive value, such as including a DNS name as part of a "kid" (key
ID) value. In those cases, the application may need to define a
convention for the canonical case to use for representing the case-
insensitive portions, such as lowercasing them, if more than one
party might need to produce the same value so that they can be
compared. (However if all other parties consume whatever value the
producing party emitted verbatim without attempting to compare it to
an independently produced value, then the case used by the producer
will not matter.)
Also, see the JSON security considerations in Section 10.12 and the Also, see the JSON security considerations in Section 10.12 and the
Unicode security considerations in Section 10.13. Unicode security considerations in Section 10.13.
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
be integrity protected if the information that they convey is to be be integrity protected if the information that they convey is to be
utilized in a trust decision. utilized in a trust decision.
The sender SHOULD include sufficient information in the Header The producer 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.
Also, see Appendix D for notes on possible key selection algorithms. Also, see Appendix D for notes on possible key selection algorithms.
skipping to change at page 20, line 42 skipping to change at page 21, line 7
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.
See current publications by the IETF TLS working group, including RFC See current publications by the IETF TLS working group, including RFC
6176 [RFC6176], for guidance on the ciphersuites currently considered 6176 [RFC6176], for guidance on the ciphersuites currently considered
to be appropriate for use. Also, see Recommendations for Secure Use to be appropriate for use. Also, see Recommendations for Secure Use
of TLS and DTLS [I-D.ietf-uta-tls-bcp] for recommendations on of TLS and DTLS [I-D.ietf-uta-tls-bcp] for recommendations on
improving the security of software and services using TLS. improving the security of software and services using TLS.
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]. TLS is used by the
"jku" and "x5u" Header Parameters defined by this specification.
9. IANA Considerations 9. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC5226] basis
after a three-week review period on the [TBD]@ietf.org mailing list, after a three-week review period on the [TBD]@ietf.org mailing list,
on the advice of one or more Designated Experts. However, to allow on the advice of one or more Designated Experts. However, to allow
for the allocation of values prior to publication, the Designated for the allocation of values prior to publication, the Designated
skipping to change at page 21, line 21 skipping to change at page 21, line 34
for access token type: example"). [[ Note to the RFC Editor: The name for access token type: example"). [[ Note to the RFC Editor: The name
of the mailing list should be determined in consultation with the of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: jose-reg-review. ]] IESG and IANA. Suggested name: jose-reg-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the longer than 21 days can be brought to the IESG's attention (using the
iesg@iesg.org mailing list) for resolution. iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Expert(s) includes Criteria that should be applied by the Designated Expert(s) includes
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
functionality, determining whether it is likely to be of general functionality, determining whether it is likely to be of general
applicability or whether it is useful only for a single application, applicability or whether it is useful only for a single application,
and whether the registration makes sense. and whether the registration description is clear.
IANA must only accept registry updates from the Designated Expert(s) IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
It is suggested that multiple Designated Experts be appointed who are It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
this specification, in order to enable broadly-informed review of this specification, in order to enable broadly-informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other Expert, that Expert should defer to the judgment of the other
Expert(s). Expert(s).
[[ Note to the RFC Editor and IANA: Pearl Liang of ICANN had
requested that the draft supply the following proposed registry
description information. It is to be used for all registries
established by this specification.
o Protocol Category: JSON Object Signing and Encryption (JOSE)
o Registry Location: http://www.iana.org/assignments/jose
o Webpage Title: (same as the protocol category)
o Registry Name: (same as the section title, but excluding the word
"Registry", for example "JSON Web Signature and Encryption Header
Parameters")
]]
9.1. JSON Web Signature and Encryption Header Parameters Registry 9.1. JSON Web Signature and Encryption Header Parameters Registry
This specification establishes the IANA JSON Web Signature and This specification establishes the IANA JSON Web Signature and
Encryption Header Parameters registry for Header Parameter names. Encryption Header Parameters registry for Header Parameter names.
The registry records the Header Parameter name and a reference to the The registry records the Header Parameter name and a reference to the
specification that defines it. The same Header Parameter name can be specification that defines it. The same Header Parameter name can be
registered multiple times, provided that the parameter usage is registered multiple times, provided that the parameter usage is
compatible between the specifications. Different registrations of compatible between the specifications. Different registrations of
the same Header Parameter name will typically use different Header the same Header Parameter name will typically use different Header
Parameter Usage Location(s) values. Parameter Usage Location(s) values.
skipping to change at page 24, line 19 skipping to change at page 24, line 49
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.11 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] in the
can be used to indicate that the content is a JWS or JWE object using manner described in RFC 6838 [RFC6838], which can be used to indicate
the JWS Compact Serialization or the JWE Compact Serialization and that the content is a JWS or JWE object using the JWS Compact
the "application/jose+json" Media Type in the MIME Media Types Serialization or the JWE Compact Serialization and the
registry, which can be used to indicate that the content is a JWS or "application/jose+json" Media Type in the MIME Media Types registry,
JWE object using the JWS JSON Serialization or the JWE JSON which can be used to indicate that the content is a JWS or JWE object
Serialization. using the JWS JSON Serialization or the JWE JSON Serialization.
o Type name: application o Type name: application
o Subtype name: jose o Subtype name: jose
o Required parameters: n/a o Required parameters: n/a
o Optional parameters: n/a o Optional parameters: n/a
o Encoding considerations: 8bit; application/jose values are encoded o Encoding considerations: 8bit; application/jose values are encoded
as a series of base64url encoded values (some of which may be the as a series of base64url encoded values (some of which may be the
empty string) separated by period ('.') characters. empty string) separated by period ('.') characters.
o Security considerations: See the Security Considerations section o Security considerations: See the Security Considerations section
of [[ this document ]] of [[ this document ]]
o Interoperability considerations: n/a o Interoperability considerations: n/a
o Published specification: [[ this document ]] o Published specification: [[ this document ]]
o Applications that use this media type: OpenID Connect, Mozilla o Applications that use this media type: OpenID Connect, Mozilla
Persona, Salesforce, Google, Android, Windows Azure, Xbox One, and Persona, Salesforce, Google, Android, Windows Azure, Xbox One, and
numerous others that use JWTs numerous others that use JWTs
o Fragment identifier considerations: n/a
o Additional information: Magic number(s): n/a, File extension(s): o Additional information: Magic number(s): n/a, File extension(s):
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
o Provisional registration? No
o Type name: application o Type name: application
o Subtype name: jose+json o Subtype name: jose+json
o Required parameters: n/a o Required parameters: n/a
o Optional parameters: n/a o Optional parameters: n/a
o Encoding considerations: 8bit; application/jose+json values are o Encoding considerations: 8bit; application/jose+json values are
represented as a JSON Object; UTF-8 encoding SHOULD be employed represented as a JSON Object; UTF-8 encoding SHOULD be employed
for the JSON object. for the JSON object.
o Security considerations: See the Security Considerations section o Security considerations: See the Security Considerations section
of [[ this document ]] of [[ this document ]]
o Interoperability considerations: n/a o Interoperability considerations: n/a
o Published specification: [[ this document ]] o Published specification: [[ this document ]]
o Applications that use this media type: TBD o Applications that use this media type: TBD
o Fragment identifier considerations: n/a
o Additional information: Magic number(s): n/a, File extension(s): o Additional information: Magic number(s): n/a, File extension(s):
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
o Provisional registration? No
10. Security Considerations 10. Security Considerations
All of the security issues that are pertinent to any cryptographic All of the security issues that are pertinent to any cryptographic
application must be addressed by JWS/JWE/JWK agents. Among these application must be addressed by JWS/JWE/JWK agents. Among these
issues are protecting the user's asymmetric private and symmetric issues are protecting the user's asymmetric private and symmetric
secret keys and employing countermeasures to various attacks. secret keys and employing countermeasures to various attacks.
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,
skipping to change at page 26, line 49 skipping to change at page 27, line 36
to be used in protocols. to be used in protocols.
Both signatures and MACs provide for integrity checking -- verifying Both signatures and MACs provide for integrity checking -- verifying
that the message has not been modified since the integrity value was that the message has not been modified since the integrity value was
computed. However, MACs provide for origination identification only computed. However, MACs provide for origination identification only
under specific circumstances. It can normally be assumed that a under specific circumstances. It can normally be assumed that a
private key used for a signature is only in the hands of a single private key used for a signature is only in the hands of a single
entity (although perhaps a distributed entity, in the case of entity (although perhaps a distributed entity, in the case of
replicated servers); however, a MAC key needs to be in the hands 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. all the entities that use it for integrity computation and checking.
Validation of a MAC only provides corroboration that the message was
generated by one of the parties that knows the symmetric MAC key.
This means that origination can only be determined if a MAC key is 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 known only to two entities and the recipient knows that it did not
create the message. MAC validation cannot be used to prove create the message. MAC validation cannot be used to prove
origination to a third party. origination to a third party.
10.6. Algorithm Validation 10.6. Algorithm Validation
The digital signature representations for some algorithms include The digital signature representations for some algorithms include
information about the algorithm used inside the signature value. For information about the algorithm used inside the signature value. For
instance, signatures produced with RSASSA-PKCS-v1_5 [RFC3447] encode instance, signatures produced with RSASSA-PKCS-v1_5 [RFC3447] encode
the hash function used and many libraries actually use the hash the hash function used and many libraries actually use the hash
algorithm specified inside the signature when validating the algorithm specified inside the signature when validating the
skipping to change at page 28, line 52 skipping to change at page 29, line 41
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.12. JSON Security Considerations 10.12. 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 producer 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]
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; JWS parsers 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 producers and that it be either treated as a "MUST" or in
manner specified in ECMAScript 5.1 by receivers. Ambiguous and the manner specified in ECMAScript 5.1 by consumers. Ambiguous and
potentially exploitable situations could arise if the JSON parser potentially exploitable situations could arise if the JSON parser
used does not enforce the uniqueness of member names or returns an used does not enforce the uniqueness of member names or returns an
unpredictable value for duplicate member names. unpredictable value for duplicate member names.
Some JSON parsers might not reject input that contains extra Some JSON parsers might not reject input that contains extra
significant characters after a valid input. For instance, the input significant characters after a valid input. For instance, the input
"{"tag":"value"}ABCD" contains a valid JSON-text object followed by "{"tag":"value"}ABCD" contains a valid JSON-text object followed by
the extra characters "ABCD". Such input MUST be rejected in its the extra characters "ABCD". Such input MUST be rejected in its
entirety. entirety.
skipping to change at page 30, line 23 skipping to change at page 31, line 12
[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),
September 2014. October 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),
September 2014. October 2014.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
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
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 31, line 8 skipping to change at page 31, line 41
[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.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[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
skipping to change at page 31, line 48 skipping to change at page 32, line 37
Sheffer, Y., Holz, R., and P. Saint-Andre, Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", "Recommendations for Secure Use of TLS and DTLS",
draft-ietf-uta-tls-bcp-03 (work in progress), draft-ietf-uta-tls-bcp-03 (work in progress),
September 2014. September 2014.
[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),
September 2014. October 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), September 2014. progress), October 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.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
skipping to change at page 32, line 31 skipping to change at page 33, line 20
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
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm [RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm
Identifier Protection Attribute", RFC 6211, April 2011. Identifier Protection Attribute", RFC 6211, April 2011.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, March 2012. Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[W3C.NOTE-xmldsig-bestpractices-20130411] [W3C.NOTE-xmldsig-bestpractices-20130411]
Hirsch, F. and P. Datta, "XML Signature Best Practices", Hirsch, F. and P. Datta, "XML Signature Best Practices",
World Wide Web Consortium Note NOTE-xmldsig-bestpractices- World Wide Web Consortium Note NOTE-xmldsig-bestpractices-
20130411, April 2013, <http://www.w3.org/TR/2013/ 20130411, April 2013, <http://www.w3.org/TR/2013/
NOTE-xmldsig-bestpractices-20130411/>. NOTE-xmldsig-bestpractices-20130411/>.
[W3C.NOTE-xmldsig-core2-20130411] [W3C.NOTE-xmldsig-core2-20130411]
skipping to change at page 52, line 13 skipping to change at page 53, line 13
Applications [CanvasApp], all of which influenced this draft. Applications [CanvasApp], all of which influenced this draft.
Thanks to Axel Nennker for his early implementation and feedback on Thanks to Axel Nennker for his early implementation and feedback on
the JWS and JWE specifications. the JWS and JWE specifications.
This specification is the work of the JOSE Working Group, which This specification is the work of the JOSE Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that influenced this specification: that influenced this specification:
Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de
Hardt, Joe Hildebrand, Jeff Hodges, Russ Housley, Edmund Jay, Tero Medeiros, Stephen Farrell, Dick Hardt, Joe Hildebrand, Jeff Hodges,
Kivinen, Yaron Y. Goland, Ben Laurie, James Manger, Matt Miller, Russ Housley, Edmund Jay, Tero Kivinen, Yaron Y. Goland, Ben Laurie,
Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel Nennker, John Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony
Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad, Paul Tarjan, Nadalin, Hideki Nara, Axel Nennker, John Panzer, Emmanuel Raviart,
Hannes Tschofenig, and Sean Turner. Eric Rescorla, Pete Resnick, Jim Schaad, 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 ]]
-34
o Addressed IESG review comments by Alissa Cooper, Pete Resnick,
Richard Barnes, Ted Lemon, and Stephen Farrell.
o Addressed Gen-ART review comments by Russ Housley.
o Referenced RFC 4945 for PEM certificate delimiter syntax.
-33 -33
o Noted that certificate thumbprints are also sometimes known as o Noted that certificate thumbprints are also sometimes known as
certificate fingerprints. certificate fingerprints.
o Added an informative reference to draft-ietf-uta-tls-bcp for o Added an informative reference to draft-ietf-uta-tls-bcp for
recommendations on improving the security of software and services recommendations on improving the security of software and services
using TLS. using TLS.
o Changed the registration review period to three weeks. o Changed the registration review period to three weeks.
 End of changes. 68 change blocks. 
138 lines changed or deleted 203 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/