Field separators

[Brad Fitzpatrick]

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,
though.

> >   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'

Into:

   # 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.

- Brad