Re: [jose] draft revision to JOSE charter

Mike Jones <Michael.Jones@microsoft.com> Tue, 15 January 2013 22:21 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6199311E80EF for <jose@ietfa.amsl.com>; Tue, 15 Jan 2013 14:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.138
X-Spam-Level:
X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 iEIa9k2fdjSQ for <jose@ietfa.amsl.com>; Tue, 15 Jan 2013 14:21:52 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6596F21F853E for <jose@ietf.org>; Tue, 15 Jan 2013 14:21:50 -0800 (PST)
Received: from BY2FFO11FD016.protection.gbl (10.1.15.203) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.596.13; Tue, 15 Jan 2013 22:21:27 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.132) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Tue, 15 Jan 2013 22:21:27 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Tue, 15 Jan 2013 22:20:37 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rbarnes@bbn.com>, "odonoghue@isoc.org" <odonoghue@isoc.org>
Thread-Topic: [jose] draft revision to JOSE charter
Thread-Index: AQHN8DaxtbAVCN9tdk2Bi7W2bXhFxphK6p6AgAAGgHA=
Date: Tue, 15 Jan 2013 22:20:36 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366A47753@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <50F06FEE.9060207@isoc.org> <8D02E89B-AF28-4D29-8710-1055BF756471@bbn.com>
In-Reply-To: <8D02E89B-AF28-4D29-8710-1055BF756471@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.74]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A47753TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(24454001)(51704002)(164054002)(377454001)(50986001)(76482001)(74662001)(512954001)(56776001)(51856001)(4396001)(5343655001)(54316002)(44976002)(15202345001)(47976001)(49866001)(56816002)(79102001)(53806001)(16406001)(46102001)(55846006)(31966008)(16297215001)(54356001)(59766001)(77982001)(16236675001)(74502001)(33656001)(5343635001)(47446002)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14MLTC103.redmond.corp.microsoft.com; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0727122FC6
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] draft revision to JOSE charter
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2013 22:22:01 -0000

Replies inline in green...



-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, January 15, 2013 1:16 PM
To: odonoghue@isoc.org
Cc: jose@ietf.org
Subject: Re: [jose] draft revision to JOSE charter



On 1,2,3,5,6:



Do I understand correctly that milestones 5 and 6 are intended to be something like the JSON serialization documents, whereas 1, 2, and 3 are supposed to be something like the current documents?  If that's the case, then we might as well call a spade a spade and remove "JSON-structured" from 1, 2, and 3.



I find that sort of back-tracking pretty distasteful, though.  As I've said before, it would be better if we could come up with a reasonable JSON syntax that would profile down to something compact and URL-safe.



