Subject: [jose] JWA ECSH-ES

From: <[email-masked]>
Date: Fri, 25 May 2012 12:58:32 +0200

Section 4 of https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02 defines:

   | ECDH-ES   | Elliptic Curve Diffie-Hellman Ephemeral Static, as    |
   |           | defined in RFC 6090<https://tools.ietf.org/html/rfc6090> [RFC6090<https://tools.ietf.org/html/rfc6090>], and using the Concat   |
   |           | KDF, as defined in Section 5.8.1 of [NIST.800-56A<https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02#ref-NIST.800-56A>],   |
   |           | where the Digest Method is SHA-256 and all OtherInfo  |
   |           | parameters are the empty bit string                   |

I suggest to change the KDF to KDF2 as described here
http://www.di-mgt.com.au/cryptoKDFs.html
and defined in ISO18033.

Reasons are:

-          The kdf defined in NIST.800-56A section 5.8.1 is not implemented in Bouncycastle while KDF1 and KDF2 are implemented.

-          NIST is a national standard while the ISO standard is international and I assume that there is a NIST adaption of it.

-          There are currently not many implementations of JWA using ECDH-ES. So this change is currently probably non-breaking.

-          The current definition seems to be difficult to implement using

o   http://msdn.microsoft.com/en-us/library/windows/desktop/aa375393%28v=vs.85%29.aspx too
because OtherInfo can not be the empty bit string because parts of OtherInfo are required like ALGORITHMID

Input about other commonly used crypto libraries should be collected. I got the impression that some of them like openssl implement only PBKDF but not KDF1, KDF2, KDF3 (prove me wrong)

Cheers
Axel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Sunday, May 13, 2012 2:09 AM
To: [email-masked]
Subject: [jose] Draft -02 of JSON Crypto Specs: JWS, JWE, JWK, JWA

New -02 versions of the JSON Object Signing and Encryption (JOSE)<http://datatracker.ietf.org/wg/jose/> specifications are now available that incorporate working decisions made since the previous versions, including decisions made at IETF 83 in Paris and in follow-up discussions on the working group list.  The drafts contain numerous clarifications, refinements, and editorial improvements.  They are:

*         JSON Web Signature (JWS) - Digital signature/HMAC specification

*         JSON Web Encryption (JWE) - Encryption specification

*         JSON Web Key (JWK) - Public key specification

*         JSON Web Algorithms (JWA) - Algorithms and identifiers specification

These specifications are available at:

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02:

 *   Clarified that it is an error when a kid value is included and no matching key is found.
 *   Removed assumption that kid (key ID) can only refer to an asymmetric key.
 *   Clarified that JWSs with duplicate Header Parameter Names MUST be rejected.
 *   Clarified the relationship between typ header parameter values and MIME types.
 *   Registered application/jws MIME type and "JWS" typ header parameter value.
 *   Simplified JWK terminology to get replace the "JWK Key Object" and "JWK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
 *   Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
 *   Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
 *   Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
 *   Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02:

 *   When using AEAD algorithms (such as AES GCM), use the "additional authenticated data" parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting "authentication tag" value as the JWE Integrity Value.
 *   Defined KDF output key sizes.
 *   Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
 *   Changed compression algorithm from gzip to DEFLATE.
 *   Clarified that it is an error when a kid value is included and no matching key is found.
 *   Clarified that JWEs with duplicate Header Parameter Names MUST be rejected.
 *   Clarified the relationship between typ header parameter values and MIME types.
 *   Registered application/jwe MIME type and "JWE" typ header parameter value.
 *   Simplified JWK terminology to get replace the "JWK Key Object" and "JWK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
 *   Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
 *   Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
 *   Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
 *   Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02:

 *   Simplified JWK terminology to get replace the "JWK Key Object" and "JWK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusion between single keys and sets of keys. As part of this change, the top-level member name for a set of keys was changed from jwk to keys.
 *   Clarified that values with duplicate member names MUST be rejected.
 *   Established JSON Web Key Set Parameters registry.
 *   Explicitly listed non-goals in the introduction.
 *   Moved algorithm-specific definitions from JWK to JWA.
 *   Reformatted to give each member definition its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02:

 *   For AES GCM, use the "additional authenticated data" parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting "authentication tag" value as the JWE Integrity Value.
 *   Defined minimum required key sizes for algorithms without specified key sizes.
 *   Defined KDF output key sizes.
 *   Specified the use of PKCS #5 padding with AES-CBC.
 *   Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
 *   Clarified that ECDH-ES is a key agreement algorithm.
 *   Required implementation of AES-128-KW and AES-256-KW.
 *   Removed the use of A128GCM and A256GCM for key wrapping.
 *   Removed A512KW since it turns out that it's not a standard algorithm.
 *   Clarified the relationship between typ header parameter values and MIME types.
 *   Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
 *   Established registries: JSON Web Signature and Encryption Header Parameters, JSON Web Signature and Encryption Algorithms, JSON Web Signature and Encryption "typ" Values, JSON Web Key Parameters, and JSON Web Key Algorithm Families.
 *   Moved algorithm-specific definitions from JWK to JWA.
 *   Reformatted to give each member definition its own section heading.

                                                            -- Mike