Archive for October, 2012

October 28, 2012
Platform Support for JWA Crypto Algorithms

IETF logoIn preparation for discussions at the JOSE working group meeting at IETF 84 in Vancouver, BC, I did some investigation into the state of support for the JWA algorithms in common Web development platforms. This table contains the data gathered. It was also discussed at the July 2012 W3C WebCrypto F2F Meeting. I’m posting it now because I’d recently received a request for it and because it may be useful at the upcoming WebCrypto meeting at TPAC in Lyon and at IETF 85 in Atlanta.

Thanks to Roland Hedberg, Axel Nennker, Emmanuel Raviart, Nov Matake, Justin Richer, Edmund Jay, Wan-Teh Chang, Christopher Kula, and Ryan Sleevi for the data they provided. If you have more data that I should add, or believe that there are additional columns or rows we should track, please let me know.

October 15, 2012
JOSE and JWT specs incorporating working group decisions since IETF 84

IETF logoNew versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been released. These versions incorporate the decisions made by the JOSE working group during and since IETF 84.

The primary change was revising the JWE format to always use AEAD encryption algorithms. The companion change was defining two new composite AEAD algorithms “A128CBC+HS256” and “A256CBC+HS512” that use AES CBC to perform encryption and matching HMAC SHA-2 algorithms to perform an integrity check on the ciphertext and the parameters used to create it.

Other than that, all changes were local in scope, with no changes to JWS – other than changing the format of the “x5c” (X.509 Certificate Chain) from a string containing a list of certificate values to an array of strings containing certificate values. Likewise, the only changes to JWT were to track changes made in the specs that it uses.

Having addressed all the open issues with resolutions with apparent working group consensus, it’s my hope that the working group will decide to send these specifications to working group last call at IETF 85.

The companion JWS JSON Serialization and JWE JSON Serialization specs were also updated.

The working group specifications are available at:

The individual submission specifications are available at:

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

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

  • Changed x5c (X.509 Certificate Chain) representation from being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the certificate chain.
  • Applied changes made by the RFC Editor to RFC 6749′s registry language to this specification.

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

  • Removed the int and kdf parameters and defined the new composite AEAD algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AES CBC, which required the use of separate integrity and key derivation functions.
  • Included additional values in the Concat KDF calculation — the desired output size and the algorithm value, and optionally PartyUInfo and PartyVInfo values. Added the optional header parameters apu (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo). Updated the KDF examples accordingly.
  • Promoted Initialization Vector from being a header parameter to being a top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cases. Promoting the Initialization Vector out of the header also avoids repeating this shared value in the JSON serialization.
  • Changed x5c (X.509 Certificate Chain) representation from being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the certificate chain.
  • Added an AES Key Wrap example.
  • Reordered the encryption steps so CMK creation is first, when required.
  • Correct statements in examples about which algorithms produce reproducible results.

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

  • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)
  • Clarify that the alg (algorithm family) member is REQUIRED.
  • Correct an instance of “JWK” that should have been “JWK Set”.
  • Applied changes made by the RFC Editor to RFC 6749′s registry language to this specification.

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

  • Removed the int and kdf parameters and defined the new composite AEAD algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AES CBC, which required the use of separate integrity and key derivation functions.
  • Included additional values in the Concat KDF calculation — the desired output size and the algorithm value, and optionally PartyUInfo and PartyVInfo values. Added the optional header parameters apu (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo).
  • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)
  • Applied changes made by the RFC Editor to RFC 6749′s registry language to this specification.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04

  • Promoted Initialization Vector from being a header parameter to being a top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cases. Promoting the Initialization Vector out of the header also avoids repeating this shared value in the JSON serialization.
  • Applied changes made by the RFC Editor to RFC 6749′s registry language to this specification.
  • Reference RFC 6755 — An IETF URN Sub-Namespace for OAuth.

http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather than a set of parallel arrays.

http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather than a set of parallel arrays.
  • Promoted Initialization Vector from being a header parameter to being a top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cases. Promoting the Initialization Vector out of the header also avoids repeating this shared value in the JSON serialization.

HTML formatted versions are available at:

October 12, 2012
OAuth 2.0 RFCs Completed

OAuth logoThe OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750. This completes the journey to standardize a pair of simple identity specifications that are already in very widespread use for Web, enterprise, cloud, and mobile applications. They make things better by enabling access to resources to be granted without giving the password for the resource to the party being granted access (a pattern that used to be all too common).

I believe that the completion of these RFCs will only accelerate the momentum behind the adoption of simple REST/JSON based identity solutions. Some of the related standards that are already well under way and in use include the OAuth Assertion Framework, the OAuth SAML 2.0 Assertion Profile and OAuth JWT Assertion Profile, JSON Web Token (JWT), the JSON Object Signing and Encryption (JOSE) specs – JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA), and OpenID Connect. Watch this space for future developments. Like OAuth 2.0, all of these are the product of collaboration by numerous people around the world and in many industries to build and deploy simple, usable identity solutions that solve real-world problems.

The goal of all these specs is to standardize functionality that is not only useful, but is simple enough that it will actually be used. OAuth 2.0 is an early success story in this regard. While the number of words in the spec has increased since early drafts, most of that is due to doing a more complete job of describing things not to do (adding security considerations), rather than adding bells and whistles. It doesn’t get much simpler than a couple of HTTP GETs and replies with simple request parameters and responses.

Dick Hardt deserves special thanks for his role both in starting what became OAuth 2.0 and seeing it through to completion. I recommend his post on the process that brought us the OAuth 2.0 RFCs.