Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
Joe Hildebrand <joe.hildebrand@webex.com> Mon, 08 August 2011 19:47 UTC
Return-Path: <Joe.Hildebrand@webex.com>
X-Original-To: woes@ietfa.amsl.com
Delivered-To: woes@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F3A11E8097 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 12:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.307
X-Spam-Level:
X-Spam-Status: No, score=-104.307 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEL7vH90ui8O for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 12:47:44 -0700 (PDT)
Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by ietfa.amsl.com (Postfix) with SMTP id 6894311E808F for <woes@ietf.org>; Mon, 8 Aug 2011 12:47:43 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Aug 2011 12:48:09 -0700
Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Mon, 8 Aug 2011 19:48:09 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Mon, 08 Aug 2011 13:48:08 -0600
From: Joe Hildebrand <joe.hildebrand@webex.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Hal Lockhart <hal.lockhart@oracle.com>
Message-ID: <CA659998.D933%joe.hildebrand@webex.com>
Thread-Topic: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
Thread-Index: AcxWBBihrIk46guWokim1psemdr46w==
In-Reply-To: <02FA13F0-131C-4BD9-AA41-E14E48403040@ve7jtb.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 08 Aug 2011 19:48:09.0847 (UTC) FILETIME=[19BB6070:01CC5604]
Cc: "woes@ietf.org" <woes@ietf.org>
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
X-BeenThere: woes@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/woes>, <mailto:woes-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/woes>
List-Post: <mailto:woes@ietf.org>
List-Help: <mailto:woes-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/woes>, <mailto:woes-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 19:47:45 -0000
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" <ve7jtb@ve7jtb.com> 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:jlaurens@cisco.com] >>> Sent: Saturday, August 06, 2011 12:31 AM >>> To: woes@ietf.org >>> 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 <turners@ieca.com >>>>>> <mailto:turners@ieca.com>> 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 >>>>>> woes@ietf.org <mailto:woes@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/woes >>>>> >>>> _______________________________________________ >>>> woes mailing list >>>> woes@ietf.org >>>> https://www.ietf.org/mailman/listinfo/woes >>> >>> _______________________________________________ >>> woes mailing list >>> woes@ietf.org >>> https://www.ietf.org/mailman/listinfo/woes >>> >> _______________________________________________ >> woes mailing list >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes > > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Thomas Hardjono
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Thomas Hardjono
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Eric Rescorla
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Jeremy Laurenson
- Re: [woes] Proposed charter, post-Quebec edition Richard L. Barnes
- Re: [woes] Proposed charter, post-Quebec edition Hal Lockhart
- [woes] Naked Public Key, was: RE: Proposed charte… Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Proposed charter, post-Quebec edition Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Jeremy Laurenson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Proposed charter, post-Quebec edition Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Paul C. Bryan
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Ben Adida
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Paul C. Bryan
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Ben Adida
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Hal Lockhart
- [woes] Support multiple Crypto algorithms? was RE… Hal Lockhart
- Re: [woes] Support multiple Crypto algorithms? wa… John Bradley
- Re: [woes] Support multiple Crypto algorithms? wa… Paul C. Bryan
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Richard L. Barnes
- Re: [woes] Support multiple Crypto algorithms? wa… Phillip Hallam-Baker
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand