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/
- [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Thomas Hardjono
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Thomas Hardjono
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Eric Rescorla
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Jeremy Laurenson
- Re: [woes] Proposed charter, post-Quebec edition Richard L. Barnes
- Re: [woes] Proposed charter, post-Quebec edition Hal Lockhart
- [woes] Naked Public Key, was: RE: Proposed charte… Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Proposed charter, post-Quebec edition Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Jeremy Laurenson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Proposed charter, post-Quebec edition Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Paul C. Bryan
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Ben Adida
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Paul C. Bryan
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Ben Adida
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Hal Lockhart
- [woes] Support multiple Crypto algorithms? was RE… Hal Lockhart
- Re: [woes] Support multiple Crypto algorithms? wa… John Bradley
- Re: [woes] Support multiple Crypto algorithms? wa… Paul C. Bryan
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Richard L. Barnes
- Re: [woes] Support multiple Crypto algorithms? wa… Phillip Hallam-Baker
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand