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

John Bradley <> Mon, 08 August 2011 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D99B421F8C59 for <>; Mon, 8 Aug 2011 12:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.537
X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WbZ+WxqTNj+X for <>; Mon, 8 Aug 2011 12:03:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 93EF321F8C51 for <>; Mon, 8 Aug 2011 12:03:41 -0700 (PDT)
Received: by vws12 with SMTP id 12so3922055vws.31 for <>; Mon, 08 Aug 2011 12:04:07 -0700 (PDT)
Received: by with SMTP id b15mr5653720vdt.425.1312830247761; Mon, 08 Aug 2011 12:04:07 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id k10sm658786vdi.43.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 12:04:06 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_21BAFEBD-0FB8-4418-86E3-D7491350BDB3"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley <>
X-Priority: 3
In-Reply-To: <50a36a05-edfd-4469-8b9e-047ca28df62a@default>
Date: Mon, 8 Aug 2011 15:04:23 -0400
Message-Id: <>
References: <50a36a05-edfd-4469-8b9e-047ca28df62a@default>
To: Hal Lockhart <>
X-Mailer: Apple Mail (2.1244.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:03:43 -0000


JWE/JWS supports multiple algorithms.   I haven't seen any argument to not have algorithm ajility.

There was a mention of what algorithms should be MTI.   I expect that discussion will continue.  (It is still gong on for xmlenc/xmldeig over at W3C)

We clearly need multiple algorithms, in my opinion.

John B.
On 2011-08-08, at 2:28 PM, 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.
> I am not in favor of this, but I concede that it would simplify things in this group a lot.
> If there was only one algorithm, there is no need for any JSON metadata about what the algorithm is being used.
> 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.
> 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 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.
> Hal
>> -----Original Message-----
>> From: Jeremy Laurenson []
>> Sent: Saturday, August 06, 2011 12:31 AM
>> To:
>> Subject: Re: [woes] Proposed charter, post-Quebec edition
>> From a Javascript dev perspective, specifying an algorithm 
>> will make it a hell of of lot easier to implement, instead of 
>> having to potentially account for multiples.
>> Lets use the example of a web app that aggregates social 
>> media data - just for giggles - and uses WOES to secure the 
>> communications to well-defined interfaces
>> If multiple vendors' websites implement WOES/JOES/JOSE with 
>> different algorithms, it becomes more complex vs a single, 
>> consistent one.
>> On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:
>>> So I'll bite on this ;)
>>> I think we can write the spec to require a particular 
>> algorithm choice, but it might make more sense to define the 
>> options and then allow the environment in which the solution 
>> will be used to specify it's requirements.  But, I believe 
>> that is a discussion we'll have while writing the spec.
>>> spt
>>> On 8/4/11 9:29 AM, John Bradley wrote:
>>>> HMAC is requirement for adoption in the JWS use cases.
>>>> If we want to describe it as something other than a 
>> "Qualified Digital
>>>> Signature", that is fine as long as it is MTI:)
>>>> John B.
>>>> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
>>>>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <
>>>>> <>> wrote:
>>>>>   On 8/2/11 7:13 PM, Paul Hoffman wrote:
>>>>>       Here is a proposal for the charter based on the 
>> discussion in
>>>>>       the BoF last week and later discussion with Sean Turner.
>>>>>       Comments, praise, scorn, etc., are welcome.
>>>>>       --Paul and Richard
>>>>>       Javascript Object Signing and Encrypting (jose)
>>>>>       ==============================__=================
>>>>>       Background
>>>>>       ----------
>>>>>       Javascript Object Notation (JSON) is a text format for the
>>>>>       serialization of structured data described in RFC 4627. The
>>>>>       JSON format is often used for serializing and transmitting
>>>>>       structured data over a network connection. With 
>> the increased
>>>>>       usage of JSON in protocols in the IETF and 
>> elsewhere, there is
>>>>>       now a desire to offer security services such as 
>> encryption and
>>>>>       digital signatures for data that is being carried 
>> in JSON format.
>>>>>       Different proposals for providing such security 
>> services have
>>>>>       already been defined and implemented. This Working Group's
>>>>>       task is to standardize two security services, 
>> encrypting and
>>>>>       digitally signing, in order to increase interoperability of
>>>>>       security features between protocols that use JSON. 
>> The Working
>>>>>       Group will base its work on well-known message security
>>>>>       primitives (e.g., CMS), and will solicit input 
>> from the rest
>>>>>       of the IETF Security Area to be sure that the security
>>>>>       functionality in the JSON format is correct.
>>>>>       This group is chartered to work on four documents:
>>>>>       1) A Standards Track document specifying how to apply a
>>>>>       JSON-structured digital signature to data, 
>> including (but not
>>>>>       limited to) JSON data structures. "Digital signature" is
>>>>>       defined as a hash operation followed by a 
>> signature operation
>>>>>       using asymmetric keys.
>>>>>   I just want to make sure that we agree now that a digital
>>>>>   signature is a hash followed by a signature algorithm 
>> (e.g., RSA
>>>>>   with SHA-256). I've seen a couple of drafts that tried 
>> to say an
>>>>>   HMAC (e.g., HMAC-SHA256) was a digital signature; one 
>> called it a
>>>>>   symmetric key based digital signature algorithm (note 
>> this phrase
>>>>>   didn't get through the IESG).
>>>>> An HMAC is not a digital signature, but the spec 
>> definitely needs to
>>>>> be able to cover MAC based authentication.
>>>>> I know that public key is getting easier as far as 
>> computation goes.
>>>>> But for many applications the non-repudiation you get in digital
>>>>> signatures is actually undesirable.
>>>>> There are interesting tricks you can do with symmetric 
>> crypto that are
>>>>> much harder to do in public key and end up with some 
>> scheme that only
>>>>> 50 academics in the world can follow and has a security proof that
>>>>> rest on rather esoteric assumptions.
>>>>> --
>>>>> Website:
>>>>> _______________________________________________
>>>>> woes mailing list
>>>>> <>
>>> _______________________________________________
>>> woes mailing list
>> _______________________________________________
>> woes mailing list
> _______________________________________________
> woes mailing list