draft-ietf-jose-json-web-signature-30.txt   draft-ietf-jose-json-web-signature-31.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: January 2, 2015 Ping Identity Expires: January 5, 2015 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
July 1, 2014 July 4, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-30 draft-ietf-jose-json-web-signature-31
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 January 2, 2015. This Internet-Draft will expire on January 5, 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 23 skipping to change at page 3, line 23
10.6. JSON Security Considerations . . . . . . . . . . . . . . . 26 10.6. JSON Security Considerations . . . . . . . . . . . . . . . 26
10.7. Unicode Comparison Security Considerations . . . . . . . . 27 10.7. Unicode Comparison Security Considerations . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 30 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 30
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 30 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 30
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30
A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 32 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 32
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 32 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 32
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 32 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33
A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 35 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 35
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 35 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 35
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 37 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 37
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 38 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 38
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 38 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 38
A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 40 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 40
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 40 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 40
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 41 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 41
A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 41 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 41
skipping to change at page 12, line 31 skipping to change at page 12, line 31
4.1.9. "typ" (Type) Header Parameter 4.1.9. "typ" (Type) Header Parameter
The "typ" (type) Header Parameter is used by JWS applications to The "typ" (type) Header Parameter is used by JWS applications to
declare the MIME Media Type [IANA.MediaTypes] of this complete JWS declare the MIME Media Type [IANA.MediaTypes] of this complete JWS
object. This is intended for use by the application when more than object. This is intended for use by the application when more than
one kind of object could be present in an application data structure one kind of object could be present in an application data structure
that can contain a JWS object; the application can use this value to that can contain a JWS object; the application can use this value to
disambiguate among the different kinds of objects that might be disambiguate among the different kinds of objects that might be
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 has no effect upon the of object is already known. This parameter is ignored by JWS
JWS processing. Use of this Header Parameter is OPTIONAL. implementations; any processing of this parameter is performed by the
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 senders omit an "application/" prefix of a media type value in a
"typ" Header Parameter when no other '/' appears in the media type "typ" Header Parameter when no other '/' appears in the media type
value. A recipient using the media type value MUST treat it as if value. A recipient using the media type value MUST treat it as if
"application/" were prepended to any "typ" value not containing a "application/" were prepended to any "typ" value not containing a
skipping to change at page 13, line 16 skipping to change at page 13, line 16
4.1.10. "cty" (Content Type) Header Parameter 4.1.10. "cty" (Content Type) Header Parameter
The "cty" (content type) Header Parameter is used by JWS applications The "cty" (content type) Header Parameter is used by JWS applications
to declare the MIME Media Type [IANA.MediaTypes] of the secured to declare the MIME Media Type [IANA.MediaTypes] of the secured
content (the payload). This is intended for use by the application content (the payload). This is intended for use by the application
when more than one kind of object could be present in the JWS when more than one kind of object could be present in the JWS
payload; the application can use this value to disambiguate among the payload; the application can use this value to disambiguate among the
different kinds of objects that might be present. It will typically different kinds of objects that might be present. It will typically
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 has no effect upon the JWS processing. Use of this This parameter is ignored by JWS implementations; any processing of
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 senders omit an "application/" prefix of a media type value in a
"cty" Header Parameter when no other '/' appears in the media type "cty" Header Parameter when no other '/' appears in the media type
value. A recipient using the media type value MUST treat it as if value. A recipient using the media type value MUST treat it as if
skipping to change at page 20, line 10 skipping to change at page 20, line 10
Implementations MUST support TLS. Which version(s) ought to be Implementations MUST support TLS. Which version(s) ought to be
implemented will vary over time, and depend on the widespread implemented will vary over time, and depend on the widespread
deployment and known security vulnerabilities at the time of deployment and known security vulnerabilities at the time of
implementation. At the time of this writing, TLS version 1.2 implementation. At the time of this writing, TLS version 1.2
[RFC5246] is the most recent version. [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
6176 [RFC6176], for guidance on the ciphersuites currently considered
to be appropriate for use.
Whenever TLS is used, the identity of the service provider encoded in Whenever TLS is used, the identity of the service provider encoded in
the TLS server certificate MUST be verified using the procedures the TLS server certificate MUST be verified using the procedures
described in Section 6 of RFC 6125 [RFC6125]. described in Section 6 of RFC 6125 [RFC6125].
9. IANA Considerations 9. IANA Considerations
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.
skipping to change at page 28, line 44 skipping to change at page 28, line 44
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, March 2011.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
11.2. Informative References 11.2. Informative References
[CanvasApp] [CanvasApp]
skipping to change at page 49, line 28 skipping to change at page 49, line 28
Turner. 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 ]]
-31
o Reworded the language about JWS implementations ignoring the "typ"
and "cty" parameters, explicitly saying that their processing is
performed by JWS applications.
o Added additional guidance on ciphersuites currently considered to
be appropriate for use, including a reference to a recent update
by the TLS working group.
-30 -30
o Added subsection headings within the Overview section for the two o Added subsection headings within the Overview section for the two
serializations. serializations.
o Added references and cleaned up the reference syntax in a few o Added references and cleaned up the reference syntax in a few
places. places.
o Applied minor wording changes to the Security Considerations o Applied minor wording changes to the Security Considerations
section and made other local editorial improvements. section and made other local editorial improvements.
 End of changes. 10 change blocks. 
8 lines changed or deleted 26 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/