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
- [woes] First draft of JSON Web Encryption (JWE) s… Mike Jones
- Re: [woes] First draft of JSON Web Encryption (JW… Thomson, Martin
- Re: [woes] First draft of JSON Web Encryption (JW… Paul C. Bryan