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

From: Mike Jones <[email-masked]>
Date: Fri, 7 Oct 2011 19:22:52 +0000

Thanks for your read of the doc and your comments, Paul.  Replies inline below…

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul C. Bryan
Sent: Monday, September 12, 2011 8:48 AM
To: [email-masked]
Subject: Re: [woes] First draft of JSON Web Encryption (JWE) spec published

On Wed, 2011-09-07 at 04:37 +0000, 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 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?

The target document sizes are driven by URL length restrictions on some mobile phone browsers, where the character limits can be 1024, 512, or sometimes even 256.  Based upon current experience, I don’t believe we’ll need to sacrifice either. :-)

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.

Where URL-safety and compactness aren’t a concern, alternate pure-JSON serializations are possible.  The current drafts specify only the URL-safe compact serialization, as it’s the one best suited for existing use cases, but the working group could decide to add another one.  (In fact, a past draft of the precursor JWT spec did define two serializations: Compact and JSON; the JSON Serialization was later dropped by consensus.  See http://self-issued.info/docs/draft-jones-json-web-token-01.html#Serializations.)

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.

This is a decision I’m open to revisiting.  I suspect you’re right that it would be more natural to include the JSON structure directly, rather than putting it in a string.

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?

Good catch.  You’re right that we either need to specify that this is an absolute URL or define the relative rules.  I’d lean towards keeping things simple by requiring absolute URLs.

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?

I agree with you that this is unnecessary language and should probably be dropped.

x5u string URL
Same question here as for jku.

Same answer. :-)

typ String String
Is this meant to be the Internet media type?

Sometimes, but not necessarily.  It’s intended to allow software that wants to understand the type of the encrypted object to do so before decryption.  There are multiple representations that could be used in practice.  This is an area of the spec that probably deserves further specification or clarification.

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?

Yes.  This is language I want us to tighten up in the next draft, possibly based upon discussions in Taipei.

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

Noted

Paul

                                                            Thanks a bunch!
                                                            -- Mike

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 11 Oct 2011 18:34:42 -0700

On Fri, 2011-10-07 at 19:22 +0000, Mike Jones wrote:

[snip]

> Where URL-safety and compactness aren’t a concern, alternate pure-JSON
> serializations are possible.  The current drafts specify only the
> URL-safe compact serialization, as it’s the one best suited for
> existing use cases, but the working group could decide to add another
> one.  (In fact, a past draft of the precursor JWT spec did define two
> serializations: Compact and JSON; the JSON Serialization was later
> dropped by consensus.  See
> http://self-issued.info/docs/draft-jones-json-web-token-01.html#Serializations.)

I'm strongly in favour of—and will probably continue to strongly
advocate—the use of a JSON-proper representation, which contains the
encrypted key and ciphertext, allowing the entire document to be
deserialized with one (JSON) library. Perhaps only this representation
would be given a media type "application/jwe+json".

[snip]

> > Is this [typ String String] meant to be the Internet media type?
> 
> Sometimes, but not necessarily.  It’s intended to allow software that
> wants to understand the type of the encrypted object to do so before
> decryption.  There are multiple representations that could be used in
> practice.  This is an area of the spec that probably deserves further
> specification or clarification.

I'm in favour of using a standardized type representation, in this case
an Internet media type. I'm not sure what the value would be of opening
it up further, though I'm open to suggestions. 

[snip]

Paul

---

From: John Bradley <[email-masked]>
Date: Wed, 12 Oct 2011 10:16:37 -0300

Nat and I did originally have a JSON serialization for signature and encryption.

The payload was however still base64url encoded to deal with canonicalization. 

I agree for applications other than security tokens in headers,  having the elements in a JSON document makes it easier to process.

John B.
On 2011-10-11, at 10:34 PM, Paul C. Bryan wrote:

> I'm strongly in favour of—and will probably continue to strongly advocate—the use of a JSON-proper representation, which contains the encrypted key and ciphertext, allowing the entire document to be deserialized with one (JSON) library. Perhaps only this representation would be given a media type "application/jwe+json".
> 
> [snip]
> 
> I'm in favour of using a standardized type representation, in this case an Internet media type. I'm not sure what the value would be of opening it up further, though I'm open to suggestions. 
> 
> [snip]
> 
> Paul 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Oct 2011 06:10:23 +0800

> The payload was however still base64url encoded to deal with 

Explain to me how canonicalization is necessary or useful.  The decision to avoid a canonical representation of JSON was a smart one.

I would have thought that the JSON serialization is the best choice.  With a base64url serialization of the JSON serialization being a necessary concession when including the encrypted object into certain constrained containers.  The current spec has it the wrong way 'round.

---

From: John Bradley <[email-masked]>
Date: Wed, 12 Oct 2011 19:52:28 -0300

Deal with by avoiding:)

For signing (not encryption with integrity)  the thing to be signed (JSON) needs to be armoured to avoid canonicalization.  
The existing signature proposal takes the body and  BASE64URL encodes it, then calculates the hash over the encoded body.

