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: [email protected] [mailto:[email protected]] On Behalf Of
Sean Turner
Sent: Monday, February 25, 2013 1:24 PM
To: [email protected]
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
