Marc Branchaud wrote:
>
> Ian Grigg wrote:
> >
> > Tying the certificate into the core crypto protocol seems to be a
> > poor design choice; outsourcing any certification to a higher layer
> > seems to work much better out in the field.
>
> I'll reserve judgement about the significance of SSLBar, but I couldn't
> agree more with the above point. The only way to use non-X.509 certs
> with TLS 1.0 is by rather clunkily extending the ciphersuites to also
> identify some kind of certificate type.
I'm currently reading Eric Rescorla's SSL&TLS book,
and a significant proportion of the problems within
the SSL/TLS protocol seem to come from the assumption
that the cert should be supplied *within* the core
protocol, and not outsourced to a higher layer.
I.e., if SSL/TLS was re-written around this simple
separation into two separate sub-protocols:
1. get the/a/all certificate(s)
2. use the key within
a lot of the complexity would disappear.
(I understand the argument that SSL/TLS does not
"require" a cert, but to all intents and purposes,
everything and everyone assumes it, AFAICS. As a
practical issue, as it effects the implementations
out there, I'm not sure it makes sense to even
consider SSL/TLS without certs.)
It seems to me to be a developing principle.
We are all agreed that the delivery of (any/the)
cert is a very hard problem. We are mostly agreed
that it is an unsolved problem.
So, as a corollary to the "hard problem," the key
to use as the starting point for any crypto protocol
should be provided to it, not bootstrapped within.
(I wonder if there is a pithy way of stating this
principle? Good crypto divorces bad PKIs? Cost
effective crypto starts with an assumed key?)
> IMO, this fact has significantly contributed to the lack of adoption of
> PGP, SPKI, and alternative PKIs on the Internet.
(I'm not quite sure what the issue here is with
PGP ... it works fine without any certification,
and it works slightly better when 3rd party sigs
("certs"?) are added by the user? Although I
grant you that the key structure is .. costly
to code, to the point of being impermeable to
new implementations.)
> TLS's new extension mechanism can help address this (see
> draft-ietf-tls-openpgp-keys), but it'll be a while before extension
> support is common.
Yes, my company's protocol (SOX) "extends" the
certificate layer by using OpenPGP. Configuring
the issuance of a new monetary contract is a bit
of a bear, in no small part due to the chain of
signatures in the OpenPGP "PKI" that we use. But,
it works, and it doesn't feel as though the big
costly "PKI" process built out of OpenPGP slows
down adoption any.
[ We tried x.509 for a while, but it was a
mistake; it lacked cleartext signing (minor
point, we hacked our own) and its fixed PKI
doesn't map to financial relationships, which
are based on WoT, not centralised permissions. ]
SSH chooses the simplest solution - opportunistic
crypto - create the certs on demand and caching them
for future checking. That is the best success formula
I have seen so far.
--
iang
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