The same is done for the envelope info.
The hash is then calculated over the encoded header and body concatenated with a ".".

Now you could take those two base64url encoded values and pass them inside a JSON object.  
That is what we originally had as our JSON serialization.

Now it has been argued that you don't gain all that much because all the stuff you are invested in still needs to be decoded.

What you do gain is being able to pass a signed/encrypted object in a response and have the recipient be able to parse it as JSON without having to sniff the content or look at the mime type to see if it is the special dot concatenated form.   

I agree a JSON serialized form is useful, however it is not magic ether.

John B.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Oct 2011 09:56:12 +0800

> Deal with by avoiding:)

An excellent tactic, agreed.  But canonicalization is only ever necessary if you need to worry about someone playing around with the encrypted/signed octets.  You can avoid that problem by refusing to define a canonicalization, so that tweaking breaks things.

> For signing (not encryption with integrity)  the thing to be signed
> (JSON) needs to be armoured to avoid canonicalization.
> The existing signature proposal takes the body and  BASE64URL encodes 
> it, then calculates the hash over the encoded body.

I can see why you chose to base64url encode.  But base64url encoding the body before signing is unnecessary.  You could just sign the octets.  Where you need to be careful is to ensure that you can sign over the header and payload in a way that the two are kept distinct.

Signature is very different from encryption, that's where I was having trouble.  I've been looking more at the encryption side so far (it's easier).  In the encrypted object, the exact form of a lot of the metadata doesn't really matter, and having a JSON object is much easier.

For signature, as soon as you sign something, you want to pass around the octets that you signed.  Otherwise, someone makes a seemingly inconsequential change and screws up your signature.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Oct 2011 19:59:06 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomson, Martin
> Sent: Wednesday, October 12, 2011 6:56 PM
> To: John Bradley
> Cc: [email-masked]; Paul C. Bryan
> Subject: Re: [jose] First draft of JSON Web Encryption (JWE) spec
published
> An excellent tactic, agreed.  But canonicalization is only ever necessary
if you
> need to worry about someone playing around with the encrypted/signed
> octets.  You can avoid that problem by refusing to define a
canonicalization,
> so that tweaking breaks things.
> 
> I can see why you chose to base64url encode.  But base64url encoding the
> body before signing is unnecessary.  You could just sign the octets.
Where
> you need to be careful is to ensure that you can sign over the header and
> payload in a way that the two are kept distinct.
> 
> Signature is very different from encryption, that's where I was having
> trouble.  I've been looking more at the encryption side so far (it's
easier).  In
> the encrypted object, the exact form of a lot of the metadata doesn't
really
> matter, and having a JSON object is much easier.

The format of the metadata might matter if there is a desire to do AEAD
algorithms where plain text attributes are authenticated as part of the
encryption process.

Jim

> 
> For signature, as soon as you sign something, you want to pass around the
> octets that you signed.  Otherwise, someone makes a seemingly
> inconsequential change and screws up your signature.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Oct 2011 12:01:31 +0800

On 2011-10-13 at 13:59:06, Jim Schaad wrote:
> The format of the metadata might matter if there is a desire to do 
> AEAD algorithms where plain text attributes are authenticated as part 
> of the encryption process.

I'd expect those attributes to separate to the non-authenticated attributes.  However, combined with a preference for consistency across the solutions, the current proposal is starting to look pretty reasonable.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 12 Oct 2011 21:53:47 -0700

On Thu, 2011-10-13 at 09:56 +0800, Thomson, Martin wrote:

> I can see why you chose to base64url encode.  But base64url encoding
> the body before signing is unnecessary.  You could just sign the
> octets.  Where you need to be careful is to ensure that you can sign
> over the header and payload in a way that the two are kept distinct.

This presumes that the octets of the JSON document itself can remain
untouched, which is a prohibitive requirement IMO. Hence why Base64
encoding the JSON serialization octets and representing them in a JSON
string does make sense to me. What makes less sense to me is
concatenating such encoded strings into a new non-JSON representation
with different semantics and require a non-JSON parser to reconstruct
it.

Paul

---

From: John Bradley <[email-masked]>
Date: Thu, 13 Oct 2011 12:21:53 -0300

Facebook, Microsoft and others started using the dot separated base64url encoded format for OAuth tokens over a year ago.

For something that is intended to be passed in a http header it is not completely unreasonable.

Size is an issue, one of the reasons the element names are so short.  

Adding what will be seen as extra characters to what we call the compact serialization will get push back.

I understand that there are advantages to sending it as JSON, however I suspect that two serializations will be required at the end of the day.

John B.
On 2011-10-13, at 1:53 AM, Paul C. Bryan wrote:

> This presumes that the octets of the JSON document itself can remain untouched, which is a prohibitive requirement IMO. Hence why Base64 encoding the JSON serialization octets and representing them in a JSON string does make sense to me. What makes less sense to me is concatenating such encoded strings into a new non-JSON representation with different semantics and require a non-JSON parser to reconstruct it.
> 
> Paul