Re: [jose] AD review of re-charter (was Re: updated JOSE charter sent to IESG)
Sean Turner <turners@ieca.com> Wed, 27 February 2013 15:04 UTC
Return-Path: <turners@ieca.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 9AEF621F8659 for <jose@ietfa.amsl.com>; Wed, 27 Feb 2013 07:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.116
X-Spam-Level:
X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 JwP5eXV3FMZC for <jose@ietfa.amsl.com>; Wed, 27 Feb 2013 07:04:53 -0800 (PST)
Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.154.37]) by ietfa.amsl.com (Postfix) with ESMTP id C8DDA21F86EB for <jose@ietf.org>; Wed, 27 Feb 2013 07:04:52 -0800 (PST)
Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 5B9468A360BB1; Wed, 27 Feb 2013 09:04:52 -0600 (CST)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 4B61B8A360B5B for <jose@ietf.org>; Wed, 27 Feb 2013 09:04:52 -0600 (CST)
Received: from [108.45.16.214] (port=63134 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1UAiYt-00073T-RD; Wed, 27 Feb 2013 09:04:52 -0600
Message-ID: <512E2093.1040803@ieca.com>
Date: Wed, 27 Feb 2013 10:04:51 -0500
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>
References: <510AF04B.8060503@isoc.org> <512BD65E.9090306@ieca.com> <4E1F6AAD24975D4BA5B1680429673943674A6B7F@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674A6B7F@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [108.45.16.214]:63134
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 4
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] AD review of re-charter (was Re: updated JOSE charter sent to IESG)
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: Wed, 27 Feb 2013 15:04:54 -0000
On 2/25/13 4:33 PM, Mike Jones wrote: > I mostly agree with this. I'll quibble with only one point. By > deleting (5) and (6) and leaving (1) and (2) as-is, you're pre-supposing > that the existing compact serializations and the JSON serializations get > consolidated into combined documents. If instead, you simply changed > the phrase "A Standards Track document specifying how to..." in (1) and > (2) to "A Standards Track document *or documents* specifying how to...", > we could get the same effect of having (5) and (6), but without having > to pre-decide how the solutions should be allocated between documents. > > Would that work for you, Sean? That'd work for me. spt > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Monday, February 25, 2013 1:24 PM > To: jose@ietf.org > Subject: [jose] AD review of re-charter (was Re: updated JOSE charter > sent to IESG) > > I have some comments on the proposed charter that I've embedded below. > > On 1/31/13 5:29 PM, Karen O'Donoghue wrote: > > > Below is the updated charter that has been submitted to the IESG for > > > review. Thank you to all who helped with the process. > > > > > > Regards, > > > Karen > > > > > > Description of JOSE 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. > > I don't think of key representations as a security service and maybe I > let this through last time but the things listed as services are > mechanisms. In most cases, the services are CIA (confidentiality, > integrity, and authentication). Let's change the last sentence to: > > With the increased usage of JSON in protocols in the IETF > > and elsewhere, there is now a desire to offer security > > services for JSON with encryption, digital signatures, > > and message authentication codes (MACs). > > We can add that the key representations are needed later. > > > 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. > > Not sure a key representations is a service and maybe I'm nitpicking but > I think encryption is a mechanism. Let's do instead: > > The Working Group will standardize the mechanism for integrity > > protection (signature and MAC) and encryption as well as the format > > for keys and algorithm identifiers to support interoperability of > > security services for 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. > > "correct" seems like the wrong word. How about "sound". > > > This group is chartered to work on eight documents: > > Let's just drop the # in this sentence and change it to: > > This group is chartered to work on the following deliverables: > > > (1) A Standards Track document specifying how to apply JSON-structured > > > integrity protection to data, including (but not limited to) JSON data > > > structures, including 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, including a compact URL-safe representation. > > Because the IESG will look at the diffs, the addition of "including a > compact URL-safe representation" in (1) and (2) as well as the addition > of (5) and (6) will no doubt raise questions. > > The first will be why are we baking the solution in to the charter? > > Based on recent discussions about and revisions to the proposed httpauth > charter, baking solutions in or placing constraints on the solution in > the form or examples/"includings" in the charters isn't going to fly. > > What charters ought to do is say where the WG wants to go and then the > drafts say how they're getting there. > > The second will obviously be why on earth would a WG solution not > support the same kind of basic functionality that the well-known > security primitives support. If the WG decides on more than one > serialization/representation is needed for whatever reason, then the > drafts can explain why there's more than one. > > Based on all of this, bullets 1 and 2 should remain unchanged and 5 and > > 6 need not be added: > > (1) A Standards Track document specifying how to apply JSON-structured > integrity protection to data, including (but not limited to) JSON data > structures. "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. > > (3) looks fine. > > > (3) A Standards Track document specifying how to encode public keys as > > > JSON- > > > structured objects. > > I like this (4) better because MTI should be specified by the application. > > > (4) A Standards Track document specifying algorithms and algorithm > > > identifiers for the previous three documents. > > As above for 5 and 6. > > > (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). > > I think these are fine but I can't really think of a reason to not > combine them. > > > (7) A Standards Track document specifying how to encode private and > > r/7/5 > > > 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 > > r/8/6 > > > 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). > > Is "application" needed in in the first sentence? > > From Karen, we'll also add in: > > (7) An Informational document detailing Use Cases and > > Requirements for JSON Object Signing and Encryption (JOSE). > > > 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). > > I want to change this as follows because it's not just the WG's decision: > > One or more of these goals may be combined into a single > > document, in which case the concrete milestones for these > > goals will be satisfied by the consolidated document(s). > > We also need some additional wording to explain how JOSE isn't going to > specify everything an application/use case needs to achieve complete > interop. I'm basing this on the recent bashing some OAUTH drafts took > and the way JOSE seems to be shaping up. I'd suggest something along > the lines of the following to provide additional lead in: > > As JSON adoption expands, the different applications utilizing > > JSON security services will grow and this leads to the need to > > support different requirements. The WG will develop a generic > > syntax that can be used by applications to secure JSON-data, > > but it will be up to the application to fully specify the use > > of the WG's documents much the same way S/MIME is the > > application of CMS to MIME-based media types. > > And we need a draft that tells an application all the things that would > need to be specified/picked to implement JOSE. This could go in the use > cases or in a new document. You're call. > > spt > > _______________________________________________ > > jose mailing list > > jose@ietf.org <mailto:jose@ietf.org> > > https://www.ietf.org/mailman/listinfo/jose >
- [jose] updated JOSE charter sent to IESG Karen O'Donoghue
- [jose] AD review of re-charter (was Re: updated J… Sean Turner
- Re: [jose] AD review of re-charter (was Re: updat… Mike Jones
- Re: [jose] AD review of re-charter (was Re: updat… Sean Turner
- Re: [jose] AD review of re-charter (was Re: updat… Sean Turner