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

"Richard L. Barnes" <rbarnes@bbn.com> Mon, 08 August 2011 21:11 UTC

Return-Path: <rbarnes@bbn.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 BC56121F8BE5 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 14:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.901
X-Spam-Level:
X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 zPmoB2rrDAh2 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 14:11:11 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 693E421F8BDB for <woes@ietf.org>; Mon, 8 Aug 2011 14:11:11 -0700 (PDT)
Received: from ros-dhcp192-1-51-80.bbn.com ([192.1.51.80]:51028) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1QqX6f-0005ob-1P; Mon, 08 Aug 2011 17:11:29 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <CA659998.D933%joe.hildebrand@webex.com>
Date: Mon, 8 Aug 2011 17:11:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C31C2F25-79DA-477A-8933-7CA5876810B3@bbn.com>
References: <CA659998.D933%joe.hildebrand@webex.com>
To: Joe Hildebrand <joe.hildebrand@webex.com>
X-Mailer: Apple Mail (2.1082)
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 21:11:12 -0000

+1

This is exactly what the  DNSSEC community has done.
<http://tools.ietf.org/html/rfc6014>

On Aug 8, 2011, at 3: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.
> 
> 
> 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
> 
> _______________________________________________
> woes mailing list
> woes@ietf.org
> https://www.ietf.org/mailman/listinfo/woes