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

"Paul C. Bryan" <> Mon, 12 September 2011 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAA4821F8B91 for <>; Mon, 12 Sep 2011 08:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hEUPesZgt0N0 for <>; Mon, 12 Sep 2011 08:45:57 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 73E8921F8B8E for <>; Mon, 12 Sep 2011 08:45:54 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKTm4pnoRzT0BaWFgG2sRdKYAdX2ekv/; Mon, 12 Sep 2011 15:48:00 UTC
Received: by qyg14 with SMTP id 14so265005qyg.2 for <>; Mon, 12 Sep 2011 08:47:42 -0700 (PDT)
Received: by with SMTP id g3mr3673541pbl.182.1315842462002; Mon, 12 Sep 2011 08:47:42 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id h5sm43960523pbq.11.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Sep 2011 08:47:40 -0700 (PDT)
From: "Paul C. Bryan" <>
In-Reply-To: <>
References: <>
Content-Type: multipart/alternative; boundary="=-qTC7Wzfk/IRwC8uvgWQG"
Date: Mon, 12 Sep 2011 08:48:20 -0700
Message-ID: <1315842500.4092.363.camel@dynamo>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Subject: Re: [woes] First draft of JSON Web Encryption (JWE) spec published
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Sep 2011 15:45:59 -0000

 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)
> 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?

> 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

> 10. IANA Considerations

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