On Aug 4, 2008, at 3:23 PM, michael@stroeder.com wrote:

Kurt Zeilenga wrote:

...

For instance, web_ldap says it provides a signature for a digital release, but clicking on the link provides a page which says "Not found".

I knew this (transition during a major OS update on my local machine). It's fixed.

My point was not wether you knew it or not, but whether any verifier would care.

...

But, as I noted with hashes, the fact that release messages are widely published may make it more likely that such problems will be detected.

Hashes have to be validated out-of-band each time a new release is published. The trusted keys be have to be validated out-of-band only each time a new trust anchor key is generated.

The point here that an attacker can create the same level of trust for any new signing key they might use (or trust in that no signing was done) for the rouge release as the trust tends to be just publication of the signing key on the web site.

And, as I noted, an attacker could just change stable from 2.m.y to 2.n.x, where 2.n.x was some crackable release.

Personally, I place a less trust on a signing key I fetch off a website than a hash I get both by email, on a moderated list, that I can verify in the list archives, and on the FTP site. The former is actually seems more subject to MITM attack than the latter. Now, with https:, I would say they have fairly comparable security considerations. Basically, if an attacker owns the website/ftp host, the attacker can fool most everyone.

...

For instance, one does need to consider that the host to sign the releases might itself been taken over and the implications of such a takeover.

There is no 100% security. I already know this. But raising security level is always an desirable goal.

You haven't clearly stated how the security level is actually getting raised through the signing you suggest.

...

Anyways, for this to go anywhere, I think you or others advocating it need to more precisely state which attacks you concerned about, how you think digital signatures will help, and detail requirements on that signing (in particular, requirements on signing key so trust can be established and maintained).

I have no objections against a single release manager using his personal key or a dedicated key for OpenLDAP tar.gz signing stored in your local file system reasonably protected by a passphrase. As I see it you're the

only one packaging the tar.gz. So this should not be too difficult for you.

What about a purely self-signed signing key with finger print published on the website, and possible release announcements. (The latter arguable would be better, as it's more widely published.) [This appears to be the appraoch you've taken with web2ldap.] But, as I've noted, this really doesn't offer significant better security than widely published hashes.

However, if what you want is a signing key in which members of the public can personally verify is in the control of the project, that would be more difficult to provide.

Or, if what you want is a signing key which is in a wide web of trust, the difficultly depends on the scale of the web of trust desired (to the point of approaching the general public problem).

Well, if you don't want to do that then just leave it...

...

Note that these are human-factor attacks, not attacks based upon any weakness in the PGP signing standards or implementations.

I already know that.

This comment was for the peanut gallery.

-- Kurt