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

[Richard Barnes <[e-mail]>]

On Fri, Apr 5, 2013 at 9:28 AM, Mike Jones <[e-mail]>wrote:

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

That won't be a problem as long as there is *a* JSON representation in the
base specification.  Which we have agreed to do.

--Richard




> ****
>
> ** **
>
> 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]****
>
> > https://www.ietf.org/mailman/listinfo/jose****
>
> >** **
>
> _______________________________________________****
>
> jose mailing list****
>
> [e-mail]****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>