draft-ietf-jose-json-web-algorithms-11.txt   draft-ietf-jose-json-web-algorithms-12.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track May 28, 2013 Intended status: Standards Track July 11, 2013
Expires: November 29, 2013 Expires: January 12, 2014
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-11 draft-ietf-jose-json-web-algorithms-12
Abstract Abstract
The JSON Web Algorithms (JWA) specification enumerates cryptographic The JSON Web Algorithms (JWA) specification enumerates cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK)
specifications. specifications.
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 29, 2013. This Internet-Draft will expire on January 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 29 skipping to change at page 2, line 29
3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA 3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA
P-384 SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . 11 P-384 SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . 11
3.5. Digital Signature with RSASSA-PSS and SHA-256 or 3.5. Digital Signature with RSASSA-PSS and SHA-256 or
SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . . 13 SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 14 3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 14
3.7. Additional Digital Signature/MAC Algorithms and 3.7. Additional Digital Signature/MAC Algorithms and
Parameters . . . . . . . . . . . . . . . . . . . . . . . . 14 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 15 4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 15
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 15 4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 15
4.2. "enc" (Encryption Method) Header Parameter Values for 4.2. "enc" (Encryption Method) Header Parameter Values for
JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 17 4.3. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 19
4.4. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 17 4.4. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 19
4.5. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 18 4.5. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 19
4.6. Direct Encryption with a Shared Symmetric Key . . . . . . 18 4.6. Direct Encryption with a Shared Symmetric Key . . . . . . 19
4.7. Key Agreement with Elliptic Curve Diffie-Hellman 4.7. Key Agreement with Elliptic Curve Diffie-Hellman
Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 18 Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 19
4.7.1. Key Derivation for "ECDH-ES" . . . . . . . . . . . . . 19 4.7.1. Header Parameters Used for ECDH Key Agreement . . . . 20
4.8. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 20 4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 20
4.8.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 20 4.7.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 20
4.8.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 20 4.7.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 20
4.8.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 20 4.7.2. Key Derivation for ECDH Key Agreement . . . . . . . . 21
4.8.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 22 4.8. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 22
4.8.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 23 4.8.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 22
4.8.4. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 23 4.8.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 23
4.8.5. Plaintext Encryption with AES_CBC_HMAC_SHA2 . . . . . 23 4.8.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 23
4.9. Plaintext Encryption with AES GCM . . . . . . . . . . . . 24 4.8.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 24
4.10. Additional Encryption Algorithms and Parameters . . . . . 24 4.8.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 25
5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 25 4.8.4. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 25
5.1. "kty" (Key Type) Parameter Values for JWK . . . . . . . . 25 4.8.5. Plaintext Encryption with AES_CBC_HMAC_SHA2 . . . . . 26
5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 25 4.9. Plaintext Encryption with AES GCM . . . . . . . . . . . . 26
5.2.1. JWK Parameters for Elliptic Curve Public Keys . . . . 25 4.10. Additional Encryption Algorithms and Parameters . . . . . 26
5.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 25 5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 27
5.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 26 5.1. "kty" (Key Type) Parameter Values for JWK . . . . . . . . 27
5.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 26 5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 28
5.2.2. JWK Parameters for Elliptic Curve Private Keys . . . . 26 5.2.1. JWK Parameters for Elliptic Curve Public Keys . . . . 28
5.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 26 5.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 28
5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 27 5.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 28
5.3.1. JWK Parameters for RSA Public Keys . . . . . . . . . . 27 5.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 28
5.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 27 5.2.2. JWK Parameters for Elliptic Curve Private Keys . . . . 29
5.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 27 5.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 29
5.3.2. JWK Parameters for RSA Private Keys . . . . . . . . . 27 5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 29
5.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 27 5.3.1. JWK Parameters for RSA Public Keys . . . . . . . . . . 29
5.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 28 5.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 29
5.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 28 5.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 29
5.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 28 5.3.2. JWK Parameters for RSA Private Keys . . . . . . . . . 30
5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 28 5.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 30
5.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 28 5.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 30
5.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 28 5.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 30
5.3.3. JWK Parameters for Symmetric Keys . . . . . . . . . . 29 5.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 30
5.3.3.1. "k" (Key Value) Parameter . . . . . . . . . . . . 29 5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 30
5.4. Additional Key Types and Parameters . . . . . . . . . . . 29 5.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 31
6.1. JSON Web Signature and Encryption Algorithms Registry . . 30 5.3.3. JWK Parameters for Symmetric Keys . . . . . . . . . . 31
6.1.1. Template . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.3.1. "k" (Key Value) Parameter . . . . . . . . . . . . 31
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 31 5.4. Additional Key Types and Parameters . . . . . . . . . . . 32
6.2. JSON Web Key Types Registry . . . . . . . . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
6.2.1. Registration Template . . . . . . . . . . . . . . . . 34 6.1. JSON Web Signature and Encryption Algorithms Registry . . 32
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 35 6.1.1. Template . . . . . . . . . . . . . . . . . . . . . . . 33
6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 35 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 33
6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 35 6.2. JSON Web Key Types Registry . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 6.2.1. Registration Template . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . . 40 6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 38
6.4. Registration of JWE Header Parameter Names . . . . . . . . 39
6.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 40
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Normative References . . . . . . . . . . . . . . . . . . . 41
8.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Digital Signature/MAC Algorithm Identifier Appendix A. Digital Signature/MAC Algorithm Identifier
Cross-Reference . . . . . . . . . . . . . . . . . . . 41 Cross-Reference . . . . . . . . . . . . . . . . . . . 44
Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 43 Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 46
Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 45 Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 48
C.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 46 C.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 49
C.2. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 47 C.2. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 50
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 48 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 51
Appendix E. Document History . . . . . . . . . . . . . . . . . . 48 Appendix E. Document History . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
The JSON Web Algorithms (JWA) specification enumerates cryptographic The JSON Web Algorithms (JWA) specification enumerates cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK) (JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK)
[JWK] specifications. All these specifications utilize JavaScript [JWK] specifications. All these specifications utilize JavaScript
Object Notation (JSON) [RFC4627] based data structures. This Object Notation (JSON) [RFC4627] based data structures. This
specification also describes the semantics and operations that are specification also describes the semantics and operations that are
specific to these algorithms and key types. specific to these algorithms and key types.
skipping to change at page 15, line 20 skipping to change at page 15, line 20
Key (CEK) and the Plaintext. This section specifies a set of Key (CEK) and the Plaintext. This section specifies a set of
specific algorithms for these purposes. specific algorithms for these purposes.
4.1. "alg" (Algorithm) Header Parameter Values for JWE 4.1. "alg" (Algorithm) Header Parameter Values for JWE
The table below is the set of "alg" (algorithm) header parameter The table below is the set of "alg" (algorithm) header parameter
values that are defined by this specification for use with JWE. values that are defined by this specification for use with JWE.
These algorithms are used to encrypt the CEK, producing the JWE These algorithms are used to encrypt the CEK, producing the JWE
Encrypted Key, or to use key agreement to agree upon the CEK. Encrypted Key, or to use key agreement to agree upon the CEK.
+----------------+---------------------------------+----------------+ +----------------+--------------------+------------+----------------+
| alg Parameter | Key Management Algorithm | Implementation | | alg Parameter | Key Management | Additional | Implementation |
| Value | | Requirements | | Value | Algorithm | Header | Requirements |
+----------------+---------------------------------+----------------+ | | | Parameters | |
| RSA1_5 | RSAES-PKCS1-V1_5 [RFC3447] | REQUIRED | +----------------+--------------------+------------+----------------+
| RSA-OAEP | RSAES using Optimal Asymmetric | OPTIONAL | | RSA1_5 | RSAES-PKCS1-V1_5 | (none) | REQUIRED |
| | Encryption Padding (OAEP) | | | | [RFC3447] | | |
| | [RFC3447], with the default | | | RSA-OAEP | RSAES using | (none) | OPTIONAL |
| | parameters specified by RFC | | | | Optimal Asymmetric | | |
| | 3447 in Section A.2.1 | | | | Encryption Padding | | |
| A128KW | Advanced Encryption Standard | RECOMMENDED | | | (OAEP) [RFC3447], | | |
| | (AES) Key Wrap Algorithm | | | | with the default | | |
| | [RFC3394] using the default | | | | parameters | | |
| | initial value specified in | | | | specified by RFC | | |
| | Section 2.2.3.1 and using 128 | | | | 3447 in Section | | |
| | bit keys | | | | A.2.1 | | |
| A256KW | AES Key Wrap Algorithm using | RECOMMENDED | | A128KW | Advanced | (none) | RECOMMENDED |
| | the default initial value | | | | Encryption | | |
| | specified in Section 2.2.3.1 | | | | Standard (AES) Key | | |
| | and using 256 bit keys | | | | Wrap Algorithm | | |
| dir | Direct use of a shared | RECOMMENDED | | | [RFC3394] using | | |
| | symmetric key as the Content | | | | the default | | |
| | Encryption Key (CEK) for the | | | | initial value | | |
| | block encryption step (rather | | | | specified in | | |
| | than using the symmetric key to | | | | Section 2.2.3.1 | | |
| | wrap the CEK) | | | | and using 128 bit | | |
| ECDH-ES | Elliptic Curve Diffie-Hellman | RECOMMENDED+ | | | keys | | |
| | Ephemeral Static [RFC6090] key | | | A256KW | AES Key Wrap | (none) | RECOMMENDED |
| | agreement using the Concat KDF, | | | | Algorithm using | | |
| | as defined in Section 5.8.1 of | | | | the default | | |
| | [NIST.800-56A], with the | | | | initial value | | |
| | agreed-upon key being used | | | | specified in | | |
| | directly as the Content | | | | Section 2.2.3.1 | | |
| | Encryption Key (CEK) (rather | | | | and using 256 bit | | |
| | than being used to wrap the | | | | keys | | |
| | CEK), as specified in | | | dir | Direct use of a | (none) | RECOMMENDED |
| | Section 4.7 | | | | shared symmetric | | |
| ECDH-ES+A128KW | Elliptic Curve Diffie-Hellman | RECOMMENDED | | | key as the Content | | |
| | Ephemeral Static key agreement | | | | Encryption Key | | |
| | per "ECDH-ES" and Section 4.7, | | | | (CEK) for the | | |
| | but where the agreed-upon key | | | | content encryption | | |
| | is used to wrap the Content | | | | step (rather than | | |
| | Encryption Key (CEK) with the | | | | using the | | |
| | "A128KW" function (rather than | | | | symmetric key to | | |
| | being used directly as the CEK) | | | | wrap the CEK) | | |
| ECDH-ES+A256KW | Elliptic Curve Diffie-Hellman | RECOMMENDED | | ECDH-ES | Elliptic Curve | "epk", | RECOMMENDED+ |
| | Ephemeral Static key agreement | | | | Diffie-Hellman | "apu", | |
| | per "ECDH-ES" and Section 4.7, | | | | Ephemeral Static | "apv" | |
| | but where the agreed-upon key | | | | [RFC6090] key | | |
| | is used to wrap the Content | | | | agreement using | | |
| | Encryption Key (CEK) with the | | | | the Concat KDF, as | | |
| | "A256KW" function (rather than | | | | defined in Section | | |
| | being used directly as the CEK) | | | | 5.8.1 of | | |
+----------------+---------------------------------+----------------+ | | [NIST.800-56A], | | |
| | with the | | |
| | agreed-upon key | | |
| | being used | | |
| | directly as the | | |
| | Content Encryption | | |
| | Key (CEK) (rather | | |
| | than being used to | | |
| | wrap the CEK), as | | |
| | specified in | | |
| | Section 4.7 | | |
| ECDH-ES+A128KW | Elliptic Curve | "epk", | RECOMMENDED |
| | Diffie-Hellman | "apu", | |
| | Ephemeral Static | "apv" | |
| | key agreement per | | |
| | "ECDH-ES" and | | |
| | Section 4.7, but | | |
| | where the | | |
| | agreed-upon key is | | |
| | used to wrap the | | |
| | Content Encryption | | |
| | Key (CEK) with the | | |
| | "A128KW" function | | |
| | (rather than being | | |
| | used directly as | | |
| | the CEK) | | |
| ECDH-ES+A256KW | Elliptic Curve | "epk", | RECOMMENDED |
| | Diffie-Hellman | "apu", | |
| | Ephemeral Static | "apv" | |
| | key agreement per | | |
| | "ECDH-ES" and | | |
| | Section 4.7, but | | |
| | where the | | |
| | agreed-upon key is | | |
| | used to wrap the | | |
| | Content Encryption | | |
| | Key (CEK) with the | | |
| | "A256KW" function | | |
| | (rather than being | | |
| | used directly as | | |
| | the CEK) | | |
+----------------+--------------------+------------+----------------+
All the names are short because a core goal of JWE is for the
representations to be compact. However, there is no a priori length
restriction on "alg" values.
The Additional Header Parameters column indicates what additional
Header Parameters are used by the algorithm, beyond "alg", which all
use. All but "dir" and "ECDH-ES" also produce a JWE Encrypted Key
value.
The use of "+" in the Implementation Requirements indicates that the The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of requirement strength is likely to be increased in a future version of
the specification. the specification.
4.2. "enc" (Encryption Method) Header Parameter Values for JWE 4.2. "enc" (Encryption Method) Header Parameter Values for JWE
The table below is the set of "enc" (encryption method) header The table below is the set of "enc" (encryption method) header
parameter values that are defined by this specification for use with parameter values that are defined by this specification for use with
JWE. These algorithms are used to encrypt the Plaintext, which JWE. These algorithms are used to encrypt the Plaintext, which
produces the Ciphertext. produces the Ciphertext.
+---------------+----------------------------------+----------------+ +-------------+------------------------+------------+---------------+
| enc Parameter | Block Encryption Algorithm | Implementation | | enc | Content Encryption | Additional | Implementatio |
| Value | | Requirements | | Parameter | Algorithm | Header | nRequirements |
+---------------+----------------------------------+----------------+ | Value | | Parameters | |
| A128CBC-HS256 | The AES_128_CBC_HMAC_SHA_256 | REQUIRED | +-------------+------------------------+------------+---------------+
| | authenticated encryption | | | A128CBC-HS2 | The | (none) | REQUIRED |
| | algorithm, as defined in | | | 56 | AES_128_CBC_HMAC_SHA_2 | | |
| | Section 4.8.3. This algorithm | | | | 56 authenticated | | |
| | uses a 256 bit key. | | | | encryption algorithm, | | |
| A256CBC-HS512 | The AES_256_CBC_HMAC_SHA_512 | REQUIRED | | | as defined in | | |
| | authenticated encryption | | | | Section 4.8.3. This | | |
| | algorithm, as defined in | | | | algorithm uses a 256 | | |
| | Section 4.8.4. This algorithm | | | | bit key. | | |
| | uses a 512 bit key. | | | A256CBC-HS5 | The | (none) | REQUIRED |
| A128GCM | AES in Galois/Counter Mode (GCM) | RECOMMENDED | | 12 | AES_256_CBC_HMAC_SHA_5 | | |
| | [AES] [NIST.800-38D] using 128 | | | | 12 authenticated | | |
| | bit keys | | | | encryption algorithm, | | |
| A256GCM | AES GCM using 256 bit keys | RECOMMENDED | | | as defined in | | |
+---------------+----------------------------------+----------------+ | | Section 4.8.4. This | | |
| | algorithm uses a 512 | | |
| | bit key. | | |
| A128GCM | AES in Galois/Counter | (none) | RECOMMENDED |
| | Mode (GCM) [AES] | | |
| | [NIST.800-38D] using | | |
| | 128 bit keys | | |
| A256GCM | AES GCM using 256 bit | (none) | RECOMMENDED |
| | keys | | |
+-------------+------------------------+------------+---------------+
All the names are short because a core goal of JWE is for the The Additional Header Parameters column indicates what additional
representations to be compact. However, there is no a priori length Header Parameters are used by the algorithm, beyond "enc", which all
restriction on "alg" values. use. All also use a JWE Initialization Vector value and and produce
JWE Ciphertext and JWE Authentication Tag values.
See Appendix B for a table cross-referencing the encryption "alg" See Appendix B for a table cross-referencing the encryption "alg"
(algorithm) and "enc" (encryption method) values used in this (algorithm) and "enc" (encryption method) values used in this
specification with the equivalent identifiers used by other standards specification with the equivalent identifiers used by other standards
and software packages. and software packages.
4.3. Key Encryption with RSAES-PKCS1-V1_5 4.3. Key Encryption with RSAES-PKCS1-V1_5
This section defines the specifics of encrypting a JWE CEK with This section defines the specifics of encrypting a JWE CEK with
RSAES-PKCS1-V1_5 [RFC3447]. The "alg" header parameter value RSAES-PKCS1-V1_5 [RFC3447]. The "alg" header parameter value
skipping to change at page 18, line 13 skipping to change at page 19, line 32
A key of size 2048 bits or larger MUST be used with this algorithm. A key of size 2048 bits or larger MUST be used with this algorithm.
An example using this algorithm is shown in Appendix A.1 of [JWE]. An example using this algorithm is shown in Appendix A.1 of [JWE].
4.5. Key Wrapping with AES Key Wrap 4.5. Key Wrapping with AES Key Wrap
This section defines the specifics of encrypting a JWE CEK with the This section defines the specifics of encrypting a JWE CEK with the
Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
the default initial value specified in Section 2.2.3.1 using 128 or the default initial value specified in Section 2.2.3.1 using 128 or
256 bit keys. The "alg" header parameter values "A128KW" or "A256KW" 256 bit keys. The "alg" header parameter values "A128KW" or "A256KW"
are used in this case. are respectively used in this case.
An example using this algorithm is shown in Appendix A.3 of [JWE]. An example using this algorithm is shown in Appendix A.3 of [JWE].
4.6. Direct Encryption with a Shared Symmetric Key 4.6. Direct Encryption with a Shared Symmetric Key
This section defines the specifics of directly performing symmetric This section defines the specifics of directly performing symmetric
key encryption without performing a key wrapping step. In this case, key encryption without performing a key wrapping step. In this case,
the shared symmetric key is used directly as the Content Encryption the shared symmetric key is used directly as the Content Encryption
Key (CEK) value for the "enc" algorithm. An empty octet sequence is Key (CEK) value for the "enc" algorithm. An empty octet sequence is
used as the JWE Encrypted Key value. The "alg" header parameter used as the JWE Encrypted Key value. The "alg" header parameter
skipping to change at page 18, line 52 skipping to change at page 20, line 23
Agreement mode and the values "ECDH-ES+A128KW" and "ECDH-ES+A256KW" Agreement mode and the values "ECDH-ES+A128KW" and "ECDH-ES+A256KW"
are used in the Key Agreement with Key Wrapping mode. are used in the Key Agreement with Key Wrapping mode.
In the Direct Key Agreement case, the output of the Concat KDF MUST In the Direct Key Agreement case, the output of the Concat KDF MUST
be a key of the same length as that used by the "enc" algorithm; in be a key of the same length as that used by the "enc" algorithm; in
this case, the empty octet sequence is used as the JWE Encrypted Key this case, the empty octet sequence is used as the JWE Encrypted Key
value. In the Key Agreement with Key Wrapping case, the output of value. In the Key Agreement with Key Wrapping case, the output of
the Concat KDF MUST be a key of the length needed for the specified the Concat KDF MUST be a key of the length needed for the specified
key wrapping algorithm, either 128 or 256 bits respectively. key wrapping algorithm, either 128 or 256 bits respectively.
A new "epk" (ephemeral public key) value MUST be generated for each A new ephemeral public key value MUST be generated for each key
key agreement transaction. agreement transaction.
4.7.1. Key Derivation for "ECDH-ES" 4.7.1. Header Parameters Used for ECDH Key Agreement
The following Header Parameter Names are reserved and are used for
key agreement as defined below. They MAY also be used for other
algorithms if so specified by those algorithm parameter definitions.
4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter
The "epk" (ephemeral public key) value created by the originator for
the use in key agreement algorithms. This key is represented as a
JSON Web Key [JWK] bare public key value. This Header Parameter is
REQUIRED and MUST be understood and processed by implementations when
these algorithms are used.
4.7.1.2. "apu" (Agreement PartyUInfo) Header Parameter
The "apu" (agreement PartyUInfo) value for key agreement algorithms
using it (such as "ECDH-ES"), represented as a base64url encoded
string. When used, the PartyUInfo value contains information about
the sender. Use of this Header Parameter is OPTIONAL. This Header
Parameter MUST be understood and processed by implementations when
these algorithms are used.
4.7.1.3. "apv" (Agreement PartyVInfo) Header Parameter
The "apv" (agreement PartyVInfo) value for key agreement algorithms
using it (such as "ECDH-ES"), represented as a base64url encoded
string. When used, the PartyVInfo value contains information about
the receiver. Use of this Header Parameter is OPTIONAL. This Header
Parameter MUST be understood and processed by implementations when
these algorithms are used.
4.7.2. Key Derivation for ECDH Key Agreement
The key derivation process derives the agreed upon key from the The key derivation process derives the agreed upon key from the
shared secret Z established through the ECDH algorithm, per Section shared secret Z established through the ECDH algorithm, per Section
6.2.2.2 of [NIST.800-56A]. 6.2.2.2 of [NIST.800-56A].
Key derivation is performed using the Concat KDF, as defined in Key derivation is performed using the Concat KDF, as defined in
Section 5.8.1 of [NIST.800-56A], where the Digest Method is SHA-256. Section 5.8.1 of [NIST.800-56A], where the Digest Method is SHA-256.
The Concat KDF parameters are set as follows: The Concat KDF parameters are set as follows:
Z This is set to the representation of the shared secret Z as an Z This is set to the representation of the shared secret Z as an
octet sequence. octet sequence.
keydatalen This is set to the number of bits in the desired output keydatalen This is set to the number of bits in the desired output
key. For "ECDH-ES", this is length of the key used by the "enc" key. For "ECDH-ES", this is length of the key used by the "enc"
algorithm. For "ECDH-ES+A128KW", and "ECDH-ES+A256KW", this is algorithm. For "ECDH-ES+A128KW", and "ECDH-ES+A256KW", this is
128 and 256, respectively. 128 and 256, respectively.
AlgorithmID This is set to the octets of the UTF-8 representation of AlgorithmID In the Direct Key Agreement case, this is set to the
the "alg" header parameter value. octets of the UTF-8 representation of the "enc" header parameter
value. In the Key Agreement with Key Wrapping case, this is set
to the octets of the UTF-8 representation of the "alg" header
parameter value.
PartyUInfo PartyUInfo contains a random data value provided by the PartyUInfo The PartyUInfo value is of the form Datalen || Data,
sender. If provided, this value MUST contain at least 512 bits where Data is a variable-length string of zero or more octets, and
and a unique value SHOULD be used for each recipient. Use of Datalen is a fixed-length, big endian 32 bit counter that
PartyUInfo is OPTIONAL when a different ephemeral key is used for indicates the length (in octets) of Data, with || being
each key agreement transaction. The PartyUInfo value is of the concatenation. If an "apu" (agreement PartyUInfo) header
form Datalen || Data, where Data is a variable-length string of
zero or more octets, and Datalen is a fixed-length, big endian 32
bit counter that indicates the length (in octets) of Data, with ||
being concatenation. If an "apu" (agreement PartyUInfo) header
parameter is present, Data is set to the result of base64url parameter is present, Data is set to the result of base64url
decoding the "apu" value and Datalen is set to the number of decoding the "apu" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence. the empty octet sequence.
PartyVInfo This is set to the empty octet sequence. PartyVInfo The PartyVInfo value is of the form Datalen || Data,
where Data is a variable-length string of zero or more octets, and
Datalen is a fixed-length, big endian 32 bit counter that
indicates the length (in octets) of Data, with || being
concatenation. If an "apv" (agreement PartyVInfo) header
parameter is present, Data is set to the result of base64url
decoding the "apv" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence.
SuppPubInfo This is set to the keydatalen represented as a 32 bit SuppPubInfo This is set to the keydatalen represented as a 32 bit
big endian integer. big endian integer.
SuppPrivInfo This is set to the empty octet sequence. SuppPrivInfo This is set to the empty octet sequence.
Note: The Diffie-Hellman Key Agreement Method [RFC2631] uses a key
derivation function similar to the Concat KDF, but with fewer
parameters. Rather than having separate PartyUInfo and PartyVInfo
parameters, it uses a single PartyAInfo parameter, which is a random
string provided by the sender, that contains 512 bits of information,
when provided. It has no suppPrivInfo parameter. Should it be
appropriate for the application, key agreement can be performed in a
manner akin to RFC 2631 by using the PartyAInfo value as the "apu"
(Agreement PartyUInfo) header parameter value, when provided, and by
using no "apv" (Agreement PartyVInfo) header parameter.
4.8. AES_CBC_HMAC_SHA2 Algorithms 4.8. AES_CBC_HMAC_SHA2 Algorithms
This section defines a family of authenticated encryption algorithms This section defines a family of authenticated encryption algorithms
built using a composition of Advanced Encryption Standard (AES) in built using a composition of Advanced Encryption Standard (AES) in
Cipher Block Chaining (CBC) mode with PKCS #5 padding [AES] Cipher Block Chaining (CBC) mode with PKCS #5 padding [AES]
[NIST.800-38A] operations and HMAC [RFC2104] [SHS] operations. This [NIST.800-38A] operations and HMAC [RFC2104] [SHS] operations. This
algorithm family is called AES_CBC_HMAC_SHA2. It also defines two algorithm family is called AES_CBC_HMAC_SHA2. It also defines two
instances of this family, one using 128 bit CBC keys and HMAC SHA-256 instances of this family, one using 128 bit CBC keys and HMAC SHA-256
and the other using 256 bit CBC keys and HMAC SHA-512. Test cases and the other using 256 bit CBC keys and HMAC SHA-512. Test cases
for these algorithms can be found in Appendix C. for these algorithms can be found in Appendix C.
skipping to change at page 23, line 12 skipping to change at page 25, line 26
4. The plaintext value is returned. 4. The plaintext value is returned.
4.8.3. AES_128_CBC_HMAC_SHA_256 4.8.3. AES_128_CBC_HMAC_SHA_256
This algorithm is a concrete instantiation of the generic This algorithm is a concrete instantiation of the generic
AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message
authentication code [RFC2104] with the SHA-256 hash function [SHS] to authentication code [RFC2104] with the SHA-256 hash function [SHS] to
provide message authentication, with the HMAC output truncated to 128 provide message authentication, with the HMAC output truncated to 128
bits, corresponding to the HMAC-SHA-256-128 algorithm defined in bits, corresponding to the HMAC-SHA-256-128 algorithm defined in
[RFC4868]. For encryption, it uses AES in the cipher block chaining [RFC4868]. For encryption, it uses AES in the Cipher Block Chaining
(CBC) mode of operation as defined in Section 6.2 of [NIST.800-38A], (CBC) mode of operation as defined in Section 6.2 of [NIST.800-38A],
with PKCS #5 padding. with PKCS #5 padding.
The input key K is 32 octets long. The input key K is 32 octets long.
The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets. The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets.
The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16 The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16
octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by
stripping off the final 16 octets. stripping off the final 16 octets.
skipping to change at page 24, line 10 skipping to change at page 26, line 25
AES_256_CBC_HMAC_SHA_512 with JWE. The Additional Authenticated Data AES_256_CBC_HMAC_SHA_512 with JWE. The Additional Authenticated Data
value used is the octets of the ASCII representation of the Encoded value used is the octets of the ASCII representation of the Encoded
JWE Header value. The JWE Initialization Vector value used is the IV JWE Header value. The JWE Initialization Vector value used is the IV
value. value.
4.9. Plaintext Encryption with AES GCM 4.9. Plaintext Encryption with AES GCM
This section defines the specifics of encrypting the JWE Plaintext This section defines the specifics of encrypting the JWE Plaintext
with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM)
[AES] [NIST.800-38D] using 128 or 256 bit keys. The "enc" header [AES] [NIST.800-38D] using 128 or 256 bit keys. The "enc" header
parameter values "A128GCM" or "A256GCM" are used in this case. parameter values "A128GCM" or "A256GCM" are respectively used in this
case.
The CEK is used as the encryption key. The CEK is used as the encryption key.
Use of an initialization vector of size 96 bits is REQUIRED with this Use of an initialization vector of size 96 bits is REQUIRED with this
algorithm. algorithm.
The Additional Authenticated Data value used is the octets of the The Additional Authenticated Data value used is the octets of the
ASCII representation of the Encoded JWE Header value. ASCII representation of the Encoded JWE Header value.
The requested size of the Authentication Tag output MUST be 128 bits, The requested size of the Authentication Tag output MUST be 128 bits,
skipping to change at page 37, line 27 skipping to change at page 39, line 44
o Parameter Name: "oth" o Parameter Name: "oth"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 5.3.2.7 of [[ this document ]] o Specification Document(s): Section 5.3.2.7 of [[ this document ]]
o Parameter Name: "k" o Parameter Name: "k"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 5.3.3.1 of [[ this document ]] o Specification Document(s): Section 5.3.3.1 of [[ this document ]]
6.4. Registration of JWE Header Parameter Names
This specification registers the Header Parameter Names defined in
Section 4.7.1 in the IANA JSON Web Signature and Encryption Header
Parameters registry [JWS].
6.4.1. Registry Contents
o Header Parameter Name: "epk"
o Header Parameter Usage Location(s): JWE
o Change Controller: IETF
o Specification Document(s): Section 4.7.1.1 of [[ this document ]]
o Header Parameter Name: "apu"
o Header Parameter Usage Location(s): JWE
o Change Controller: IETF
o Specification Document(s): Section 4.7.1.2 of [[ this document ]]
o Header Parameter Name: "apv"
o Header Parameter Usage Location(s): JWE
o Change Controller: IETF
o Specification Document(s): Section 4.7.1.3 of [[ this document ]]
7. Security Considerations 7. Security Considerations
All of the security issues faced by any cryptographic application All of the security issues faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are must be faced by a JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's private and symmetric keys, preventing various
attacks, and helping the user avoid mistakes such as inadvertently attacks, and helping the user avoid mistakes such as inadvertently
encrypting a message for the wrong recipient. The entire list of encrypting a message for the wrong recipient. The entire list of
security considerations is beyond the scope of this document, but security considerations is beyond the scope of this document, but
some significant considerations are listed here. some significant considerations are listed here.
skipping to change at page 38, line 44 skipping to change at page 41, line 38
[AES] National Institute of Standards and Technology (NIST), [AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197, "Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001. November 2001.
[DSS] National Institute of Standards and Technology, "Digital [DSS] 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.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption Encryption (JWE)", draft-ietf-jose-json-web-encryption
(work in progress), May 2013. (work in progress), July 2013.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), May 2013. draft-ietf-jose-json-web-key (work in progress),
July 2013.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), May 2013. in progress), July 2013.
[NIST.800-38A] [NIST.800-38A]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation", "Recommendation for Block Cipher Modes of Operation",
NIST PUB 800-38A, December 2001. NIST PUB 800-38A, December 2001.
[NIST.800-38D] [NIST.800-38D]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,
December 2001. December 2001.
[NIST.800-56A] [NIST.800-56A]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography (Revised)", NIST PUB Using Discrete Logarithm Cryptography", NIST Special
800-56A, March 2007. Publication 800-56A, Revision 2, May 2013.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002. (AES) Key Wrap Algorithm", RFC 3394, September 2002.
skipping to change at page 40, line 40 skipping to change at page 43, line 35
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple [JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", September 2010. Encryption", September 2010.
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign",
September 2010. September 2010.
[MagicSignatures] [MagicSignatures]
Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011. Signatures", January 2011.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[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.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
skipping to change at page 48, line 38 skipping to change at page 51, line 38
Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner. Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner and Stephen Farrell served as Security area directors Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix E. Document History Appendix E. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-12
o In the Direct Key Agreement case, the Concat KDF AlgorithmID is
set to the octets of the UTF-8 representation of the "enc" header
parameter value.
o Restored the "apv" (agreement PartyVInfo) parameter.
o Moved the "epk", "apu", and "apv" Header Parameter definitions to
be with the algorithm descriptions that use them.
o Changed terminology from "block encryption" to "content
encryption".
-11 -11
o Removed the Encrypted Key value from the AAD computation since it o Removed the Encrypted Key value from the AAD computation since it
is already effectively integrity protected by the encryption is already effectively integrity protected by the encryption
process. The AAD value now only contains the representation of process. The AAD value now only contains the representation of
the JWE Encrypted Header. the JWE Encrypted Header.
o Removed "apv" (agreement PartyVInfo) since it is no longer used. o Removed "apv" (agreement PartyVInfo) since it is no longer used.
o Added more information about the use of PartyUInfo during key o Added more information about the use of PartyUInfo during key
 End of changes. 25 change blocks. 
165 lines changed or deleted 323 lines changed or added

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