We absolutely need to make a choice on algorithms. What I am saying is that I would like to make the choice once every three years or so as an IETF-wide issue and not have to revisit it in every new WG and have each WG go through the same discussion.
On Sat, Aug 6, 2011 at 12:30 AM, Jeremy Laurenson <[email protected]>wrote: > 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 > -- Website: http://hallambaker.com/
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
