Proposed Specification for New Consumer-Server Commnunications

[Brad Fitzpatrick]

I'm not crypto expert, but...

On Thu, 9 Jun 2005, Nathan D. Bowen wrote:

> > No need to include the word "hmac" in here.
>
> I see your point about generality, but does it follow that we should
> continue to simply call it "secret", ditching the idea of making it
> *any* less ambiguous? Does anyone have any other suggestions? I've heard
> that we have to anticipate HMAC-SHA1, HMAC-TIGER, and UMAC, so perhaps
> it is 'mac_secret'/'enc_mac_secret'. Or, since I see the signed ID token
> being called "sig" in the "Checking Identity" section, would it be fair
> to call this the 'signing_secret'? 'sig_secret'?

I'd like to call it "shared_secret" to distinguish from the server-only
secrets, and to make it more clear that both parties have that
shared_secret.

> Help us out -- you've informed us that they are *not* all hashing
> algorithms. But what *are* they all? Signing algorithms? MAC algorithms?

They're all MACs.  A way to verify a message.  The HMAC-* family verify
messages based on a shared secret and a hash function H.

> Even if everyone's happy with the parameter names and/or sick of
> discussing them, someone is going to need your help to choose a general
> term to use in the English language parts of the specification.

I'm glad you're working on this part of the spec... I agree it's important
not to confuse future implementors.

> Speaking of 'gx', does anyone prefer 'gen' over 'g' and 'modulus' over
> 'p' -- but not also prefer 'server_public' and 'consumer_public' over
> 'gy' and 'gx'?

I don't like gx and gy either.  server_public and consumer_public sound
great.

- Brad