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

[Paul Crowley]

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.

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!)

You should make it explicit that the return URL should always contain a 
nonce, and should be checked.

In general, it would be good to go into more detail on exactly what 
precautions an identity client, or server, need to follow to preserve 
security.  You mention a couple (don't give away why identity was 
refused in the URL; don't accept trust roots like http://*.co.uk/) but I 
suspect there are more that you've bourne in mind while coding 
LiveJournal's OpenID implementation that need documented here - things 
about what you need to tell or warn the user, for example.

I proposed an SSO protocol similar to OpenID a while back: see
http://groups-beta.google.com/group/sci.crypt/msg/49211bbc7f871094
-- 

   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/