Subject: [woes] First draft of JSON Web Encryption (JWE) spec published

From: Mike Jones <[email-masked]>
Date: Wed, 7 Sep 2011 04:37:56 +0000

I'm pleased to announce the publication of the first draft<http://self-issued.info/docs/draft-jones-json-web-encryption-00.html> of the JSON Web Encryption (JWE)<http://self-issued.info/docs/draft-jones-json-web-encryption.html> specification. It enables JSON-based encryption of content in a parallel manner to how the JSON Web Signature (JWS)<http://self-issued.info/docs/draft-jones-json-web-signature.html> specification enables JSON-based signing of content.
My thanks to John Bradley, Nat Sakimura, Eric Rescorla, and Joe Hildebrand for helping make this initial version a reality!
The specification is available at these locations:

*        http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption-00.txt

*        http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption-00.xml

*        http://self-issued.info/docs/draft-jones-json-web-encryption-00.html

*        http://self-issued.info/docs/draft-jones-json-web-encryption-00.txt

*        http://self-issued.info/docs/draft-jones-json-web-encryption-00.xml

*        http://self-issued.info/docs/draft-jones-json-web-encryption.html (will point to new versions as they are posted)

*        http://self-issued.info/docs/draft-jones-json-web-encryption.txt (will point to new versions as they are posted)

*        http://self-issued.info/docs/draft-jones-json-web-encryption.xml (will point to new versions as they are posted)

*        http://svn.openid.net/repos/specifications/json_web_encryption/1.0/ (Subversion repository, with html, txt, and html versions available)

I also posted about this at http://self-issued.info/?p=538.

                                                            -- Mike

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 7 Sep 2011 14:16:37 +0800

Or to add another link for the rest of us:

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

I found the presentation to be a little sketchy.  The table is difficult to parse.  I think that the table is constraining how you describe the parameters, and I'm concerned that underspecification here will hurt.  The second and third columns don't seem to add much over the description (the second column is all "string").  I'd suggest that you give each parameter a numbered section.  That way, they appear in the TOC.

The x5u parameter identifies what exactly?  Is it the URI for a resource that, upon retrieval (e.g., HTTP GET), produces an X.509 certificate (chain)?  I think that's what you mean.  The example seems to use base64url encoding, which seems pointless.

"Utilizing TLS" also needs to be expanded.  You obviously need to ensure that the authority providing the resource is authenticated and that the representation you retrieve is free from modification, so say that.

The "typ" parameter seems a little underspecified.

The epk parameter isn't a string by its description, though the table indicates that it is.  ...unless you wanted to base64url encode the JSON object.

The alg and enc parameters use StringOrURI as their definition.  There are no URIs defined for either.  I suspect that there is something in there you are wanting to get at, but I recommend that just "String" is sufficient.  After all, someone is going to have to decide if "alg": "http://foo" is equal to "alg": "HTTP://FOO" and I don't want to have to be that guy.  Saying that you character-wise compare the strings for equality is really, really good.

That doesn't preclude the definition of a scheme where URIs are used to prevent collisions in the namespace, but I suspect that your existing text on public/private use of codes is sufficient.

BTW, I like your decision to make all parameters mandatory.  This is less a concern with encryption as it is with signature, but it seems like it's better to be consistent across the two.

--Martin

On 2011-09-07 at 14:37:56, Mike Jones wrote:
> I'm pleased to announce the publication of the first draft 
> <http://self-issued.info/docs/draft-jones-json-web-encryption-00.html>
> of the JSON Web Encryption (JWE)
> <http://self-issued.info/docs/draft-jones-json-web-encryption.html>
> specification. It enables JSON-based encryption of content in a 
> parallel manner to how the JSON Web Signature (JWS) <http://self- 
> issued.info/docs/draft-jones-json-web-signature.html>
> specification enables JSON-based signing of content.
> 
> My thanks to John Bradley, Nat Sakimura, Eric Rescorla, and Joe 
> Hildebrand for helping make this initial version a reality!
> 
> *
> http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption-
> 00.t
> xt
> 
> *
> http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption-
> 00.x
> ml
> 
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption-00.html
> 
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption-00.txt
> 
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption-00.xml
> 
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption.html
> (will point to new versions as they are posted)
> 
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption.txt (will 
> point to new versions as they are posted)
> 
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption.xml (will 
> point to new versions as they are posted)
> 
> *
> http://svn.openid.net/repos/specifications/json_web_encryption/1.0/
> (Subversion repository, with html, txt, and html versions available)
> 
> 
> 
> I also posted about this at http://self-issued.info/?p=538 
> <http://self-issued.info/?p=538> .
> 
> 
> 
>                                                             -- Mike
> 
>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 12 Sep 2011 08:48:20 -0700

On Wed, 2011-09-07 at 04:37 +0000, Mike Jones wrote:
> I’m pleased to announce the publication of the first draft of the JSON
> Web Encryption (JWE) specification. It enables JSON-based encryption
> of content in a parallel manner to how the JSON Web Signature (JWS)

My comments, on excerpts from the text:

> JSON Web Encryption (JWE) is a compact encryption format intended for
> space constrained environments such as HTTP Authorization headers and
> URI query parameters.
Is there a target document size you're aiming for here (and hence can
test whether such objectives can even be met), or just
as-small-as-possible so it has the best possible chance to fit into such
environments? If it turns out that JSON is not suitable to meet these
objectives, which shall be sacrificed: JSON or compactness?

> JWE provides a wrapper for encrypted content using JSON data
> structures and base64url encoding. The representation consists of
> three parts: the JWT Header, the JWE Encrypted Key, and the JWE
> Ciphertext. The three parts are base64url-encoded for transmission,
> and typically represented as the concatenation of the encoded strings
> in that order, with the three strings being separated by period ('.')
> characters, as is done when used in JSON Web Tokens (JWTs)

You've invented a whole new structure that is not JSON. Sure, it
leverages JSON in the header, which is then base64-encoded (which I
point out also contains base64-encoded values itself, so this results in
double-base64-encoding of some values). I would argue that there should
at least be a representation that remains JSON-proper, which contains
the encrypted key and ciphertext.

> epk string String

JSON provides for the intuitive representation structured data. Why are
you choosing to encode a structured value in a string? If your answer is
"compactness" then I think we need to either rethink the use of JSON or
rethink this objective of compactness.

> jku string URL

What are the rules for accessing such keys? Can this be a URL relative
to the encrypted document, if it has a known location?

> Omitting this [kid] parameter is equivalent to setting it to an empty
> string.

Why are you allowing for empty string? What is the semantic of having it
be empty string? What about null?

> x5u string URL

Same question here as for jku.

> typ String String

Is this meant to the the Internet media type?

> For GCM, the random 64-bit IV is prepended to the ciphertext.

Isn't the "iv" property in the header already being used for this
purpose?

> 10. IANA Considerations

I recommend that a media type also be proposed, such as "application/jwe
+json".

Paul