Subject: [woes] WOES Charter Proposal

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Jun 2011 15:24:53 +0300

Web Object Encryption and Signing (woes)
========================================

Background
----------

JSON (an acronym for JavaScript Object Notation) is a text format for
the serialization of structured data. It is derived from the JavaScript
programming language for representing simple data structures and
associative arrays, called objects. Despite its relationship to
JavaScript, it is language-independent, with parsers available for
almost every programming
language.

The JSON format is described in RFC 4627 and builds on two structures:
* A collection of name/value pairs. In various languages, this is
realized as an object, record, struct, dictionary, hash table, keyed
list, or associative array.
* An ordered list of values. In most languages, this is realized as an
array, vector, list, or sequence.

The JSON format is often used for serializing and transmitting
structured data over a network connection. It was initially used in the
Web environment to transmit data between a server and web application,
serving as an alternative to XML. Now, JSON is being used in various
other protocols as well.

With the increased usage of JSON in protocols there is now also the
desire to offer security services, such as encryption, and message
signing, for JSON encoded data. Different proposals for providing these
security services have been defined and implemented.  Examples are: JSON
Web Token [JWT], Simple Web Tokens [SWT], Magic Signatures
[MagicSignatures], JSON Simple Sign [JSS], JavaScript Message Security
Format [JSMS]. 

This working group aims to develop specifications to standardize these
security services for JSON encoded data to improve interoperability, and
to increase confidence in the offered security functionality based on
the expert review process utilized in the IETF. Future work in the group
may offer support for other security services. Re-chartering of the
group is, however, required.

This working group aims to re-use well-defined concepts from
Cryptographic Message Syntax
(CMS) [CMS], XML Digital Signature [XMLDSIG] and XML Encryption [XMLENC]
since the group aims to develop a JavaScript-developer-friendly
JSON-equivalent for CMS. 

Since this work is within the realm of the security domain respective
experts will be involved. 

References
----------

[JWT] M. Jones, et al. "JSON Web Signature (JWS)",
draft-jones-json-web-signature-01 (work in progress), Mar. 2011.

[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign",
September 2010.

[MagicSignatures] Panzer (editor), J., Laurie, B., and D. Balfanz,
"Magic Signatures", August 2010.

[SWT] Hardt, D. and Y. Goland, "Simple Web Token (SWT)", Version
0.9.5.1, November 2009.

XMLDIG] W3C, "XML Signature Syntax and Processing (Second Edition)",
available at
http://www.w3.org/TR/xmldsig-core/, Jun. 2008. 

[XMLENC] W3C, "XML Encryption Syntax and Processing", available at
http://www.w3.org/TR/xmlenc-core/, Dec. 2002.

[CMS]  R. Housley, "Cryptographic Message Syntax", RFC 3852, Jul. 2004. 

[JSMS] E. Rescorla, J. Hildebrand, "JavaScript Message Security Format",
draft-rescorla-jsms-00 (work in progress), Mar. 2011.

Deliverables
------------

This group is chartered to work on two documents: 

1) A Standards Track document specifying how to apply a digital
signature and a keyed message digest to 
JSON encoded data.

2) A Standards Track document illustrating how to encrypt JSON encoded
data. 

Goals and Milestones
--------------------

Aug 2011    Submit JSON object signing document as a WG item.

Aug 2011    Submit JSON object encryption document as a WG item.

Mar 2012    Start Working Group Last Call on JSON object signing
document.

Mar 2012    Start Working Group Last Call on JSON object encryption
document.

Apr 2012    Submit JSON object signing document to IESG for
consideration as
Standards Track document.

Apr 2012    Submit JSON object encryption document to IESG for
consideration
as Standards Track document.

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Jun 2011 12:31:07 -0400

Thanks for kicking this off Hannes.  In Prague, I thought the goal was 
pretty straightforward: JSONize CMS.  To that end I think we can clip 
out some of the references to work already done.  The BOF can decide 
later what draft is the basis for the starting point.

Edits as follows - and one embedded question:

