Re: [OAUTH-WG] MAC Tokens body hash
Eran Hammer-Lahav <eran@hueniverse.com> Tue, 02 August 2011 15:44 UTC
Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D9D21F84D6 for <oauth@ietfa.amsl.com>; Tue, 2 Aug 2011 08:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGbidQQt1Z-x for <oauth@ietfa.amsl.com>; Tue, 2 Aug 2011 08:44:36 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 899E821F84C7 for <oauth@ietf.org>; Tue, 2 Aug 2011 08:44:34 -0700 (PDT)
Received: (qmail 23059 invoked from network); 2 Aug 2011 15:44:43 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Aug 2011 15:44:43 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 2 Aug 2011 08:44:42 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Phil Hunt <phil.hunt@oracle.com>
Date: Tue, 02 Aug 2011 08:43:52 -0700
Thread-Topic: [OAUTH-WG] MAC Tokens body hash
Thread-Index: AcxRKUkMyVZxXQY5SNyC3fjbz7SzfwAAXE1g
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F643E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> <62E9072B-6687-4906-9241-717D6EBD8167@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723450245F63D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B5B1A97C-DC72-445A-8037-D49B913105B8@oracle.com>
In-Reply-To: <B5B1A97C-DC72-445A-8037-D49B913105B8@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F643EP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MAC Tokens body hash
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 02 Aug 2011 15:44:40 -0000
Yep. I would like to allow each application to extend what is being signed, such as payload or specific headers. I don't want to open the door for additional specifications defining how to use the ext parameter. If there is enough consensus for an extended signing model, we should define a new scheme. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, August 02, 2011 8:31 AM To: Eran Hammer-Lahav Cc: William J. Mills; OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash Not sure I understand. How does 'app' change the issue about internal format and register? Is it not for the user of the field to use and document its use as appropriate? I think the text that you had for ext was just fine. Cutting the field out, eliminates any possibility of extensibility -- and that would close a door that dead-ends the MAC design --> likely causing another MAC variant IMHO. That may be what you are looking for. Just want to make sure that's what you intend. Phil @independentid www.independentid.com<http://www.independentid.com> phil.hunt@oracle.com<mailto:phil.hunt@oracle.com> On 2011-08-01, at 11:22 PM, Eran Hammer-Lahav wrote: I am going to drop both 'bodyhash' and 'ext', and instead add 'app'. 'app' allows you to include any data you want. 'ext' without an internal format and register is just asking for trouble, and I have no intention of adding that level of complexity. There are other proposals in the IETF for full HTTP message signatures, and I'll leave these more complex use cases to them. If you can demonstrate actual need (with examples) of both 'app' and 'ext', I'm willing to reconsider but you can clearly accomplish the same end result with just one, application-specific parameter. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com]<mailto:[mailto:phil.hunt@oracle.com]> Sent: Monday, August 01, 2011 10:51 PM To: William J. Mills Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash Agree. -1 on removing the ext parameter. Phil @independentid www.independentid.com<http://www.independentid.com/> phil.hunt@oracle.com<mailto:phil.hunt@oracle.com> On 2011-08-01, at 9:06 AM, William J. Mills wrote: I think the extended parameter still has use if someone extends the MAC stuff specifically, whcih the additional hash is useful for a data signature, that's off the cuff though without implementing somethign to try it out. ________________________________ From: Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> To: William J. Mills <wmills@yahoo-inc.com<mailto:wmills@yahoo-inc.com>>; OAuth WG <oauth@ietf.org<mailto:oauth@ietf.org>> Cc: Ben Adida <ben@adida.net<mailto:ben@adida.net>>; "'Adam Barth (adam@adambarth.com<mailto:adam@adambarth.com>)'" <adam@adambarth.com<mailto:adam@adambarth.com>> Sent: Monday, August 1, 2011 8:59 AM Subject: RE: [OAUTH-WG] MAC Tokens body hash Would you still like to see both such app-specific payload hash AND the ext parameter? I'm thinking of taking your idea and dropping ext. This way, the application can define anything they want to put in the payload hash. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com]<mailto:[mailto:wmills@yahoo-inc.com]> Sent: Monday, August 01, 2011 8:41 AM To: Eran Hammer-Lahav; OAuth WG Cc: Ben Adida; 'Adam Barth (adam@adambarth.com<mailto:adam@adambarth.com>)' Subject: Re: [OAUTH-WG] MAC Tokens body hash Instead of "body" hash why not make it a payload hash or additional hash. The app can include a hash of data there as defined by the app, and you've reserved a spot for that. ________________________________ From: Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> To: OAuth WG <oauth@ietf.org<mailto:oauth@ietf.org>> Cc: Ben Adida <ben@adida.net<mailto:ben@adida.net>>; "'Adam Barth (adam@adambarth.com<mailto:adam@adambarth.com>)'" <adam@adambarth.com<mailto:adam@adambarth.com>> Sent: Friday, July 29, 2011 6:43 PM Subject: [OAUTH-WG] MAC Tokens body hash I plan to drop support for the bodyhash parameter in the next draft based on bad implementation experience. Even with simple text body, UTF encoding has introduced significant issues for us. The current draft does not work using simple JS code between a browser and node.js even when both use the same v8 engine due to differences in the body encoding. Basically, the JS string used to send a request from the browser is not the actual string sent on the wire. To fix that, we need to force UTF-8 encoding on both sides. However, that is very much application specific. This will not work for non-text bodies. Instead, the specification should offer a simple way to use the ext parameter for such needs, including singing headers. And by offer I mean give examples, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will introduce unacceptable complexity that will basically make this work useless. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash William J. Mills
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash William J. Mills
- Re: [OAUTH-WG] MAC Tokens body hash Phil Hunt
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash Phil Hunt
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash Skylar Woodward
- Re: [OAUTH-WG] MAC Tokens body hash Barry Leiba
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash Phillip Hunt
- Re: [OAUTH-WG] MAC Tokens body hash William J. Mills
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash Phil Hunt
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash William J. Mills
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash William J. Mills
- Re: [OAUTH-WG] MAC Tokens body hash Eran Hammer-Lahav
- Re: [OAUTH-WG] MAC Tokens body hash Phillip Hunt