brad at danga.com
Sun Jun 5 16:31:30 PDT 2005
On Mon, 6 Jun 2005, Paul Crowley wrote:
> > * What is dh.q (order)?
> That's necessary if we use the Schnorr group. Q is a largeish (160-bit)
> prime that divides p-1, and g^q = 1 mod p. Schorr groups are no harder
> to work in and have certain security advantages over standard Z*_p
> groups because they are of prime order, though it's not clear that those
> advantages will matter here.
I'd have to spend some time reading before I'd understand it. I'll hope
you side towards the simplest thing necessary for our requirements and
then maybe I won't have to do any more reading. :-) Let me know if I do,
> > in Debian. SHA-256 isn't in PHP. etc, etc.
> In that case should go for SHA1 for now. It'll be easy enough to switch
> to a more secure hash function when it becomes clear what way the world
> is going to go; that's why I've made the hash function explicit in
> various places in the protocol.
Okay. SHA-1 for now, then. So in the future consumer could send
openid.pref_hash="sha256" or "tiger" and if server knew that one, it'd do
it, otherwise fallback to sha-1.
So maybe change:
# openid.auth_type = 'hmac-sha1'
# openid.auth_type = 'hmac'
# openid.hash_pref = 'sha256,tiger,sha1'
> > * I don't think the "assert_identity" literal in token_contents needs
> > to be there. It'll just hinder us going forward when it's already
> > implied by openid.mode='id_res' and token_content's "assert_identity"
> > actual field.
> No, I think it's essential that when you sign (or otherwise
> authenticate) something, that you start of by saying what it is that
> you're asserting. You can go on to say what you're asserting it about,
> but I'm keen that we open with "this is a token that is for this".
> Otherwise if the protocol grows we could end up in a situation where a
> token intended for one situation becomes usable for another.
Won't fight it.
More information about the yadis