Agree. Algorithm agility is a must, but large numbers of supported algorithms out of the gate are not. Having a small set of algorithms widely-implemented will increase interoperability drastically, particularly considering that in some of the target operating environments, we'll need to wait for people with adequate cryptographic skills to help.
I do really like the idea of splitting the MTI specification into a small separate draft, so that it can be rev'd easily as needed. On 8/8/11 1:04 PM, "John Bradley" <[email protected]> wrote: > Hal, > > JWE/JWS supports multiple algorithms. I haven't seen any argument to not > have algorithm ajility. > > There was a mention of what algorithms should be MTI. I expect that > discussion will continue. (It is still gong on for xmlenc/xmldeig over at > W3C) > > We clearly need multiple algorithms, in my opinion. > > John B. > On 2011-08-08, at 2:28 PM, Hal Lockhart wrote: > >> 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 > > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
