Proposed Specification for New Consumer-Server Commnunications
brad at danga.com
Thu Jun 9 12:57:22 PDT 2005
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
> 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
More information about the yadis