shared secret alternative to DSA
paul at ciphergoth.org
Sun Jun 5 11:03:41 PDT 2005
Jean-Luc Delatre wrote:
> Sorry, entirely untrue, you need only a *subset* of ASN1.
> 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
> However, for using HMAC, I would use Tiger hash rather than SHA1 which
> is known to be "broken":
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.
> faster (20%) than Paul Johnston's SHA1
> 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
More information about the yadis