draft-ietf-jose-jwk-thumbprint-05.txt   draft-ietf-jose-jwk-thumbprint-06.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track N. Sakimura Intended status: Standards Track N. Sakimura
Expires: November 28, 2015 NRI Expires: December 26, 2015 NRI
May 27, 2015 June 24, 2015
JSON Web Key (JWK) Thumbprint JSON Web Key (JWK) Thumbprint
draft-ietf-jose-jwk-thumbprint-05 draft-ietf-jose-jwk-thumbprint-06
Abstract Abstract
This specification defines a method for computing a hash value over a This specification defines a method for computing a hash value over a
JSON Web Key (JWK). It defines which fields in a JWK are used in the JSON Web Key (JWK). It defines which fields in a JWK are used in the
hash computation, the method of creating a canonical form for those hash computation, the method of creating a canonical form for those
fields, and how to convert the resulting Unicode string into a byte fields, and how to convert the resulting Unicode string into a byte
sequence to be hashed. The resulting hash value can be used for sequence to be hashed. The resulting hash value can be used for
identifying or selecting the key represented by the JWK that is the identifying or selecting the key represented by the JWK that is the
subject of the thumbprint. subject of the thumbprint.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 November 28, 2015. This Internet-Draft will expire on December 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. JSON Web Key (JWK) Thumbprint . . . . . . . . . . . . . . . . 3 3. JSON Web Key (JWK) Thumbprint . . . . . . . . . . . . . . . . 3
3.1. Example JWK Thumbprint Computation . . . . . . . . . . . . 4 3.1. Example JWK Thumbprint Computation . . . . . . . . . . . . 4
3.2. JWK Members Used in the Thumbprint Computation . . . . . . 5 3.2. JWK Members Used in the Thumbprint Computation . . . . . . 5
3.2.1. JWK Thumbprint of a Private Key . . . . . . . . . . . 6 3.2.1. JWK Thumbprint of a Private Key . . . . . . . . . . . 6
3.2.2. Why Not Include Optional Members? . . . . . . . . . . 6 3.2.2. Why Not Include Optional Members? . . . . . . . . . . 6
3.3. Order and Representation of Members in Hash Input . . . . 7 3.3. Order and Representation of Members in Hash Input . . . . 7
3.4. JWK Thumbprints of Keys Not in JWK Format . . . . . . . . 8 3.4. Selection of Hash Function . . . . . . . . . . . . . . . . 8
3.5. JWK Thumbprints of Keys Not in JWK Format . . . . . . . . 8
4. Practical JSON and Unicode Considerations . . . . . . . . . . 8 4. Practical JSON and Unicode Considerations . . . . . . . . . . 8
5. Relationship to Digests of X.509 Values . . . . . . . . . . . 9 5. Relationship to Digests of X.509 Values . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This specification defines a method for computing a hash value This specification defines a method for computing a hash value
(a.k.a. digest) over a JSON Web Key (JWK) [JWK]. It defines which (a.k.a. digest) over a JSON Web Key (JWK) [JWK]. It defines which
fields in a JWK are used in the hash computation, the method of fields in a JWK are used in the hash computation, the method of
creating a canonical form for those fields, and how to convert the creating a canonical form for those fields, and how to convert the
resulting Unicode string into a byte sequence to be hashed. The resulting Unicode string into a byte sequence to be hashed. The
resulting hash value can be used for identifying or selecting the key resulting hash value can be used for identifying or selecting the key
represented by the JWK that is the subject of the thumbprint, for represented by the JWK that is the subject of the thumbprint, for
skipping to change at page 3, line 50 skipping to change at page 3, line 50
1. Construct a JSON object [RFC7159] containing only the required 1. Construct a JSON object [RFC7159] containing only the required
members of a JWK representing the key and with no whitespace or members of a JWK representing the key and with no whitespace or
line breaks before or after any syntactic elements and with the line breaks before or after any syntactic elements and with the
required members ordered lexicographically by the Unicode required members ordered lexicographically by the Unicode
[UNICODE] code points of the member names. (This JSON object is [UNICODE] code points of the member names. (This JSON object is
itself a legal JWK representation of the key.) itself a legal JWK representation of the key.)
2. Hash the octets of the UTF-8 representation of this JSON object 2. Hash the octets of the UTF-8 representation of this JSON object
with a cryptographic hash function H. For example, SHA-256 [SHS] with a cryptographic hash function H. For example, SHA-256 [SHS]
might be used as H. might be used as H. See Section 3.4 for a discussion on the
choice of hash function.
The resulting value is the JWK Thumbprint with H of the JWK. The The resulting value is the JWK Thumbprint with H of the JWK. The
details of this computation are further described in subsequent details of this computation are further described in subsequent
sections. sections.
3.1. Example JWK Thumbprint Computation 3.1. Example JWK Thumbprint Computation
This section demonstrates the JWK Thumbprint computation for the JWK This section demonstrates the JWK Thumbprint computation for the JWK
below (with long lines broken for display purposes only): below (with long lines broken for display purposes only):
skipping to change at page 8, line 5 skipping to change at page 8, line 5
numbers that are not integers are not defined by this specification. numbers that are not integers are not defined by this specification.
Also, as noted in "The I-JSON Message Format" [RFC7493], Also, as noted in "The I-JSON Message Format" [RFC7493],
implementations cannot expect an integer whose absolute value is implementations cannot expect an integer whose absolute value is
greater than 9007199254740991 (i.e., that is outside the range greater than 9007199254740991 (i.e., that is outside the range
[-(2**53)+1, (2**53)-1]) to be treated as an exact value. (As of the [-(2**53)+1, (2**53)-1]) to be treated as an exact value. (As of the
time of this writing, none are defined that use JSON numbers.) time of this writing, none are defined that use JSON numbers.)
See Section 4 for a discussion of further practical considerations See Section 4 for a discussion of further practical considerations
pertaining to the representation of the hash input. pertaining to the representation of the hash input.
3.4. JWK Thumbprints of Keys Not in JWK Format 3.4. Selection of Hash Function
A specific hash function must be chosen by an application to compute
the hash value of the hash input. For example, SHA-256 [SHS] might
be used as the hash function by the application. While SHA-256 is a
good default choice at the time of this writing, the hash function of
choice can be expected to change over time as the cryptographic
landscape evolves.
Note that in many cases, only the party that creates a key will need
to know the hash function used. A typical usage is for the producer
of the key to use the base64url-encoded JWK Thumbprint value as a
"kid" (key ID) value. The consumer of the "kid" treats it as an
opaque value that it uses to select the key. Only if multiple
parties will be reproducing the JWK Thumbprint calculation for some
reason, will parties other than the original producer of the JWK
Thumbprint need to know which hash function was used.
3.5. JWK Thumbprints of Keys Not in JWK Format
Note that a key need not be in JWK format to create a JWK Thumbprint Note that a key need not be in JWK format to create a JWK Thumbprint
of it. The only prerequisites are that the JWK representation of the of it. The only prerequisites are that the JWK representation of the
key be defined and the party creating the JWK Thumbprint is in key be defined and the party creating the JWK Thumbprint is in
possession of the necessary key material. These are sufficient to possession of the necessary key material. These are sufficient to
create the hash input from the JWK representation of the key, as create the hash input from the JWK representation of the key, as
described in Section 3.3. described in Section 3.3.
4. Practical JSON and Unicode Considerations 4. Practical JSON and Unicode Considerations
Implementations will almost certainly use functionality provided by Implementations will almost certainly use functionality provided by
the platform's JSON support when parsing the JWK and emitting the the platform's JSON support when parsing the JWK and emitting the
JSON object used as the hash input. As a practical consideration, JSON object used as the hash input. As a practical consideration,
future JWK member names should be avoided for which different future JWK member names and values should be avoided for which
platforms or libraries might emit different representations. As of different platforms or libraries might emit different
the time of this writing, currently all defined JWK member names use representations. As of the time of this writing, currently all
only printable ASCII characters, which should not exhibit this defined JWK member names and values use only printable ASCII
problem. Note however, that JSON.stringify() cannot be counted on to characters, which should not exhibit this problem. Note however,
lexicographically sort the members of JSON objects, so while it may that JSON.stringify() cannot be counted on to lexicographically sort
be able to be used to emit some kinds of member values, different the members of JSON objects, so while it may be able to be used to
code is likely to be needed to perform the sorting. emit some kinds of member values, different code is likely to be
needed to perform the sorting.
In particular, while the operation of lexicographically ordering In particular, while the operation of lexicographically ordering
member names by their Unicode code points is well defined, different member names by their Unicode code points is well defined, different
platform sort functions may produce different results for non-ASCII platform sort functions may produce different results for non-ASCII
characters, in ways that may not be obvious to developers. If characters, in ways that may not be obvious to developers. If
writers of future specifications defining new JWK key type values writers of future specifications defining new JWK key type values
choose to restrict themselves to ASCII member names (which are for choose to restrict themselves to printable ASCII member names and
machine and not human consumption anyway), some future values (which are for machine and not human consumption anyway), some
interoperability problems might be avoided. future interoperability problems might be avoided.
However, if new JWK members are defined that use non-ASCII member However, if new JWK members are defined that use non-ASCII member
names, their definitions should specify the exact Unicode code point names or values, their definitions should specify the exact Unicode
sequences used to represent them. This is particularly important in code point sequences used to represent them. This is particularly
cases in which Unicode normalization could result in the important in cases in which Unicode normalization could result in the
transformation of one set of code points into another under any transformation of one set of code points into another under any
circumstances. circumstances.
Use of escaped characters in JWKs for which JWK Thumbprints will be Use of escaped characters in JWKs for which JWK Thumbprints will be
computed should be avoided. Use of escaped characters in the hash computed should be avoided. Use of escaped characters in the hash
input JWKs derived from these original JWKs is prohibited. input JWKs derived from these original JWKs is prohibited.
There is a natural representation to use for numeric values that are There is a natural representation to use for numeric values that are
integers. However, this specification does not attempt to define a integers. However, this specification does not attempt to define a
standard representation for numbers that are not integers or that standard representation for numbers that are not integers or that
skipping to change at page 9, line 30 skipping to change at page 9, line 49
defined in Section 4.1.2.7 of [RFC5280], than to applications that defined in Section 4.1.2.7 of [RFC5280], than to applications that
use digests of complete certificate values, as the "x5t" (X.509 use digests of complete certificate values, as the "x5t" (X.509
certificate SHA-1 thumbprint) [JWS] value defined for X.509 certificate SHA-1 thumbprint) [JWS] value defined for X.509
certificate objects does. While logically equivalent to a digest of certificate objects does. While logically equivalent to a digest of
the SPKI representation of the key, a JWK Thumbprint is computed over the SPKI representation of the key, a JWK Thumbprint is computed over
a JSON representation of that key, rather than over an ASN.1 a JSON representation of that key, rather than over an ASN.1
representation of it. representation of it.
6. IANA Considerations 6. IANA Considerations
This specification makes no requests of IANA. This specification adds to the instructions to the Designated Experts
for the following IANA registries, all of which are in the JSON
Object Signing and Encryption (JOSE) protocol category [IANA.JOSE]:
o JSON Web Key Types
o JSON Web Key Elliptic Curve
o JSON Web Key Parameters
Because of the practical JSON and Unicode considerations described in
Section 4, for these registries, the Designated Experts must either
require that JWK member names and values being registered use only
printable ASCII characters excluding double quote ('"') and
backslash ('\') (the Unicode characters with code points U+0021,
U+0023 through U+005B, and U+005D through U+007E) or if new JWK
members or values are defined that use other code points, require
that their definitions specify the exact Unicode code point sequences
used to represent them. Furthermore, proposed registrations must not
be accepted that use Unicode code points that can only be represented
in JSON strings as escaped characters.
7. Security Considerations 7. Security Considerations
The JSON Security Considerations and Unicode Comparison Security The JSON Security Considerations and Unicode Comparison Security
Considerations described in Sections 10.2 and 10.3 of "JSON Web Considerations described in Sections 10.2 and 10.3 of "JSON Web
Signature (JWS)" [JWS] also apply to this specification. Signature (JWS)" [JWS] also apply to this specification.
Also, as described in Section 4, some implementations may produce Also, as described in Section 4, some implementations may produce
incorrect results if esoteric or escaped characters are used in the incorrect results if esoteric or escaped characters are used in the
member names. The security implications of this appear to be limited member names. The security implications of this appear to be limited
skipping to change at page 10, line 35 skipping to change at page 11, line 23
key would still work about 1/3 of the time, but would appear to be a key would still work about 1/3 of the time, but would appear to be a
different key. Thus, while thumbprint values are valuable for different key. Thus, while thumbprint values are valuable for
identifying legitimate keys, comparing thumbprint values is not a identifying legitimate keys, comparing thumbprint values is not a
reliable means of excluding (blacklisting) the use of particular keys reliable means of excluding (blacklisting) the use of particular keys
(or transformations thereof). (or transformations thereof).
8. References 8. References
8.1. Normative References 8.1. Normative References
[IANA.JOSE]
IANA, "JSON Object Signing and Encryption (JOSE)",
<http://www.iana.org/assignments/jose>.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
May 2015, <http://www.rfc-editor.org/info/rfc7518>. May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015, [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>. <http://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, May 2015, Signature (JWS)", RFC 7515, May 2015,
<http://www.rfc-editor.org/info/rfc7515>. <http://www.rfc-editor.org/info/rfc7515>.
skipping to change at page 11, line 32 skipping to change at page 12, line 25
Appendix A. Acknowledgements Appendix A. Acknowledgements
James Manger and John Bradley participated in discussions that led to James Manger and John Bradley participated in discussions that led to
the creation of this specification. Jim Schaad also contributed to the creation of this specification. Jim Schaad also contributed to
this specification. this specification.
Appendix B. Document History Appendix B. 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 ]]
-06
o Addressed comments in SecDir review by Adam Montville.
-05 -05
o Addressed comments in Kathleen Moriarty's AD review. o Addressed comments in Kathleen Moriarty's AD review.
-04 -04
o Addressed additional review comments by Jim Schaad, which resulted o Addressed additional review comments by Jim Schaad, which resulted
in several clarifications and some corrections to the case of RFC in several clarifications and some corrections to the case of RFC
2119 keywords. 2119 keywords.
 End of changes. 13 change blocks. 
29 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/