Fernando Rodriguez <frodriguez.develo...@outlook.com> writes: > On Sunday, September 06, 2015 4:29:25 PM lee wrote:
> [...] >> >> When creating the certificate, I have used the fqdn the host does >> actually have and knows itself by (because I needed to fill in the >> fields, and it seemed most reasonable to use the actual host name). >> >> That this host can be reached at all, via different fqdns and IPs, is a >> matter of network traffic (re-)direction and of how the DNS-entries >> currently happen to be. They are all transparent and irrelevant to the >> user/client and subject to change. Why should they matter for a >> certificate which is supposed to let me figure out whether I'm >> connecting to the host I'm expecting to connect to, or to something >> else? > [...] > > An SSL certificate provides both encryption and authentication. For the > encryption part it's simple, you own the private key, the certificate has the > public key, so only you can decrypt whatever is encrypted with it. > > Authentication is more complicated. It's easy if you think of if like a > driver > license. The hostname is like the photo, if I get pulled over and hand over a > stolen license to the officer he'll know it's not me by looking at the photo. > Your browser does the same with the hostname, if somebody steals your private > key they will also have to steal your domain name to impersonate you. If > somebody grabs a hold of your CA's private key is like stealing the DMV > printer, now they can issue themselves a license with your name and their own > picture. But if they hand it over to an officer he will call it in and find > out > it's fake, that's the equivalent of revocation lists and ocsp. > > Of course it only works because we trust the DMV (or the CA in this case) to > be diligent in verifying you are who you say you are before issuing a license > or certificate. So it all doesn't apply as much to self issued certificates > but > it still applies to some extent. Actually, it does not work. What my face looks like is not subject to network traffic (re-)direction and the content of DNS entries. It changes with age and can still be recognized. I could send you a picture of my face and you would never know whose face is on the picture: that's like an FQDN or IP. I could just as well give you an IP address or FQDN to identify myself. The purpose of driver licenses is not identification. Anyway, why would I need some sort of document to identify myself if my face would suffice? In practise, the document is more important than the face that's on it. IIRC, there is a way with gpg to change the email address(es) of your key. That makes sense because the address is for having the convenience of not needing to specify a key-ID or something else. And that I might be using another email address does not invalidate the key. It's the key itself which is relevant, not what is being used to pick which key to choose. Linking a certificate to an FQDN or IP is clutching at straws at best. As my face changes with time, they also do. With documents to identify me, I don't update the picture all the time. When the ID-document I currently have expires, I won't have one that hasn't expired because they have become so insanely expensive that I can't afford one. That's similar to the work it would take to put a new certificate in place for all the users just because it's linked to an FQDN/IP. It might be cheaper if you could change out the picture as you can change the email address with gpg. The concept is flawed. And how could I myself verify that a CA does its job the way they are supposed to do it? In the end, it's no more than a deception, and that shouldn't be needed to be able to use encrypted connections. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
