One more time, SSL vs GPG was Re: hackage, cabal-get, and security

[Shae Matijs Erisson]

"S. Alexander Jacobson" <alex at alexjacobson.com> writes:

Abstract:

GPG and SSL are tools for entirely different goals.
GPG can give you some assurance that a file was signed by a certain person.
SSL can give you some assurance that received data is the same as server data.

SSL does not guarantee that a certain person put information on the server,
only that the information that you got did come from the server.
That's just not the same thing at all.


You can skip the rest of this message if you don't want the blow by blow.


> * With GPG, all developers need to create and manage private keys (including
> all that workflow associated pre-generating revocation certificates, etc).
> With SSL, only server operators do.

How do server operators know that the packages they get come from the actual
developers and are not forged? If you use an SSL upload, how do you know who or
where the upload came from? In this scenario, developers must be their own
server operators to achieve any security.

> * With GPG, developers need to keep their private keys secure on all their
> machines.  If ANY of their machines are cracked, their identity is owned
> until they are able to publish a revocation certificate. They need to keep
> all their revocation certificates in a safe place and NOT on the machine
> where they keep their private keys and proximate to wherever they happen to
> be!  Developers have to be really diligent.  With SSL, only server operators
> need to manage certs and they are already expected to be diligent.

No, this is not true. 

Keys are kept on a single machine. Your identity is not 'owned' if a copy of
your keyring is stolen, not unless that keyring has no password. You will want
to keep the revocation certificate in one or two other places, so there's a
greater chance that someone would crack your box and then revoke your key.

On the other hand, SSL certificates must have no password, or else they require
the server admin to type in the password each time the SSL server starts.
In the password case, you either need to decrease security by sharing the
password with multiple people or you need to wake up the guy with the password
everytime the power goes out, the kernel panics, or other force majeure
restarts the SSL server or the hardware.

If someone cracks the SSL server, how do you revoke the certificate?

> * With GPG, developers needs to establish a chain of key signings to all of
> the users of the modules they create. With SSL, developers only need a
> relationship with a server operator.

No, this is not true. 

There is no difference between a relationship with a server operator and a
chain of key signings.

> * With GPG, module users have to understand the whole public key security
> model and how to use gpg etc (e.g. how do they get a key signing
> relationship? how often will they do a gpg --refresh, why?). With SSL, users
> don't need to learn anything new.

SSL doesn't do what GPG does. SSL doesn't have any way to update certificate
trust other than manually removing or adding certificates.

> And this isn't all just theory.  In practice, SSL's transport security model
> has been *vastly* more successful in the real world than any content signing
> model (e.g. whatever happenned to SHTTP(1)).  And note that the *only*
> widespread code-signing model, is Microsoft's active-x and that relies on a
> centralized CA, like SSL, rather than a GPG style web-of-trust.

No, this is not true. 

Other widespread code-signing models exist in the form of Linux distributions
that allow signed packages that fit into the web of trust, see Mandriva, Red
Hat, and Debian for examples.

If you want to take Microsoft as an example, they also use GPG-style per-file
signatures for ActiveX components. They don't use SSL in place of the per-file
signatures.
-- 
It seems I've been living two lives. One life is a self-employed web developer
In the other life, I'm shapr, functional programmer.  | www.ScannedInAvian.com
One of these lives has futures (and subcontinuations!)|  --Shae Matijs Erisson