| < draft-jones-json-web-signature-00.txt | draft-jones-json-web-signature-01.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Jones | Network Working Group M. Jones | |||
| Internet-Draft Microsoft | Internet-Draft Microsoft | |||
| Intended status: Standards Track D. Balfanz | Intended status: Standards Track D. Balfanz | |||
| Expires: September 29, 2011 Google | Expires: September 26, 2011 Google | |||
| J. Bradley | J. Bradley | |||
| independent | independent | |||
| Y. Goland | Y. Goland | |||
| Microsoft | Microsoft | |||
| J. Panzer | J. Panzer | |||
| N. Sakimura | N. Sakimura | |||
| Nomura Research Institute | Nomura Research Institute | |||
| P. Tarjan | P. Tarjan | |||
| March 28, 2011 | March 25, 2011 | |||
| JSON Web Signature (JWS) | JSON Web Signature (JWS) | |||
| draft-jones-json-web-signature-00 | draft-jones-json-web-signature-01 | |||
| Abstract | Abstract | |||
| JSON Web Signature (JWS) is a means of representing signed content | JSON Web Signature (JWS) is a means of representing signed content | |||
| using JSON data structures. Related encryption capabilities are | using JSON data structures. Related encryption capabilities are | |||
| described in the separate JSON Web Encryption (JWE) specification. | described in the separate JSON Web Encryption (JWE) specification. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
| 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 September 29, 2011. | This Internet-Draft will expire on September 26, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 18 ¶ | skipping to change at page 3, line 18 ¶ | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 5 | 3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 5 | |||
| 3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 6 | 4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 6 | |||
| 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 9 | 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 9 | |||
| 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 9 | 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 9 | |||
| 5. Rules for Creating and Validating a JWS . . . . . . . . . . . 9 | 5. Rules for Creating and Validating a JWS . . . . . . . . . . . 9 | |||
| 6. Base64url encoding as used by JWSs . . . . . . . . . . . . . . 11 | 6. Base64url encoding as used by JWSs . . . . . . . . . . . . . . 11 | |||
| 7. Signing JWSs with Cryptographic Algorithms . . . . . . . . . . 11 | 7. Signing JWSs with Cryptographic Algorithms . . . . . . . . . . 11 | |||
| 7.1. Creating a JWS with HMAC SHA-256 . . . . . . . . . . . . . 12 | 7.1. Creating a JWS with HMAC SHA-256, HMAC SHA-384, or | |||
| 7.2. Creating a JWS with RSA SHA-256 . . . . . . . . . . . . . 13 | HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 7.3. Creating a JWS with ECDSA P-256 SHA-256 . . . . . . . . . 14 | 7.2. Creating a JWS with RSA SHA-256, RSA SHA-384, or RSA | |||
| 7.4. Additional Algorithms . . . . . . . . . . . . . . . . . . 15 | SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 7.3. Creating a JWS with ECDSA P-256 SHA-256, ECDSA P-384 | ||||
| SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . . . . 14 | ||||
| 7.4. Additional Algorithms . . . . . . . . . . . . . . . . . . 16 | ||||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 9.1. Unicode Comparison Security Issues . . . . . . . . . . . . 16 | 9.1. Unicode Comparison Security Issues . . . . . . . . . . . . 17 | |||
| 10. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 17 | 10. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 17 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 | |||
| Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 20 | Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 20 | |||
| A.1. JWS using HMAC SHA-256 . . . . . . . . . . . . . . . . . . 20 | A.1. JWS using HMAC SHA-256 . . . . . . . . . . . . . . . . . . 21 | |||
| A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 20 | A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 22 | A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 22 | A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| A.2. JWS using RSA SHA-256 . . . . . . . . . . . . . . . . . . 23 | A.2. JWS using RSA SHA-256 . . . . . . . . . . . . . . . . . . 23 | |||
| A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 23 | A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 26 | A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 26 | A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . . 28 | A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 29 | A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| Appendix B. Notes on implementing base64url encoding without | Appendix B. Algorithm Identifier Cross-Reference . . . . . . . . 29 | |||
| padding . . . . . . . . . . . . . . . . . . . . . . . 29 | Appendix C. Notes on implementing base64url encoding without | |||
| Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 30 | padding . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
| Appendix D. Document History . . . . . . . . . . . . . . . . . . 31 | Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 | Appendix E. Document History . . . . . . . . . . . . . . . . . . 33 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
| 1. Introduction | 1. Introduction | |||
| JSON Web Signature (JWS) is a compact signature format intended for | JSON Web Signature (JWS) is a compact signature format intended for | |||
| space constrained environments such as HTTP Authorization headers and | space constrained environments such as HTTP Authorization headers and | |||
| URI query parameters. The JWS signature mechanisms are independent | URI query parameters. The JWS signature mechanisms are independent | |||
| of the type of content being signed, allowing arbitrary content to be | of the type of content being signed, allowing arbitrary content to be | |||
| signed. A related encryption capability is described in a separate | signed. A related encryption capability is described in a separate | |||
| JSON Web Encryption (JWE) [JWE] specification. | JSON Web Encryption (JWE) [JWE] specification. | |||
| skipping to change at page 5, line 18 ¶ | skipping to change at page 5, line 18 ¶ | |||
| Base64url Encoding For the purposes of this specification, this term | Base64url Encoding For the purposes of this specification, this term | |||
| always refers to the he URL- and filename-safe Base64 encoding | always refers to the he URL- and filename-safe Base64 encoding | |||
| described in RFC 4648 [RFC4648], Section 5, with the '=' padding | described in RFC 4648 [RFC4648], Section 5, with the '=' padding | |||
| characters omitted, as permitted by Section 3.2. | characters omitted, as permitted by Section 3.2. | |||
| 3. JSON Web Signature (JWS) Overview | 3. JSON Web Signature (JWS) Overview | |||
| JWSs represent content that is base64url encoded and digitally | JWSs represent content that is base64url encoded and digitally | |||
| signed, and optionally encrypted, using JSON data structures. A | signed, and optionally encrypted, using JSON data structures. A | |||
| portion of the base64url encoded content that is signed is the JWS | portion of the base64url encoded content that is signed is the JWS | |||
| Payload Input. | Payload Input. An accompanying base64url encoded JSON object - the | |||
| JWS Header Input - describes the signature method used. | ||||
| An accompanying base64url encoded JSON object - the JWS Header Input | ||||
| - describes the signature method used. | ||||
| The names within the header JSON object MUST be unique. These names | The member names within the Decoded JWS Header Input are referred to | |||
| are referred to as Header Parameter Names. The corresponding values | as Header Parameter Names. These names MUST be unique. The | |||
| are referred to as Header Parameter Values. | corresponding values are referred to as Header Parameter Values. | |||
| JWSs contain a signature that ensures the integrity of the contents | JWSs contain a signature that ensures the integrity of the contents | |||
| of the JWS Header Input and the JWS Payload Input. This signature | of the JWS Header Input and the JWS Payload Input. This signature | |||
| value is the JWS Crypto Output. The JSON Header object MUST contain | value is the JWS Crypto Output. The JSON Header object MUST contain | |||
| an "alg" parameter, the value of which is a string that unambiguously | an "alg" parameter, the value of which is a string that unambiguously | |||
| identifies the algorithm used to sign the JWS Header Input and the | identifies the algorithm used to sign the JWS Header Input and the | |||
| JWS Payload Input to produce the JWS Crypto Output. | JWS Payload Input to produce the JWS Crypto Output. | |||
| 3.1. Example JWS | 3.1. Example JWS | |||
| skipping to change at page 7, line 25 ¶ | skipping to change at page 7, line 25 ¶ | |||
| | | | | Table 3. The processing of | | | | | | Table 3. The processing of | | |||
| | | | | the "alg" (algorithm) header | | | | | | the "alg" (algorithm) header | | |||
| | | | | parameter, if present, | | | | | | parameter, if present, | | |||
| | | | | requires that the value of | | | | | | requires that the value of | | |||
| | | | | the "alg" header parameter | | | | | | the "alg" header parameter | | |||
| | | | | MUST be one that is both | | | | | | MUST be one that is both | | |||
| | | | | supported and for which there | | | | | | supported and for which there | | |||
| | | | | exists a key for use with | | | | | | exists a key for use with | | |||
| | | | | that algorithm associated | | | | | | that algorithm associated | | |||
| | | | | with the signer of the | | | | | | with the signer of the | | |||
| | | | | content. This header | | | | | | content. The "alg" parameter | | |||
| | | | | parameter is REQUIRED. | | | | | | value is case sensitive. | | |||
| | | | | This header parameter is | | ||||
| | | | | REQUIRED. | | ||||
| | typ | string | String | The "typ" (type) header | | | typ | string | String | The "typ" (type) header | | |||
| | | | | parameter is used to declare | | | | | | parameter is used to declare | | |||
| | | | | the type of the signed | | | | | | the type of the signed | | |||
| | | | | content. This header | | | | | | content. The "typ" value is | | |||
| | | | | case sensitive. This header | | ||||
| | | | | parameter is OPTIONAL. | | | | | | parameter is OPTIONAL. | | |||
| | jku | string | URL | The "jku" (JSON Key URL) | | | jku | string | URL | The "jku" (JSON Key URL) | | |||
| | | | | header parameter is a URL | | | | | | header parameter is a URL | | |||
| | | | | that points to JSON-encoded | | | | | | that points to JSON-encoded | | |||
| | | | | public key certificates that | | | | | | public key certificates that | | |||
| | | | | can be used to validate the | | | | | | can be used to validate the | | |||
| | | | | signature. The specification | | | | | | signature. The specification | | |||
| | | | | for this encoding is TBD. | | | | | | for this encoding is TBD. | | |||
| | | | | This header parameter is | | | | | | This header parameter is | | |||
| | | | | OPTIONAL. | | | | | | OPTIONAL. | | |||
| skipping to change at page 8, line 21 ¶ | skipping to change at page 8, line 21 ¶ | |||
| | | | | a change of key to | | | | | | a change of key to | | |||
| | | | | recipients. Omitting this | | | | | | recipients. Omitting this | | |||
| | | | | parameter is equivalent to | | | | | | parameter is equivalent to | | |||
| | | | | setting it to an empty | | | | | | setting it to an empty | | |||
| | | | | string. The interpretation | | | | | | string. The interpretation | | |||
| | | | | of the contents of the "kid" | | | | | | of the contents of the "kid" | | |||
| | | | | parameter is unspecified. | | | | | | parameter is unspecified. | | |||
| | | | | This header parameter is | | | | | | This header parameter is | | |||
| | | | | OPTIONAL. | | | | | | OPTIONAL. | | |||
| | x5u | string | URL | The "x5u" (X.509 URL) header | | | x5u | string | URL | The "x5u" (X.509 URL) header | | |||
| | | | | parameter is a URL that | | | | | | parameter is a URL utilizing | | |||
| | | | | TLS RFC 5785 [RFC5785] that | | ||||
| | | | | points to an X.509 public key | | | | | | points to an X.509 public key | | |||
| | | | | certificate that can be used | | | | | | certificate or certificate | | |||
| | | | | to validate the signature. | | | | | | chain that can be used to | | |||
| | | | | This certificate MUST conform | | | | | | validate the signature. This | | |||
| | | | | to RFC 5280 [RFC5280]. This | | | | | | certificate or certificate | | |||
| | | | | header parameter is OPTIONAL. | | | | | | chain MUST use the PEM | | |||
| | | | | encoding RFC 1421 [RFC1421] | | ||||
| | | | | and MUST conform to RFC 5280 | | ||||
| | | | | [RFC5280]. This header | | ||||
| | | | | parameter is OPTIONAL. | | ||||
| | x5t | string | String | The "x5t" (x.509 certificate | | | x5t | string | String | The "x5t" (x.509 certificate | | |||
| | | | | thumbprint) header parameter | | | | | | thumbprint) header parameter | | |||
| | | | | provides a base64url encoded | | | | | | provides a base64url encoded | | |||
| | | | | SHA-256 thumbprint (a.k.a. | | | | | | SHA-1 thumbprint (a.k.a. | | |||
| | | | | digest) of the DER encoding | | | | | | digest) of the DER encoding | | |||
| | | | | of an X.509 certificate that | | | | | | of an X.509 certificate that | | |||
| | | | | can be used to match a | | | | | | can be used to match the | | |||
| | | | | certificate. This header | | | | | | certificate. This header | | |||
| | | | | parameter is OPTIONAL. | | | | | | parameter is OPTIONAL. | | |||
| +-----------+--------+--------------+-------------------------------+ | +-----------+--------+--------------+-------------------------------+ | |||
| Table 1: Reserved Header Parameter Definitions | Table 1: Reserved Header Parameter Definitions | |||
| Additional reserved header parameter names MAY be defined via the | Additional reserved header parameter names MAY be defined via the | |||
| IANA JSON Web Signature Header Parameters registry, as per Section 8. | IANA JSON Web Signature Header Parameters registry, as per Section 8. | |||
| The syntax values used above are defined as follows: | The syntax values used above are defined as follows: | |||
| skipping to change at page 11, line 37 ¶ | skipping to change at page 11, line 37 ¶ | |||
| 6. Base64url encoding as used by JWSs | 6. Base64url encoding as used by JWSs | |||
| JWSs make use of the base64url encoding as defined in RFC 4648 | JWSs make use of the base64url encoding as defined in RFC 4648 | |||
| [RFC4648]. As allowed by Section 3.2 of the RFC, this specification | [RFC4648]. As allowed by Section 3.2 of the RFC, this specification | |||
| mandates that base64url encoding when used with JWSs MUST NOT use | mandates that base64url encoding when used with JWSs MUST NOT use | |||
| padding. The reason for this restriction is that the padding | padding. The reason for this restriction is that the padding | |||
| character ('=') is not URL safe. | character ('=') is not URL safe. | |||
| For notes on implementing base64url encoding without padding, see | For notes on implementing base64url encoding without padding, see | |||
| Appendix B. | Appendix C. | |||
| 7. Signing JWSs with Cryptographic Algorithms | 7. Signing JWSs with Cryptographic Algorithms | |||
| JWSs use specific cryptographic algorithms to sign the contents of | JWSs use specific cryptographic algorithms to sign the contents of | |||
| the JWS Header Input and the JWS Payload Input. The use of the | the JWS Header Input and the JWS Payload Input. The use of the | |||
| following algorithms for producing JWSs is defined in this section. | following algorithms for producing JWSs is defined in this section. | |||
| The table below is the list of "alg" header parameter values reserved | The table below is the list of "alg" header parameter values reserved | |||
| by this specification, each of which is explained in more detail in | by this specification, each of which is explained in more detail in | |||
| the following sections: | the following sections: | |||
| skipping to change at page 12, line 25 ¶ | skipping to change at page 12, line 25 ¶ | |||
| | ES256 | ECDSA using P-256 curve and SHA-256 hash | | | ES256 | ECDSA using P-256 curve and SHA-256 hash | | |||
| | | algorithm | | | | algorithm | | |||
| | ES384 | ECDSA using P-384 curve and SHA-384 hash | | | ES384 | ECDSA using P-384 curve and SHA-384 hash | | |||
| | | algorithm | | | | algorithm | | |||
| | ES512 | ECDSA using P-521 curve and SHA-512 hash | | | ES512 | ECDSA using P-521 curve and SHA-512 hash | | |||
| | | algorithm | | | | algorithm | | |||
| +--------------------+----------------------------------------------+ | +--------------------+----------------------------------------------+ | |||
| Table 3: JSON Web Signature Reserved Algorithm Values | Table 3: JSON Web Signature Reserved Algorithm Values | |||
| Of these algorithms, only HMAC SHA-256 and RSA SHA-256 MUST be | See Appendix B for a table cross-referencing the "alg" values used in | |||
| implemented by conforming implementations. It is RECOMMENDED that | this specification with the equivalent identifiers used by other | |||
| implementations also support the ECDSA P-256 SHA-256 algorithm. | standards and software packages. | |||
| Of these algorithms, only HMAC SHA-256 MUST be implemented by | ||||
| conforming implementations. It is RECOMMENDED that implementations | ||||
| also support the RSA SHA-256 and ECDSA P-256 SHA-256 algorithms. | ||||
| Support for other algorithms is OPTIONAL. | Support for other algorithms is OPTIONAL. | |||
| The signed content for a JWS is the same for all algorithms: the | The signed content for a JWS is the same for all algorithms: the | |||
| concatenation of the JWS Header Input, a period ('.') character, and | concatenation of the JWS Header Input, a period ('.') character, and | |||
| the JWS Payload Input. This character sequence is referred to as the | the JWS Payload Input. This character sequence is referred to as the | |||
| JWS Signing Input. Note that if the JWS represents a JWT, this | JWS Signing Input. Note that if the JWS represents a JWT, this | |||
| corresponds to the portion of the JWT representation preceding the | corresponds to the portion of the JWT representation preceding the | |||
| second period character. The UTF-8 representation of the JWS Signing | second period character. The UTF-8 representation of the JWS Signing | |||
| Input is passed to the respective signing algorithms. | Input is passed to the respective signing algorithms. | |||
| 7.1. Creating a JWS with HMAC SHA-256 | 7.1. Creating a JWS with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 | |||
| Hash based Message Authentication Codes (HMACs) enable one to use a | Hash based Message Authentication Codes (HMACs) enable one to use a | |||
| secret plus a cryptographic hash function to generate a Message | secret plus a cryptographic hash function to generate a Message | |||
| Authentication Code (MAC). This can be used to demonstrate that the | Authentication Code (MAC). This can be used to demonstrate that the | |||
| MAC matches the hashed content, in this case the JWS Signing Input, | MAC matches the hashed content, in this case the JWS Signing Input, | |||
| which therefore demonstrates that whoever generated the MAC was in | which therefore demonstrates that whoever generated the MAC was in | |||
| possession of the secret. | possession of the secret. The means of exchanging the shared key is | |||
| outside the scope of this specification. | ||||
| The algorithm for implementing and validating HMACs is provided in | The algorithm for implementing and validating HMACs is provided in | |||
| RFC 2104 [RFC2104]. Although any HMAC can be used with JWSs, this | RFC 2104 [RFC2104]. This section defines the use of the HMAC SHA- | |||
| section defines the use of the SHA-256 cryptographic hash function as | 256, HMAC SHA-384, and HMAC SHA-512 cryptographic hash functions as | |||
| defined in FIPS 180-3 [FIPS.180-3]. The reserved "alg" header | defined in FIPS 180-3 [FIPS.180-3]. The reserved "alg" header | |||
| parameter value "HS256" is used in the JWS Header Input to indicate | parameter values "HS256", "HS384", and "HS512" are used in the JWS | |||
| that the JWS Crypto Output contains a base64url encoded HMAC SHA-256 | Header Input to indicate that the JWS Crypto Output contains a | |||
| HMAC value. | base64url encoded HMAC value using the respective hash function. | |||
| The HMAC SHA-256 MAC is generated as follows: | The HMAC SHA-256 MAC is generated as follows: | |||
| 1. Apply the HMAC SHA-256 algorithm to the UTF-8 representation of | 1. Apply the HMAC SHA-256 algorithm to the UTF-8 representation of | |||
| the JWS Signing Input using the shared key to produce an HMAC. | the JWS Signing Input using the shared key to produce an HMAC. | |||
| 2. Base64url encode the HMAC as defined in this document. | 2. Base64url encode the HMAC, as defined in this specification. | |||
| The output is the JWS Crypto Output for that JWS. | The output is the JWS Crypto Output for that JWS. | |||
| The HMAC SHA-256 MAC for a JWS is validated as follows: | The HMAC SHA-256 MAC for a JWS is validated as follows: | |||
| 1. Apply the HMAC SHA-256 algorithm to the UTF-8 representation of | 1. Apply the HMAC SHA-256 algorithm to the UTF-8 representation of | |||
| the JWS Signing Input of the JWS using the shared key. | the JWS Signing Input of the JWS using the shared key. | |||
| 2. Base64url encode the previously generated HMAC as defined in this | 2. Base64url encode the previously generated HMAC, as defined in | |||
| document. | this specification. | |||
| 3. If the JWS Crypto Output and the previously calculated value | 3. If the JWS Crypto Output and the previously calculated value | |||
| exactly match, then one has confirmation that the key was used to | exactly match, then one has confirmation that the key was used to | |||
| generate the HMAC on the JWS and that the contents of the JWS | generate the HMAC on the JWS and that the contents of the JWS | |||
| have not be tampered with. | have not be tampered with. | |||
| 4. If the validation fails, the signed content MUST be rejected. | 4. If the validation fails, the signed content MUST be rejected. | |||
| Signing with the HMAC SHA-384 and HMAC SHA-512 algorithms is | Signing with the HMAC SHA-384 and HMAC SHA-512 algorithms is | |||
| performed identically to the procedure for HMAC SHA-256 - just with | performed identically to the procedure for HMAC SHA-256 - just with | |||
| correspondingly longer key and result values. | correspondingly longer key and result values. | |||
| 7.2. Creating a JWS with RSA SHA-256 | 7.2. Creating a JWS with RSA SHA-256, RSA SHA-384, or RSA SHA-512 | |||
| This section defines the use of the RSASSA-PKCS1-v1_5 signature | This section defines the use of the RSASSA-PKCS1-v1_5 signature | |||
| algorithm as defined in RFC 3447 [RFC3447], Section 8.2 (commonly | algorithm as defined in RFC 3447 [RFC3447], Section 8.2 (commonly | |||
| known as PKCS#1), using SHA-256 as the hash function. Note that the | known as PKCS#1), using SHA-256, SHA-384, or SHA-512 as the hash | |||
| use of the RSASSA-PKCS1-v1_5 algorithm is described in FIPS 186-3 | function. The RSASSA-PKCS1-v1_5 algorithm is described in FIPS 186-3 | |||
| [FIPS.186-3], Section 5.5, as is the SHA-256 cryptographic hash | [FIPS.186-3], Section 5.5, and the SHA-256, SHA-384, and SHA-512 | |||
| function, which is defined in FIPS 180-3 [FIPS.180-3]. The reserved | cryptographic hash functions are defined in FIPS 180-3 [FIPS.180-3]. | |||
| "alg" header parameter value "RS256" is used in the JWS Header Input | The reserved "alg" header parameter values "RS256", "RS384", and | |||
| to indicate that the JWS Crypto Output contains an RSA SHA-256 | "RS512" are used in the JWS Header Input to indicate that the JWS | |||
| signature. | Crypto Output contains a base64url encoded RSA signature using the | |||
| respective hash function. | ||||
| The public keys employed may be retrieved using Header Parameter | ||||
| methods described in Section 4.1 or may be distributed using methods | ||||
| that are outside the scope of this specification. | ||||
| A 2048-bit or longer key length MUST be used with this algorithm. | A 2048-bit or longer key length MUST be used with this algorithm. | |||
| The RSA SHA-256 signature is generated as follows: | The RSA SHA-256 signature is generated as follows: | |||
| 1. Let K be the signer's RSA private key and let M be the UTF-8 | 1. Generate a digital signature of the UTF-8 representation of the | |||
| representation of the JWS Signing Input. | JWS Signing Input using RSASSA-PKCS1-V1_5-SIGN and the SHA-256 | |||
| hash function with the desired private key. The output will be a | ||||
| 2. Compute the octet string S = RSASSA-PKCS1-V1_5-SIGN (K, M) using | byte array. | |||
| SHA-256 as the hash function. | ||||
| 3. Base64url encode the octet string S, as defined in this document. | 2. Base64url encode the byte array, as defined in this | |||
| specification. | ||||
| The output is the JWS Crypto Output for that JWS. | The output is the JWS Crypto Output for that JWS. | |||
| The RSA SHA-256 signature for a JWS is validated as follows: | The RSA SHA-256 signature for a JWS is validated as follows: | |||
| 1. Take the JWS Crypto Output and base64url decode it into an octet | 1. Take the JWS Crypto Output and base64url decode it into a byte | |||
| string S. If decoding fails, then the signed content MUST be | array. If decoding fails, the signed content MUST be rejected. | |||
| rejected. | ||||
| 2. Let M be the UTF-8 representation of the JWS Signing Input and | ||||
| let (n, e) be the public key corresponding to the private key | ||||
| used by the signer. | ||||
| 3. Validate the signature with RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, | 2. Submit the UTF-8 representation of the JWS Signing Input and the | |||
| S) using SHA-256 as the hash function. | public key corresponding to the private key used by the signer to | |||
| the RSASSA-PKCS1-V1_5-VERIFY algorithm using SHA-256 as the hash | ||||
| function. | ||||
| 4. If the validation fails, the signed content MUST be rejected. | 3. If the validation fails, the signed content MUST be rejected. | |||
| Signing with the RSA SHA-384 and RSA SHA-512 algorithms is performed | Signing with the RSA SHA-384 and RSA SHA-512 algorithms is performed | |||
| identically to the procedure for RSA SHA-256 - just with | identically to the procedure for RSA SHA-256 - just with | |||
| correspondingly longer key and result values. | correspondingly longer key and result values. | |||
| 7.3. Creating a JWS with ECDSA P-256 SHA-256 | 7.3. Creating a JWS with ECDSA P-256 SHA-256, ECDSA P-384 SHA-384, or | |||
| ECDSA P-521 SHA-512 | ||||
| The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by | The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by | |||
| FIPS 186-3 [FIPS.186-3]. ECDSA provides for the use of Elliptic | FIPS 186-3 [FIPS.186-3]. ECDSA provides for the use of Elliptic | |||
| Curve cryptography, which is able to provide equivalent security to | Curve cryptography, which is able to provide equivalent security to | |||
| RSA cryptography but using shorter key lengths and with greater | RSA cryptography but using shorter key lengths and with greater | |||
| processing speed. This means that ECDSA signatures will be | processing speed. This means that ECDSA signatures will be | |||
| substantially smaller in terms of length than equivalently strong RSA | substantially smaller in terms of length than equivalently strong RSA | |||
| Digital Signatures. | Digital Signatures. | |||
| This specification defines the use of ECDSA with the P-256 curve and | This specification defines the use of ECDSA with the P-256 curve and | |||
| the SHA-256 cryptographic hash function. The P-256 curve is also | the SHA-256 cryptographic hash function, ECDSA with the P-384 curve | |||
| defined in FIPS 186-3. The reserved "alg" header parameter value | and the SHA-384 hash function, and ECDSA with the P-521 curve and the | |||
| "ES256" is used in the JWS Header Input to indicate that the JWS | SHA-512 hash function. The P-256, P-384, and P-521 curves are also | |||
| Crypto Output contains an ECDSA P-256 SHA-256 signature. | defined in FIPS 186-3. The reserved "alg" header parameter values | |||
| "ES256", "ES384", and "ES512" are used in the JWS Header Input to | ||||
| indicate that the JWS Crypto Output contains a based64url encoded | ||||
| ECDSA P-256 SHA-256, ECDSA P-384 SHA-384, or ECDSA P-521 SHA-512 | ||||
| signature, respectively. | ||||
| The public keys employed may be retrieved using Header Parameter | ||||
| methods described in Section 4.1 or may be distributed using methods | ||||
| that are outside the scope of this specification. | ||||
| A JWS is signed with an ECDSA P-256 SHA-256 signature as follows: | A JWS is signed with an ECDSA P-256 SHA-256 signature as follows: | |||
| 1. Generate a digital signature of the UTF-8 representation of the | 1. Generate a digital signature of the UTF-8 representation of the | |||
| JWS Signing Input using ECDSA P-256 SHA-256 with the desired | JWS Signing Input using ECDSA P-256 SHA-256 with the desired | |||
| private key. The output will be the EC point (R, S), where R and | private key. The output will be the EC point (R, S), where R and | |||
| S are unsigned integers. | S are unsigned integers. | |||
| 2. Turn R and S into byte arrays in big endian order. Each array | 2. Turn R and S into byte arrays in big endian order. Each array | |||
| will be 32 bytes long. | will be 32 bytes long. | |||
| 3. Concatenate the two byte arrays in the order R and then S. | 3. Concatenate the two byte arrays in the order R and then S. | |||
| 4. Base64url encode the 64 byte array as defined in this | 4. Base64url encode the 64 byte array, as defined in this | |||
| specification. | specification. | |||
| The output is the JWS Crypto Output for the JWS. | The output is the JWS Crypto Output for the JWS. | |||
| The ECDSA P-256 SHA-256 signature for a JWS is validated as follows: | The ECDSA P-256 SHA-256 signature for a JWS is validated as follows: | |||
| 1. Take the JWS Crypto Output and base64url decode it into a byte | 1. Take the JWS Crypto Output and base64url decode it into a byte | |||
| array. If decoding fails, the signed content MUST be rejected. | array. If decoding fails, the signed content MUST be rejected. | |||
| 2. The output of the base64url decoding MUST be a 64 byte array. | 2. The output of the base64url decoding MUST be a 64 byte array. | |||
| skipping to change at page 16, line 44 ¶ | skipping to change at page 17, line 16 ¶ | |||
| issues we have especially around comparison of names. For instance, | issues we have especially around comparison of names. For instance, | |||
| comparisons of header parameter names and other parameters must occur | comparisons of header parameter names and other parameters must occur | |||
| after they are unescaped. Need to also put in text about: Importance | after they are unescaped. Need to also put in text about: Importance | |||
| of keeping secrets secret. Rotating keys. Strengths and weaknesses | of keeping secrets secret. Rotating keys. Strengths and weaknesses | |||
| of the different algorithms. | of the different algorithms. | |||
| TBD: Need to put in text about why strict JSON validation is | TBD: Need to put in text about why strict JSON validation is | |||
| necessary. Basically, that if malformed JSON is received then the | necessary. Basically, that if malformed JSON is received then the | |||
| intent of the sender is impossible to reliably discern. | intent of the sender is impossible to reliably discern. | |||
| TBD: Write security considerations about the implications of using a | ||||
| SHA-1 hash (for compatibility reasons) for the "x5t" (x.509 | ||||
| certificate thumbprint). | ||||
| 9.1. Unicode Comparison Security Issues | 9.1. Unicode Comparison Security Issues | |||
| Header parameter names in JWSs are Unicode strings. For security | Header parameter names in JWSs are Unicode strings. For security | |||
| reasons, the representations of these names must be compared verbatim | reasons, the representations of these names must be compared verbatim | |||
| after performing any escape processing (as per RFC 4627 [RFC4627], | after performing any escape processing (as per RFC 4627 [RFC4627], | |||
| Section 2.5). | Section 2.5). | |||
| This means, for instance, that these JSON strings must compare as | This means, for instance, that these JSON strings must compare as | |||
| being equal ("sig", "\u0073ig"), whereas these must all compare as | being equal ("sig", "\u0073ig"), whereas these must all compare as | |||
| being not equal to the first set or to each other ("SIG", "Sig", | being not equal to the first set or to each other ("SIG", "Sig", | |||
| skipping to change at page 17, line 42 ¶ | skipping to change at page 18, line 19 ¶ | |||
| different endpoints that "knows" about each endpoints' private | different endpoints that "knows" about each endpoints' private | |||
| parameters. | parameters. | |||
| o Clarify the optional ability to provide type information in the | o Clarify the optional ability to provide type information in the | |||
| JWS header. Specifically, clarify the intended use of the "typ" | JWS header. Specifically, clarify the intended use of the "typ" | |||
| Header Parameter, whether it conveys syntax or semantics, and | Header Parameter, whether it conveys syntax or semantics, and | |||
| indeed, whether this is the right approach. Also clarify the | indeed, whether this is the right approach. Also clarify the | |||
| relationship between these type values and MIME [RFC2045] types. | relationship between these type values and MIME [RFC2045] types. | |||
| o Clarify the semantics of the "kid" (key ID) header parameter. | o Clarify the semantics of the "kid" (key ID) header parameter. | |||
| Open issues include: What happens if a kid header is received with | Open issues include: What happens if a "kid" header is received | |||
| an unrecognized value? Is that an error? Should it be treated as | with an unrecognized value? Is that an error? Should it be | |||
| if it's empty? What happens if the header has a recognized value | treated as if it's empty? What happens if the header has a | |||
| but the value doesn't match the key associated with that value, | recognized value but the value doesn't match the key associated | |||
| but it does match another key that is associated with the issuer? | with that value, but it does match another key that is associated | |||
| Is that an error? | with the issuer? Is that an error? | |||
| o The "x5t" parameter is currently specified as "a base64url encoded | ||||
| SHA-256 thumbprint of the DER encoding of an X.509 certificate". | ||||
| SHA-1 was traditionally used for certificate digests but | ||||
| collisions are possible to create and can be used for denial of | ||||
| service attacks within multi-tenant services. We need to | ||||
| understand the compatibility issues of using SHA-256 thumbprints | ||||
| instead. We also likely want to specify the digest algorithm | ||||
| explicitly. | ||||
| o Several people have objected to the requirement for implementing | o Consider whether a key type parameter should also be introduced. | |||
| RSA SHA-256, some because they will only be using HMACs and | ||||
| symmetric keys, and others because they only want to use ECDSA | ||||
| when using asymmetric keys, either for security or key length | ||||
| reasons, or both. I believe therefore, that we should consider | ||||
| changing the MUST for RSA SHA-256 to RECOMMENDED. | ||||
| o Since RFC 3447 Section 8 explicitly calls for people NOT to adopt | o Since RFC 3447 Section 8 explicitly calls for people NOT to adopt | |||
| RSASSA-PKCS1 for new applications and instead requests that people | RSASSA-PKCS1 for new applications and instead requests that people | |||
| transition to RSASSA-PSS, we probably need some Security | transition to RSASSA-PSS, we probably need some Security | |||
| Considerations text explaining why RSASSA-PKCS1 is being used | Considerations text explaining why RSASSA-PKCS1 is being used | |||
| (it's what's commonly implemented) and what the potential | (it's what's commonly implemented) and what the potential | |||
| consequences are. | consequences are. | |||
| o Generalize the normative text on signing algorithms so that the | ||||
| descriptions apply equally to the use of various key lengths - not | ||||
| just HMAC SHA-256, RSA SHA-256, and ECDSA P-256 SHA-256. | ||||
| o Add a table cross-referencing the algorithm name strings used in | ||||
| standard software packages and specifications. | ||||
| o Add Security Considerations text on timing attacks. | o Add Security Considerations text on timing attacks. | |||
| o Finish the Security Considerations section. | o Finish the Security Considerations section. | |||
| o Sort out what to do with the IANA registries if this is first | o Sort out what to do with the IANA registries if this is first | |||
| standardized as an OpenID specification. | standardized as an OpenID specification. | |||
| o Write the related specification for encoding public keys using | o Write the related specification for encoding public keys using | |||
| JSON, as per the agreement documented at | JSON, as per the agreement documented at | |||
| http://self-issued.info/?p=390. This will be used by the "jku" | http://self-issued.info/?p=390. This will be used by the "jku" | |||
| (JSON Key URL) header parameter. | (JSON Key URL) header parameter. | |||
| o Write the companion encryption specification, per the agreements | o Finish the companion encryption specification, per the agreements | |||
| documented at http://self-issued.info/?p=378. | documented at http://self-issued.info/?p=378. | |||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [FIPS.180-3] | [FIPS.180-3] | |||
| National Institute of Standards and Technology, "Secure | National Institute of Standards and Technology, "Secure | |||
| Hash Standard (SHS)", FIPS PUB 180-3, October 2008. | Hash Standard (SHS)", FIPS PUB 180-3, October 2008. | |||
| [FIPS.186-3] | [FIPS.186-3] | |||
| National Institute of Standards and Technology, "Digital | National Institute of Standards and Technology, "Digital | |||
| Signature Standard (DSS)", FIPS PUB 186-3, June 2009. | Signature Standard (DSS)", FIPS PUB 186-3, June 2009. | |||
| [JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, | [JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, | |||
| J., Sakimura, N., and P. Tarjan, "JSON Web Token (JWT)", | J., Sakimura, N., and P. Tarjan, "JSON Web Token (JWT)", | |||
| March 2011. | March 2011. | |||
| [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic | ||||
| Mail: Part I: Message Encryption and Authentication | ||||
| Procedures", RFC 1421, February 1993. | ||||
| [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | |||
| Resource Locators (URL)", RFC 1738, December 1994. | Resource Locators (URL)", RFC 1738, December 1994. | |||
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
| Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
| Bodies", RFC 2045, November 1996. | Bodies", RFC 2045, November 1996. | |||
| [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
| Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||
| February 1997. | February 1997. | |||
| skipping to change at page 20, line 14 ¶ | skipping to change at page 20, line 17 ¶ | |||
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
| May 2008. | May 2008. | |||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
| 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. | |||
| [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known | ||||
| Uniform Resource Identifiers (URIs)", RFC 5785, | ||||
| April 2010. | ||||
| [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. | |||
| 11.2. Informative References | 11.2. Informative References | |||
| [CanvasApp] | [CanvasApp] | |||
| Facebook, "Canvas Applications", 2010. | Facebook, "Canvas Applications", 2010. | |||
| [JCA] Oracle, "Java Cryptography Architecture", 2011. | ||||
| [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., Bradley, J., and N. Sakimura, "JSON Web | [JWE] Jones, M., Bradley, J., and N. Sakimura, "JSON Web | |||
| Encryption (JWE)", March 2011. | Encryption (JWE)", March 2011. | |||
| [MagicSignatures] | [MagicSignatures] | |||
| Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic | Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic | |||
| Signatures", August 2010. | Signatures", August 2010. | |||
| [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup | [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup | |||
| Language) XML-Signature Syntax and Processing", RFC 3275, | Language) XML-Signature Syntax and Processing", RFC 3275, | |||
| March 2002. | March 2002. | |||
| 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], note that the payload can | all represent JSON Web Tokens (JWTs) [JWT], the payload can be any | |||
| 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 | |||
| The following example JSON header object declares that the data | The following example JSON header object declares that the data | |||
| structure is a JSON Web Token (JWT) [JWT] and the JWS Signing Input | structure is a JSON Web Token (JWT) [JWT] and the JWS Signing Input | |||
| is signed using the HMAC SHA-256 algorithm. Note that white space is | is signed using the HMAC SHA-256 algorithm. Note that white space is | |||
| explicitly allowed in Decoded JWS Header Input strings and no | explicitly allowed in Decoded JWS Header Input strings and no | |||
| canonicalization is performed before encoding. | canonicalization is performed before encoding. | |||
| skipping to change at page 29, line 29 ¶ | skipping to change at page 29, line 29 ¶ | |||
| S. We then pass (x, y), (R, S) and the UTF-8 representation of the | S. We then pass (x, y), (R, S) and the UTF-8 representation of the | |||
| JWS Signing Input to an ECDSA signature verifier that has been | JWS Signing Input to an ECDSA signature verifier that has been | |||
| configured to use the P-256 curve with the SHA-256 hash function. | configured to use the P-256 curve with the SHA-256 hash function. | |||
| As explained in Section 7.3, the use of the k value in ECDSA means | As explained in Section 7.3, the use of the k value in ECDSA means | |||
| that we cannot validate the correctness of the signature in the same | that we cannot validate the correctness of the signature in the same | |||
| way we validated the correctness of the HMAC. Instead, | way we validated the correctness of the HMAC. Instead, | |||
| implementations MUST use an ECDSA validator to validate the | implementations MUST use an ECDSA validator to validate the | |||
| signature. | signature. | |||
| Appendix B. Notes on implementing base64url encoding without padding | Appendix B. Algorithm Identifier Cross-Reference | |||
| This appendix contains a table cross-referencing the "alg" values | ||||
| used in this specification with the equivalent identifiers used by | ||||
| other standards and software packages. See XML DSIG [RFC3275] and | ||||
| Java Cryptography Architecture [JCA] for more information about the | ||||
| names defined by those documents. | ||||
| +-------+-----+----------------------------+----------+-------------+ | ||||
| | Algor | JWS | XML DSIG | JCA | OID | | ||||
| | ithm | | | | | | ||||
| +-------+-----+----------------------------+----------+-------------+ | ||||
| | HMAC | HS2 | http://www.w3.org/2001/04/ | HmacSHA2 | 1.2.840.113 | | ||||
| | using | 56 | xmldsig-more#hmac-sha256 | 56 | 549.2.9 | | ||||
| | SHA-2 | | | | | | ||||
| | 56 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | HMAC | HS3 | http://www.w3.org/2001/04/ | HmacSHA3 | 1.2.840.113 | | ||||
| | using | 84 | xmldsig-more#hmac-sha384 | 84 | 549.2.10 | | ||||
| | SHA-3 | | | | | | ||||
| | 84 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | HMAC | HS5 | http://www.w3.org/2001/04/ | HmacSHA5 | 1.2.840.113 | | ||||
| | using | 12 | xmldsig-more#hmac-sha512 | 12 | 549.2.11 | | ||||
| | SHA-5 | | | | | | ||||
| | 12 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | RSA | RS2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.113 | | ||||
| | using | 56 | xmldsig-more#rsa-sha256 | thRSA | 549.1.1.11 | | ||||
| | SHA-2 | | | | | | ||||
| | 56 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | RSA | RS3 | http://www.w3.org/2001/04/ | SHA384wi | 1.2.840.113 | | ||||
| | using | 84 | xmldsig-more#rsa-sha384 | thRSA | 549.1.1.12 | | ||||
| | SHA-3 | | | | | | ||||
| | 84 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | RSA | RS5 | http://www.w3.org/2001/04/ | SHA512wi | 1.2.840.113 | | ||||
| | using | 12 | xmldsig-more#rsa-sha512 | thRSA | 549.1.1.13 | | ||||
| | SHA-5 | | | | | | ||||
| | 12 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | ECDSA | ES2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.100 | | ||||
| | using | 56 | xmldsig-more#ecdsa-sha256 | thECDSA | 45.3.1.7 | | ||||
| | P-256 | | | | | | ||||
| | curve | | | | | | ||||
| | and | | | | | | ||||
| | SHA-2 | | | | | | ||||
| | 56 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | ECDSA | ES3 | http://www.w3.org/2001/04/ | SHA384wi | 1.3.132.0.3 | | ||||
| | using | 84 | xmldsig-more#ecdsa-sha384 | thECDSA | 4 | | ||||
| | P-384 | | | | | | ||||
| | curve | | | | | | ||||
| | and | | | | | | ||||
| | SHA-3 | | | | | | ||||
| | 84 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| | ECDSA | ES5 | http://www.w3.org/2001/04/ | SHA512wi | 1.3.132.0.3 | | ||||
| | using | 12 | xmldsig-more#ecdsa-sha512 | thECDSA | 5 | | ||||
| | P-521 | | | | | | ||||
| | curve | | | | | | ||||
| | and | | | | | | ||||
| | SHA-5 | | | | | | ||||
| | 12 | | | | | | ||||
| | hash | | | | | | ||||
| | algo | | | | | | ||||
| | rithm | | | | | | ||||
| +-------+-----+----------------------------+----------+-------------+ | ||||
| Table 4: Algorithm Identifier Cross-Reference | ||||
| Appendix C. Notes on implementing base64url encoding without padding | ||||
| This appendix describes how to implement base64url encoding and | This appendix describes how to implement base64url encoding and | |||
| decoding functions without padding based upon standard base64 | decoding functions without padding based upon standard base64 | |||
| encoding and decoding functions that do use padding. | encoding and decoding functions that do use padding. | |||
| To be concrete, example C# code implementing these functions is shown | To be concrete, example C# code implementing these functions is shown | |||
| below. Similar code could be used in other languages. | below. Similar code could be used in other languages. | |||
| static string base64urlencode(byte [] arg) | static string base64urlencode(byte [] arg) | |||
| { | { | |||
| skipping to change at page 30, line 45 ¶ | skipping to change at page 32, line 45 ¶ | |||
| '=' padding characters are added; if the length mod 4 is 3, one '=' | '=' padding characters are added; if the length mod 4 is 3, one '=' | |||
| padding character is added; if the length mod 4 is 1, the input is | padding character is added; if the length mod 4 is 1, the input is | |||
| malformed. | malformed. | |||
| An example correspondence between unencoded and encoded values | An example correspondence between unencoded and encoded values | |||
| follows. The byte sequence below encodes into the string below, | follows. The byte sequence below encodes into the string below, | |||
| which when decoded, reproduces the byte sequence. | which when decoded, reproduces the byte sequence. | |||
| 3 236 255 224 193 | 3 236 255 224 193 | |||
| A-z_4ME | A-z_4ME | |||
| Appendix C. 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. | Applications [CanvasApp], all of which influenced this draft. | |||
| Appendix D. Document History | Appendix E. Document History | |||
| -01 | ||||
| o Changed RSA SHA-256 from MUST be supported to RECOMMENDED that it | ||||
| be supported. Rationale: Several people have objected to the | ||||
| requirement for implementing RSA SHA-256, some because they will | ||||
| only be using HMACs and symmetric keys, and others because they | ||||
| only want to use ECDSA when using asymmetric keys, either for | ||||
| security or key length reasons, or both. | ||||
| o Clarified that "x5u" is an HTTPS URL referencing a PEM-encoded | ||||
| certificate or certificate chain. | ||||
| o Clarified that the "alg" parameter value is case sensitive. | ||||
| o Changed "x5t" (x.509 certificate thumbprint) to use a SHA-1 hash, | ||||
| rather than a SHA-256 hash, for compatibility reasons. | ||||
| -00 | -00 | |||
| o Created first signature draft using content split from | o Created first signature draft using content split from | |||
| draft-jones-json-web-token-01. This split introduced no semantic | draft-jones-json-web-token-01. This split introduced no semantic | |||
| changes. | changes. | |||
| Authors' Addresses | Authors' Addresses | |||
| Michael B. Jones | Michael B. Jones | |||
| End of changes. 46 change blocks. | ||||
| 112 lines changed or deleted | 236 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||