Re: [gentoo-user] broken seamonkey :(

[lee <lee@yagibdah.de>]

Fernando Rodriguez <frodriguez.developer@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.