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

Phillip Hallam-Baker <> Tue, 09 August 2011 02:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FFA021F8581 for <>; Mon, 8 Aug 2011 19:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.451
X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id btYrufNURzX2 for <>; Mon, 8 Aug 2011 19:33:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 580DC21F8556 for <>; Mon, 8 Aug 2011 19:33:47 -0700 (PDT)
Received: by gxk19 with SMTP id 19so1367066gxk.31 for <>; Mon, 08 Aug 2011 19:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4cRTNfv3XzYjTPpy/GNQNL5aU2n4rV8z9lqOvlKF77E=; b=hScBmLCuzKomqUF5igOlKtqruqeNU/cEmnfMdh9o4Sr7cQKuIC3D1DEUlITodR9RfR XK9Q/iW5tYcVq4cF6f/M0ahlaalzWylOrmb8G6ri7D8yRdhMkmSuzWGuR1goES2hKIiu b/CCQkvIMhFEkBpGvZO2f2zh/IF2WKOZOQOVg=
MIME-Version: 1.0
Received: by with SMTP id s6mr5146998anp.50.1312857253713; Mon, 08 Aug 2011 19:34:13 -0700 (PDT)
Received: by with HTTP; Mon, 8 Aug 2011 19:34:13 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 9 Aug 2011 03:34:13 +0100
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Joe Hildebrand <>
Content-Type: multipart/alternative; boundary=00163691fc2d3f97cb04aa0966ad
Cc: "" <>
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 02:33:48 -0000

On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand <>wrote;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

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