As a lay user, I don't immediately see what's wrong with SSL itself. It seems to get the job done simply and right when it somes to HTTPS or some other protocol like IMAP over SSL if your provider supports it. What bugs me, again as a lay user, is the lack of support for SSL and existence of apparently pointless standards where SSL would do.
There's a huge number of web pages with more or less private content, like LJ, that don't go over SSL by default. Why not?
Only a few mail providers support client connections with IMAP or SMTP over SSL. Why not all of them?
Email transport is not encrypted. Surely that's ridiculous as there is always a DNS and an SMTP(?) server at the receiving end, which could hopefully be convinced to negotiate keys for their known users.
We seem to have a tool called SSH that I think is not the same as telnet over SSL. I only have a hazy understanding of what it is but it seems unnecessarily different. Why?
We have a VPN tool called IPsec, which again seems to be a different thing than SSL. Why?
So, I would naively expect there to be one thing that establishes an authenticated and encrypted point-to-point connection, and I'd expect all the other conenction-based tools to operate over it. I'd expect the creation of multiple VPNs over SSL to be a straightforward matter for user processes to arrange. I'd also expect to be able to make some DNS query that can provide a public key for joe@domain.tld (but maybe this is part of what you suggest). I wouldn't expect OpenPGP to be on the same bandwagon necessarily, as it's not connection-based. On the other hand, it's interesting to consider whether the same binary message format could serve both connection-based and file-based communications.
I'm not sure what all this has to do with your aims. I vaguely understand that the main thing you want to fix is having a working standard for a trust network, and a woking instance of that standard that isn't Verisign. However I don't understand to what extent the Verisign problem could be fixed by bringing out an instance rather than a standard for a new open certificate authority (so act like Verisign and have users manually accept your root certificates). I also don't understand how important would be the residual requirements if you take the view that host names get certified, and then the hosts can certify enything in their domains.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2007-02-19 12:34 pm (UTC)So, I would naively expect there to be one thing that establishes an authenticated and encrypted point-to-point connection, and I'd expect all the other conenction-based tools to operate over it. I'd expect the creation of multiple VPNs over SSL to be a straightforward matter for user processes to arrange. I'd also expect to be able to make some DNS query that can provide a public key for joe@domain.tld (but maybe this is part of what you suggest). I wouldn't expect OpenPGP to be on the same bandwagon necessarily, as it's not connection-based. On the other hand, it's interesting to consider whether the same binary message format could serve both connection-based and file-based communications.
I'm not sure what all this has to do with your aims. I vaguely understand that the main thing you want to fix is having a working standard for a trust network, and a woking instance of that standard that isn't Verisign. However I don't understand to what extent the Verisign problem could be fixed by bringing out an instance rather than a standard for a new open certificate authority (so act like Verisign and have users manually accept your root certificates). I also don't understand how important would be the residual requirements if you take the view that host names get certified, and then the hosts can certify enything in their domains.