Mike Jones: self-issued

Musings on Digital Identity

Month: July 2012

IETF 84 versions of JOSE and JWT specifications

By

On July 31, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoI’ve made a minor release of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications to support the working group discussions at IETF 84 in Vancouver, BC. This release incorporates working group feedback since the minor release on July 16th and updates the lists of open issues in the JWE and JWA specifications.

The 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-05

  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Indented artwork elements to better distinguish them from the body text.

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

  • Support both direct encryption using a shared or agreed upon symmetric key, and the use of a shared or agreed upon symmetric key to key wrap the CMK.
  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Updated open issues.
  • Indented artwork elements to better distinguish them from the body text.

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

  • Indented artwork elements to better distinguish them from the body text.

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

  • Support both direct encryption using a shared or agreed upon symmetric key, and the use of a shared or agreed upon symmetric key to key wrap the CMK. Specifically, added the alg values dir, ECDH-ES+A128KW, and ECDH-ES+A256KW to finish filling in this set of capabilities.
  • Updated open issues.

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

  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Indented artwork elements to better distinguish them from the body text.

HTML-formatted versions are available at:

My congratulations to Andrew Nash

By

On July 18, 2012

In People

Andrew NashMy congratulations to Andrew Nash on his new position as CTO of Trulioo. Have fun playing on the swings and the monkey bars!

Pre-IETF 84 versions of JOSE and JWT specifications

By

On July 16, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoI’ve made a minor release of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) working group specifications and the JWS and JWE JSON Serialization (JWS-JS, JWE-JS) individual submission specifications in preparation for IETF 84 in Vancouver, BC. These versions incorporate feedback from working group members since the major release on July 6th, and update the lists of open issues in preparation for discussions in Vancouver (and on the working group mailing lists).

One significant addition is that the JWT and JWE-JS specs both now contain complete, testable examples with encrypted results. No normative changes were made.

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-04

  • Completed JSON Security Considerations section, including considerations about rejecting input with duplicate member names.
  • Completed security considerations on the use of a SHA-1 hash when computing x5t (x.509 certificate thumbprint) values.
  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML DSIG 2.0 [W3C.CR xmldsig core2 20120124] for its security considerations.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Reference draft-jones-jose-jws-json-serialization instead of draft-jones-json-web-signature-json-serialization.
  • Described additional open issues.
  • Applied editorial suggestions.

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

  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML Encryption 1.1 [W3C.CR xmlenc core1 20120313] for its security considerations.
  • Reference draft-jones-jose-jwe-json-serialization instead of draft-jones-json-web-encryption-json-serialization.
  • Described additional open issues.
  • Applied editorial suggestions.

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

  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML DSIG 2.0 [W3C.CR xmldsig core2 20120124] for its security considerations.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Described additional open issues.
  • Applied editorial suggestions.

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

  • Added text requiring that any leading zero bytes be retained in base64url encoded key value representations for fixed-length values.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Described additional open issues.
  • Applied editorial suggestions.

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

  • Added an example of an encrypted JWT.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Applied editorial suggestions.

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

  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs).

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

  • Added a complete JWE-JS example.
  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs).

HTML-formatted versions are available at:

OAuth Core draft -30 published

By

On July 15, 2012

In OAuth, Specifications

OAuth logoDraft -30 of the OAuth Core spec has been published. The only change was:

  • Added text explaining why the server_error and temporarily_unavailable error codes are needed.

The draft is available at:

An HTML-formatted version is available at:

Thanks to Dick Hardt for quickly resolving this issue.

OAuth Core -29 and OAuth Bearer -22 specs published

By

On July 12, 2012

In OAuth, Specifications

OAuth logoNew versions of the OAuth Core and Bearer specs have been published that are intended to address all outstanding issues. (Although see Dick Hardt’s forwarded note from Charles Honton, which may result in an additional issue.)

