Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

Thomas Hardjono <hardjono@MIT.EDU> Tue, 09 August 2011 20:43 UTC

Return-Path: <hardjono@mit.edu>
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 9917A21F8C7F for <woes@ietfa.amsl.com>; Tue, 9 Aug 2011 13:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.144
X-Spam-Level:
X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 BC7WhFfMKRQY for <woes@ietfa.amsl.com>; Tue, 9 Aug 2011 13:43:23 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7C64221F8C7E for <woes@ietf.org>; Tue, 9 Aug 2011 13:43:23 -0700 (PDT)
X-AuditID: 1209190f-b7b44ae000000a24-3d-4e419b71e84d
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F6.BD.02596.17B914E4; Tue, 9 Aug 2011 16:41:21 -0400 (EDT)
Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p79KhqPs011449 for <woes@ietf.org>; Tue, 9 Aug 2011 16:43:52 -0400
Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p79Khp98007022 for <woes@ietf.org>; Tue, 9 Aug 2011 16:43:52 -0400
Received: from w92exhub5.exchange.mit.edu (18.7.73.11) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 9 Aug 2011 16:43:44 -0400
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub5.exchange.mit.edu ([18.7.73.11]) with mapi; Tue, 9 Aug 2011 16:43:51 -0400
From: Thomas Hardjono <hardjono@MIT.EDU>
To: "woes@ietf.org" <woes@ietf.org>
Date: Tue, 09 Aug 2011 16:43:49 -0400
Thread-Topic: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
Thread-Index: AcxWPNcHBGaoFzKlTHKeGEC10gBurwAgJQrQAAFgpisABCcNIA==
Message-ID: <DADD7EAD88AB484D8CCC328D40214CCD0E7504259F@EXPO10.exchange.mit.edu>
References: <DADD7EAD88AB484D8CCC328D40214CCD0E7504252B@EXPO10.exchange.mit.edu> <CA66D9C2.DABE%joe.hildebrand@webex.com>
In-Reply-To: <CA66D9C2.DABE%joe.hildebrand@webex.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPKsWRmVeSWpSXmKPExsUixCmqrFs429HPYP8JAYsL32czOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+edzawFl8UqZixdxNLA2CHUxcjJISFgIrFt82lmCFtM4sK9 9WxdjFwcQgL7GCWurPvJDOFcZpR4cPkXlPOCUaLn7AIWkBYhga2MEgve1UMk+hklvsztYgJJ sAloSJz7vZcdxBYRUJY4t2cjWJxFQEXicc9fsLiwQLrEnPd7mCBqMiS2H+1mhrCdJP7d7GMF sXkFAiReTz4EVMMBtKBaYtlGWZAwp4CpxIZpjWBjGIHO/n5qDdgYZgFxiVtP5jNBvCMosWj2 HrjX/u16yAZRLypxp309I0S9jsSC3Z/YIGxtiWULXzNDrBWUODnzCcsERolZSMbOQtIyC0nL LCQtCxhZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6OVmluilppRuYgTHmyT/DsZvB5UOMQpw MCrx8HLyO/gJsSaWFVfmHmKU5GBSEuXVAUarEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeJ7OA crwpiZVVqUX5MClpDhYlcd7GHUCTBNITS1KzU1MLUotgsjIcHEoSvHkgQwWLUtNTK9Iyc0oQ 0kwcnCDDeYCGLwap4S0uSMwtzkyHyJ9iVJQS560ASQiAJDJK8+B6YenwFaM40CvCvGkgVTzA VArX/QpoMBPQ4Po7DiCDSxIRUlINjH5+F5yOxrq0lAasVHjDJ7Dr3kQN68R5t588F1sR77q6 wd/n0Vbf4iN36th/1q6yzdn78mnn65vPxdf877sadGvjdCeNgzaSpwP+y+lsldy+W4KrqbSN naX26QWW+ArbOVYTIsvO5t4L8f1SnK20zudkx1dj/m/nztzddKl0youDf9odDs68mKrEUpyR aKjFXFScCACksROpYgMAAA==
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: Tue, 09 Aug 2011 20:43:24 -0000

Hi Joe,

Its perfectly ok (and necessary for interop) for the implementers to agree beforehand about which cipher(s) are must implement. Support for multiple ciphers is a good thing. However, there is no need to call these out within the JOSE specification.

Perhaps the chairs can simply do a WG consensus call to ask which ciphers/algorithms to implement as part of the first WG deliverables.

/thomas/

__________________________________________


> -----Original Message-----
> From: Joe Hildebrand [mailto:joe.hildebrand@webex.com]
> Sent: Tuesday, August 09, 2011 2:34 PM
> To: Thomas Hardjono; woes@ietf.org
> Subject: Re: [woes] Support multiple Crypto algorithms? was RE:
> Proposed charter, post-Quebec edition
> 
> One of the goals of JOSE is to increase the number of interoperable
> implementations.  I don't think a lack of MTI algorithms will further
> that goal.
> 
> 
> On 8/9/11 12:02 PM, "Thomas Hardjono" <hardjono@MIT.EDU> wrote:
> 
> >
> > As far as I can remember, CMS (RFC3852 and RFC5652) does not choose
> > any specific algorithm.
> >
> > Therefore it make sense for JOSE to follow the same approach.
> >
> > /thomas/
> >
> >
> >
> > __________________________________________
> >
> > From: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On Behalf
> > Of Phillip Hallam-Baker
> > Sent: Monday, August 08, 2011 10:34 PM
> > To: Joe Hildebrand
> > Cc: woes@ietf.org
> > Subject: Re: [woes] Support multiple Crypto algorithms? was RE:
> > Proposed charter, post-Quebec edition
> >
> >
> > On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand
> > <joe.hildebrand@webex.com>
> > 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.
> >
> > +1
> >
> > And that way we can have two profiles (or more) to address different
> > implementation situations.
> >
> > Web Services implementation constraints are frequently asymmetric.
> > There is one portion built on some all-singing/dancing platform like
> > .NET or whatever and that talks to a thin client embedded in Jscript
> > or a mobile device or what-have-you.
> >
> > If we can avoid creating yet another crypto-registry (i.e. re-use the
> > PEM or whatever algorithm registry) then all the spec needs to say is
> > that X is the slot where the algorithm name goes and the MTI doc(s)
> > specify how to get interoperability.
> >
> 
> --
> Joe Hildebrand