Improving OpenID's use of cryptography 3 - odds and ends
mart at degeneration.co.uk
Thu Jun 2 02:59:00 PDT 2005
Paul Crowley wrote:
> I'm worried by the format of what is signed - what guarantees that the
> sequence "::" can't turn up in any of the things being signed? You
> should check for this sequence in everything you sign and reject if it's
> present. Better yet, use a really robust means of concatenation such as
> SPKI's length:string format: if you want to put together two tokens,
> "hello" and "mum", they are expressed as 5:hello3:mum. That way
> ambiguity is impossible.
I can actually think of one specific case where :: *will* appear in
URLs: IPv6 addresses. Unless we're going to ban running consumers and ID
servers on servers without hostnames (which will be unenforcable anyway,
as everyone will just implement the easiest thing possible) there will
one day be return URLs like http://[::1]/openid (that's the IPv6
loopback address, for example)
> OpenID consumers and servers should run NTP. If a timestamp appears to
> be in the future, it probably makes sense to tolerate it so long as the
> discrepancy is no more than a few seconds. (This should have gone into
> "lifespans" - sorry!)
That's something that will be impossible for many consumers. Remember
that there are loads of weblogs running on crummy hosting accounts where
the user only gets FTP access. The user is at the mercy of the server
admin to keep the clock set right. While I'd assume that most of them
are right, it would be wrong to make this a requirement as there may be
a drift of up to five minutes if the clock hasn't been set for a while.
> You should make it explicit that the return URL should always contain a
> nonce, and should be checked.
Currently a nonce is considered to be just a parameter the consumer
sends back to itself. The ID server ignores it. In previous discussion
on the subject it was noted that even if a nonce was mandatory some
consumers would just generate garbage so that they appear to have a
nonce. Make it a "best practice", sure, but making it mandatory to send
one is just going to give a false sense of security.
I think it's important to bear in mind that many (or even most)
consumers aren't going to be big sites like LiveJournal, they are going
to be little sites running simple CGI or PHP scripts as part of some
simple forum or weblog application they are running. I've not yet
absorbed the full implications of your proposals in previous threads,
but I think it's important to keep the consumer light. Ideally, I'd like
to keep the server light too, but since there will be less of those it
doesn't matter so much if they are more complex.
If it's a pain to implement in a simple and ideally stateless script,
it'll only be implemented by the "big guys", and in that case I would
consider it a failure just like every other similar scheme before it.
More information about the yadis