IETF Logo Mail Archive

Re: [OAUTH-WG] Signature crypto

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 25 November 2009 13:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 1424B3A67A8 for <oauth@core3.amsl.com>; Wed, 25 Nov 2009 05:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 y7kXvJmsaEMK for <oauth@core3.amsl.com>; Wed, 25 Nov 2009 05:52:32 -0800 (PST)
Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by core3.amsl.com (Postfix) with ESMTP id 2E95B28C10C for <oauth@ietf.org>; Wed, 25 Nov 2009 05:52:32 -0800 (PST)
Received: from mail18-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 8.1.240.5; Wed, 25 Nov 2009 13:52:26 +0000
Received: from mail18-va3 (localhost.localdomain [127.0.0.1]) by mail18-va3-R.bigfish.com (Postfix) with ESMTP id 7126310D82AE; Wed, 25 Nov 2009 13:52:26 +0000 (UTC)
X-SpamScore: -8
X-BigFish: VPS-8(zz98dN168aJzz1202hzzz2dh6bh87h61h)
X-Spam-TCS-SCL: 0:0
X-FB-DOMAIN-IP-MATCH: fail
Received: from mail18-va3 (localhost.localdomain [127.0.0.1]) by mail18-va3 (MessageSwitch) id 1259157143191790_6224; Wed, 25 Nov 2009 13:52:23 +0000 (UTC)
Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.244]) by mail18-va3.bigfish.com (Postfix) with ESMTP id D76E119C80A6; Wed, 25 Nov 2009 13:52:22 +0000 (UTC)
Received: from imx2.tcd.ie (134.226.1.156) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server id 14.0.482.32; Wed, 25 Nov 2009 13:52:20 +0000
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 6FD8168006; Wed, 25 Nov 2009 13:52:19 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A046A66C085; Wed, 25 Nov 2009 13:52:19 +0000
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 60E4768006; Wed, 25 Nov 2009 13:52:19 +0000 (GMT)
Message-ID: <4B0D3698.8070706@cs.tcd.ie>
Date: Wed, 25 Nov 2009 13:52:24 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.23 (X11/20090812)
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A146A66C085
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.28)
X-Reverse-DNS: imx2.tcd.ie
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
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 13:52:33 -0000

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.

v2.23.0 | Report a Bug | By Email