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

Abstracts: GPG secures documents, not interactions. SSL secures interactions, not documents Hackage is an interaction not a document. Therefore, SSL can secure Hackage, but GPG can't. GPG requires that users learn GPG and attend key signing parties. SSL requires no additional work from the user. Therefore, SSL is easier for users than GPG. GPG requires authors to learn GPG and attend key signing parties. SSL requires authors to learn nothing. Therefore, SSL is easier for authors. SSL requires server operators to obtain a cert and authenticate users. GPG requires little of server operators. Therefore, GPG is easier for server operators. GPG requires that an arbitrarily long chain of attendees at key signing parties all to manage keys AND verify identity properly in order to authenticate authorship of a document. SSL requires only that a server operators manage keys and verify identity properly in orer to authenticate authorship of a document. Therefore, SSL is less risky/more secure than GPG. Gory Details: A Hackage installation exists because some server operator did the due dilligence of building up an accurate package database. However, since Hackage exposes a search interface rather than a database file, absent a secure (SSL) connection to the server, Hackage users have no way to authenticate search results e.g a mapping from package name to URL. On Thu, 19 May 2005, Shae Matijs Erisson wrote:

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.

Typically server operators issue developers a password via some secure means. The server operator knows it is the developer that is uploading because only the developer (hopefully) has the password, just as with GPG only the developer (hopefuly) has the private key. I'm not sure what security you think developers need here.

...

* 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.

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.

No. You need a key on every machine on which you intend to sign code. The worry is not just that someone will steal your keyring file. The worry is that they replace your GPG executable with one that allows them to intercept your password. And my point about revocation certificates is that you are vulnerable to anyone in your network that fails to handle maintaining revocation certs properly. I think server operators are likely to be more reachable and diligent about such things than work-a-day developers. And the SSL/CA model doesn't require that a user maintain a revocation cert in order to accomplish a revocation!

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.

However, if someone gets root, they can do whatever they want anyway so, ALSO getting the private key may add little value. Moreover, since they can replace the password system and force a reboot in any case, there is no major value to requiring a password. Note, they can only do damage for the time they have root and are not discovered. Note that usually professionally managed SSL servers are more hardenned than the typical developer box.

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

You tell your CA to add it to a Certificate Revocation List.

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

Actually there is a substantial difference. Both sender and reciever have a very specific relationship with a CA whose job it is to provide these sorts of relationships. One requires you to go to key signing parties. The other does not. In theory you can implement a CA type role on top of GPG, but then you are operating a CA rather than a GPG chain of trust.

...

* 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.

SSL doesn't *need* a way to update certificates except when you want to add/remove a CA and that is/should-be relatively rare. GPG requires users to deal with manual key exchanges on a regular basis.

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.

With Debian, I assume you are referring to http://www.debian.org/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign It looks like they are experimenting with signing packages and it looks like they are still not clear on exactly what a signed package actually signifies. Note this is in contrast to signed release files which would be analogous to signed modulemaps rather than signed packages. In theory I could implement that sort of security for module maps, but that is a different discusion.

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.

True. Except that note that Microsoft code signing is CA based NOT GPG-style chain-of-trust based. And the reasons they chose code-signing over SSL for ActiveX are not necessarily relevant here. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

"S. Alexander Jacobson" 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.

...

* 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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries