Re: [OAUTH-WG] Signature crypto

Breno <breno.demedeiros@gmail.com> Fri, 04 December 2009 19:46 UTC

Return-Path: <breno.demedeiros@gmail.com>
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 77ED93A67D8 for <oauth@core3.amsl.com>; Fri, 4 Dec 2009 11:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level:
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 HS6cOPTgX9rv for <oauth@core3.amsl.com>; Fri, 4 Dec 2009 11:46:33 -0800 (PST)
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 5133D3A6A4D for <oauth@ietf.org>; Fri, 4 Dec 2009 11:46:33 -0800 (PST)
Received: by ywh1 with SMTP id 1so3106550ywh.18 for <oauth@ietf.org>; Fri, 04 Dec 2009 11:46:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LSLUWxaf+IR9muXsr7vIbLPshHBYHud7kmj+XLOR6iA=; b=ezw8s5mut5JvEcdJHLRJz+yly/FsA6If+OH/zT2IuoZxOvi0CIa9CHZmQVzIbAnNiB 3g+fIifLA+1H3acQQB6I8xXpC38xPAl0TK/9gaAtJ8SETXUeS4TVlrqs1o3ennx9dRvd BBS2Ji98LnV6PTfwYJmECcJkEtoVIxMPY/IhU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ftaJlcDcZxsxwG1bqjRRsFtdH5jJcUVRqSxSjqE+X7jOD30EcRPi1B0kw5F8PaGtvz DthuuSdtkRA/OvqR9a0K0YHr1Mnqm3bfdfBISHM/9B9NqI1foZ48MdKzur7jGoP2/faz oo3z5qSRCwPQGk6OLLiKvlUso4J0jyN52mNL0=
MIME-Version: 1.0
Received: by 10.101.62.11 with SMTP id p11mr4610071ank.21.1259955981793; Fri, 04 Dec 2009 11:46:21 -0800 (PST)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <f98165700912041023y3207d801r42f01c7a0c4352bb@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9570912041037t199cc9d3rbd4d31d327f8988b@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <f98165700912041048s7f1f53bs27ec2b78f7f44c8b@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9570912041112h71c0644dm8c908478dbff2e9a@mail.gmail.com> <f98165700912041120k2b13eed2l4b51f6b22e35824e@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 04 Dec 2009 11:46:21 -0800
Message-ID: <f98165700912041146w2d543b25l9b1e7ec8df0ef8a0@mail.gmail.com>
From: Breno <breno.demedeiros@gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: multipart/alternative; boundary="001636eee42dba39c00479ec5c9f"
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: Fri, 04 Dec 2009 19:46:34 -0000

I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature
scheme, PKCS#11 does establish a signature scheme based on RSA + SHA-1.

So to delve beyond the level of abstraction of 'authentication mechanism
name' you need to point to a separate spec for both signing and
verification.

I am not sure how much one needs to do beyond defining the byte
representation of what needs to be signed.

Some MACs require random pads in addition to keys. Those won't fit into this
abstraction but I don't think we need absolute generality here.

On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote:

> Point where?
>
>
>
> I didn’t mean new spec for the algorithm, just for how it is used with the
> OAuth authentication scheme.
>
>
>
> EHL
>
>
>
> *From:* Breno [mailto:breno.demedeiros@gmail.com]
> *Sent:* Friday, December 04, 2009 11:20 AM
> *To:* Brian Eaton
> *Cc:* Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
>
> *Subject:* Re: [OAUTH-WG] Signature crypto
>
>
>
> There is no need to publish a new spec for a new MAC algorithm. MAC
> algorithms typically go through certification (e.g., NIST) and have detailed
> specs, including test vectors for interoperability.
>
>
>
> For OAuth, if you want to explicitly support a new MAC algorithm you will
> not need to change the transport and you just have to point to the
> particular spec that defines the MAC algorithm.
>
> On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton <beaton@google.com> wrote:
>
> On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > I am trying to avoid the need to publish a specification every time you
> want
> > to add a new MAC-based algorithm.
>
> People are going to end up needing to write new code every time they
>
> want to add a new MAC-based algorithm.
>
> Cheers,
> Brian
>
>
>
>
> --
> Breno de Medeiros
>



-- 
Breno de Medeiros