Re: [jose] AD review of re-charter (was Re: updated JOSE charter sent to IESG)

[Mike Jones <[e-mail]>]

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?



                                                            -- Mike



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Sean Turner
Sent: Monday, February 25, 2013 1:24 PM
To: [e-mail]
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

[e-mail]<mailto:[e-mail]>

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