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

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

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Mike Jones
> Sent: Monday, March 11, 2013 1:22 PM
> To: odonoghue@isoc.org; jose@ietf.org
> Subject: Re: [jose] updated draft charter text incorporating AD's
> comments
> 
> Looks good to me
> 
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Karen O'Donoghue
> Sent: Sunday, March 10, 2013 11:13 AM
> To: jose@ietf.org
> 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
> 
> 
> 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).
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

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