And therein is the root of the problem: Trustworthiness is assessed by what you refer to as the "browser vendors". Unfortunately, there is no Trustworthiness assessment of those vendors.
The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates. It is nothing more than theatre and provides no actual security benefit whatsoever. Anyone believing otherwise is operating under a delusion.
--- Keith Medcalf
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org
Not strictly true. The current system at least gives you "you have reached
the hostname your browser tried to reach". A self-signed cert doesn't
even give you that.
> Because of that lost trust, any cross-signed cert would likely be
> revoked by the browsers. It would also make the browser vendors
> question whether the signing CA is worthy of their trust.
And therein is the root of the problem: Trustworthiness is assessed by what you refer to as the "browser vendors". Unfortunately, there is no Trustworthiness assessment of those vendors.
The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates. It is nothing more than theatre and provides no actual security benefit whatsoever. Anyone believing otherwise is operating under a delusion.
The problem is about lack of pen-testing and a philosphy of security. In order to run a CA, one not only has to build the infrastructure but also have constant external pen-testing and patch management in place. Whether it be Comodo or RSA or now Diginotar, unless an overwhelming philosphy of "computer and network security" is paradigmed into the corporate DNA, this will keep happening - and not only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read - APT attacks).
The problem for us as a community if to find a benchmark of which company "does have a clue" vs those that don't. Until then, it will just be whack-a-mole/CA.
You wouldn't have 2 certs for that... I'd have *one* cert for that. And if when
you got to the IP address you were trying to reach, the cert didn't validate as
matching the hostname, you know something fishy is up.
And if you *do* have two certs for it, I'd like to talk to the bozos at
Thawte and Comodo who obviously didn't check the paperwork.
This is a very interesting problem. As it happens, some folks in the
IETF have anticipated this one. For those who are interested, Paul
Hoffman and Jakob Schlyter have been working within the DANE working
group at the IETF to provide for a means to alleviate some of the
responsibility of the browser vendors as to who gets to decide what is a
valid certificate, by allowing for that burden to be shifted to the
subject through the use of secure DNS. A list of hashes is published in
the subject's domain indicating what are valid certificates. And so if
a CA went rogue, the subject domains would be able to indicate to the
browser that something is afoot. For more information, please see http://datatracker.ietf.org/wg/dane/.
Except that this just shifts the burden of trust on to DNSSEC, which also
necessitates a central authority of 'trust'. Unless there's an explicitly
more secure way of storing DNSSEC private keys, this just moves the bullseye
from CAs to DNSSEC signers.
In article <CAJNn=DNMrGC42i4Q_Wjvz-i9uV_4w1YnfM8vcX4g_wnXLoT=vA@mail.gmail.com> you write:
Except that this just shifts the burden of trust on to DNSSEC, which also
necessitates a central authority of 'trust'. Unless there's an explicitly
more secure way of storing DNSSEC private keys, this just moves the bullseye
from CAs to DNSSEC signers.
It does, but it also limits the damage. If you lose your DNSSEC key,
bad guys can forge names below you in the DNS tree. If you lose your
CA key, bad guys can forge any name they want.
Or to look at it another way, if I put effort into securing my own
DNS, and I am careful about the providers above me in the tree, I can
limit the chance of DNSSEC compromise. With SSL, it doesn't matter
what I do, I'm always at the mercy of the next Diginotar.
this has already happened with mozilla.com, google.com, microsoft.com
.... my point was that as a user, and as a service operator, what in
today's CA world helps me know that the service operator's certificate
is what my user-client sees? some 'trust' in the fact that
thawte/comodo/verisign/cnnic didn't issue a cert for the
service-operator's service incorrectly?
I think I need a method that the service operator can use to signal to
my user-client outside the certificate itself that the certificate #1234 is the 'right' one.
Date: Mon, 12 Sep 2011 11:22:11 -0400
Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy,
releases updates
From: Christopher Morrow <morrowc.lists@gmail.com>
I think I need a method that the service operator can use to signal to my
user-client outside the certificate itself that the certificate #1234 is the 'right' one.
A certificate that cdrtifies the crertificate is valid, maybe?
And why would you trust that any more than the origial certificate?
And, if you do trust *that* certificate, what do you need the original
one for?
Seriously, about the only way I see to ameliorate this kind of problem is
for people to use self-signed certificates that are then authenticated
by _multiple_ 'trust anchors'. If the end-user world raises warnings
for a certificate 'authenticated' by say, less than five separate entities.
then the compomise of any _single_ anchor is of pretty much 'no' value.
Even better, let the user set the 'paranoia' level -- how many different
'trusted' authorities have to have authenticated the self-signed certificate
before the user 'really trusts' it.
Similarly, the certificate 'owner' can decide how much 'redundancy' it
wants in the 'authentiation' of it's identity -- how many separate
authorities it gets to 'co-sign' it's certificate.
Date: Mon, 12 Sep 2011 11:22:11 -0400
Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy,
releases updates
From: Christopher Morrow <morrowc.lists@gmail.com>
I think I need a method that the service operator can use to signal to my
user-client outside the certificate itself that the certificate #1234 is the 'right' one.
A certificate that cdrtifies the crertificate is valid, maybe?
so the DANE work does this, sort of... you sign (with dnssec) your
cert fingerprint, the client does a lookup (requiring dnssec signed
responses) to verify that the cert FP matches that which is in DNS.
And why would you trust that any more than the origial certificate?
at least in this case the domain owner (presumably the service owner
in question) has signed (with their private key) the DNS content you
get back.
There are failure modes, but it's more in line with the
service-owner/service-user level not some oddball thirdparty.
Seriously, about the only way I see to ameliorate this kind of problem is
for people to use self-signed certificates that are then authenticated
by _multiple_ 'trust anchors'. If the end-user world raises warnings
for a certificate 'authenticated' by say, less than five separate entities.
then the compomise of any _single_ anchor is of pretty much 'no' value.
Even better, let the user set the 'paranoia' level -- how many different
'trusted' authorities have to have authenticated the self-signed certificate
before the user 'really trusts' it.
this almost sounds like GPS position fixing... 'require 4 satellites
in view', or something along those lines. Interesting as an idea
though.
So if I want my small website to support encryption, I now have to pay
5 companies, and hope that all my users have those 5 CAs in their
browser? Much better to use the existing DNS infrastructure (that all
5 of them would likely be using for their validation anyway), and not
have to pay anyone anything.
I said "some", not all, of the responsibility. By adding an independent
PKI there is an additional control put in place to confirm that in fact
the signer is authorized to sign. Should one go as far as to remove CA
caches from browsers altogether?
