draft-ietf-jose-json-web-signature-03.txt   draft-ietf-jose-json-web-signature-04.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 7, 2013 Ping Identity Expires: January 17, 2013 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
July 6, 2012 July 16, 2012
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-03 draft-ietf-jose-json-web-signature-04
Abstract Abstract
JSON Web Signature (JWS) is a means of representing content secured JSON Web Signature (JWS) is a means of representing content secured
with digital signatures or Message Authentication Codes (MACs) using with digital signatures or Message Authentication Codes (MACs) using
JavaScript Object Notation (JSON) data structures. Cryptographic JavaScript Object Notation (JSON) 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. described in the separate JSON Web Algorithms (JWA) specification.
Related encryption capabilities are described in the separate JSON Related encryption capabilities are described in the separate JSON
Web Encryption (JWE) specification. Web Encryption (JWE) specification.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 7, 2013. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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.5. "x5t" (X.509 Certificate Thumbprint) Header 4.1.5. "x5t" (X.509 Certificate Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 8 Parameter . . . . . . . . . . . . . . . . . . . . . . 8
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 9 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 9
4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 9 4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 9
4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 9 4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 9
4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 10 4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 10
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 10 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 10
4.3. Private Header Parameter Names . . . . . . . . . . . . . . 10 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 10
5. Rules for Creating and Validating a JWS . . . . . . . . . . . 10 5. Rules for Creating and Validating a JWS . . . . . . . . . . . 10
6. Securing JWSs with Cryptographic Algorithms . . . . . . . . . 12 6. Securing JWSs with Cryptographic Algorithms . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. JSON Web Signature and Encryption Header Parameters 7.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 13 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1.1. Registration Template . . . . . . . . . . . . . . . . 13 7.1.1. Registration Template . . . . . . . . . . . . . . . . 13
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14
7.2. JSON Web Signature and Encryption Type Values Registry . . 15 7.2. JSON Web Signature and Encryption Type Values Registry . . 15
7.2.1. Registration Template . . . . . . . . . . . . . . . . 15 7.2.1. Registration Template . . . . . . . . . . . . . . . . 15
7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 16 7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 16
7.3. Media Type Registration . . . . . . . . . . . . . . . . . 16 7.3. Media Type Registration . . . . . . . . . . . . . . . . . 16
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Cryptographic Security Considerations . . . . . . . . . . 17 8.1. Cryptographic Security Considerations . . . . . . . . . . 17
8.2. JSON Security Considerations . . . . . . . . . . . . . . . 18 8.2. JSON Security Considerations . . . . . . . . . . . . . . . 18
8.3. Unicode Comparison Security Considerations . . . . . . . . 18 8.3. Unicode Comparison Security Considerations . . . . . . . . 18
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 21 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 21
A.1. JWS using HMAC SHA-256 . . . . . . . . . . . . . . . . . . 21 A.1. JWS using HMAC SHA-256 . . . . . . . . . . . . . . . . . . 21
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 21 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 21
A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 23 A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 23
A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 23 A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 23
A.2. JWS using RSA SHA-256 . . . . . . . . . . . . . . . . . . 23 A.2. JWS using RSA SHA-256 . . . . . . . . . . . . . . . . . . 24
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 23 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 24
A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 27 A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 27
A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 27 A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 27
A.3. JWS using ECDSA P-256 SHA-256 . . . . . . . . . . . . . . 27 A.3. JWS using ECDSA P-256 SHA-256 . . . . . . . . . . . . . . 27
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 27 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 27
A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 29 A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 29
A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 29 A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 29
A.4. JWS using ECDSA P-521 SHA-512 . . . . . . . . . . . . . . 30 A.4. JWS using ECDSA P-521 SHA-512 . . . . . . . . . . . . . . 30
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30
A.4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 32 A.4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 32
A.4.3. Validating . . . . . . . . . . . . . . . . . . . . . . 32 A.4.3. Validating . . . . . . . . . . . . . . . . . . . . . . 32
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 32 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 32
Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 33 Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 33
Appendix C. Notes on implementing base64url encoding without Appendix C. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . . 35 padding . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Appendix E. Document History . . . . . . . . . . . . . . . . . . 36 Appendix E. Document History . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
JSON Web Signature (JWS) is a compact format for representing content JSON Web Signature (JWS) is a compact format for representing content
secured with digital signatures or Message Authentication Codes secured with digital signatures or Message Authentication Codes
(MACs) intended for space constrained environments such as HTTP (MACs) intended for space constrained environments such as HTTP
Authorization headers and URI query parameters. It represents this Authorization headers and URI query parameters. It represents this
content using JavaScript Object Notation (JSON) [RFC4627] data content using JavaScript Object Notation (JSON) [RFC4627] based data
structures. The JWS cryptographic mechanisms provide integrity structures. The JWS cryptographic mechanisms provide integrity
protection for arbitrary sequences of bytes. protection for arbitrary sequences of bytes.
Cryptographic algorithms and identifiers for use with this Cryptographic algorithms and identifiers for use with this
specification are described in the separate JSON Web Algorithms (JWA) specification are described in the separate JSON Web Algorithms (JWA)
[JWA] specification. Related encryption capabilities are described [JWA] specification. Related encryption capabilities are described
in the separate JSON Web Encryption (JWE) [JWE] specification. in the separate JSON Web Encryption (JWE) [JWE] specification.
1.1. Notational Conventions 1.1. Notational Conventions
skipping to change at page 4, line 42 skipping to change at page 4, line 42
JWS Header A string representing a JSON object that describes the JWS Header A string representing a JSON object that describes the
digital signature or MAC operation applied to create the JWS digital signature or MAC operation applied to create the JWS
Signature value. Signature value.
JWS Payload The bytes to be secured - a.k.a., the message. The JWS Payload The bytes to be secured - a.k.a., the message. The
payload can contain an arbitrary sequence of bytes. payload can contain an arbitrary sequence of bytes.
JWS Signature A byte array containing the cryptographic material JWS Signature A byte array containing the cryptographic material
that secures the JWS Header and the JWS Payload. that secures the JWS Header and the JWS Payload.
Base64url Encoding The URL- and filename-safe Base64 encoding
described in RFC 4648 [RFC4648], Section 5, with the (non URL-
safe) '=' padding characters omitted, as permitted by Section 3.2.
(See Appendix C for notes on implementing base64url encoding
without padding.)
Encoded JWS Header Base64url encoding of the bytes of the UTF-8 Encoded JWS Header Base64url encoding of the bytes of the UTF-8
[RFC3629] representation of the JWS Header. [RFC3629] representation of the JWS Header.
Encoded JWS Payload Base64url encoding of the JWS Payload. Encoded JWS Payload Base64url encoding of the JWS Payload.
Encoded JWS Signature Base64url encoding of the JWS Signature. Encoded JWS Signature Base64url encoding of the JWS Signature.
JWS Secured Input The concatenation of the Encoded JWS Header, a JWS Secured Input The concatenation of the Encoded JWS Header, a
period ('.') character, and the Encoded JWS Payload. period ('.') character, and the Encoded JWS Payload.
skipping to change at page 5, line 19 skipping to change at page 5, line 23
representing a JWS Header. representing a JWS Header.
Header Parameter Value The value of a member of the JSON object Header Parameter Value The value of a member of the JSON object
representing a JWS Header. representing a JWS Header.
JWS Compact Serialization A representation of the JWS as the JWS Compact Serialization A representation of the JWS as the
concatenation of the Encoded JWS Header, the Encoded JWS Payload, concatenation of the Encoded JWS Header, the Encoded JWS Payload,
and the Encoded JWS Signature in that order, with the three and the Encoded JWS Signature in that order, with the three
strings being separated by period ('.') characters. strings being separated by period ('.') characters.
Base64url Encoding For the purposes of this specification, this term
always refers to the URL- and filename-safe Base64 encoding
described in RFC 4648 [RFC4648], Section 5, with the (non URL-
safe) '=' padding characters omitted, as permitted by Section 3.2.
(See Appendix C for notes on implementing base64url encoding
without padding.)
Collision Resistant Namespace A namespace that allows names to be Collision Resistant Namespace A namespace that allows names to be
allocated in a manner such that they are highly unlikely to allocated in a manner such that they are highly unlikely to
collide with other names. For instance, collision resistance can collide with other names. For instance, collision resistance can
be achieved through administrative delegation of portions of the be achieved through administrative delegation of portions of the
namespace or through use of collision-resistant name allocation namespace or through use of collision-resistant name allocation
functions. Examples of Collision Resistant Namespaces include: functions. Examples of Collision Resistant Namespaces include:
Domain Names, Object Identifiers (OIDs) as defined in the ITU-T Domain Names, Object Identifiers (OIDs) as defined in the ITU-T
X.660 and X.670 Recommendation series, and Universally Unique X.660 and X.670 Recommendation series, and Universally Unique
IDentifiers (UUIDs) [RFC4122]. When using an administratively IDentifiers (UUIDs) [RFC4122]. When using an administratively
delegated namespace, the definer of a name needs to take delegated namespace, the definer of a name needs to take
skipping to change at page 7, line 48 skipping to change at page 7, line 40
both specifications, its usage must be compatible between the both specifications, its usage must be compatible between the
specifications. specifications.
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 algorithm specified by the algorithm used to secure the JWS. The algorithm specified by the
"alg" value MUST be supported by the implementation and there MUST be "alg" value MUST be supported by the implementation and there MUST be
a key for use with that algorithm associated with the party that a key for use with that algorithm associated with the party that
digitally signed or MACed the content or the JWS MUST be rejected. digitally signed or MACed the content or the JWS MUST be rejected.
The "alg" value is case sensitive. Its value MUST be a string
containing a StringOrURI value. This header parameter is REQUIRED.
A list of defined "alg" values for use with JWS is presented in
Section 3.1 of the JSON Web Algorithms (JWA) [JWA] specification.
"alg" values SHOULD either be registered in the IANA JSON Web "alg" values SHOULD either be registered in the IANA JSON Web
Signature and Encryption Algorithms registry [JWA] or be a URI that Signature and Encryption Algorithms registry [JWA] or be a URI that
contains a Collision Resistant Namespace. contains a Collision Resistant Namespace. The "alg" value is a case
sensitive string containing a StringOrURI value. This header
parameter is REQUIRED.
A list of defined "alg" values can be found in the IANA JSON Web
Signature and Encryption Algorithms registry [JWA]; the initial
contents of this registry is the values defined 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
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 certificate MUST use protection; an HTTP GET request to retrieve the certificate MUST use
TLS [RFC2818] [RFC5246]; the identity of the server MUST be TLS [RFC2818] [RFC5246]; the identity of the server MUST be
skipping to change at page 9, line 48 skipping to change at page 9, line 42
the "kid" value is unspecified. Its value MUST be a string. This the "kid" value is unspecified. Its value MUST be a string. This
header parameter is OPTIONAL. header parameter is OPTIONAL.
When used with a JWK, the "kid" value MAY be used to match a JWK When used with a JWK, the "kid" value MAY be used to match a JWK
"kid" parameter value. "kid" parameter value.
4.1.8. "typ" (Type) Header Parameter 4.1.8. "typ" (Type) Header Parameter
The "typ" (type) header parameter is used to declare the type of this The "typ" (type) header parameter is used to declare the type of this
object. The type value "JWS" MAY be used to indicate that this object. The type value "JWS" MAY be used to indicate that this
object is a JWS. The "typ" value is case sensitive. Its value MUST object is a JWS. The "typ" value is a case sensitive string. This
be a string. This header parameter is OPTIONAL. header parameter is OPTIONAL.
MIME Media Type [RFC2046] values MAY be used as "typ" values. MIME Media Type [RFC2046] values MAY be used as "typ" values.
"typ" values SHOULD either be registered in the IANA JSON Web "typ" values SHOULD either be registered in the IANA JSON Web
Signature and Encryption Type Values registry Section 7.2 or be a URI Signature and Encryption Type Values registry Section 7.2 or be a URI
that contains a Collision Resistant Namespace. that contains a Collision Resistant Namespace.
4.1.9. "cty" (Content Type) Header Parameter 4.1.9. "cty" (Content Type) Header Parameter
The "cty" (content type) header parameter is used to declare the type The "cty" (content type) header parameter is used to declare the type
of the secured content (the Payload). The "cty" value is case of the secured content (the Payload). The "cty" value is a case
sensitive. Its value MUST be a string. This header parameter is sensitive string. This header parameter is OPTIONAL.
OPTIONAL.
The values used for the "cty" header parameter come from the same The values used for the "cty" header parameter come from the same
value space as the "typ" header parameter, with the same rules value space as the "typ" header parameter, with the same rules
applying. applying.
4.2. Public Header Parameter Names 4.2. Public Header Parameter Names
Additional header parameter names can be defined by those using JWSs. Additional header parameter names can be defined by those using JWSs.
However, in order to prevent collisions, any new header parameter However, in order to prevent collisions, any new header parameter
name SHOULD either be registered in the IANA JSON Web Signature and name SHOULD either be registered in the IANA JSON Web Signature and
skipping to change at page 13, line 46 skipping to change at page 13, line 41
This specification establishes the IANA JSON Web Signature and This specification establishes the IANA JSON Web Signature and
Encryption Header Parameters registry for reserved JWS and JWE header Encryption Header Parameters registry for reserved JWS and JWE header
parameter names. The registry records the reserved header parameter parameter names. The registry records the reserved header parameter
name and a reference to the specification that defines it. The same name and a reference to the specification that defines it. The same
Header Parameter Name may be registered multiple times, provided that Header Parameter Name may be registered multiple times, provided that
the parameter usage is compatible between the specifications. the parameter usage is compatible between the specifications.
7.1.1. Registration Template 7.1.1. Registration Template
Header Parameter Name: Header Parameter Name:
The name requested (e.g., "example"). The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted.
Change Controller: Change Controller:
For standards-track RFCs, state "IETF". For others, give the name For standards-track RFCs, state "IETF". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
e-mail address, home page URI) may also be included. e-mail address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document that specifies the parameter, preferably Reference to the document that specifies the parameter, preferably
including a URI that can be used to retrieve a copy of the including a URI that can be used to retrieve a copy of the
document. An indication of the relevant sections may also be document. An indication of the relevant sections may also be
skipping to change at page 15, line 45 skipping to change at page 15, line 39
value, the MIME type value that it is an abbreviation for (if any), value, the MIME type value that it is an abbreviation for (if any),
and a reference to the specification that defines it. and a reference to the specification that defines it.
MIME Media Type [RFC2046] values MUST NOT be directly registered as MIME Media Type [RFC2046] values MUST NOT be directly registered as
new "typ" values; rather, new "typ" values MAY be registered as short new "typ" values; rather, new "typ" values MAY be registered as short
names for MIME types. names for MIME types.
7.2.1. Registration Template 7.2.1. Registration Template
"typ" Header Parameter Value: "typ" Header Parameter Value:
The name requested (e.g., "example"). The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted.
Abbreviation for MIME Type: Abbreviation for MIME Type:
The MIME type that this name is an abbreviation for (e.g., The MIME type that this name is an abbreviation for (e.g.,
"application/example"). "application/example").
Change Controller: Change Controller:
For standards-track RFCs, state "IETF". For others, give the name For standards-track RFCs, state "IETF". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
e-mail address, home page URI) may also be included. e-mail address, home page URI) may also be included.
skipping to change at page 17, line 45 skipping to change at page 17, line 40
All the security considerations in XML DSIG 2.0 All the security considerations in XML DSIG 2.0
[W3C.CR-xmldsig-core2-20120124], also apply to this specification, [W3C.CR-xmldsig-core2-20120124], also apply to this specification,
other than those that are XML specific. Likewise, many of the best other than those that are XML specific. Likewise, many of the best
practices documented in XML Signature Best Practices practices documented in XML Signature Best Practices
[W3C.WD-xmldsig-bestpractices-20110809] also apply to this [W3C.WD-xmldsig-bestpractices-20110809] also apply to this
specification, other than those that are XML specific. specification, other than those that are XML specific.
Keys are only as strong as the amount of entropy used to generate Keys are only as strong as the amount of entropy used to generate
them. A minimum of 128 bits of entropy should be used for all keys, them. A minimum of 128 bits of entropy should be used for all keys,
and depending upon the application context, more may be required. and depending upon the application context, more may be required. In
particular, it may be difficult to generate sufficiently random
values in some browsers and application environments.
When utilizing TLS to retrieve information, the authority providing When utilizing TLS to retrieve information, the authority providing
the resource MUST be authenticated and the information retrieved MUST the resource MUST be authenticated and the information retrieved MUST
be free from modification. be free from modification.
When cryptographic algorithms are implemented in such a way that When cryptographic algorithms are implemented in such a way that
successful operations take a different amount of time than successful operations take a different amount of time than
unsuccessful operations, attackers may be able to use the time unsuccessful operations, attackers may be able to use the time
difference to obtain information about the keys employed. Therefore, difference to obtain information about the keys employed. Therefore,
such timing differences must be avoided. such timing differences must be avoided.
TBD: Write security considerations about the implications of using a A SHA-1 hash is used when computing "x5t" (x.509 certificate
SHA-1 hash (for compatibility reasons) for the "x5t" (x.509 thumbprint) values, for compatibility reasons. Should an effective
certificate thumbprint). means of producing SHA-1 hash collisions be developed, and should an
attacker wish to interfere with the use of a known certificate on a
given system, this could be accomplished by creating another
certificate whose SHA-1 hash value is the same and adding it to the
certificate store used by the intended victim. A prerequisite to
this attack succeeding is the attacker having write access to the
intended victim's certificate store.
TBD: We need a section on generating randomness in browsers; it's If, in the future, certificate thumbprints need to be computed using
easy to screw up. hash functions other than SHA-1, it is suggested that additional
related header parameters be defined for that purpose. For example,
it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint
using SHA-256) header parameter could be defined and used.
8.2. JSON Security Considerations 8.2. JSON Security Considerations
TBD: We need to look into any issues relating to security and JSON Strict JSON validation is a security requirement. If malformed JSON
parsing. One wonders just how secure most JSON parsing libraries is received, then the intent of the sender is impossible to reliably
are. Were they ever hardened for security scenarios? If not, what discern. Ambiguous and potentially exploitable situations could
kind of holes does that open up? We need to put in text about why arise if the JSON parser used does not reject malformed JSON syntax.
strict JSON validation is necessary - basically, that if malformed
JSON is received then the intent of the sender is impossible to Section 2.2 of the JavaScript Object Notation (JSON) specification
reliably discern. [RFC4627] states "The names within an object SHOULD be unique",
whereas this specification states that "Header Parameter Names within
this object MUST be unique; JWSs with duplicate Header Parameter
Names MUST be rejected". Thus, this specification requires that the
Section 2.2 "SHOULD" be treated as a "MUST". Ambiguous and
potentially exploitable situations could arise if the JSON parser
used does not enforce the uniqueness of member names.
8.3. Unicode Comparison Security Considerations 8.3. Unicode Comparison Security Considerations
Header parameter names and algorithm names are Unicode strings. For Header parameter names and algorithm names are Unicode strings. For
security reasons, the representations of these names must be compared security reasons, the representations of these names must be compared
verbatim after performing any escape processing (as per RFC 4627 verbatim after performing any escape processing (as per RFC 4627
[RFC4627], Section 2.5). This means, for instance, that these JSON [RFC4627], Section 2.5). This means, for instance, that these JSON
strings must compare as being equal ("sig", "\u0073ig"), whereas strings must compare as being equal ("sig", "\u0073ig"), whereas
these must all compare as being not equal to the first set or to each these must all compare as being not equal to the first set or to each
other ("SIG", "Sig", "si\u0047"). other ("SIG", "Sig", "si\u0047").
skipping to change at page 19, line 9 skipping to change at page 19, line 19
9. Open Issues 9. Open Issues
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
The following items remain to be considered or done in this draft: The following items remain to be considered or done in this draft:
o Should we define an optional nonce and/or timestamp header o Should we define an optional nonce and/or timestamp header
parameter? (Use of a nonce is an effective countermeasure to some parameter? (Use of a nonce is an effective countermeasure to some
kinds of attacks.) kinds of attacks.)
o Some have objected to the language "Implementations MUST
understand the entire contents of the header; otherwise, the JWS
MUST be rejected" in this spec and the related language in the
JWE, JWK, and JWT specs. Others believe that this is essential in
a security specification.
o Finish the Security Considerations section. o Finish the Security Considerations section.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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
skipping to change at page 20, line 27 skipping to change at page 20, line 45
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode [USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode
Normalization Forms", Unicode Standard Annex 15, 09 2009. Normalization Forms", Unicode Standard Annex 15, 09 2009.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[W3C.WD-xmldsig-bestpractices-20110809]
Datta, P. and F. Hirsch, "XML Signature Best Practices",
World Wide Web Consortium WD WD-xmldsig-bestpractices-
20110809, August 2011, <http://www.w3.org/TR/2011/
WD-xmldsig-bestpractices-20110809>.
10.2. Informative References 10.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign",
September 2010. September 2010.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", July 2012. Encryption (JWE)", July 2012.
skipping to change at page 21, line 4 skipping to change at page 21, line 31
[MagicSignatures] [MagicSignatures]
Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011. Signatures", January 2011.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Reagle, J., Solo, D., Datta, P., Hirsch, F., Eastlake, D., Reagle, J., Hirsch, F., Cantor, S., Roessler, T.,
Roessler, T., Cantor, S., and K. Yiu, "XML Signature Eastlake, D., Yiu, K., Solo, D., and P. Datta, "XML
Syntax and Processing Version 2.0", World Wide Web Signature Syntax and Processing Version 2.0", World Wide
Consortium CR CR-xmldsig-core2-20120124, January 2012, Web Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
[W3C.WD-xmldsig-bestpractices-20110809]
Datta, P. and F. Hirsch, "XML Signature Best Practices",
World Wide Web Consortium WD WD-xmldsig-bestpractices-
20110809, August 2011, <http://www.w3.org/TR/2011/
WD-xmldsig-bestpractices-20110809>.
Appendix A. JWS Examples Appendix A. JWS Examples
This section provides several examples of JWSs. While these examples This section provides several examples of JWSs. While these examples
all represent JSON Web Tokens (JWTs) [JWT], the payload can be any all represent JSON Web Tokens (JWTs) [JWT], the payload can be any
base64url encoded content. base64url encoded content.
A.1. JWS using HMAC SHA-256 A.1. JWS using HMAC SHA-256
A.1.1. Encoding A.1.1. Encoding
skipping to change at page 36, line 19 skipping to change at page 36, line 19
A-z_4ME A-z_4ME
Appendix D. Acknowledgements Appendix D. Acknowledgements
Solutions for signing JSON content were previously explored by Magic Solutions for signing JSON content were previously explored by Magic
Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas
Applications [CanvasApp], all of which influenced this draft. Dirk Applications [CanvasApp], all of which influenced this draft. Dirk
Balfanz, Yaron Y. Goland, John Panzer, and Paul Tarjan all made Balfanz, Yaron Y. Goland, John Panzer, and Paul Tarjan all made
significant contributions to the design of this specification. significant contributions to the design of this specification.
My thanks to Axel Nennker for his early implementation and feedback Thanks to Axel Nennker for his early implementation and feedback on
on the JWS and JWE specifications. the JWS and JWE specifications.
Appendix E. Document History Appendix E. 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 ]]
-04
o Completed JSON Security Considerations section, including
considerations about rejecting input with duplicate member names.
o Completed security considerations on the use of a SHA-1 hash when
computing "x5t" (x.509 certificate thumbprint) values.
o Refer to the registries as the primary sources of defined values
and then secondarily reference the sections defining the initial
contents of the registries.
o Normatively reference XML DSIG 2.0 [W3C.CR-xmldsig-core2-20120124]
for its security considerations.
o Added this language to Registration Templates: "This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted."
o Reference draft-jones-jose-jws-json-serialization instead of
draft-jones-json-web-signature-json-serialization. to
o Described additional open issues.
o Applied editorial suggestions.
-03 -03
o Added the "cty" (content type) header parameter for declaring type o Added the "cty" (content type) header parameter for declaring type
information about the secured content, as opposed to the "typ" information about the secured content, as opposed to the "typ"
(type) header parameter, which declares type information about (type) header parameter, which declares type information about
this object. this object.
o Added "Collision Resistant Namespace" to the terminology section. o Added "Collision Resistant Namespace" to the terminology section.
o Reference ITU.X690.1994 for DER encoding. o Reference ITU.X690.1994 for DER encoding.
 End of changes. 28 change blocks. 
56 lines changed or deleted 109 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/