Re: [OAUTH-WG] Signature crypto

"Vrancken Bart bv" <Bart.bv.Vrancken@alcatel-lucent.be> Wed, 25 November 2009 15:49 UTC

Return-Path: <Bart.bv.Vrancken@alcatel-lucent.be>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245303A684D for <oauth@core3.amsl.com>; Wed, 25 Nov 2009 07:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF+d7hYmoJdC for <oauth@core3.amsl.com>; Wed, 25 Nov 2009 07:49:41 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id BF3073A6861 for <oauth@ietf.org>; Wed, 25 Nov 2009 07:49:40 -0800 (PST)
Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAPFm44x008712 for <oauth@ietf.org>; Wed, 25 Nov 2009 16:49:34 +0100
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 16:49:25 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Nov 2009 16:49:25 +0100
Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E044CFE8B@FRVELSMBS22.ad2.ad.alcatel.com>
In-Reply-To: <6c0fd2bc0911250628l7a9bc86gdfe15154c2566210@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OAUTH-WG] Signature crypto
Thread-Index: Acpt264rvoc2V/dqRauAu2lrI/NlbQACvd9Q
References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET><4B0D3698.8070706@cs.tcd.ie><3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> <6c0fd2bc0911250628l7a9bc86gdfe15154c2566210@mail.gmail.com>
From: Vrancken Bart bv <Bart.bv.Vrancken@alcatel-lucent.be>
To: oauth@ietf.org
X-OriginalArrivalTime: 25 Nov 2009 15:49:25.0639 (UTC) FILETIME=[DD4FF170:01CA6DE6]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Subject: Re: [OAUTH-WG] Signature crypto
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2009 15:49:42 -0000

+1
Interoperability is the most important part for a spec like this. Require that everyone uses 1 specific algorithm and allow other algorithms.

Bart

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hubert Le Van Gong
Sent: woensdag 25 november 2009 15:29
To: Infinity Linden (Meadhbh Hamrick)
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Signature crypto

+1
A mandatory support will surely help interoperability. If we also have
the negotiation piece
of protocol we had discussed before then we should be fine on that end
of things.

Hubert



On Wed, Nov 25, 2009 at 3:18 PM, Infinity Linden (Meadhbh Hamrick)
<infinity@lindenlab.com> wrote:
> +1 to stephen's comment.
> when it comes to algorithm support and selection, i think the consensus
> that's emerged is we should require an algorithm that "looks good" at the
> moment the spec is being drafted, but allow the use of other optional
> algorithms. ("looks good" here means that there are no known successful
> attacks against the math of the algorithm and there's a general consensus
> amongst cryptographers that there won't be one in the next 20 years.)
> the rationale behind this may have to do with the experience some
> implementers had with MOSS / MIME Object Security Services (aka RFC1848.)
> MOSS was specified to address issues people had raised with PEM (Privacy
> Enhanced Mail). The problem with MOSS is that it was near infinitely
> flexible and you could create an implementation that strictly adhered to the
> specification, but was non-interoperable if you chose to support a different
> set of optional encipherment algorithms.
> so the concern here is that if you allow all hash algorithms to be optional,
> you'll find some outlier who wants to use HAVAL with Rabin Williams to
> generate signatures and will sell this solution into the marketplace, then
> go out of business. people who bought the solution won't think anything's
> wrong 'til they try to hook it up to someone else who's using a more
> traditional SHA256+RSA or ECDSA solution. a great wailing and gnashing of
> teeth will follow.
> but if we REQUIRE that everyone use SHA256 but allow other hash algorithms,
> then we won't have this problem.
> -cheers
> -meadhbh
> --
>   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
>         http://wiki.secondlife.com/wiki/User:Infinity_Linden
>
>
> On Wed, Nov 25, 2009 at 05:52, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>>
>>
>> Eran Hammer-Lahav wrote:
>> > I think we have consensus that the spec should not mandate a particular
>> > hash algorithm. This still leave the issue of assigning algorithms short
>> > names for the purpose of negotiation and declaration. Is there a registry
>> > available for such algorithms we can use or do we need to create a new one?
>>
>> Sorry to have missed out on the thread where that was discussed, but
>> it'd be odd for an IETF security spec to not mandate some algorithms
>> and quite likely to generate comments later in the process if there's
>> no well-defined way to ensure interop. Do we have that?
>>
>> Ta,
>> S.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth