Re: [OAUTH-WG] Signature crypto

[Eran Hammer-Lahav <[e-mail]>]

That's beside the point. You are talking about implementation and I'm talking about specification.

Are you expecting them to write a new RFC to add support for HMAC-1024? That's the implications of what you are suggesting. Instead, I am trying to define a few (1 or 2) classes of algorithms, provide well-defined process of them, and provide an easy registration process for new algorithms which fit the class.

A MAC class would be defined as applying any MAC algorithm which can be described by digest=mac(key,text) where text is the signature base string, key is the symmetric shared secret associated with the token, and digest is the value sent to the server for authentication (after properly encoded).

With this definition, you can extend the protocol by simply sending an email to a designated list, get quick feedback, and register a new algorithm that fits this template. However, if you want to use a new algorithm that requires, say, asymmetric shared secret or a different normalization of the HTTP request (something different from the signature base string), then you need to write an RFC (or any other Open Standard) and go through a longer process.

EHL

> -----Original Message-----
> From: Brian Eaton [mailto:[e-mail]]
> Sent: Friday, December 04, 2009 11:13 AM
> To: Eran Hammer-Lahav
> Cc: Breno; OAuth WG ([e-mail])
> Subject: Re: [OAUTH-WG] Signature crypto
> 
> On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav
> <[e-mail]> 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