shared secret alternative to DSA

[Paul Crowley]

Jean-Luc Delatre wrote:
> Sorry, entirely untrue,  you need only a *subset* of ASN1.

Interesting.  Thanks.

> Yes,  I would very much like a completely stateless consumer if  that 
> can be done safely, i.e. safe from spoofing of the forwarded/returned 
> "state" values.

See my latest proposal riffing off Brad's ideas - now the simplest 
consumer doesn't have to understand the authentication at all.

> The server is an entirely different story from the consumer, performance 
> wise.
> However, for using HMAC, I would use Tiger hash rather than SHA1 which 
> is known to be "broken":
> http://lists.danga.com/pipermail/yadis/2005-May/000272.html

You're right - and Tiger is my favourite replacement, too.  It's a 
shame, because I'd rather recommend a NIST standard if possible, but 
SHA-256 and friends are such performance dogs that they really put me 
off.  Tiger is a very neat and powerful design.  Like SHA-256 and 
friends, it's a pain to implement without 64-bit math, but bearable.

I'd be interested to know what alternative hash function would be 
favoured by implementors.

> And I *do have* a Tiger hash implementation in Javascript which is 
> faster (20%) than Paul Johnston's SHA1

Cool.

> I am not convinced by "secrets in the clear"...

OK.  Why, incidentally?

> What about adding some kind of key in the <link re=...  key='... 
> base64..."  with which one could authenticate the server replies?
> Because there are really only *two* parties from the very beginning: the 
> consumer and the ID url issued thru the browser and each of those is 
> implicitely trustworthy to the other.

I like this proposal a lot: it is much closer to my personal allegiences 
on the matter of PKI, which are with things like SPKI and YURL. 
Unfortunately, to do it right it means importing all of something like 
SPKI into OpenID, which would kill it stone dead at a stroke.

Why do you need SPKI?  Because with all these references to the private 
key everywhere, it's very hard to change, so you want to protect it very 
well.  That means you don't want it resting on the server where it could 
be stolen, and you don't want to splash out for key storage hardware 
either, so you need to delegate its authority to other keys.  The 
authority delegated must be strictly time-limited and may be limited in 
other ways.  At this point, you've got half SPKI's feature set, and 
you'll probably find you need the other half too.

Once OpenID takes off, I'd like to propose some SPKI-based extensions 
that appropriate clients could use, but all that can be added later.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/