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

From: Sean Turner <[email-masked]>
Date: Mon, 25 Feb 2013 16:23:42 -0500

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 25 Feb 2013 21:33:09 +0000

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?

                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, February 25, 2013 1:24 PM
To: [email-masked]
Subject: [jose] AD review of re-charter (was Re: updated JOSE charter sent to IESG)

> 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

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

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

> solicit input from the rest of the IETF Security Area to be sure that

> the security functionality in the JSON format is correct.

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

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.

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.

> identifiers for the previous three documents.

As above for 5 and 6.

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

r/7/5

> concepts and structures in (3).

> (8) A Standards Track application document specifying a means of

> protecting

r/8/6

> upon the concepts and structures in (2) and (7).  This document may

> register additional algorithms in registries defined by (4).

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

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-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose

---

From: Sean Turner <[email-masked]>
Date: Wed, 27 Feb 2013 10:04:51 -0500

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

That'd work for me.

spt

> [email-masked] <mailto:[email-masked]>
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 27 Feb 2013 10:05:28 -0500

Any other comments on the suggested changes?

spt

On 2/25/13 4:23 PM, Sean Turner wrote:
> [email-masked]