+1 This is exactly what the DNSSEC community has done. <http://tools.ietf.org/html/rfc6014>
On Aug 8, 2011, at 3:48 PM, Joe Hildebrand wrote: > 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 _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