On 6/14/11 8:24 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> almost every programming language.
>
> signing, for JSON encoded data.

<delete>
> Different proposals for providing these
</delete>

> security services for JSON encoded data to improve interoperability, and

r/these security services/these two security services

> the expert review process utilized in the IETF.

<delete>
> Future work in the group
> _http://www.w3.org/TR/xmldsig-core/_, Jun. 2008.
>
> _http://www.w3.org/TR/xmlenc-core/_, Dec. 2002.
>

</delete>

<insert>

This working group will base its work on the Cryptographic Message 
Syntax (CMS).

Anything other work items beyond the two listed below are out of scope 
and will require a recharter.

</insert>

> Deliverables

<question>

I want to be clear that when we're talking about digital signatures 
we're not talking about HMAC-y operations.  If you want to include this 
here then it need to be reflected earlier as something different than 
digital signatures.

</question>

> Mar 2012 Start Working Group Last Call on JSON object signing document.
>
> Mar 2012 Start Working Group Last Call on JSON object encryption document.
>
> Apr 2012 Submit JSON object signing document to IESG for consideration as
> Apr 2012 Submit JSON object encryption document to IESG for consideration
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 15 Jun 2011 11:07:10 +1000

Sean,

I would make almost the opposite edits to the charter than you.
I think it is really helpful that the charter lists different existing proposals (JWT, SWT, MagicSigs, JSS, JSMS). They provides a great context for the WG; they show different approaches; they show people want something in this space.
I think most of the JSON background can be dropped.

  >later what draft is the basis for the starting point.

  ...
  <delete>
  </delete>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 15 Jun 2011 10:44:29 +0300

I put the JSON background there because the purpose of the working group
is meant to be understood also by those who have not been involved in
the work.  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Manger, James H
> Sent: Wednesday, June 15, 2011 4:07 AM
> To: Sean Turner; [email-masked]
> Subject: Re: [woes] WOES Charter Proposal
> 
> Sean,
> 
> I think it is really helpful that the charter lists different 
> existing proposals (JWT, SWT, MagicSigs, JSS, JSMS). They 
> provides a great context for the WG; they show different 
> approaches; they show people want something in this space.

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Jun 2011 17:26:37 +0000

One change I'd request to the draft charter is that the group should be chartered to produce one or more documents - not exactly two documents, per the current proposal.  That leaves the working group free to factor the solution as makes best sense to the group.  I'd change that section of the document to:

    This group is chartered to work on one or more Standards Track documents defining the following functionality: 

    1) A JSON-based method of applying digital signatures and keyed message digests to data that may represent JSON data structures.

    2) A JSON-based method of applying encryption to data that may represent JSON data structures.

Separately, we may want to consider whether the following should be in scope:

    3) A JSON-based method of representing public keys.

Also, please update and/or add these references (some were out of date, some were missing):

    [JWS] M. Jones, et al. "JSON Web Signature (JWS)", draft-jones-json-web-signature-02 (work in progress), Apr. 2011.

    [JWT] M. Jones, et al. "JSON Web Token (JWT)", draft-jones-json-web-token-04 (work in progress), Mar. 2011.

    [JWK] M. Jones. "JSON Web Key (JWK)", draft-jones-json-web-token-00 (work in progress), Apr. 2011.

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Wednesday, June 15, 2011 12:44 AM
To: ext Manger, James H; Sean Turner; [email-masked]
Subject: Re: [woes] WOES Charter Proposal

I put the JSON background there because the purpose of the working group is meant to be understood also by those who have not been involved in the work.  

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of ext Manger, James H
> I think it is really helpful that the charter lists different existing 
> proposals (JWT, SWT, MagicSigs, JSS, JSMS). They provides a great 
> context for the WG; they show different approaches; they show people 
> want something in this space.

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 16 Jun 2011 11:33:11 -0600

Slight tweaks

On 6/16/11 11:26 AM, "Mike Jones" <[email-masked]> wrote:

>     1) A JSON-based method of applying digital signatures and keyed message
> digests to data that may represent JSON data structures.

