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

Phillip Hallam-Baker <hallam@gmail.com> Thu, 04 August 2011 12:24 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 52FF621F8B0F for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 05:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.472
X-Spam-Level:
X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.126, 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 irL64iUjH-Ns for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 05:24:05 -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 2269921F8B0E for <woes@ietf.org>; Thu, 4 Aug 2011 05:24:05 -0700 (PDT)
Received: by gxk19 with SMTP id 19so1154991gxk.31 for <woes@ietf.org>; Thu, 04 Aug 2011 05:24:19 -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=AvfBl/UyQOBCUDqtrpiA7apedTZ0bK8vVWG+e0SW+as=; b=k+vw1A1W519Lbb9cYpe2wIJmUmMcimeKHlVhOk6T/PawRKTP69kcbBM9sPTP1EXrhj Jlt2e4ErubMjqUnHaDPckoMxxYrhClAR7UAFlpQcil3EuSfwMRgQxVTVf6LrhtOowjVw 99cztQfxBmKeJ9PVPcN755QcW0+ANxcdH62N8=
MIME-Version: 1.0
Received: by 10.101.178.21 with SMTP id f21mr645990anp.138.1312460658866; Thu, 04 Aug 2011 05:24:18 -0700 (PDT)
Received: by 10.100.34.3 with HTTP; Thu, 4 Aug 2011 05:24:18 -0700 (PDT)
In-Reply-To: <15A4A9CD-FC3C-4D51-9EB5-6D05F372F5E2@gmail.com>
References: <4F25253E-A870-4956-AAB1-20890B655984@vpnc.org> <15A4A9CD-FC3C-4D51-9EB5-6D05F372F5E2@gmail.com>
Date: Thu, 4 Aug 2011 08:24:18 -0400
Message-ID: <CAMm+Lwha49v6A_isb_JxwSegPtwf1ZwzWb9dgRypErQr+7cziA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=005045017caa5a7c3304a9ad0f76
Cc: "woes@ietf.org" <woes@ietf.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 12:24:06 -0000

Based on experience of DANE, I think that the whole process will go a lot
faster if there isn't an attempt to rush through a scheme.

I can't see any technical issues in this case but my experience of DANE has
been that we argue for several months on whether to consider an issue that
could be addressed in a couple of weeks if it was accepted as a technical
matter. And at the end the issue is still not resolved.


Trying to make a consensus building process go faster than consensus can be
built is a sure recipe for disaster.

These schedules are nonsense.

On Thu, Aug 4, 2011 at 12:11 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote;wrote:

> Is the object here to arrive at an RFC or to arrive at a standard with a
> broad base of support in the web services apps community?
>
> If the latter the I suggest much more time so as to have the ability to get
> buy in from the relevant community.
>
>
> Sent from my angry birds pad
>
> On Aug 2, 2011, at 19:13, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
> > Here is a proposal for the charter based on the discussion in the BoF
> last week and later discussion with Sean Turner. Comments, praise, scorn,
> etc., are welcome.
> >
> > --Paul and Richard
> >
> > Javascript Object Signing and Encrypting (jose)
> > ===============================================
> >
> > Background
> > ----------
> >
> > Javascript Object Notation (JSON) is a text format for the serialization
> of structured data described in RFC 4627. The JSON format is often used for
> serializing and transmitting structured data over a network connection. With
> the increased usage of JSON in protocols in the IETF and elsewhere, there is
> now a desire to offer security services such as encryption and digital
> signatures for data that is being carried in JSON format.
> >
> > Different proposals for providing such security services have already
> been defined and implemented. This Working Group's task is to standardize
> two security services, encrypting and digitally signing, in order to
> increase interoperability of security features between protocols that use
> JSON.  The Working Group will base its work on well-known message security
> primitives (e.g., CMS), and will solicit input from the rest of the IETF
> Security Area to be sure that the security functionality in the JSON format
> is correct.
> >
> > This group is chartered to work on four documents:
> >
> > 1) A Standards Track document specifying how to apply a JSON-structured
> digital signature to data, including (but not limited to) JSON data
> structures. "Digital signature" is defined as a hash operation followed by a
> signature operation using asymmetric keys.
> >
> > 2) A Standards Track document specifying how to apply a JSON-structured
> encryption to data, including (but not limited to) JSON data structures.
> >
> > 3) A Standards Track document specifying how to encode public keys as
> JSON-structured objects.
> >
> > 4) A Standards Track document specifying mandatory-to-implement
> algorithms for the other three documents.
> >
> > The working group may decide to address one or more of these goals in a
> single document, in which case the concrete milestones for
> signing/encryption below will both be satisfied by the single document.
> >
> > Goals and Milestones
> > --------------------
> >
> > Aug 2011    Submit JSON object signing document as a WG item.
> >
> > Aug 2011    Submit JSON object encryption document as a WG item.
> >
> > Aug 2011    Submit JSON key format document as a WG item.
> >
> > Aug 2011    Submit JSON algoritm document as a WG item.
> >
> > Jan 2012    Start Working Group Last Call on JSON object signing
> document.
> >
> > Jan 2012    Start Working Group Last Call on JSON object encryption
> document.
> >
> > Jan 2012    Start Working Group Last Call on JSON key format document.
> >
> > Jan 2012    Start Working Group Last Call on JSON algorithm document.
> >
> > Feb 2012    Submit JSON object signing document to IESG for consideration
> as
> > Standards Track document.
> >
> > Feb 2012    Submit JSON object encryption document to IESG for
> consideration
> > as Standards Track document.
> >
> > Feb 2012    Submit JSON key format document to IESG for consideration
> > as Standards Track document.
> >
> > Feb 2012    Submit JSON algorithm document to IESG for consideration
> > as Standards Track document.
> >
> > _______________________________________________
> > woes mailing list
> > woes@ietf.org
> > https://www.ietf.org/mailman/listinfo/woes
>



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