I can recreate my system from backup in
Seconds Minutes Hours Days Weeks Never tested Never backed up ( 471 votes ~ 6 comments )
You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.
To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.
This is the comment you were replying to, attached to the weblog Debian ca-certificates question
#7 Re: Debian ca-certificates question Posted by dkg (216.254.xx.xx) on Mon 12 Mar 2007 at 17:13 Thanks for your feedback about the article, simonw. I agree that it's a little heavy for non-technical users, but i'm not sure how to make it less heavy and still encourage people to actually understand the tools they're using. I also regularly re-read the howtos and my own notes about SSL/TLS. They're complicated concepts, and they seem to be growing more complicated instead of simpler. 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. 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.
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.
Posting Format:
Inappropriate comments will be removed.
Some help on entry formatting is available
Username:
Password:
[ Advanced Login ]
Register Account