... may represent arbitrary data, including JSON data structures and text

>     2) A JSON-based method of applying encryption to data that may represent

Same as 1) above.  Not just for JSON.

> Also, please update and/or add these references (some were out of date, some

Let's also add:

4) Any JSON-specific prerequisite tooling such as JSON Schema

And add draft-zyp-json-schema as a reference.  I CC'd Kris Zyp to see if
he's ok with that.  Kris: this might be a chance for a WG to pick up JSON
Schema if you like.

-- 
Joe Hildebrand

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Jun 2011 17:48:56 +0000

Agreed

-----Original Message-----
From: Joe Hildebrand [mailto:[email-masked]] 
Sent: Thursday, June 16, 2011 10:33 AM
To: Mike Jones; Tschofenig, Hannes (NSN - FI/Espoo); ext Manger, James H; Sean Turner; [email-masked]; [email-masked]
Subject: Re: [woes] WOES Charter Proposal

Slight tweaks

On 6/16/11 11:26 AM, "Mike Jones" <[email-masked]> wrote:

>     1) A JSON-based method of applying digital signatures and keyed 
> message digests to data that may represent JSON data structures.

Let's also add:

And add draft-zyp-json-schema as a reference.  I CC'd Kris Zyp to see if he's ok with that.  Kris: this might be a chance for a WG to pick up JSON Schema if you like.

--
Joe Hildebrand

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jun 2011 18:51:58 +0100

3 & 4 there look a bit like scope-creep to me

Why are they absolutely needed?

S.

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Jun 2011 18:14:43 +0000

About (3), you sign and encrypt things with keys.  The header/envelope often references the key, which must have a known representation.  In a JSON-based world, it's often simpler to represent public keys as JSON rather than ASN.1 (for the same reasons that we're considering JSON signatures and encryption when we already have CMS).  It's not creep - it's providing a complete JSON-based signing/encryption solution.

I personal agree that (4) schemas is creep, but I support Joe's desire to have it considered as an input document.

				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, June 16, 2011 10:52 AM
To: Joe Hildebrand
Cc: Mike Jones; Tschofenig, Hannes (NSN - FI/Espoo); ext Manger, James H; Sean Turner; [email-masked]; [email-masked]
Subject: Re: [woes] WOES Charter Proposal

S.

On 16/06/11 18:33, Joe Hildebrand wrote:
> And add draft-zyp-json-schema as a reference.  I CC'd Kris Zyp to see 
> if he's ok with that.  Kris: this might be a chance for a WG to pick 
> up JSON Schema if you like.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jun 2011 19:43:28 +0100

> About (3), you sign and encrypt things with keys.  The header/envelope often references the key, which must have a known representation.  In a JSON-based world, it's often simpler to represent publ…

And you need algorithm ids and parameters and a way to represent hmac outputs etc but those are not called out specifically which makes (3) look like a slippery slope.

> I personal agree that (4) schemas is creep, but I support Joe's desire to have it considered as an input document.

I'm thinking in charter terms, this is the first I think I've heard of non crypto work being proposed here (sorry if I missed that).

Simpler, more tightly scoped, charters seem to get approved easier,

Cheers 
S

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Jun 2011 18:47:02 +0000

For what it's worth, the HMAC and signature output representations to use *are* explicitly specified in the JWS and JWT specs (which is necessary to achieve interoperability).

				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, June 16, 2011 11:43 AM
To: Mike Jones
Cc: Joe Hildebrand; Tschofenig, Hannes (NSN - FI/Espoo); extManger, James H; Sean Turner; [email-masked]; [email-masked]
Subject: Re: [woes] WOES Charter Proposal

Cheers 
S

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 16 Jun 2011 13:21:56 -0600

Agree that 4 is scope creep that is outside of the scope of normal security
area stuff, but it's likely to be a prereq.  I'm fine with dropping it from
the charter, potentially getting support from the Apps ADs to move stuff
like JSON Schema through the Apps AWG.

-- 
Joe Hildebrand