Philipp Gühring wrote:
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.
We have the paradox situation that I have to tell people that they should use
HTTPS with server-certificates and username+password inside the HTTPS
session, because that´s more secure than client certificates ...
Does anyone have an idea how we can fix this flaw within SSL/TLS within a
reasonable timeframe, so that it can be implemented and shipped by the
vendors in this century?
(I don´t think that starting from scratch and replacing SSL makes much sense,
since it´s just one huge flaw ...)
re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
aka ... that was part of the relying-party-only certificates from the
mid-90s;
http://www.garlic.com/~lynn/subpubkey.html#rpo
i.e. the x.509 identity digital certificates from the early 90s, were
becoming
more and more overloaded with personal information ... and by the
mid-90s, lots of institutions were starting to realize all that personal
information represented significant privacy and liability issues ... and
the RPO digital certificates were born.
However, it was trivial to demonstrate that (for all those business
processes)
that the digital certificates were redundant and superfluous (however, there
was some amount of industry brain washing that digital certificates were
mandatory ... especially if digital signatures was used ... even if they
served no useful purpose).
this also showed up in work on pk-init for kerberos supporting digital
signature authentication ... and got into the confused mess with redundant
and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#kerberos
and similarly digital signatures for radius
http://www.garlic.com/~lynn/subpubkey.html#radius
(between kerberos and radius, they represent possibly the majority
of authentication in the world today)
part of the confusion regarding the necessity for digital certificates
could be seen in the X9F financial standards work ... the appending
of even a relying-party-only digital certificate (lacking any personal
information) could represent a factor of 100 times payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat
for a nominal electronic payment transactions (and also 100 times
processing bloat). as a result, there was some standardization
effort looking at "compressed" (relying party only) digital certificates
(even tho they were serving no useful purpose), attempting to
get the payload bloat down to possibly only 5-10 times (instead
of 100 times). I took the opportunity to demonstrate that it
would be logically possible to compress such digital certificates
to zero bytes ... totally eliminating the payload bloat. then rather
than advocating the elimination of totally useless, redundant
and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless
there could be an infrastructure that mandated zero-byte
digital certificates appended to every transaction.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
