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

From: Mike Jones <[email-masked]>
Date: Tue, 1 Nov 2011 00:57:48 +0000

Hi Martin,

I've made the following changes to the current versions of the specs as a result of your comments.

I used your language for the "x5u" parameter description in the JWE and JWS specs, as well as the relevant portions of it in the "jku" (JSON Web Key URL) parameter description.

The "epk" parameter is now a JSON object, as you suggested.

I added this text to the security considerations for the JWS and JWE specs:
	"When utilizing TLS to retrieve information, the authority providing the resource MUST be authenticated and the information retrieved MUST be free from modification."

				Thanks again,
				-- Mike

P.S.  I plan to include a concrete example in a new draft that will be available before we meet in Taiwan.

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Sunday, October 09, 2011 4:44 PM
To: Mike Jones; [email-masked]
Cc: Nat Sakimura
Subject: RE: First draft of JSON Web Encryption (JWE) spec published

Hi Mike,

You know, the document does not contain a complete example.  That is, an example that includes header+key+ciphertext (and the corresponding plain text).  Until I read it again, I didn't realize that you were using base64url on each part and concatenating with '.' as a separator.

I was previously under the impression that this was one big JSON object.  But then I couldn't find the "ciphertext" parameter.

A few more replies inline.

On 2011-10-08 at 06:01:59, Mike Jones wrote:
> {MT} 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.
> 
> It provides an HTTPS address where a PEM-encoded certificate can be 
> retrieved.  An example document that could be retrieved from such a 
> URL
> follows:

I should have been clearer.  *I* understand what x5u means, but the text is a little ambiguous.

OLD:
   The "x5u" (X.509 URL) header parameter is a URL utilizing TLS (as defined in RFC 5785 [RFC5785]) that points to an X.509 public key certificate or certificate chain that that corresponds to the key that was used to encrypt the JWE.  This certificate or certificate chain MUST use the PEM encoding (per RFC 1421 [RFC1421]) and MUST conform to RFC 5280 [RFC5280].  This header parameter is OPTIONAL.  

SUGGEST:
   The "x5u" (X.509 URL) header parameter is a URL that refers to a resource for the X.509 public key certificate or certificate chain corresponding to the key used to encrypt the object.

   The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 [RFC5280] in PEM encoded form [RFC 1421].   [TBD: determine correct MIME type for PEM-encoded certificate chain]

   The protocol used to acquire the resource MUST provide integrity protection.  An HTTP GET request [RFC2616] to retrieve the certificate MUST use TLS [RFC2818][RFC5246] with server authentication [RFC6125].

Notes:
 - The TLS stuff has far less impact for encryption than it does for signing, but it might be good to get the text right and then reuse it.
 - Using RFC 5785 as a reference here is strange.
 - The implicit assumption here is that we're using HTTP over TLS [RFC2818], but that doesn't mean that another protocol cannot provide secure access to the certificate.
 - This doesn't constrain the resource from using content negotiation to provide an alternative form if that suits.  For instance, I might like to retrieve a java keystore, but that's my business :)
 - I'm not sure that describing optionality on each parameter is a great approach because of the way that each parameter interacts.  It might be better to say that a JWE MUST contain (a+b+c OR a+b+d OR b+e) and MAY contain any other parameter.  Then for each of the optional parameter, describe why it might be included or provide enough information in the description to make this obvious.

> {MT} The "typ" parameter seems a little underspecified.
> Agreed.  I'd be interested in discussions on this topic in Taiwan.

It seems like MIME would work here.  You might also like to discuss the possibility of revealing something about the payload through its content type.  This should very much be optional.

> {MT} 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.
>
> Actually, the ephemeral public key is represented as a string 
> containing a JSON object in JWK format.

Why not make "epk" a JSON object directly?  Does it need to be quoted for any particular reason?
 
> {MT} The alg and enc parameters use StringOrURI as their definition.  
> There See Section 9.2 on additional algorithms

Ahh.   That might be a good addition to the description, I missed it there.

Cheers,
Martin

---

From: Mike Jones <[email-masked]>
Date: Tue, 1 Nov 2011 00:58:24 +0000

Hi Paul,

I’ve made these changes to the specs as a result of your feedback.

The “epk” (Ephemeral Public Key) is now a structured object.

The “jku” and “x5u” URLs are now required to be absolute URLs (in both the JWE and JWS specs).

Removed this unnecessary language from the “kid” description: "Omitting this parameter is equivalent to setting it to an empty string".

I added consideration of defining media types to the to-do lists for the relevant specs.

                                                                Thanks again,
                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Friday, October 07, 2011 12:23 PM
To: Paul C. Bryan; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] First draft of JSON Web Encryption (JWE) spec published

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Paul C. Bryan
Sent: Monday, September 12, 2011 8:48 AM
To: [email-masked]<mailto:[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