Improving OpenID's use of cryptography 3 - odds and ends

[Martin Atkins]

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.