draft-ietf-jose-json-web-signature-36.txt   draft-ietf-jose-json-web-signature-37.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: April 27, 2015 Ping Identity Expires: May 23, 2015 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
October 24, 2014 November 19, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-36 draft-ietf-jose-json-web-signature-37
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 April 27, 2015. This Internet-Draft will expire on May 23, 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 3, line 33 skipping to change at page 3, line 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 36 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 36
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . 36 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . 36
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . 38 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . 38
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 39 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 39
A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 41 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 41
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 41 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 42
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 41 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 42
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 43 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 44
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 44 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 44
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 44 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 44
A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 46 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 46
A.5. Example Unsecured JWS . . . . . . . . . . . . . . . . . . 46 A.5. Example Unsecured JWS . . . . . . . . . . . . . . . . . . 46
A.6. Example JWS using General JWS JSON Serialization . . . . 47 A.6. Example JWS using General JWS JSON Serialization . . . . 47
A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 47 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 48
A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 48 A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 48
A.6.3. Complete JOSE Header Values . . . . . . . . . . . . . 48 A.6.3. Complete JOSE Header Values . . . . . . . . . . . . . 48
A.6.4. Complete JWS JSON Serialization Representation . . . . 48 A.6.4. Complete JWS JSON Serialization Representation . . . . 49
A.7. Example JWS using Flattened JWS JSON Serialization . . . 49 A.7. Example JWS using Flattened JWS JSON Serialization . . . 49
Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 50 Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 50
Appendix C. Notes on implementing base64url encoding without Appendix C. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . . 51 padding . . . . . . . . . . . . . . . . . . . . . . . 52
Appendix D. Notes on Key Selection . . . . . . . . . . . . . . . 52 Appendix D. Notes on Key Selection . . . . . . . . . . . . . . . 53
Appendix E. Negative Test Case for "crit" Header Parameter . . . 54 Appendix E. Negative Test Case for "crit" Header Parameter . . . 54
Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 55 Appendix F. Detached Content . . . . . . . . . . . . . . . . . . 55
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 55 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 55
Appendix H. Document History . . . . . . . . . . . . . . . . . . 56 Appendix H. Document History . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
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
skipping to change at page 11, line 26 skipping to change at page 11, line 26
4.1.1. "alg" (Algorithm) Header Parameter 4.1.1. "alg" (Algorithm) Header Parameter
The "alg" (algorithm) Header Parameter identifies the cryptographic The "alg" (algorithm) Header Parameter identifies the cryptographic
algorithm used to secure the JWS. The JWS Signature value is not algorithm used to secure the JWS. The JWS Signature value is not
valid if the "alg" value does not represent a supported algorithm, or valid if the "alg" value does not represent a supported algorithm, or
if there is not a key for use with that algorithm associated with the if there is not a key for use with that algorithm associated with the
party that digitally signed or MACed the content. "alg" values should party that digitally signed or MACed the content. "alg" values should
either be registered in the IANA JSON Web Signature and Encryption either be registered in the IANA JSON Web Signature and Encryption
Algorithms registry defined in [JWA] or be a value that contains a Algorithms registry defined in [JWA] or be a value that contains a
Collision-Resistant Name. The "alg" value is a case-sensitive string Collision-Resistant Name. The "alg" value is a case-sensitive ASCII
containing a StringOrURI value. This Header Parameter MUST be string containing a StringOrURI value. This Header Parameter MUST be
present and MUST be understood and processed by implementations. present and MUST be understood and processed by implementations.
A list of defined "alg" values for this use can be found in the IANA A list of defined "alg" values for this use can be found in the IANA
JSON Web Signature and Encryption Algorithms registry defined in JSON Web Signature and Encryption Algorithms registry defined in
[JWA]; the initial contents of this registry are the values defined [JWA]; the initial contents of this registry are the values defined
in Section 3.1 of the JSON Web Algorithms (JWA) [JWA] specification. in Section 3.1 of the JSON Web Algorithms (JWA) [JWA] specification.
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
skipping to change at page 16, line 50 skipping to change at page 16, line 50
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
the listed steps fails, then the signature or MAC cannot be the listed steps fails, then the signature or MAC cannot be
validated. validated.
When there are multiple JWS Signature values, it is an application When there are multiple JWS Signature values, it is an application
decision which of the JWS Signature values must successfully validate decision which of the JWS Signature values must successfully validate
for the JWS to be accepted. In some cases, all must successfully for the JWS to be accepted. In some cases, all must successfully
validate or the JWS will be rejected. In other cases, only a validate or the JWS will be considered invalid. In other cases, only
specific JWS signature value needs to be successfully validated. a specific JWS Signature value needs to be successfully validated.
However, in all cases, at least one JWS signature value MUST However, in all cases, at least one JWS Signature value MUST
successfully validate or the JWS MUST be rejected. successfully validate or the JWS MUST be considered invalid.
1. Parse the JWS representation to extract the serialized values 1. Parse the JWS representation to extract the serialized values
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
skipping to change at page 18, line 19 skipping to change at page 18, line 19
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.
9. 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-8) 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.
10. 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 considered invalid. Otherwise, in the JWS JSON
case, return a result to the application indicating which of the Serialization case, return a result to the application
validations succeeded and failed. In the JWS Compact indicating which of the validations succeeded and failed. In
Serialization case, the result can simply indicate whether the the JWS Compact Serialization case, the result can simply
JWS was accepted or rejected. indicate whether or not the JWS was successfully validated.
Finally, note that it is an application decision which algorithms may Finally, note that it is an application decision which algorithms may
be used 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 consider the JWS to be invalid.
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 JSON objects. 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.
skipping to change at page 19, line 29 skipping to change at page 19, line 29
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; however, if the only information used
in the trust decision is a key, these parameters need not be
integrity protected, since changing them in a way that causes a
different key to be used will cause the validation to fail.
The producer 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.
skipping to change at page 23, line 7 skipping to change at page 23, line 7
"protected":"<integrity-protected header contents>", "protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>, "header":<non-integrity-protected header contents>,
"signature":"<signature contents>" "signature":"<signature contents>"
} }
See Appendix A.7 for an example JWS using the flattened JWS JSON See Appendix A.7 for an example JWS using the flattened JWS JSON
Serialization syntax. Serialization syntax.
8. TLS Requirements 8. TLS Requirements
Implementations MUST support TLS. Which version(s) ought to be Implementations supporting the "jku" and/or "x5u" Header Parameters
implemented will vary over time, and depend on the widespread MUST support TLS. Which TLS version(s) ought to be implemented will
deployment and known security vulnerabilities at the time of vary over time, and depend on the widespread deployment and known
implementation. At the time of this writing, TLS version 1.2 security vulnerabilities at the time of implementation. At the time
[RFC5246] is the most recent version. of this writing, TLS version 1.2 [RFC5246] is the most recent
version.
To protect against information disclosure and tampering, To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a confidentiality protection MUST be applied using TLS with a
ciphersuite that provides confidentiality and integrity protection. ciphersuite that provides confidentiality and integrity protection.
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]. TLS is used by the described in Section 6 of RFC 6125 [RFC6125].
"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 jose-reg-review@ietf.org after a three-week review period on the jose-reg-review@ietf.org
mailing list, on the advice of one or more Designated Experts. mailing list, on the advice of one or more Designated Experts.
However, to allow for the allocation of values prior to publication, However, to allow for the allocation of values prior to publication,
the Designated Expert(s) may approve registration once they are the Designated Expert(s) may approve registration once they are
satisfied that such a specification will be published. satisfied that such a specification will be published.
Registration requests must be sent to the jose-reg-review@ietf.org Registration requests must be sent to the jose-reg-review@ietf.org
mailing list for review and comment, with an appropriate subject mailing list for review and comment, with an appropriate subject
(e.g., "Request for access token type: example"). (e.g., "Request to register header parameter: example").
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@ietf.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
skipping to change at page 27, line 38 skipping to change at page 27, line 38
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) each separated from the next by a single period empty string) each separated from the next by a single period
('.') character. ('.') character.
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,
numerous others that use JWTs Amazon Web Services, and numerous others that use JWTs
o Fragment identifier considerations: n/a 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 Provisional registration? No
skipping to change at page 33, line 26 skipping to change at page 33, line 26
[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),
October 2014. November 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),
October 2014. November 2014.
[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
October 1969. October 1969.
[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,
skipping to change at page 34, line 43 skipping to change at page 34, line 43
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
11.2. Informative References 11.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
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-06 (work in progress), draft-ietf-uta-tls-bcp-07 (work in progress),
October 2014. November 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),
October 2014. November 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), October 2014. progress), November 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 40, line 23 skipping to change at page 40, line 23
D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8 MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ", NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
"e":"AQAB", "e":"AQAB",
"d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I "d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0 jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT 439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ" BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ",
"p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi
YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG
BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc",
"q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa
ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA
-njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc",
"dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q
CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb
34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0",
"dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa
7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky
NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU",
"qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o
y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU
W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U"
} }
The RSA private key is then passed to the RSA signing function, which The RSA private key is then passed to the RSA signing function, which
also takes the hash type, SHA-256, and the JWS Signing Input as also takes the hash type, SHA-256, and the JWS Signing Input as
inputs. The result of the digital signature is an octet sequence, inputs. The result of the digital signature is an octet sequence,
which represents a big endian integer. In this example, it is: which represents a big endian integer. In this example, it is:
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69, [112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69,
243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125, 243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125,
131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81, 131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81,
skipping to change at page 56, line 14 skipping to change at page 56, line 21
Tschofenig, and Sean Turner. Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors during the creation of this specification.
Appendix H. Document History Appendix H. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-37
o Updated the TLS requirements language to only require
implementations to support TLS when they support features using
TLS.
o Updated the language about integrity protecting Header Parameters
when used in a trust decision.
o Restricted algorithm names to using only ASCII characters.
o When describing actions taken as a result of validation failures,
changed statements about rejecting the JWS to statements about
considering the JWS to be invalid.
o Added the CRT parameter values to example RSA private key
representations.
o Updated the example IANA registration request subject line.
-36 -36
o Defined a flattened JWS JSON Serialization syntax, which is o Defined a flattened JWS JSON Serialization syntax, which is
optimized for the single digital signature or MAC case. optimized for the single digital signature or MAC case.
o Clarified where white space and line breaks may occur in JSON o Clarified where white space and line breaks may occur in JSON
objects by referencing Section 2 of RFC 7159. objects by referencing Section 2 of RFC 7159.
o Specified that registration reviews occur on the o Specified that registration reviews occur on the
jose-reg-review@ietf.org mailing list. jose-reg-review@ietf.org mailing list.
 End of changes. 24 change blocks. 
41 lines changed or deleted 79 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/