Yes, (1), (2), (3) (and (4)) are the deliverables in the present charter (http://datatracker.ietf.org/wg/jose/charter/).  The "JSON-structured" wording is from the current charter.  I suppose it could be changed to "JSON-based" if people prefer that.  But minimizing changes to the existing charter items also seems like a good goal.  I'd be fine with either the "JSON-structured" wording from the current charter or "JSON-based".



And yes, (5) and (6) are the JSON serialization documents, which we decided adopt as working group documents and create charter items for at the working group meeting in Atlanta.  Consensus to do this is recorded at http://www.ietf.org/proceedings/85/minutes/minutes-85-jose.    See http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-04 and http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-04 for the current versions of these documents.



On 4:



This group has agreed time and again that we will not have mandatory to implement algorithms.  As Mr. Housley put it, according to the IETF 85 minutes, "Each app defines MTI, achieving separation of MTI from syntax.".  So the phrase "including mandatory-to-implement algorithms" needs to be struck from item (4).



This statement makes no sense, as our current charter already *requires* us to produce "A Standards Track document specifying mandatory-to-implement algorithms for the other three documents".  The rechartering is about adding the new deliverables 5-8 - not changing our existing deliverables, of which this is one already one.



On 7,8:



I have no idea what milestones 7 and 8 are supposed to entail.  JWE already has wrapped keys, and JWS should (for MAC).  As above, we should strive to get this right the first time instead of doing something halfway with a promise to patch it later.



I'm surprised that you say that don't understand 7 and 8, as you were in the Friday morning meeting in Atlanta that was organized by Joe Hildebrand and Jim Schaad that defined them.  The minutes of that meeting are at http://www.ietf.org/mail-archive/web/jose/current/msg01337.html.  Deliverable (A) in the minutes is charter item (7).  Deliverable (B) in the minutes is charter item (8).



(7) extends (3) to define JSON representations for private and symmetric keys (whereas (3) only defines representations for public keys).  See http://tools.ietf.org/html/draft-jones-jose-json-private-and-symmetric-key-00 for a draft that does this.



As we discussed at that meeting, while JWE uses wrapped key *values* (wrapped CMKs), this new document that Matt is writing will enable us to wrap both key values and associated key properties.  It wraps a JWK representation (which per (7), may represent private and symmetric keys), including potential key properties as the key's "alg" and "kid" values, as well as others that may be used.  It's intentionally more general than the wrapped CMK value used in JWE, again, as discussed during the Friday meeting in Atlanta.



--Richard



                                                                Best wishes,

                                                                -- Mike



On Jan 11, 2013, at 3:02 PM, Karen O'Donoghue <odonoghue@isoc.org<mailto:odonoghue@isoc.org>> wrote:



> Folks,

>

> Below is a draft update to our charter based on discussions at the last IETF meeting. The key changes are adding key representations and algorithm identifiers to the scope of work. This includes some minor language updates in the general section, the addition of deliverables 5-8, and the addition and modification of a number of milestones related to these documents.

>

> In addition, the phrase "using a compact URL-safe representation" has been added to the descriptions of the first two deliverables and "compact JSON object" used in the milestones.

>

> Jim and I will be submitting a revised charter shortly, and we would like your comments by 18 January if possible.

>

> Thanks,

> Karen

>

>

> Description of Working Group

>

> 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, digital signatures, message authentication codes (MACs), and key representations 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 four kinds of security services, integrity protection (signature and MAC), encryption, key representations, and algorithm identifiers, 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 eight documents:

>

> (1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures, using a compact URL-safe representation.  "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs.

>

> (2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures, using a compact URL-safe representation.

>

> (3) A Standards Track document specifying how to encode public keys as JSON-structured objects.

>

> (4) A Standards Track document specifying algorithms and algorithm identifiers, including mandatory-to-implement algorithms for the previous three documents.

>

> (5) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures, using a JSON representation supporting multiple recipients.  This document will build upon the concepts and structures in (1).

>

> (6) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures, using a JSON representation supporting multiple recipients.  This document will build upon the concepts and structures in (2).

>

> (7) A Standards Track document specifying how to encode private and symmetric keys as JSON-structured objects.  This document will build upon the concepts and structures in (3).

>

> (8) A Standards Track application document specifying a means of protecting private and symmetric keys via encryption.  This document will build upon the concepts and structures in (2) and (7).  This document may register additional algorithms in registries defined by (4).

>

> The working group may decide to address combinations of these goals in consolidated document(s), in which case the concrete milestones for these goals will be satisfied by the consolidated document(s).

>

> Goals and Milestones

>

> Jan 2012              Submit compact JSON object integrity document (1) as a WG item.

>

> Jan 2012              Submit compact JSON object encryption document (2) as a WG item.

>

> Jan 2012              Submit JSON key format document (3) as a WG item.

>

> Jan 2012              Submit JSON algorithm document (4) as a WG item.

>

> Feb 2013              Start Working Group Last Call on compact JSON object integrity document (1).

>

> Feb 2013              Start Working Group Last Call on compact JSON object encryption document (2).

>

> Feb 2013              Start Working Group Last Call on JSON key format document (3).

>

> Feb 2013              Start Working Group Last Call on JSON algorithm document (4).

>

> Mar 2013             Submit JSON object integrity document (1) to IESG for consideration as Standards Track document.

>

> Mar 2013             Submit JSON object encryption document (2) to IESG for consideration as Standards Track document.

>

> Mar 2013             Submit JSON key format document (3) to IESG for consideration as Standards Track document.

>

> Mar 2013             Submit JSON algorithm document (4) to IESG for consideration as Standards Track document.

>

> Mar 2013             Submit multi-recipient JSON object integrity document (5) as a WG item.

>

> Mar 2013             Submit multi-recipient JSON object encryption document (6) as a WG item.

>

> Mar 2013             Submit JSON private and symmetric key document (7) as a WG item.

>

> Mar 2013             Submit JSON key protection application document (8) as a WG item.

>

> Jun 2013              Start Working Group Last Call on multi-recipient JSON object integrity document (5).

>

> Jun 2013              Start Working Group Last Call on multi-recipient JSON object encryption document (6).

>

> Jun 2013              Start Working Group Last Call on JSON private and symmetric key document (7).

>

> Jun 2013              Start Working Group Last Call on JSON key protection application document (8).

>

> Jul 2013               Submit multi-recipient JSON object integrity document (5) to IESG for consideration as Standards Track document.

>

> Jul 2013               Submit multi-recipient JSON object encryption document (6) to IESG for consideration as Standards Track document.

>

> Jul 2013               Submit JSON private and symmetric key document (7) to IESG for consideration as Standards Track document.

>

> Jul 2013               Submit JSON key protection application document (8) to IESG for consideration as Standards Track document.

>

> _______________________________________________

> jose mailing list

> jose@ietf.org<mailto:jose@ietf.org>

> https://www.ietf.org/mailman/listinfo/jose



_______________________________________________

jose mailing list

jose@ietf.org<mailto:jose@ietf.org>

https://www.ietf.org/mailman/listinfo/jose