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

Thomas Hardjono <hardjono@MIT.EDU> Tue, 09 August 2011 18:02 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 46B6421F89A1 for <woes@ietfa.amsl.com>; Tue, 9 Aug 2011 11:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 PMI-weOeExXS for <woes@ietfa.amsl.com>; Tue, 9 Aug 2011 11:02:27 -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 7BF1F21F8747 for <woes@ietf.org>; Tue, 9 Aug 2011 11:02:27 -0700 (PDT)
X-AuditID: 1209190f-b7b44ae000000a24-ff-4e4175b91570
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 6C.95.02596.9B5714E4; Tue, 9 Aug 2011 14:00:25 -0400 (EDT)
Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p79I2tWW017400 for <woes@ietf.org>; Tue, 9 Aug 2011 14:02:56 -0400
Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p79I2sKw005384 for <woes@ietf.org>; Tue, 9 Aug 2011 14:02:55 -0400
Received: from w92exhub6.exchange.mit.edu (18.7.73.12) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 9 Aug 2011 11:02:38 -0700
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub6.exchange.mit.edu ([18.7.73.12]) with mapi; Tue, 9 Aug 2011 14:02:53 -0400
From: Thomas Hardjono <hardjono@MIT.EDU>
To: "woes@ietf.org" <woes@ietf.org>
Date: Tue, 9 Aug 2011 14:02:51 -0400
Thread-Topic: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
Thread-Index: AcxWPNcHBGaoFzKlTHKeGEC10gBurwAgJQrQ
Message-ID: <DADD7EAD88AB484D8CCC328D40214CCD0E7504252B@EXPO10.exchange.mit.edu>
References: <02FA13F0-131C-4BD9-AA41-E14E48403040@ve7jtb.com> <CA659998.D933%joe.hildebrand@webex.com> <CAMm+LwgTWTbB3r0AqtZgmLfGUsYVo8poCXsoED27gG+-BbpY9g@mail.gmail.com>
In-Reply-To: <CAMm+LwgTWTbB3r0AqtZgmLfGUsYVo8poCXsoED27gG+-BbpY9g@mail.gmail.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPKsWRmVeSWpSXmKPExsUixCmqrbuz1NHP4Nd+LosL32czOTB6LFny kymAMYrLJiU1J7MstUjfLoErY97WHewFt3grFu67ytjAOJ27i5GTQ0LARGLh0ddsELaYxIV7 64FsLg4hgX2MEs0fD7CCJIQELjNKvNySDpF4zihx6P89RghnK6NEy4vnUE4/o8SjlRvAWtgE NCTO/d7LDmKLCChLnNuzkQnEZhFQkbh5cjtYXFggXWLO+z1MEDUZEtuPdjN3MXIA2UYSu5da gpi8AgESRy+rQIxfzyixcudksFZOgUCJ/1vPs4DYjEBnfz+1BmwMs4C4xK0n85kg3hGUWDR7 DzPMa/92PWSDqBeVuNO+nhGiXk/ixtQpbBC2tsSyha/B6nmBek/OfMIygVFiFpKxs5C0zELS MgtJywJGllWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxjB8SbJv4Px20GlQ4wC HIxKPLyc/A5+QqyJZcWVuYcYJTmYlER5DYHRKsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd14Y UI43JbGyKrUoHyYlzcGiJM7buANokkB6YklqdmpqQWoRTFaGg0NJgrcGZKhgUWp6akVaZk4J QpqJgxNkOA/Q8BiQGt7igsTc4sx0iPwpRkUpcd4JIAkBkERGaR5cLywdvmIUB3pFmHc2SBUP MJXCdb8CGswENLj+jgPI4JJEhJRUA6P0wZYpTKlWwt+DdhmnqQotvPb5164vikUhblvURS0m MJ9hZvnOdF5O7Nvt3Zdn9oWbC3Ili57Wy7lfUj7l96yy2/81Z1x9s4Xb4GKMxuX+o1d/XGd1 mnnZoi38pJb1pIagWxt6M2SyfD8/2mYumSspMiVEVmrZ8xbp0NiwwNADDZbX1KQiK5RYijMS DbWYi4oTAedGdCliAwAA
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 18:02:28 -0000

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.
 
-- 
Website: http://hallambaker.com/