The specifications are available at:

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-29 are:

  • Added “MUST” to “A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint” and added text explaining why this must be so.
  • Added that the authorization server MUST “ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request”.
  • Added Security Considerations section “Misuse of Access Token to Impersonate Resource Owner in Implicit Flow”.
  • Added references in the “Implicit” and “Implicit Grant” sections to particularly pertinent security considerations.
  • Added appendix “Use of application/x-www-form-urlencoded Media Type” and referenced it in places that this encoding is used.
  • Deleted “;charset=UTF-8” from examples formerly using “Content-Type: application/x-www-form-urlencoded;charset=UTF-8”.
  • Added the phrase “with a character encoding of UTF-8” when describing how to send requests using the HTTP request entity-body.
  • For symmetry when using HTTP Basic authentication, also apply the application/x-www-form-urlencoded encoding to the client password, just as was already done for the client identifier.
  • Added “The ABNF below is defined in terms of Unicode code points [W3C.REC xml 20081126]; these characters are typically encoded in UTF-8”.
  • Replaced UNICODENOCTRLCHAR in ABNF with UNICODECHARNOCRLF = %x09 / %x20-7E / %x80-D7FF / %xE000-FFFD / %x10000-10FFFF.
  • Corrected incorrect uses of “which”.
  • Reduced multiple blank lines around artwork elements to single blank lines.
  • Removed Eran Hammer’s name from the author list, at his request. Dick Hardt is now listed as the editor.

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-22 are:

  • Removed uses of HTTPbis in favor of RFC 2616 and RFC 2617, since HTTPbis is not an approved standard.
  • Match formatting of artwork elements with OAuth core specification.

HTML-formatted versions are available at:

Thanks to Dick Hardt for editing the Core specification. Thanks to Julian Reschke for supplying the text in Core Appendix B on the use of the application/x-www-form-urlencoded encoding.

JSON Serialization Specifications Renamed

By

On July 9, 2012

In Cryptography, JSON, Specifications

IETF logoI renamed the JSON Serialization specifications so that they now have “jose” in the document name. Jim Schaad tells me that then they’ll automatically be added to the JOSE Related Documents list at http://datatracker.ietf.org/wg/jose/. No normative changes were made.

These documents use the JWS and JWE crypto calculations, but enable multiple parallel signatures and multiple recipients.

The new versions are:

HTML formatted versions are available at:

Updated Simple Web Discovery (SWD) Specification

By

On July 6, 2012

In JSON, Specifications

IETF logoI’ve updated the Simple Web Discovery (SWD) specification to incorporate editorial improvements suggested by Julian Reschke and to apply applicable editorial improvements also recently made to the JOSE specifications. No normative changes were made.

The updated specification is available at:

Changes made were:

  • Changed “requests use the x-www-form-urlencoded format” to “requests use query parameters” and changed “an x-www-form-urlencoded form” to “a form encoded using the application/x-www-form-urlencoded encoding algorithm”, both at the suggestion of Julian Reschke.
  • Updated examples to use “urn:example:” URNs rather than “urn:example.org:” URNs, also at Julian’s suggestion.
  • Applied applicable editorial improvements from JOSE specs to SWD.
  • Updated references to related specifications.

An HTML formatted version is available at:

Updated JWT Bearer Token Profiles for OAuth 2.0

By

On July 6, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoI’ve updated the OAuth JWT Profile document to track minor changes to some of the underling documents. No normative changes were made.

The updated specification is available at:

Changes made were:

  • Tracked specification name changes: “The OAuth 2.0 Authorization Protocol” to “The OAuth 2.0 Authorization Framework” and “OAuth 2.0 Assertion Profile” to “Assertion Framework for OAuth 2.0”.
  • Merged in changes between draft-ietf-oauth-saml2-bearer-11 and draft-ietf-oauth-saml2-bearer-13. All changes were strictly editorial.

An HTML formatted version is available at:

Updated versions of JOSE and JWT specifications

By

On July 6, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoNew versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been released. These versions incorporate numerous suggestions from working group members and developers that clarify the intent of the specifications and make them easier to read and implement. In particular, the JWE spec now includes encryption and key derivation examples for a number of algorithms that have been verified in multiple independent implementations.

I’ve worked to close out all the former “TBD” items in the specs, bringing them up to an editorially complete state, in preparation for working group last call. As with previous releases, see the “Open Issues” sections for a small number of discussion points that I believe merit working group attention.

