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

Phillip Hallam-Baker <> Thu, 04 August 2011 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55AE221F8AF3 for <>; Thu, 4 Aug 2011 06:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.035
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Omzf0bpvO7qu for <>; Thu, 4 Aug 2011 06:38:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5283321F8AF2 for <>; Thu, 4 Aug 2011 06:38:29 -0700 (PDT)
Received: by gxk19 with SMTP id 19so1205781gxk.31 for <>; Thu, 04 Aug 2011 06:38:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id r25mr711943ano.94.1312465122635; Thu, 04 Aug 2011 06:38:42 -0700 (PDT)
Received: by with HTTP; Thu, 4 Aug 2011 06:38:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 4 Aug 2011 09:38:42 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: John Bradley <>
Content-Type: multipart/alternative; boundary=0016e6d26d726a2ebd04a9ae19aa
Cc: "" <>, Paul Hoffman <>
Subject: Re: [woes] Proposed charter, post-Quebec edition
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: 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:

    [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 <> 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 <> 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: