There seems to be a position forming around the idea that woes/joes/jose should specify (perhaps even design) a single algorithm (perhaps one for sign and one for encrypt). I presume that means that if in future it was necessary to use a different algorithm we would just start over and write a new spec.
I am not in favor of this, but I concede that it would simplify things in this group a lot. If there was only one algorithm, there is no need for any JSON metadata about what the algorithm is being used. All we need is a way to indicate what is signed or encrypted and something that says this is a JOES signature (or encryption) and perhaps some kind of indication of what key was used. If we were to specify only one algorithm, but provide metadata to indicate the algorithm, others will use additional, unspecified algorithms, just as people used 3-DES and AES in Kerberos while continuing to cite RFC 1510 which only includes DES. I won't bother to list the many (many, many) reasons why a single algorithm is unlikely to fly, unless it turns out a lot of people are really committed to that view. Instead, I suggest we say explicitly say that multiple algorithms will be possible, but one will be MTI. It wouldn't hurt to also say we are not going to design any new algorithms, but simply provide means to specify which existing one is being used. Hal > -----Original Message----- > From: Jeremy Laurenson [mailto:[email protected]] > Sent: Saturday, August 06, 2011 12:31 AM > To: [email protected] > Subject: Re: [woes] Proposed charter, post-Quebec edition > > > 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 > _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
