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: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46B6421F89A1 for <>; Tue, 9 Aug 2011 11:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PMI-weOeExXS for <>; Tue, 9 Aug 2011 11:02:27 -0700 (PDT)
Received: from (DMZ-MAILSEC-SCANNER-4.MIT.EDU []) by (Postfix) with ESMTP id 7BF1F21F8747 for <>; Tue, 9 Aug 2011 11:02:27 -0700 (PDT)
X-AuditID: 1209190f-b7b44ae000000a24-ff-4e4175b91570
Received: from ( []) by (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 []) by (8.13.8/8.9.2) with ESMTP id p79I2tWW017400 for <>; Tue, 9 Aug 2011 14:02:56 -0400
Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU []) by (8.13.8/8.12.4) with ESMTP id p79I2sKw005384 for <>; Tue, 9 Aug 2011 14:02:55 -0400
Received: from ( by W92EXEDGE6.EXCHANGE.MIT.EDU ( with Microsoft SMTP Server (TLS) id; Tue, 9 Aug 2011 11:02:38 -0700
Received: from ([]) by ([]) with mapi; Tue, 9 Aug 2011 14:02:53 -0400
From: Thomas Hardjono <hardjono@MIT.EDU>
To: "" <>
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: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.



From: [] On Behalf Of Phillip Hallam-Baker
Sent: Monday, August 08, 2011 10:34 PM
To: Joe Hildebrand
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 <> 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.


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.