I also applied the changes made to the JOSE specs to the related individual submission JWS JSON Serialization and JWE JSON Serialization specs, which enable multiple recipients.

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-03

  • Added the cty (content type) header parameter for declaring type information about the secured content, as opposed to the typ (type) header parameter, which declares type information about this object.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Reference ITU.X690.1994 for DER encoding.
  • Added an example JWS using ECDSA P-521 SHA-512. This has particular illustrative value because of the use of the 521 bit integers in the key and signature values. This is also an example in which the payload is not a base64url encoded JSON object.
  • Added an example x5c value.
  • No longer say “the UTF-8 representation of the JWS Secured Input (which is the same as the ASCII representation)”. Just call it “the ASCII representation of the JWS Secured Input”.
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate registry values.
  • Changed name of the JSON Web Signature and Encryption “typ” Values registry to be the JSON Web Signature and Encryption Type Values registry, since it is used for more than just values of the typ parameter.
  • Moved registries JSON Web Signature and Encryption Header Parameters and JSON Web Signature and Encryption Type Values to the JWS specification.
  • Numerous editorial improvements.

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

  • Added the kdf (key derivation function) header parameter to provide crypto agility for key derivation. The default KDF remains the Concat KDF with the SHA-256 digest function.
  • Reordered encryption steps so that the Encoded JWE Header is always created before it is needed as an input to the AEAD “additional authenticated data” parameter.
  • Added the cty (content type) header parameter for declaring type information about the secured content, as opposed to the typ (type) header parameter, which declares type information about this object.
  • Moved description of how to determine whether a header is for a JWS or a JWE from the JWT spec to the JWE spec.
  • Added complete encryption examples for both AEAD and non-AEAD algorithms.
  • Added complete key derivation examples.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Reference ITU.X690.1994 for DER encoding.
  • Added Registry Contents sections to populate registry values.
  • Numerous editorial improvements.

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

  • Clarified that kid values need not be unique within a JWK Set.
  • Moved JSON Web Key Parameters registry to the JWK specification.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Changed registration requirements from RFC Required to Specification Required with Expert Review.
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate registry values.
  • Numerous editorial improvements.

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

  • Always use a 128 bit “authentication tag” size for AES GCM, regardless of the key size.
  • Specified that use of a 128 bit IV is REQUIRED with AES CBC. It was previously RECOMMENDED.
  • Removed key size language for ECDSA algorithms, since the key size is implied by the algorithm being used.
  • Stated that the int key size must be the same as the hash output size (and not larger, as was previously allowed) so that its size is defined for key generation purposes.
  • Added the kdf (key derivation function) header parameter to provide crypto agility for key derivation. The default KDF remains the Concat KDF with the SHA-256 digest function.
  • Clarified that the mod and exp values are unsigned.
  • Added Implementation Requirements columns to algorithm tables and Implementation Requirements entries to algorithm registries.
  • Changed AES Key Wrap to RECOMMENDED.
  • Moved registries JSON Web Signature and Encryption Header Parameters and JSON Web Signature and Encryption Type Values to the JWS specification.
  • Moved JSON Web Key Parameters registry to the JWK specification.
  • Changed registration requirements from RFC Required to Specification Required with Expert Review.
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate registry values.
  • No longer say “the UTF-8 representation of the JWS Secured Input (which is the same as the ASCII representation)”. Just call it “the ASCII representation of the JWS Secured Input”.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Numerous editorial improvements.

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

  • Added the cty (content type) header parameter for declaring type information about the secured content, as opposed to the typ (type) header parameter, which declares type information about this object. This significantly simplified nested JWTs.
  • Moved description of how to determine whether a header is for a JWS or a JWE from the JWT spec to the JWE spec.
  • Changed registration requirements from RFC Required to Specification Required with Expert Review.
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate registry values.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Numerous editorial improvements.

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

  • Tracked editorial changes made to the JWS spec.

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

  • Updated examples to track updated algorithm properties in the JWA spec.
  • Tracked editorial changes made to the JWE spec.

HTML formatted versions are available at:

Special thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund Jay for validating the JWE examples!

Powered by WordPress & Theme by Anders Norén