once more, with feeling.

Dirk-Willem van Gulik dirkx at webweaving.org
Wed Sep 17 16:02:47 EDT 2008


 > ... discussion on CA/cert acceptance hurdles in the UI ....

I am just wondering if we need a dose of PGP-style reality here.

We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst
they all appear use the same technology - the assurances, UI,  
operational
regimen, 'investment' and user expectations are way different:

A)	Symbolic Locks (think bicycle locks in Amsterdam, or the little
	plastic luggage locks people use) - just a bit of reassurance
	that snooping is not trivial.

	=> so you'd just want your browser to indicate something about
	SSL, just like you causally mention mime-type or port-number.

B)	Some sort of assurance that you are talking to whom you think you
	are talking to - and that such is the case next time round. And
	in a grown up sort of way - but no need to go the investment
	to have some paid minder reassuring you that there is no
	monster under the bed. E.g. some privacy, say on an online forum.

	=> so in this case you'd probably want a near friction less
	or perhaps even invisible initial persistent accept and
	some sort of low-key warning if the cert or chain changed
	over time beyond some range.

C)	Fair assurance that you are talking with whom you think
	you are talking to - is really that entity - and some
	trust. E.g. the canonical credit card payment case.

	=> behaviour as we have today.

D)	Proper TLS; where both each end of the connection has a well
	defined idea of the reliability. E.g. the authenticate
	properly with an x509 to a server with a cert against
	an explicit list of CA's which are carefully selected
	by the 'powers that be' and with full CRLs.

Unfortunately there is currently no way for the server to indicate any
of this; or the user to indicate what his or her expectations are.

So my take is that it is pretty much impossible to get the UI to do
the right thing - until it has this information* - and even then
you have a fair chunk of education left to do :).

But without it - the entire discussion is moot.

As to technical options to accomplish this - it would not be hard
to *_socialise_* a few small technical hints: i.e if it is a
straight  self-signed server, certificate, with minimal data - assume
A; case C is easy; and in case 'D' one would care enough to have
a proper set-up.

That just leaves case B - and distinguishing it from a failed C.  And
that is hard. Especially as a messy B should not compromise a C.

So I guess that needs some very clear marker from the site owner. Which
could be as simple as insisting on things like an funky DN, a CN with
the FQDN set to something like 'ad-hoc', a concept that a certificate
with just a CN, but no other O, OU, L or C fields.

And obviously one could try to boil the ocean; write a small RFC
detailing some OID to put in the certificate for case A & B :) - and
include the fewlines of openssl in the document to make your own
'B' certificate.

Key would not be the technical aspect - but socialising it with enough
webmaster folks** that there is enough of a mass to tempt them
browser boys. And that is the going to be the very hard part :)


Dw

*)  I strongly think that the current plug-ins which check if a
     certificates fingerprint is the same from multiple vantage
     points around the internet is really quite orthogonal to this
     issue. So no solace there.

**) And capitalise on the fact that they need to recreate their  
certificates
     as most folks seem to stick to the default 365 days.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list