On 8/2/11 7:13 PM, Paul Hoffman wrote:
Here is a proposal for the charter based on the discussion in the BoF last week
and later discussion with Sean Turner. Comments, praise, scorn, etc., are
welcome.
--Paul and Richard
Javascript Object Signing and Encrypting (jose)
===============================================
Background
----------
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 and digital
signatures for data that is being carried in JSON format.
Different proposals for providing such security services have already been
defined and implemented. This Working Group's task is to standardize two
security services, encrypting and digitally signing, in order to increase
interoperability of security features between 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.
This group is chartered to work on four documents:
1) A Standards Track document specifying how to apply a JSON-structured digital signature
to data, including (but not limited to) JSON data structures. "Digital
signature" is defined as a hash operation followed by a signature operation using
asymmetric keys.
I just want to make sure that we agree now that a digital signature is a
hash followed by a signature algorithm (e.g., RSA with SHA-256). I've
seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256)
was a digital signature; one called it a symmetric key based digital
signature algorithm (note this phrase didn't get through the IESG).
2) A Standards Track document 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 mandatory-to-implement algorithms for
the other three documents.
I think this addition is good. In the past we've bundled the MTI
algorithms with the protocol and then reving the MTI algorithms caused
unnecessary churn on the protocol even if the protocol is stable.
I also think this draft need not only include MTI algorithms, but the
draft definitely needs to say which ones are the MTI algorithms.
The working group may decide to address one or more of these goals in a single
document, in which case the concrete milestones for signing/encryption below
will both be satisfied by the single document.
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.
Aug 2011 Submit JSON key format document as a WG item.
Aug 2011 Submit JSON algoritm document as a WG item.
Jan 2012 Start Working Group Last Call on JSON object signing document.
Jan 2012 Start Working Group Last Call on JSON object encryption document.
Jan 2012 Start Working Group Last Call on JSON key format document.
Jan 2012 Start Working Group Last Call on JSON algorithm document.
Feb 2012 Submit JSON object signing document to IESG for consideration as
Standards Track document.
Feb 2012 Submit JSON object encryption document to IESG for consideration
as Standards Track document.
Feb 2012 Submit JSON key format document to IESG for consideration
as Standards Track document.
Feb 2012 Submit JSON algorithm document to IESG for consideration
as Standards Track document.
The dates are little ambitious. Just based on the process, I doubt this
can be charter by the end of August. I'd swap Aug->Oct, Jan->Mar, and
leave Feb as-is.
spt
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
