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]
https://www.ietf.org/mailman/listinfo/jose
