On 30/12/08 13:13, Kyle Hamilton wrote:
You're failing to recognize one thing: if a Growl-like notification
came up whenever my browser established a TLS session, describing
"This certificate is said to belong to<subject>. The one who's
saying it is<Issuer>. BEWARE: this issuer is NOT audited to
financial services standards, do NOT put in your credit card or other
financial information"... well, I'd be able to see it, know about it,
and react to it appropriately.
This is much more likely to be a good model for the end-user, yes, and
was the original model from what I recall. This is based on the
principle that only end-to-end security models are worth much.
In fact, this could easily take the place of the "unknown_issuer" and
"issuer_not_trusted" errors. (Really, what are we saying there? We
don't know/trust the issuer to keep our financial information secure.
Why are we bundling 'financial security' with 'any security'?)
:)
As for "We aren't really purposing SSL to "just ecommerce" as far as I
know..." -- that's a load of baloney. When you look at the history
(Netscape partnering with Verisign to provide the lock icon *in order
to promote trust in ecommerce* -- remember, this was back just after
the Commercial Internet eXchange started, and began taking traffic off
of the entirely non-commercial NSFnet), and you look at the fact that
every audit requirement that the Mozilla Foundation is willing to
accept is based on either the ANSI X9 standards for financial-services
certification authorities, the WebTrust standards for the same, or the
ETSI standards which are designed to enable the issuance of Qualified
Certificates...
...every single one of these standards is for *financial services*.
Right, you are correct that those who built the process were orienting
SSL to credit cards and protection from eavesdropping.
However those who used the result -- the market place -- ignored all
that. In particular, the vast number of users look to three major uses:
* protection of non-ecommerce but still sensitive data
* online banking
* compliance (credit card processing)
That last is the old story.
What is particularly interesting here is that the online banking *is*
financially oriented, but SSL is not particularly good at it, has never
really been adequate or even compelling. Hence the green EV thing,
hence the original companies involved now sell other stuff to banks, and
certificates have a sort of "embarrassing relative" feel to them.
I honestly don't believe that it should be limited to financial
services (including due diligence related to providing financial
instruments including credit card numbers over the net between the
cardholder and the merchant). But, that's what we currently have,
because the inertia is so entrenched that nobody has ever been able to
convince the browser vendors that it might even remotely be a good
idea.
Right. We have this obsession with protecting the old vision.
Meanwhile the market has moved on. Including the threats market.
(in fact, it wasn't until a LOT of people got infuriated at Netscape
over the Verisign tax that other CAs were even allowed into the
program -- but every one of them was vetted to the same extent
Verisign was. Now, Mozilla, as the direct descendant of that code
base and mentality, has kept the same thing.)
Exactly. Something has to break. Which will it be? Right now, we are
seeing what is breaking.
Certificate usage is increasing (for whatever reason). So we are going
to see more things, more stress. This is just the beginning.
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
