On Thu, 2011-08-04 at 09:03 -0400, Sean Turner wrote: > 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).
I don't agree. I believe we should be able to use this useful plumbing to ensure integrity/authenticity without having to rely exclusively on public key cryptography. > > 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. I agree, though IMO the sooner we can get strawman drafts out to start taking shots at, the better. > spt > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
