Maybe It's Snake Oil All the Way Down

[Peter Gutmann]

Ian Grigg <iang at systemics.com> writes:

>It's also very much oriented to x.509 and similar certificate/PKI models,
>which means it is difficult to use in web of trust (I know this because we
>started on the path of adding web of trust and text signing features to x.509
>before going back to OpenPGP), financial and nymous applications whereby
>trust is bootstrapped a different way.

That's a red herring.  It happens to use X.509 as its preferred bit-bagging
format for public keys, but that's about it.  People use self-signed certs,
certs from unknown CAs [0], etc etc, and you don't need certs at all if you
don't need them, <blatant self-promotion>I've just done an RFC draft that uses
shared secret keys for mutual authentication of client and server, with no
need for certificates of any kind</blatant self-promotion>, so the use of
certs, and in particular a hierarchical PKI, is merely an optional extra.
It's no more required in SSL than it is in SSHv2.

>Has anyone read Ferguson and Schneier's _Practical Cryptography_ ?  Does it
>address this issue of how an outsider decides how to "make or buy"?  I just
>read the reviews on Amazon, they are ... entertaining!

They spend a nontrivial portion of the book reinventing SSL/SSHv2.  I guess
they lean towards the roll-your-own side of the argument :-).  I'm firmly in
the opposite camp (see "Lessons Learned in Implementing and Deploying Crypto
Software", links off my home page at http://www.cs.auckland.ac.nz/~pgut001/).
I think that providing an abstract description of a fairly complex security
protocol *in a book targeted at security novices* and then hoping that they
manage to implement it correctly is asking for trouble.  OTOH it's fun going
through the thought processes involved in designing the protocol.  I just wish
they'd applied the process to SSL or SSHv2 instead, so that at the end of it
they could tell the reader to go out and grab an implementation that someone
else has got right for them.

Peter.

[0] The vendor of one widely-used MTA once told me that 90% of the certs they
    saw used in STARTTLS applications were non-big name CA-issued ones (self-
    signed, etc etc).