Subject: [jose] updated draft charter text incorporating AD's comments

From: Karen O'Donoghue <[email-masked]>
Date: Sun, 10 Mar 2013 14:13:05 -0400

Folks,

Here is the updated charter text based on Sean's comments and Mike's 
response. If there are any errors, please identify them asap as I plan 
to forward this back to Sean (and thus the IESG) in the very near future.

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 for JSON with encryption, digital signatures, and 
message authentication
codes (MACs).

Different proposals for providing such security services have already 
been defined
and implemented.  This 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 sound.

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.

This group is chartered to work on the following deliverables:

(1) A Standards Track document or documents 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 or documents specifying how to apply a 
JSON-structured
encryption to data, including (but not limited to) JSON data structures.

(3) A Standards Track document specifying how to encode public keys as JSON-
structured objects.

(4) A Standards Track document specifying algorithms and algorithm 
identifiers for
the previous three documents.

(5) A Standards Track document specifying how to encode private and 
symmetric
keys as JSON-structured objects.  This document will build upon the 
concepts and
structures in (3).

(6) A Standards Track document specifying a means of protecting private 
and symmetric
keys via encryption.  This document will build upon the concepts and 
structures in (2)
and (5).  This document may register additional algorithms in registries 
defined by (4).

(7) An Informational document detailing Use Cases and Requirements for 
JSON Object
Signing and Encryption (JOSE).

(8) An Informational document that tells an application what needs to be 
specified in order
to implement JOSE.

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Mar 2013 17:22:05 +0000

Looks good to me

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Sunday, March 10, 2013 11:13 AM
To: [email-masked]
Subject: [jose] updated draft charter text incorporating AD's comments

Folks,

Here is the updated charter text based on Sean's comments and Mike's response. If there are any errors, please identify them asap as I plan to forward this back to Sean (and thus the IESG) in the very near future.

Regards,
Karen

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 for JSON with encryption, digital signatures, and message authentication codes (MACs).

Different proposals for providing such security services have already been defined and implemented.  This 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 sound.

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.

(1) A Standards Track document or documents 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 or documents specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.

(3) A Standards Track document specifying how to encode public keys as JSON- structured objects.

(4) A Standards Track document specifying algorithms and algorithm identifiers for the previous three documents.

(5) A Standards Track document specifying how to encode private and symmetric keys as JSON-structured objects.  This document will build upon the concepts and structures in (3).

(6) A Standards Track document specifying a means of protecting private and symmetric keys via encryption.  This document will build upon the concepts and structures in (2) and (5).  This document may register additional algorithms in registries defined by (4).

(7) An Informational document detailing Use Cases and Requirements for JSON Object Signing and Encryption (JOSE).

(8) An Informational document that tells an application what needs to be specified in order to implement JOSE.

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

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Dan Brown <[email-masked]>
Date: Mon, 11 Mar 2013 18:44:43 +0000

I just joined JOSE, and have a brief comment about JWA:

For ECC-based encryption, it may make sense to use ECIES, because it complies with ANSI X9.63, IEEE P1363, ISO 18033-2, and SEC1.  (The current CMS-based approach is slightly different.)  If the list has already discussed this issue, then please excuse me (and point me to the archive thread).

Best regards,

Daniel Brown
Research In Motion Limited

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike Jones
> Sent: Monday, March 11, 2013 1:22 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [jose] updated draft charter text incorporating AD's
> comments
> 
> Looks good to me
> 
> 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
> message authentication codes (MACs).
> 
> been defined and implemented.  This 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 sound.
> 
> security services will grow and this leads to the need to support
> different requirements.
> The WG will
> 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.
> 
> JSON-structured integrity protection to data, including (but not
> limited to) JSON data structures.
> JSON-structured encryption to data, including (but not limited to) JSON
> data structures.
> 
> identifiers for the previous three documents.
> 
> symmetric keys as JSON-structured objects.  This document will build
> upon the concepts and structures in (3).
> 
> and symmetric keys via encryption.  This document will build upon the
> concepts and structures in (2) and (5).  This document may register
> additional algorithms in registries defined by (4).
> 
> JSON Object Signing and Encryption (JOSE).
> 
> which case the concrete milestones for these goals will be satisfied by
> the consolidated document(s).
> 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.