Re: [woes] Proposed charter, post-Quebec edition

John Bradley <ve7jtb@ve7jtb.com> Thu, 04 August 2011 13:25 UTC

Return-Path: <ve7jtb@ve7jtb.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 D0EE921F8AE6 for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 06:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.538
X-Spam-Level:
X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk0-K-IGJzkF for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 06:25:01 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50A21F89C2 for <woes@ietf.org>; Thu, 4 Aug 2011 06:24:56 -0700 (PDT)
Received: by vxi40 with SMTP id 40so1789444vxi.31 for <woes@ietf.org>; Thu, 04 Aug 2011 06:25:10 -0700 (PDT)
Received: by 10.52.70.83 with SMTP id k19mr730098vdu.405.1312464310123; Thu, 04 Aug 2011 06:25:10 -0700 (PDT)
Received: from [192.168.1.211] ([190.22.14.181]) by mx.google.com with ESMTPS id u3sm731145vcc.43.2011.08.04.06.25.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 06:25:09 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_5F9D3F7B-9020-4CD7-AC91-52B6997A60AD"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAMm+LwhO98tr8PnC0ebObHAmPptP3kvV5Jq=u6LSs3ARjA5PYQ@mail.gmail.com>
Date: Thu, 4 Aug 2011 09:25:17 -0400
Message-Id: <BD80D366-B164-4466-B57C-ADC6E01DFEE7@ve7jtb.com>
References: <4F25253E-A870-4956-AAB1-20890B655984@vpnc.org> <DADD7EAD88AB484D8CCC328D40214CCD0E743D3330@EXPO10.exchange.mit.edu> <4E39B44C.1070706@stpeter.im> <4E39B483.7080101@stpeter.im> <DDAE45CD-111B-4C5F-83B0-0F267B8EC8E7@ve7jtb.com> <CAMm+LwhO98tr8PnC0ebObHAmPptP3kvV5Jq=u6LSs3ARjA5PYQ@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: "woes@ietf.org" <woes@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [woes] Proposed charter, post-Quebec edition
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: Thu, 04 Aug 2011 13:25:02 -0000

XPath is NOT the way to go.  No argument from me.

The JWS spec has admittedly been focused on allowing JSON to be used as tokens for OAuth and openID.

Those need to be passed around in a URL safe way,  so we need a serialization that supports that.

In Quebec we did touch on alternate serializations that may be more suitable for other use cases.

I suspect that signing a manifest/reference is something we should be able to support in the JOSE spec.  

Finding the best way to accommodate they without complicating the simpler cases is something that should be explored.

John B.
On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:

> 
> 
> On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url encoded blobs.
> 
> In most cased we intend for those to be JSON, but nothing prevents this from being used with XML similar to the failed SAML simple sign.
> 
> With JSON payloads we really wanted to avoid touching the payload.  Inserting elements, canonicalization  and other things that touch the payload are highly problematic.
> 
> I really want to avoid C18N as well. The problem is how to do it.
> 
> If the data object is small it is no big deal base64 encoding it and storing it as an attribute.
> 
> But if the data object is larger (XML document, image, etc.) then some form of indirection is going to be necessary. For example take the digest of the data and sign that or if multiple objects are involved some sort of manifest scheme.
> 
> 
> I really don't want to have to BASE64 a multimedia stream. So I think I am going to need some MIME like packaging scheme that allows us to send a JSON structure with attachments. I think that is going to be a very common requirement for others as well and I would like that to be a part of the standards toolkit rather than have to re-invent it for each protocol. 
> 
> 
> Another very common corner case that is related is how to take a standard data object such as a JPEG, sign it and then attach the signature inside the data object. 
> 
> The blunder committed in XML Signature was to use XPath for that which introduced a mechanism for arbitrary transformations - yuk!
> 
> I really don't want to specify the precise means of embedding signatures in various media types but I certainly need an approach that makes it possible to use the spec as a basis for doing that. 
> 
> 
> -- 
> Website: http://hallambaker.com/
>