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

"Paul C. Bryan" <> Mon, 08 August 2011 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E568F5E8001 for <>; Mon, 8 Aug 2011 12:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VHmU-AoblP1E for <>; Mon, 8 Aug 2011 12:20:42 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 5A8F121F8560 for <>; Mon, 8 Aug 2011 12:20:40 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Mon, 08 Aug 2011 19:21:08 UTC
Received: by with SMTP id 36so3289273pzk.31 for <>; Mon, 08 Aug 2011 12:20:57 -0700 (PDT)
Received: by with SMTP id j5mr6004373wfd.18.1312831257081; Mon, 08 Aug 2011 12:20:57 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id i9sm6206512pbk.4.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 12:20:56 -0700 (PDT)
From: "Paul C. Bryan" <>
In-Reply-To: <50a36a05-edfd-4469-8b9e-047ca28df62a@default>
References: <50a36a05-edfd-4469-8b9e-047ca28df62a@default>
Content-Type: multipart/alternative; boundary="=-iNkFK04kZGa6VOzG8o7y"
Date: Mon, 08 Aug 2011 12:21:01 -0700
Message-ID: <1312831261.5484.40.camel@dynamo>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
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: Mon, 08 Aug 2011 19:20:43 -0000

On Mon, 2011-08-08 at 11:28 -0700, 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.

If such a position is actually forming, I'd like to know why we'd want
to pre-bake obsolescence into the spec.

> I am not in favor of this, but I concede that it would simplify things
> in this group a lot.

If by simplify you mean thinning out the number of people who will find
it useful, perhaps. ;-)

> If there was only one algorithm, there is no need for any JSON
> metadata about what the algorithm is being used.

True, but perhaps at the very least we'd need some kind of metadata
saying what version of JOSE is being used, if nothing more than to
determine what version of what cipher(s) it supports.

> 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.

This may not be enough, especially when JOSE undergoes a revision.

> 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 think if we establish a minimum supported set, with extensibility
(i.e. cipher suite can be specified), we retain core interoperability
while not throwing out the standard when the core ciphers prove

> 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.

+1, though I suggest we may codify a handful of well-used suites while
possibly making one mandatory to implement.