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

Joe Hildebrand <joe.hildebrand@webex.com> Mon, 08 August 2011 19:47 UTC

Return-Path: <Joe.Hildebrand@webex.com>
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 86F3A11E8097 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 12:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.307
X-Spam-Level:
X-Spam-Status: No, score=-104.307 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
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 mEL7vH90ui8O for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 12:47:44 -0700 (PDT)
Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by ietfa.amsl.com (Postfix) with SMTP id 6894311E808F for <woes@ietf.org>; Mon, 8 Aug 2011 12:47:43 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Aug 2011 12:48:09 -0700
Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Mon, 8 Aug 2011 19:48:09 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Mon, 08 Aug 2011 13:48:08 -0600
From: Joe Hildebrand <joe.hildebrand@webex.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Hal Lockhart <hal.lockhart@oracle.com>
Message-ID: <CA659998.D933%joe.hildebrand@webex.com>
Thread-Topic: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
Thread-Index: AcxWBBihrIk46guWokim1psemdr46w==
In-Reply-To: <02FA13F0-131C-4BD9-AA41-E14E48403040@ve7jtb.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 08 Aug 2011 19:48:09.0847 (UTC) FILETIME=[19BB6070:01CC5604]
Cc: "woes@ietf.org" <woes@ietf.org>
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: Mon, 08 Aug 2011 19:47:45 -0000

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.


On 8/8/11 1:04 PM, "John Bradley" <ve7jtb@ve7jtb.com> wrote:

> Hal,
> 
> 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 [mailto:jlaurens@cisco.com]
>>> Sent: Saturday, August 06, 2011 12:31 AM
>>> To: woes@ietf.org
>>> 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 <turners@ieca.com
>>>>>> <mailto:turners@ieca.com>> 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: http://hallambaker.com/
>>>>>> 
>>>>>> _______________________________________________
>>>>>> woes mailing list
>>>>>> woes@ietf.org <mailto:woes@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/woes
>>>>> 
>>>> _______________________________________________
>>>> woes mailing list
>>>> woes@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/woes
>>> 
>>> _______________________________________________
>>> woes mailing list
>>> woes@ietf.org
>>> https://www.ietf.org/mailman/listinfo/woes
>>> 
>> _______________________________________________
>> woes mailing list
>> woes@ietf.org
>> https://www.ietf.org/mailman/listinfo/woes
> 
> _______________________________________________
> woes mailing list
> woes@ietf.org
> https://www.ietf.org/mailman/listinfo/woes

-- 
Joe Hildebrand