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

"Paul C. Bryan" <paul.bryan@forgerock.com> Mon, 12 September 2011 15:45 UTC

Return-Path: <paul.bryan@forgerock.com>
X-Original-To: woes@ietfa.amsl.com
Delivered-To: woes@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA4821F8B91 for <woes@ietfa.amsl.com>; Mon, 12 Sep 2011 08:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEUPesZgt0N0 for <woes@ietfa.amsl.com>; Mon, 12 Sep 2011 08:45:57 -0700 (PDT)
Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) by ietfa.amsl.com (Postfix) with SMTP id 73E8921F8B8E for <woes@ietf.org>; Mon, 12 Sep 2011 08:45:54 -0700 (PDT)
Received: from mail-qy0-f178.google.com ([209.85.216.178]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKTm4pnoRzT0BaWFgG2sRdKYAdX2ekv/lU@postini.com; Mon, 12 Sep 2011 15:48:00 UTC
Received: by qyg14 with SMTP id 14so265005qyg.2 for <woes@ietf.org>; Mon, 12 Sep 2011 08:47:42 -0700 (PDT)
Received: by 10.68.41.163 with SMTP id g3mr3673541pbl.182.1315842462002; Mon, 12 Sep 2011 08:47:42 -0700 (PDT)
Received: from [192.168.1.177] (S0106001346fbe4af.vf.shawcable.net. [174.1.44.35]) by mx.google.com with ESMTPS id h5sm43960523pbq.11.2011.09.12.08.47.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Sep 2011 08:47:40 -0700 (PDT)
From: "Paul C. Bryan" <paul.bryan@forgerock.com>
To: woes@ietf.org
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435B782D23@TK5EX14MBXC203.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739435B782D23@TK5EX14MBXC203.redmond.corp.microsoft.com>
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-BeenThere: woes@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/woes>, <mailto:woes-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/woes>
List-Post: <mailto:woes@ietf.org>
List-Help: <mailto:woes-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/woes>, <mailto:woes-request@ietf.org?subject=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
purpose?


> 10. IANA Considerations

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

Paul