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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
