Weblog entry #12 for k2
See all weblog entries made by k2.
I was updating my Debian Unstable box a few minutes ago and during the pre-install configuration, it asked me if I wanted to install CA certicates for cacert.org and debconf.org. I didn't install them because it had asked me to install if I trusted them.
I had read Steve's recent article on SSH keys and hence wanted to know if there is a way to check the trustworthiness of these ca-certificates. Any help is welcome.
PS: The above said package ca-certificates was obtained from official debian repository by apt.
Comments on this Entry
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Compare fingerprints against those listed online?
[ Parent | Reply to this comment ]
He might have found them on the back of a cereal packet, but if you don't trust DD's you have bigger issues if you run Debian.
"Note that certificate authorities whose certificates are included in
this package are not in any way audited for trustworthiness and RFC
3647 compliance, and that full responsibility to assess them rests
with the user."
Basically if someone gets paid money to say you are who you claim to be, the whole scheme is flawed from the start. Now who do I have to pay to get my GPG key signed?
My experience at looking at the innards of certificate authority behavior, protocols and support is that "at least my credit card number is encrypted" as it goes to "who ever" ;)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
It's probably worth asking both of these questions about all the CAs that come pre-installed in your web browser, as well, though almost no one does this because there appears to be little choice at the moment.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I've expanded that discussion into a longer article talking about the details of what's wrong with our current X.509-based CA model.
You probably know/understand most of it already, but i'd be happy to hear any feedback about it. What i really want is time to work on the tools, of course ;)
[ Parent | Reply to this comment ]
Perhaps a little heavy for non-technical readers. But it taught me stuff I didn't know, and is very clear.
Afraid, whilst I understand conceptually the various encryption schemes as much as I need to use them without being too inept, I'm not up on cryptographic details, and I still have to reread the various howto documents regularly when doing anything with SSL/TLS.
I couldn't help thinking of Machiavelli;
"It must be considered that there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things...."
The problem with the CA-Cert is the financial model.
Whilst it would be nice to have communities come together for this, few organizations are that concerned. Looking at my "trusted" CAs I note that the ABA is the only one that leaps out as a community model. You'd think perhaps that other authorities would have arisen out of communities with a serious need for security, and big money, even if it was only other groups of bankers and money men.
It is tempting to throw away everything that came before. I must resist.
It is also tempting to look at solving the other big "SSL" issue at the same time, which is the handing of a certificate with the connection (i.e. One certificate per "IP address + port" combination). But I don't think for financial transactions this is a big issue.
Of course by putting a PGP signature along side a URI (protocol://server/ref + protocol://server/ref+sig) one can handle static content of all types within many existing protocols, and need only a small browser (or other software) plugin to validate the signatures. But I don't think that lends itself to dynamic content as well (I may be wrong on that).
Much for me to think about.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
You also raise good concerns about "throwing away everything that has gone before," and i share those concerns. This is why i'm a proponent of the OpenPGP keys extension for TLS: it leaves the existing TLS infrastructure intact, while piggybacking on it and another existing, well-tested model (OpenPGP) to provide a better way of doing things for folks who want to do better.
As for the one-cert-per-address/port combination problem, the OpenPGP certificate model would resolve that, since a single OpenPGP certificate can contain multiple subkeys and multiple uids.
But even if your toolset isn't ready for the OpenPGP extension to TLS, there are a number of other potential workarounds, depending on which aspect of the one-cert-per-address/port problem bugs you.
- rfc 3546 describes the TLS server name extension, which allows a pre-handshake negotiation of server name, which can then be used by the server to select a certificate. This is implemented in gnutls, but i'm not sure how widely-adopted it is in other libraries (or clients).
- rfc 3280 section 4.2.1.7 describes the SubjectAltName X.509 extension, which appears to allow multiple name-based vhosts (in the https context) on a single IP with a single certificate. I found this through the CA Cert VhostTaskForce, and i've published a couple more notes about it. It seems to be pretty widely supported in most modern web browsers. And servers can be comfortably agnostic about the contents of any extensions in the certificates they offer, though they'll need to know how to support it if you're doing reciprocal X.509 PKI authentication where the client offers its own cert to the server.
[ Parent | Reply to this comment ]
I'm not sure how your proposed model of an OpenPGP signature alongside a URI would work, even for static content. How would the signature be published? via a DNS extension? via the same protocol as the parent URI, but at some different, well-defined address? It's an interesting idea, but i want to know more.
It was something discussed before, when people discussed signing web content. Originally they proposed putting the signature in the mark-up, but that is messy.
People proposed different ideas for how to deliver the signature. For the web namespace just appending an agreed extension to the location part of the URI is probably "good enough", and would often support the same content via different means (file: http: https: ftp:). Probably best to work with the URI idea some more, any simple mechanical rules that gets from content to signature would work (e.g. file:///tmp/test.txt.pgp, file+pgp:///tmp/test.txt ...), but yes it makes sense to use the same underlying transport protocol in each case.
I don't see how it can be generalized to dynamic content easily. But then it does something different to https, one guarantees the message, the other the messenger.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
But then it does something different to https, one guarantees the message, the other the messenger.i'm not sure this is quite true. https does indeed guarantee the message, because the entire transaction is wrapped in a layer of strong encryption which is anchored by the certificate of the server. The messenger itself is no more guaranteed by https than the signing certificate authority.
[ Parent | Reply to this comment ]