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

[Sean Turner <[e-mail]>]

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
>