Re: [jose] updated draft charter text incorporating AD's comments

[Mike Jones <[e-mail]>]

Hmmm...  I feel really queasy about the proposed rewording for (1), as it could lead to significant unintended consequences and potential obstacles when we go for final approval of the JWS and JWE specs.  Here's why...



The wording could easily be interpreted as a mandate that the end-representation itself be JSON - not just that the representation utilize JSON for representing structured data, which is what is actually the case now.  I could easily imagine the new wording enabling a situation where someone would then file a DISCUSS saying that the current Compact Serialization representations aren't JSON and so don't meet the requirements of the charter.



For that reason, I believe we would be FAR better off to leave the first two charter items exactly as they are at http://datatracker.ietf.org/wg/jose/charter/ than to accept the new wording.  The current wording is:



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.



So yes, I strongly object to the new wording, as I don't want to open the door for the current representations to be rejected on charter grounds later.  If it helps, you can reassure objectors that we ARE producing pure JSON representations too, but that they're not the only JSON-based representations for integrity protected and encrypted content.



Why don't we just scale back the recharter request to only add the new items and leave the existing items alone, if that's what it will take to be approved.



                                                            Thanks for asking,

                                                            -- Mike



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Sean Turner
Sent: Friday, April 05, 2013 5:29 AM
To: [e-mail]
Subject: Re: [jose] updated draft charter text incorporating AD's comments



Hi,



We've gotten what amounts to two discusses on the charter.  I wanted to run these by the WG in case there were any violent objections.



1. (easy one first) What does "JSON-structured integrity protection" and "JSON-structured encryption" mean?



It was explained "JSON-structured" means that the metadata about how you did the encryption/integrity is expressed in JSON not that the payload itself is JSON.  I.e., the algorithm description, key identifiers, etc.

are in JSON but not necessary the payload.



I proposed:



OLD:



   specifying how to apply JSON-structured integrity

   protection to data



NEW:



   specifying a JSON structure for integrity-protected data



and the same again for encryption:



OLD:



   specifying how to apply a JSON-structured encryption to data



NEW:



   specifying a JSON structure for encrypted data



2. (hard one) Barry's been told by some App folks who are working on new JSON-based protocols that they don't see the applicability of JOSE to their work.



I think there is some concern that we're doing our own thing here in security land and not consulting with others.  That's not a true characterization based the use case we have from ALTO and XMPP, but

nonetheless this feedback worries both Barry and myself.   What I'm

going to do is prompt/prod the Apps folks to engage and say why/how it won't work for them.  What we might also do is some education in the appsawg; one of those here's how it works kind of presentations.  We'll reach out, but they need to reach out too because I don't want to have to be pinned waiting on a input that may never come.  To that end, putting some wording in the charter earlier than the numbered bullet about the uses cases, I think, solves this dilemma:



   The WG will strive to gather use cases to ensure the broadest

   possible applicability of the mechanism.



spt



On 3/10/13 2:13 PM, Karen O'Donoghue wrote:

> Folks,

>

> Here is the updated charter text based on Sean's comments and Mike's

> response. If there are any errors, please identify them asap as I plan

> to forward this back to Sean (and thus the IESG) in the very near future.

>

> 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 for JSON with encryption, digital signatures, and

> message authentication codes (MACs).

>

> Different proposals for providing such security services have already

> been defined and implemented.  This 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 sound.

>

> 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.

>

> This group is chartered to work on the following deliverables:

>

> (1) A Standards Track document or documents 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 or documents 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 algorithms and algorithm

> identifiers for the previous three documents.

>

> (5) 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).

>

> (6) A Standards Track document specifying a means of protecting

> private and symmetric keys via encryption.  This document will build

> upon the concepts and structures in (2) and (5).  This document may

> register additional algorithms in registries defined by (4).

>

> (7) An Informational document detailing Use Cases and Requirements for

> JSON Object Signing and Encryption (JOSE).

>

> (8) An Informational document that tells an application what needs to

> be specified in order to implement JOSE.

>

> 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).

>

> _______________________________________________

> jose mailing list

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

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

>

_______________________________________________

jose mailing list

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

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