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

Phillip Hallam-Baker <hallam@gmail.com> Thu, 04 August 2011 13:38 UTC

Return-Path: <hallam@gmail.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 55AE221F8AF3 for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 06:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.035
X-Spam-Level:
X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 Omzf0bpvO7qu for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 06:38:29 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5283321F8AF2 for <woes@ietf.org>; Thu, 4 Aug 2011 06:38:29 -0700 (PDT)
Received: by gxk19 with SMTP id 19so1205781gxk.31 for <woes@ietf.org>; Thu, 04 Aug 2011 06:38:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PzWP18wh6EuMmIZBJ31ngjr5BJd8aS/bD7WEvnAiAsA=; b=Y5WV168X4Q/ritBUw5Wcre8Il1AMun6iMiOHbR4ll0CgPu4+XwMqMDvFNklk8vfBUA HppdOGDS0F+JZk/Ky1X7AdR5MiLBCGENAkGCVvbDIbKrQxWRtS7sa+Q6A4owDUyQlfYM Co8v9aWsz4/XuCJgZylSi54MBNhRgU0VJJAfY=
MIME-Version: 1.0
Received: by 10.101.164.25 with SMTP id r25mr711943ano.94.1312465122635; Thu, 04 Aug 2011 06:38:42 -0700 (PDT)
Received: by 10.100.34.3 with HTTP; Thu, 4 Aug 2011 06:38:42 -0700 (PDT)
In-Reply-To: <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> <BD80D366-B164-4466-B57C-ADC6E01DFEE7@ve7jtb.com>
Date: Thu, 4 Aug 2011 09:38:42 -0400
Message-ID: <CAMm+LwhPpqO13VxYOUYEeZ=nGPEt+pDpsbzBgRy6NtLQ3YfJmQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=0016e6d26d726a2ebd04a9ae19aa
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:38:30 -0000

Since we are doing encryption as well, there are two problems needing a
common solution.


Let us say we are encrypting a blob of data - 200K or so. Do we really want
to have a JSON structure with the data blob JSON encoded?

For that and for the signing case I think we are going to want a structure
that is something like:

Package
    [Type=JSON Length=203 bytes]
        <Encryption stuff>
    [ID=2as9uas9u9 Length=293939933 bytes]
        <Binary blob>

Ascii encoding for control data is good, it helps debugging etc. But Ascii
encoding JPEG bytes does not really help me much.

The package could even be as simple as a JSON control block that gives the
length of a data blob that is to follow immediately.


On Thu, Aug 4, 2011 at 9:25 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> 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/
>
>
>


-- 
Website: http://hallambaker.com/