idnits 2.17.1 draft-ietf-jose-jwk-thumbprint-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2015) is 3206 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 457 -- Looks like a reference, but probably isn't: '1' on line 457 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JOSE Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track N. Sakimura 5 Expires: January 10, 2016 NRI 6 July 9, 2015 8 JSON Web Key (JWK) Thumbprint 9 draft-ietf-jose-jwk-thumbprint-08 11 Abstract 13 This specification defines a method for computing a hash value over a 14 JSON Web Key (JWK). It defines which fields in a JWK are used in the 15 hash computation, the method of creating a canonical form for those 16 fields, and how to convert the resulting Unicode string into a byte 17 sequence to be hashed. The resulting hash value can be used for 18 identifying or selecting the key represented by the JWK that is the 19 subject of the thumbprint. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 10, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. JSON Web Key (JWK) Thumbprint . . . . . . . . . . . . . . . . 3 59 3.1. Example JWK Thumbprint Computation . . . . . . . . . . . . 4 60 3.2. JWK Members Used in the Thumbprint Computation . . . . . . 5 61 3.2.1. JWK Thumbprint of a Private Key . . . . . . . . . . . 6 62 3.2.2. Why Not Include Optional Members? . . . . . . . . . . 6 63 3.3. Order and Representation of Members in Hash Input . . . . 7 64 3.4. Selection of Hash Function . . . . . . . . . . . . . . . . 8 65 3.5. JWK Thumbprints of Keys Not in JWK Format . . . . . . . . 8 66 4. Practical JSON and Unicode Considerations . . . . . . . . . . 8 67 5. Relationship to Digests of X.509 Values . . . . . . . . . . . 9 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 74 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 This specification defines a method for computing a hash value 80 (a.k.a. digest) over a JSON Web Key (JWK) [JWK]. It defines which 81 fields in a JWK are used in the hash computation, the method of 82 creating a canonical form for those fields, and how to convert the 83 resulting Unicode string into a byte sequence to be hashed. The 84 resulting hash value can be used for identifying or selecting the key 85 represented by the JWK that is the subject of the thumbprint, for 86 instance, by using the base64url-encoded JWK Thumbprint value as a 87 "kid" (key ID) value. 89 1.1. Notational Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 95 The interpretation should only be applied when the terms appear in 96 all capital letters. 98 2. Terminology 100 This specification uses the same terminology as the "JSON Web Key 101 (JWK)" [JWK], "JSON Web Signature (JWS)" [JWS], and "JSON Web 102 Algorithms (JWA)" [JWA] specifications. 104 This term is defined by this specification: 106 JWK Thumbprint 107 The digest value for a JWK. 109 3. JSON Web Key (JWK) Thumbprint 111 The thumbprint of a JSON Web Key (JWK) is computed as follows: 113 1. Construct a JSON object [RFC7159] containing only the required 114 members of a JWK representing the key and with no whitespace or 115 line breaks before or after any syntactic elements and with the 116 required members ordered lexicographically by the Unicode 117 [UNICODE] code points of the member names. (This JSON object is 118 itself a legal JWK representation of the key.) 120 2. Hash the octets of the UTF-8 representation of this JSON object 121 with a cryptographic hash function H. For example, SHA-256 [SHS] 122 might be used as H. See Section 3.4 for a discussion on the 123 choice of hash function. 125 The resulting value is the JWK Thumbprint with H of the JWK. The 126 details of this computation are further described in subsequent 127 sections. 129 3.1. Example JWK Thumbprint Computation 131 This section demonstrates the JWK Thumbprint computation for the JWK 132 below (with long lines broken for display purposes only): 134 { 135 "kty": "RSA", 136 "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAt 137 VT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn6 138 4tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FD 139 W2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n9 140 1CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINH 141 aQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 142 "e": "AQAB", 143 "alg": "RS256", 144 "kid": "2011-04-29" 145 } 147 As defined in "JSON Web Key (JWK)" [JWK] and "JSON Web Algorithms 148 (JWA)" [JWA], the required members for an RSA public key are: 150 o "kty" 151 o "n" 152 o "e" 154 Therefore, these are the members used in the thumbprint computation. 156 Their lexicographic order, per Section 3.3, is: 158 o "e" 159 o "kty" 160 o "n" 162 Therefore the JSON object constructed as an intermediate step in the 163 computation is as follows (with long lines broken for display 164 purposes only): 166 {"e":"AQAB","kty":"RSA","n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2 167 aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCi 168 FV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65Y 169 GjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n 170 91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_x 171 BniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw"} 173 The octets of the UTF-8 representation of this JSON object are: 175 [123, 34, 101, 34, 58, 34, 65, 81, 65, 66, 34, 44, 34, 107, 116, 121, 176 34, 58, 34, 82, 83, 65, 34, 44, 34, 110, 34, 58, 34, 48, 118, 120, 177 55, 97, 103, 111, 101, 98, 71, 99, 81, 83, 117, 117, 80, 105, 76, 74, 178 88, 90, 112, 116, 78, 57, 110, 110, 100, 114, 81, 109, 98, 88, 69, 179 112, 115, 50, 97, 105, 65, 70, 98, 87, 104, 77, 55, 56, 76, 104, 87, 180 120, 52, 99, 98, 98, 102, 65, 65, 116, 86, 84, 56, 54, 122, 119, 117, 181 49, 82, 75, 55, 97, 80, 70, 70, 120, 117, 104, 68, 82, 49, 76, 54, 182 116, 83, 111, 99, 95, 66, 74, 69, 67, 80, 101, 98, 87, 75, 82, 88, 183 106, 66, 90, 67, 105, 70, 86, 52, 110, 51, 111, 107, 110, 106, 104, 184 77, 115, 116, 110, 54, 52, 116, 90, 95, 50, 87, 45, 53, 74, 115, 71, 185 89, 52, 72, 99, 53, 110, 57, 121, 66, 88, 65, 114, 119, 108, 57, 51, 186 108, 113, 116, 55, 95, 82, 78, 53, 119, 54, 67, 102, 48, 104, 52, 81, 187 121, 81, 53, 118, 45, 54, 53, 89, 71, 106, 81, 82, 48, 95, 70, 68, 188 87, 50, 81, 118, 122, 113, 89, 51, 54, 56, 81, 81, 77, 105, 99, 65, 189 116, 97, 83, 113, 122, 115, 56, 75, 74, 90, 103, 110, 89, 98, 57, 99, 190 55, 100, 48, 122, 103, 100, 65, 90, 72, 122, 117, 54, 113, 77, 81, 191 118, 82, 76, 53, 104, 97, 106, 114, 110, 49, 110, 57, 49, 67, 98, 79, 192 112, 98, 73, 83, 68, 48, 56, 113, 78, 76, 121, 114, 100, 107, 116, 193 45, 98, 70, 84, 87, 104, 65, 73, 52, 118, 77, 81, 70, 104, 54, 87, 194 101, 90, 117, 48, 102, 77, 52, 108, 70, 100, 50, 78, 99, 82, 119, 195 114, 51, 88, 80, 107, 115, 73, 78, 72, 97, 81, 45, 71, 95, 120, 66, 196 110, 105, 73, 113, 98, 119, 48, 76, 115, 49, 106, 70, 52, 52, 45, 99, 197 115, 70, 67, 117, 114, 45, 107, 69, 103, 85, 56, 97, 119, 97, 112, 198 74, 122, 75, 110, 113, 68, 75, 103, 119, 34, 125] 200 Using SHA-256 [SHS] as the hash function H, the JWK SHA-256 201 Thumbprint value is the SHA-256 hash of these octets, specifically: 203 [55, 54, 203, 177, 120, 124, 184, 48, 156, 119, 238, 140, 55, 5, 197, 204 225, 111, 251, 158, 133, 151, 21, 144, 31, 30, 76, 89, 177, 17, 130, 205 245, 123] 207 The base64url encoding [JWS] of this JWK SHA-256 Thumbprint value 208 (which might, for instance, be used as a "kid" (key ID) value) is: 210 NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs 212 3.2. JWK Members Used in the Thumbprint Computation 214 Only the required members of a key's representation are used when 215 computing its JWK Thumbprint value. As defined in "JSON Web Key 216 (JWK)" [JWK] and "JSON Web Algorithms (JWA)" [JWA], the required 217 members for an elliptic curve public key for the curves specified in 218 Section 6.2.1.1 of [JWK], in lexicographic order, are: 220 o "crv" 221 o "kty" 222 o "x" 223 o "y" 225 the required members for an RSA public key, in lexicographic order, 226 are: 228 o "e" 229 o "kty" 230 o "n" 232 and the required members for a symmetric key, in lexicographic order, 233 are: 235 o "k" 236 o "kty" 238 As other "kty" (key type) values are defined, the specifications 239 defining them should be similarly consulted to determine which 240 members, in addition to "kty", are required. 242 3.2.1. JWK Thumbprint of a Private Key 244 The JWK Thumbprint of a JWK representing a private key is computed as 245 the JWK Thumbprint of a JWK representing the corresponding public 246 key. This has the intentional benefit that the same JWK Thumbprint 247 value can be computed both by parties using either the public or 248 private key. The JWK Thumbprint can then be used to refer to both 249 keys of the key pair. Application context can be used to determine 250 whether the public or the private key is the one being referred to by 251 the JWK Thumbprint. 253 This specification defines the method of computing JWK Thumbprints of 254 JWKs representing private keys for interoperability reasons -- so 255 that different implementations computing JWK Thumbprints of private 256 keys will produce the same result. 258 3.2.2. Why Not Include Optional Members? 260 Optional members of JWKs are intentionally not included in the JWK 261 Thumbprint computation so that their absence or presence in the JWK 262 does not alter the resulting value. The JWK Thumbprint value is a 263 digest of the members required to represent the key as a JWK -- not 264 of additional data that may also accompany the key. 266 Optional members are not included so that the JWK Thumbprint refers 267 to a key -- not a key with an associated set of key attributes. This 268 has the benefit that while in different application contexts 269 different subsets of attributes about the key might or might not be 270 included in the JWK, the JWK Thumbprint of any JWK representing the 271 key remains the same regardless of which optional attributes are 272 present. Different kinds of thumbprints could be defined by other 273 specifications that might include some or all additional JWK members, 274 should use cases arise where such different kinds of thumbprints 275 would be useful. See Section 9.1 of [JWK] for notes on some ways to 276 cryptographically bind attributes to a key. 278 3.3. Order and Representation of Members in Hash Input 280 The required members in the input to the hash function are ordered 281 lexicographically by the Unicode code points of the member names. 283 Characters in member names and member values MUST be represented 284 without being escaped. This means that thumbprints of JWKs that 285 require such characters are not defined by this specification. (This 286 is not expected to limit the applicability of this specification, in 287 practice, as the members of JWK representations are not expected to 288 use any of these characters.) The characters specified as requiring 289 escaping by Section 7 of [RFC7159] are quotation mark, reverse 290 solidus (a.k.a. backslash), and the control characters U+0000 through 291 U+001F. 293 If the JWK key type uses members whose values are themselves JSON 294 objects, the members of those objects MUST likewise be 295 lexicographically ordered. (As of the time of this writing, none are 296 defined that do.) 298 If the JWK key type uses members whose values are JSON numbers, if 299 the numbers are integers, they MUST be represented as a JSON number 300 as defined in Section 6 of [RFC7159] without including a fraction 301 part or exponent part. For instance, the value "1.024e3" MUST be 302 represented as "1024". This means that thumbprints of JWKs that use 303 numbers that are not integers are not defined by this specification. 304 Also, as noted in "The I-JSON Message Format" [RFC7493], 305 implementations cannot expect an integer whose absolute value is 306 greater than 9007199254740991 (i.e., that is outside the range 307 [-(2**53)+1, (2**53)-1]) to be treated as an exact value. (As of the 308 time of this writing, none are defined that use JSON numbers.) 310 See Section 4 for a discussion of further practical considerations 311 pertaining to the representation of the hash input. 313 3.4. Selection of Hash Function 315 A specific hash function must be chosen by an application to compute 316 the hash value of the hash input. For example, SHA-256 [SHS] might 317 be used as the hash function by the application. While SHA-256 is a 318 good default choice at the time of this writing, the hash function of 319 choice can be expected to change over time as the cryptographic 320 landscape evolves. 322 Note that in many cases, only the party that creates a key will need 323 to know the hash function used. A typical usage is for the producer 324 of the key to use the base64url-encoded JWK Thumbprint value as a 325 "kid" (key ID) value. In this case, the consumer of the "kid" treats 326 it as an opaque value that it uses to select the key. 328 However, in some cases, multiple parties will be reproducing the JWK 329 Thumbprint calculation and comparing the results. In these cases, 330 the parties will need to know which hash function was used and use 331 the same one. 333 3.5. JWK Thumbprints of Keys Not in JWK Format 335 Note that a key need not be in JWK format to create a JWK Thumbprint 336 of it. The only prerequisites are that the JWK representation of the 337 key be defined and the party creating the JWK Thumbprint is in 338 possession of the necessary key material. These are sufficient to 339 create the hash input from the JWK representation of the key, as 340 described in Section 3.3. 342 4. Practical JSON and Unicode Considerations 344 Implementations will almost certainly use functionality provided by 345 the platform's JSON support when parsing the JWK and emitting the 346 JSON object used as the hash input. As a practical consideration, 347 future JWK member names and values should be avoided for which 348 different platforms or libraries might emit different 349 representations. As of the time of this writing, currently all 350 defined JWK member names and values use only printable ASCII 351 characters, which should not exhibit this problem. Note however, 352 that JSON.stringify() cannot be counted on to lexicographically sort 353 the members of JSON objects, so while it may be able to be used to 354 emit some kinds of member values, different code is likely to be 355 needed to perform the sorting. 357 In particular, while the operation of lexicographically ordering 358 member names by their Unicode code points is well defined, different 359 platform sort functions may produce different results for non-ASCII 360 characters, in ways that may not be obvious to developers. If 361 writers of future specifications defining new JWK key type values 362 choose to restrict themselves to printable ASCII member names and 363 values (which are for machine and not human consumption anyway), some 364 future interoperability problems might be avoided. 366 However, if new JWK members are defined that use non-ASCII member 367 names or values, their definitions should specify the exact Unicode 368 code point sequences used to represent them. This is particularly 369 important in cases in which Unicode normalization could result in the 370 transformation of one set of code points into another under any 371 circumstances. 373 Use of escaped characters in JWKs for which JWK Thumbprints will be 374 computed should be avoided. Use of escaped characters in the hash 375 input JWKs derived from these original JWKs is prohibited. 377 There is a natural representation to use for numeric values that are 378 integers. However, this specification does not attempt to define a 379 standard representation for numbers that are not integers or that 380 contain an exponent component. This is not expected to be a problem 381 in practice, as the required members of JWK representations are 382 expected to use only numbers that are integers. 384 Use of number representations containing fraction or exponent parts 385 in JWKs for which JWK Thumbprints will be computed should be avoided. 387 All of these practical considerations are really an instance of Jon 388 Postel's principle: "Be liberal in what you accept, and conservative 389 in what you send." 391 5. Relationship to Digests of X.509 Values 393 JWK Thumbprint values are computed on the JWK members required to 394 represent a key, rather than all members of a JWK that the key is 395 represented in. Thus, they are more analogous to applications that 396 use digests of X.509 Subject Public Key Info (SPKI) values, which are 397 defined in Section 4.1.2.7 of [RFC5280], than to applications that 398 use digests of complete certificate values, as the "x5t" (X.509 399 certificate SHA-1 thumbprint) [JWS] value defined for X.509 400 certificate objects does. While logically equivalent to a digest of 401 the SPKI representation of the key, a JWK Thumbprint is computed over 402 a JSON representation of that key, rather than over an ASN.1 403 representation of it. 405 6. IANA Considerations 407 This specification adds to the instructions to the Designated Experts 408 for the following IANA registries, all of which are in the JSON 409 Object Signing and Encryption (JOSE) protocol category [IANA.JOSE]: 410 o JSON Web Key Types 411 o JSON Web Key Elliptic Curve 412 o JSON Web Key Parameters 414 IANA, please add a link to this specification in the Reference 415 sections of these registries after the existing links to RFC 7518 for 416 the first two and the link to RFC 7517 for the last. 418 Because of the practical JSON and Unicode considerations described in 419 Section 4, for these registries, the Designated Experts must either 420 require that JWK member names and values being registered use only 421 printable ASCII characters excluding double quote ('"') and 422 backslash ('\') (the Unicode characters with code points U+0021, 423 U+0023 through U+005B, and U+005D through U+007E) or if new JWK 424 members or values are defined that use other code points, require 425 that their definitions specify the exact Unicode code point sequences 426 used to represent them. Furthermore, proposed registrations must not 427 be accepted that use Unicode code points that can only be represented 428 in JSON strings as escaped characters. 430 7. Security Considerations 432 The JSON Security Considerations and Unicode Comparison Security 433 Considerations described in Sections 10.2 and 10.3 of "JSON Web 434 Signature (JWS)" [JWS] also apply to this specification. 436 Also, as described in Section 4, some implementations may produce 437 incorrect results if esoteric or escaped characters are used in the 438 member names. The security implications of this appear to be limited 439 for JWK Thumbprints of public keys, since while it may result in 440 implementations failing to identify the intended key, it should not 441 leak information, since the information in a public key is already 442 public in nature, by definition. 444 A hash of a symmetric key has the potential to leak information about 445 the key value. Thus, the JWK Thumbprint of a symmetric key should be 446 typically be concealed from parties not in possession of the 447 symmetric key, unless in the application context, the cryptographic 448 hash used, such as SHA-256, is known to provide sufficient protection 449 against disclosure of the key value. 451 A JWK Thumbprint will only uniquely identify a particular key if a 452 single unambiguous JWK representation for that key is defined and 453 used when computing the JWK Thumbprint. (Such representations are 454 defined for all the key types defined in "JSON Web Algorithms (JWA)" 455 [JWA].) For example, if an RSA key were to use "e":"AAEAAQ" 456 (representing [0, 1, 0, 1]) rather than the specified correct 457 representation of "e":"AQAB" (representing [1, 0, 1]), a different 458 thumbprint value would be produced for what could be effectively the 459 same key, at least for implementations that are lax in validating the 460 JWK values that they accept. Thus, JWK Thumbprint values can only be 461 relied upon to be unique for a given key if the implementation also 462 validates that the correct representation of the key is used. 464 Even more insidious is that an attacker may supply a key that is a 465 transformation of a legal key in order to have it appear to be a 466 different key. For instance, if a legitimate RSA key uses a modulus 467 value N and an attacker supplies a key with modulus 3*N, the modified 468 key would still work about 1/3 of the time, but would appear to be a 469 different key. Thus, while thumbprint values are valuable for 470 identifying legitimate keys, comparing thumbprint values is not a 471 reliable means of excluding (blacklisting) the use of particular keys 472 (or transformations thereof). 474 8. References 476 8.1. Normative References 478 [IANA.JOSE] 479 IANA, "JSON Object Signing and Encryption (JOSE)", 480 . 482 [JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 483 May 2015, . 485 [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015, 486 . 488 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 489 Signature (JWS)", RFC 7515, May 2015, 490 . 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 496 Interchange Format", RFC 7159, March 2014. 498 [SHS] National Institute of Standards and Technology, "Secure 499 Hash Standard (SHS)", FIPS PUB 180-4, March 2012, . 502 [UNICODE] The Unicode Consortium, "The Unicode Standard", 503 . 505 8.2. Informative References 507 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 508 Housley, R., and W. Polk, "Internet X.509 Public Key 509 Infrastructure Certificate and Certificate Revocation List 510 (CRL) Profile", RFC 5280, May 2008. 512 [RFC7493] Bray, T., "The I-JSON Message Format", RFC 7493, 513 March 2015. 515 Appendix A. Acknowledgements 517 James Manger and John Bradley participated in discussions that led to 518 the creation of this specification. Thanks also to Joel Halpern, 519 Barry Leiba, Adam Montville, Kathleen Moriarty, and Jim Schaad for 520 their reviews of this specification. 522 Appendix B. Document History 524 [[ to be removed by the RFC editor before publication as an RFC ]] 526 -08 528 o Added IANA instructions in response to a comment by Barry Leiba. 530 -07 532 o Addressed Gen-ART review comment by Joel Halpern. 534 -06 536 o Addressed comments in SecDir review by Adam Montville. 538 -05 540 o Addressed comments in Kathleen Moriarty's AD review. 542 -04 543 o Addressed additional review comments by Jim Schaad, which resulted 544 in several clarifications and some corrections to the case of RFC 545 2119 keywords. 547 -03 549 o Addressed review comments by James Manger and Jim Schaad, 550 including adding a section on the relationship to digests of X.509 551 values. 553 -02 555 o No longer register the new JSON Web Signature (JWS) and JSON Web 556 Encryption (JWE) Header Parameters and the new JSON Web Key (JWK) 557 member name "jkt" (JWK SHA-256 Thumbprint) for holding these 558 values. 560 o Added security considerations about the measures needed to ensure 561 that a unique JWK Thumbprint value is produced for a key. 563 o Added text saying that the base64url encoded JWK Thumbprint value 564 could be used as a "kid" (key ID) value. 566 o Broke a sentence up that used to be way too long. 568 -01 570 o Addressed issues pointed out by Jim Schaad, including defining the 571 JWK Thumbprint computation in a manner that allows different hash 572 functions to be used over time. 574 o Added Nat Sakimura as an editor. 576 -00 578 o Created draft-ietf-jose-jwk-thumbprint-00 from 579 draft-jones-jose-jwk-thumbprint-01 with no normative changes. 581 Authors' Addresses 583 Michael B. Jones 584 Microsoft 586 Email: mbj@microsoft.com 587 URI: http://self-issued.info/ 588 Nat Sakimura 589 Nomura Research Institute 591 Email: n-sakimura@nri.co.jp 592 URI: http://nat.sakimura.org/