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

[Sean Turner <[e-mail]>]

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: [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
>