>From a Javascript dev perspective, specifying an algorithm will make it a hell >of of lot easier to implement, instead of having to potentially account for >multiples.
Lets use the example of a web app that aggregates social media data - just for giggles - and uses WOES to secure the communications to well-defined interfaces If multiple vendors' websites implement WOES/JOES/JOSE with different algorithms, it becomes more complex vs a single, consistent one. On Aug 5, 2011, at 2:16 PM, Sean Turner wrote: > So I'll bite on this ;) > > I think we can write the spec to require a particular algorithm choice, but > it might make more sense to define the options and then allow the environment > in which the solution will be used to specify it's requirements. But, I > believe that is a discussion we'll have while writing the spec. > > spt > > On 8/4/11 9:29 AM, John Bradley wrote: >> HMAC is requirement for adoption in the JWS use cases. >> >> If we want to describe it as something other than a "Qualified Digital >> Signature", that is fine as long as it is MTI:) >> >> John B. >> >> >> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote: >> >>> >>> >>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email protected] >>> <mailto:[email protected]>> 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). >>> >>> >>> An HMAC is not a digital signature, but the spec definitely needs to >>> be able to cover MAC based authentication. >>> >>> >>> I know that public key is getting easier as far as computation goes. >>> But for many applications the non-repudiation you get in digital >>> signatures is actually undesirable. >>> >>> There are interesting tricks you can do with symmetric crypto that are >>> much harder to do in public key and end up with some scheme that only >>> 50 academics in the world can follow and has a security proof that >>> rest on rather esoteric assumptions. >>> >>> -- >>> Website: http://hallambaker.com/ >>> >>> _______________________________________________ >>> woes mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/woes >> > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
