Re: PGP signing release

Folks,

I think we should PGP sign all the "official" packages that are provided
for download from the various mirror sites. IMHO, this is important
because:

- ensuring that end users can trust PostgreSQL is an important part to
getting the product used in mission-critical applications, as I'm sure
you all know. Part of that is producing good software; another part is
ensuring that users can trust that the software we put out hasn't been
tampered with.

- people embedding trojan horses in open source software is not unheard
of. In fact, it's probably becoming more common: OpenSSH, sendmail,
libpcap/tcpdump and bitchx have all been the victim of trojan horse
attacks fairly recently.

- PGP signing binaries is relatively easy, and doesn't need to be done
frequently.

Comments?

I'd volunteer to do the work myself, except that it's pretty closely
intertwined with the release process itself...

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

Neil Conway <neilc(at)samurai(dot)com> writes:
> I think we should PGP sign all the "official" packages that are provided
> for download from the various mirror sites.

This is probably a good idea.

> I'd volunteer to do the work myself, except that it's pretty closely
> intertwined with the release process itself...

Marc would have to be the guy who actually generates the tarball
signatures. But you could possibly help him get the procedure set up,
if he's not familiar with it already...

regards, tom lane

On Sun, 2003-02-02 at 18:39, Neil Conway wrote:
> Folks,
>
> I think we should PGP sign all the "official" packages that are provided
> for download from the various mirror sites. IMHO, this is important
> because:
>
> - ensuring that end users can trust PostgreSQL is an important part to
> getting the product used in mission-critical applications, as I'm sure
> you all know. Part of that is producing good software; another part is
> ensuring that users can trust that the software we put out hasn't been
> tampered with.
>
> - people embedding trojan horses in open source software is not unheard
> of. In fact, it's probably becoming more common: OpenSSH, sendmail,
> libpcap/tcpdump and bitchx have all been the victim of trojan horse
> attacks fairly recently.
>
> - PGP signing binaries is relatively easy, and doesn't need to be done
> frequently.
>
> Comments?
>
> I'd volunteer to do the work myself, except that it's pretty closely
> intertwined with the release process itself...
>
> Cheers,
>
> Neil

Actually, if you just had everyone sign the "official" key and submit it
back to the party that's signing, that would probably be good enough.
Basically, as long as people can verify the package has been signed and
can reasonably verify that the signing key is safe and/or can be
verified, confidence should be high in the signed package.

I certainly have no problem with people signing my key nor with signing
others as long as we can verify/authenticate each others keys prior.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Sun, 2 Feb 2003, Neil Conway wrote:

> Folks,
>
> I think we should PGP sign all the "official" packages that are provided
> for download from the various mirror sites. IMHO, this is important
> because:
>
> - ensuring that end users can trust PostgreSQL is an important part to
> getting the product used in mission-critical applications, as I'm sure
> you all know. Part of that is producing good software; another part is
> ensuring that users can trust that the software we put out hasn't been
> tampered with.

right, that is why we started to provide md5 checksums ...

> I'd volunteer to do the work myself, except that it's pretty closely
> intertwined with the release process itself...

well, if you want to tell me the steps, I'll consider it ...

On Sunday 02 February 2003 21:23, Marc G. Fournier wrote:
> On Sun, 2 Feb 2003, Neil Conway wrote:
> > I think we should PGP sign all the "official" packages that are provided
> > for download from the various mirror sites. IMHO, this is important
> > because:

> right, that is why we started to provide md5 checksums ...

Actually this impacts RPMs more than the tarball, although the tarball's md5
sums are important. I have been intending to do this for some time; maybe
it's time to bite the bullet.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> On Sun, 2 Feb 2003, Neil Conway wrote:
>> - ensuring that end users can trust PostgreSQL is an important part to
>> getting the product used in mission-critical applications, as I'm sure
>> you all know. Part of that is producing good software; another part is
>> ensuring that users can trust that the software we put out hasn't been
>> tampered with.

> right, that is why we started to provide md5 checksums ...

The md5 checksum is useful as a cross-check that you've got a clean
copy, but it doesn't prove that the copy on the FTP site hasn't been
tampered with. Someone who's managed to break into the FTP server
could replace the tarball with a trojaned version *and* alter the md5
file to match. The point of a PGP signature is that only someone who
has the corresponding secret key could make a signature file that
matches the tarball and the public key.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I think we should PGP sign all the "official" packages that are
> provided for download from the various mirror sites.

Doesn't anyone around here read pgsql-general? :) I've been arguing for
this over there since June of last year. I've also been signing the
checksums with PGP and posting those to the mailing list.

If this is done (and I am very glad to see a renewed interest forming),
I'd like to see it done the correct way - it's too easy to get this wrong
and could actually decrease the security of the project by providing a
false sense of security. I think this list would be a good place to discuss
how it would be implemented.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200302030948
-----BEGIN PGP SIGNATURE-----
Comment: http://www.gtsm.com/pgp.html

iD8DBQE+PoGQvJuQZxSWSsgRAinkAJ9HViGZIfWVvX8RswLsNfec7ln6yQCfbO+L
WjSKSr61QKkfpL6Ax0vt4Ag=
=0MK8
-----END PGP SIGNATURE-----

On Sun, 2003-02-02 at 21:23, Marc G. Fournier wrote:
> well, if you want to tell me the steps, I'll consider it ...

I certainly wouldn't consider myself to be an expert in PGP, but my
understanding of the basic steps is:

(1) Generate a public/private key pair for the PGDG team. This should be
used to sign all "official" packages.

(2) Have this PK signed by various people who can actually verify that
Marc Fournier == 'that PGP key' == 'PGDG member'.

(2) Upload the public key to PGP keyservers, like keyserver.net,
www.pgp.net, etc. as well as provide a copy of the public key on
www.postgresql.org and ftp.postgresql.org

(3) Sign official releases using the PGDG private key, and provide the
signatures on www.postgresql.org along with the packages themselves.

If someone more experienced in the use of PGP would like to comment,
please go ahead.

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

> (3) Sign official releases using the PGDG private key, and provide the
> signatures on www.postgresql.org along with the packages themselves.

Sounds about right. I'd go as far as to sign release announcements and
security emails as well.

--
Rod Taylor <rbt(at)rbt(dot)ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

On Sun, 2003-02-02 at 20:23, Marc G. Fournier wrote:

> right, that is why we started to provide md5 checksums ...

md5 checksums only validate that the intended package (trojaned or
legit) has been properly received. They offer nothing from a security
perspective unless the checksums have been signed with a key which can
be readily validated from multiple independent sources.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Mon, Feb 03, 2003 at 12:24:14PM -0600, Greg Copeland wrote:
> On Sun, 2003-02-02 at 20:23, Marc G. Fournier wrote:
>
> > right, that is why we started to provide md5 checksums ...
>
> md5 checksums only validate that the intended package (trojaned or
> legit) has been properly received. They offer nothing from a security
> perspective unless the checksums have been signed with a key which can
> be readily validated from multiple independent sources.

If you can get the md5 sum of "multiple independent sources",
it's about the same thing. It all depends on how much you trust
those sources.

I'm not saying md5 is as secure as pgp, not at all, but you can't
trust those pgp keys to be the real one either.

Kurt

On Mon, 3 Feb 2003, Kurt Roeckx wrote:

> I'm not saying md5 is as secure as pgp, not at all, but you can't
> trust those pgp keys to be the real one either.

Sure you can. Just verify that they've been signed by someone you trust.

For example, next time I happen to run into Bruce Momjian, I hope he'll
have his PGP key fingerprint with him. I can a) verify that he's the
same guy I who, under the name "Bruce Momjian," was giving the seminar I
went to last weekend, and b) check his passport ID to see that the U.S.
government believes that someone who looks him is indeed "Bruce Momjian"
and a U.S. citizen. That, for me, is enough to trust that he is who he
says he is when he gives me the fingerprint.

I take that fingerprint back to my computer and verify that the key I
downloaded from the MIT keyserver has the same fingerprint. Then I sign
that key with my own signature, assigning it an appropriate level of trust.

Next time I download a postgres release, I then grab a copy of the
postgres release-signing public key, and verify that its private key was
used to sign the postgres release, and that it is signed by Bruce's key.

Now I have a direct chain of trust that I can evaluate:

1. Do I believe that the person I met was indeed Bruce Momjian?

2. Do I trust him to take care of his own key and be careful signing
other keys?

3. Do I trust his opinion that the postgres release-signing key that
he signed is indeed valid?

4. Do I trust the holder of the postgres release-signing key to have
taken care of the key and have been careful about signing releases
with it?

Even if you extend this chain by a couple of people, that's trust in a
lot fewer people than you're going to need if you want to trust an MD5
signature.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Mon, 2003-02-03 at 13:55, Kurt Roeckx wrote:
> On Mon, Feb 03, 2003 at 12:24:14PM -0600, Greg Copeland wrote:
> > On Sun, 2003-02-02 at 20:23, Marc G. Fournier wrote:
> >
> > > right, that is why we started to provide md5 checksums ...
> >
> > md5 checksums only validate that the intended package (trojaned or
> > legit) has been properly received. They offer nothing from a security
> > perspective unless the checksums have been signed with a key which can
> > be readily validated from multiple independent sources.
>
> If you can get the md5 sum of "multiple independent sources",
> it's about the same thing. It all depends on how much you trust
> those sources.
>
> I'm not saying md5 is as secure as pgp, not at all, but you can't
> trust those pgp keys to be the real one either.

No, that is not the same thing at all. PKI specifically allows for "web
of trust". Nothing about md5 checksums allows for this. As such,
chances are, if a set of md5 checksums have been forged, they will be
propagated and presented as being valid even though they are not.

I'll say this again. Checksums alone offers zero security protection.
It was never intended to address that purpose. As such, it does not
address it. If you need security, use a security product. Checksums
ONLY purpose is to ensure copy propagation validation. It does not
address certification of authenticity in any shape or form.

As for trusting the validity of the keys contained within a PKI, that's
where the whole concept of "web of trust" comes into being. You can
ignore it and not benefit or you can embrace it, as people are
advocating, and leverage it.

Validation of keys can be as simple as snail-mail, phone calls, and
fingerprint validation. It's that simple. It's why fingerprints exist
in the first place.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Mon, 2003-02-03 at 22:35, Curt Sampson wrote:
> On Mon, 3 Feb 2003, Kurt Roeckx wrote:
>
> > I'm not saying md5 is as secure as pgp, not at all, but you can't
> > trust those pgp keys to be the real one either.
>
> Sure you can. Just verify that they've been signed by someone you trust.
>
> For example, next time I happen to run into Bruce Momjian, I hope he'll
> have his PGP key fingerprint with him. I can a) verify that he's the
> same guy I who, under the name "Bruce Momjian," was giving the seminar I
> went to last weekend, and b) check his passport ID to see that the U.S.
> government believes that someone who looks him is indeed "Bruce Momjian"
> and a U.S. citizen. That, for me, is enough to trust that he is who he
> says he is when he gives me the fingerprint.
>
> I take that fingerprint back to my computer and verify that the key I
> downloaded from the MIT keyserver has the same fingerprint. Then I sign
> that key with my own signature, assigning it an appropriate level of trust.
>
> Next time I download a postgres release, I then grab a copy of the
> postgres release-signing public key, and verify that its private key was
> used to sign the postgres release, and that it is signed by Bruce's key.
>
> Now I have a direct chain of trust that I can evaluate:
>
> 1. Do I believe that the person I met was indeed Bruce Momjian?
>
> 2. Do I trust him to take care of his own key and be careful signing
> other keys?
>
> 3. Do I trust his opinion that the postgres release-signing key that
> he signed is indeed valid?
>
> 4. Do I trust the holder of the postgres release-signing key to have
> taken care of the key and have been careful about signing releases
> with it?
>
> Even if you extend this chain by a couple of people, that's trust in a
> lot fewer people than you're going to need if you want to trust an MD5
> signature.
>
> cjs

And that's the beginning of the web of trust. ;) Worth noting that
snail-mail and phone calls can easily play a role in this process as
well. I think if USPO can play a role in delivering master keys for pin
pads used by banks across America and the around the world, surely it's
good enough to help propagate key information for signing packages.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Mon, 2003-02-03 at 22:35, Curt Sampson wrote:
> 2. Do I trust him to take care of his own key and be careful signing
> other keys?
>
> 3. Do I trust his opinion that the postgres release-signing key that
> he signed is indeed valid?
>
> 4. Do I trust the holder of the postgres release-signing key to have
> taken care of the key and have been careful about signing releases
> with it?
>

Sorry to respond again, however, I did want to point out, signing a key
does not have to imply an absolute level of trust of the signer. There
are several trust levels. For example, if we validated keys via phone
and mail, I would absolutely not absolutely trust the key I'm signing.
However, if I had four people which mostly trusted the signed key and
one or two which absolutely trusted the signed key whom I absolutely
trust, then it's a fairly safe bet I too can trust the key. Again, this
all comes back to building a healthy web of trust.

Surely there are a couple of key developers whom would be willing to
sign each other's keys and have previously met before. Surely this
would be the basis for phone validation. Then, of course, there is 'ol
snail-mail route too. Of course, nothing beats meeting in person having
valid ID and fingerprints "in hand." ;)

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Tue, 3 Feb 2003, Greg Copeland wrote:

> Surely there are a couple of key developers whom would be willing to
> sign each other's keys and have previously met before. Surely this
> would be the basis for phone validation. Then, of course, there is 'ol
> snail-mail route too. Of course, nothing beats meeting in person having
> valid ID and fingerprints "in hand." ;)

I should mention, I'm not always so paranoid that I check ID and all of
that. It really depends on how well I know the person. I've met Bruce only
once, so I wouldn't do it over the phone at all, since we don't share much
non-public background and I'm not dead certain that I could tell his voice
from a similar one. The same is not true when it comes to doing this with
some of my close friends.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Mon, Feb 03, 2003 at 22:55:12 -0600,
Greg Copeland <greg(at)CopelandConsulting(dot)Net> wrote:
>
> I'll say this again. Checksums alone offers zero security protection.
> It was never intended to address that purpose. As such, it does not
> address it. If you need security, use a security product. Checksums
> ONLY purpose is to ensure copy propagation validation. It does not
> address certification of authenticity in any shape or form.

Checksums can be used for security in that they can be transmitted through
alternative channels using lower bandwidth than that used for the raw data.
(They are also what is normally signed by asymmetric keys for performance
reasons.).

And note that even signing the releases only protects against some kinds
of problems. If someone breaks into the CVS server shortly before a release,
they could change the source code and have a reasonable chance that the change
would go unnoticed for long enough to make it into a release. There are also
circumstances that the developers might be compromised (at least from the
standpoint of the downloaders). I wouldn't be that surprised if under pressure
from the FBI the developers might cooperate in getting a trojaned copy of
the database server into the hands of someone the FBI was interested in.
(Ogranized crime really should be supporting open source since they really
need software they can trust and it is a lot easier to check for trojaned
source, than it is for trojaned binaries.) Large amounts of money could also
produce the same result. I don't think either of those scenarios is likely,
but they are possible.

Signing the releases is a good idea, but they aren't going to be a 100%
guarenty against trojans.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are generally two ways to do it: have a "project" key, or have
each developer use their own key. The advantage of the first way is
that each release is signed by the same key, which is clearly
associated with the project. The disadvantage is control, security,
and accountablility. The second way pretty much reverses the
arguments: each key is controlled by one person, but there is no
obvious mapping between that person and the project. Individual keys
also have a history associated with them, and are usually already
integrated into the Web of Trust.

Many projects use the individual method, including Apache, GnuPG, and
OpenSSH. Some use the project method, such as sendmail and proftpd.
Either is okay with me, but some questions need to be answered if
using a project key:

Who will actually hold the key? Where will it be physically kept?

How many people will know the passphrase?

Who will be responsible for signing the files? Is there a backup person?

Will it be a signing-only key? What size? Should it expire?

How is verification of the files before signing accomplished?

I've got some ideas about most of those, especially the last two. This will
not be that easy of a process, but on the other hand, new versions do not
appear very frequently, and it is important to get this right the first time.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200302041207

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+P/XQvJuQZxSWSsgRAuKEAJwPKMe/nlBIk/Qm/dh2BbPvXbUQ4gCfeVqD
8TkRv3JkZ9T7t2YYBaCVc24=
=RnK6
-----END PGP SIGNATURE-----

On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:
> On Mon, 3 Feb 2003, Kurt Roeckx wrote:
>
> > I'm not saying md5 is as secure as pgp, not at all, but you can't
> > trust those pgp keys to be the real one either.
>
> Sure you can. Just verify that they've been signed by someone you trust.

I know how it works, it's just very unlikely I'll ever meet
someone so it gives me a good chain.

Anyway, I think pgp is good thing to do, just don't assume that
it's always better then just md5.

Kurt

On Tue, 2003-02-04 at 12:55, Kurt Roeckx wrote:
> On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:
> > On Mon, 3 Feb 2003, Kurt Roeckx wrote:
> >
> > > I'm not saying md5 is as secure as pgp, not at all, but you can't
> > > trust those pgp keys to be the real one either.
> >
> > Sure you can. Just verify that they've been signed by someone you trust.
>
> I know how it works, it's just very unlikely I'll ever meet
> someone so it gives me a good chain.
>
> Anyway, I think pgp is good thing to do, just don't assume that
> it's always better then just md5.

Not necessarily better -- but it's always as good as md5.

--
Rod Taylor <rbt(at)rbt(dot)ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

Having just started working with GPG I shouldn't be considered an expert but
it seems to me that each core developer should create a key and should
cross-sign each others' keys to form a web of trust to verify the
authenticity of those signatures. In any case, I think that if
security-related projects like GnuPG and OpenSSH use the individual method
then it wouldn't be a bad idea to follow their lead.

One hopes that situations like last week's "ousting" of one of the core
FreeBSD developers
(http://slashdot.org/article.pl?sid=03/02/03/239238&mode=thread&tid=122&tid=156)
are rare but if such a situation were to arise, a shared project key would be
Very Bad (tm).

If I understand GPG correctly, one can create a "detached signature" of a
document. As such, any or all of the core developers could create and post
such a signature and a user could verify against as many signatures as
desired to feel secure that the file is good.

Cheers,
Steve

On Tuesday 04 February 2003 9:15 am, greg(at)turnstep(dot)com wrote:
> There are generally two ways to do it: have a "project" key, or have
> each developer use their own key. The advantage of the first way is
> that each release is signed by the same key, which is clearly
> associated with the project. The disadvantage is control, security,
> and accountablility. The second way pretty much reverses the
> arguments: each key is controlled by one person, but there is no
> obvious mapping between that person and the project. Individual keys
> also have a history associated with them, and are usually already
> integrated into the Web of Trust.
>
> Many projects use the individual method, including Apache, GnuPG, and
> OpenSSH. Some use the project method, such as sendmail and proftpd.
> Either is okay with me, but some questions need to be answered if
> using a project key:
>
> Who will actually hold the key? Where will it be physically kept?
>
> How many people will know the passphrase?
>
> Who will be responsible for signing the files? Is there a backup person?
>
> Will it be a signing-only key? What size? Should it expire?
>
> How is verification of the files before signing accomplished?
>
>
> I've got some ideas about most of those, especially the last two. This will
> not be that easy of a process, but on the other hand, new versions do not
> appear very frequently, and it is important to get this right the first
> time.

Comments intermixed below.

On Tue, 2003-02-04 at 12:04, Steve Crawford wrote:
> Having just started working with GPG I shouldn't be considered an expert but
> it seems to me that each core developer should create a key and should
> cross-sign each others' keys to form a web of trust to verify the

This is a good idea regardless as which "key" approach is used. Being
able to reliably trust a key is only as strong as the associated "web of
trust."

> authenticity of those signatures. In any case, I think that if
> security-related projects like GnuPG and OpenSSH use the individual method
> then it wouldn't be a bad idea to follow their lead.
>

There are pros and cons associated with each approach. Neither is
really better IMO. If three people are required to sign a package prior
to release, what happens when one of them is unavailable for signing
(vacation, hospital, etc). This is one of the reasons why having a
single project key which the core developers sign may appear to be
easier.

> One hopes that situations like last week's "ousting" of one of the core
> FreeBSD developers
> (http://slashdot.org/article.pl?sid=03/02/03/239238&mode=thread&tid=122&tid=156)
> are rare but if such a situation were to arise, a shared project key would be
> Very Bad (tm).
>

If a revocation key has been properly generated (as it should of been),
this is not a problem at all. The revocation key is quickly shot over
to the known key servers and included with the newly generated project
key. As people add and confirm the new project key, the old key is
automatically revoked. Again, if this is properly handled, it is not
much of a problem at all. PKI, by means of revocation keys,
specifically addresses this need.

> If I understand GPG correctly, one can create a "detached signature" of a
> document. As such, any or all of the core developers could create and post
> such a signature and a user could verify against as many signatures as
> desired to feel secure that the file is good.
>
> Cheers,
> Steve
>

IIRC, PGP and GPG both support detached signatures.
> >
> > Who will actually hold the key? Where will it be physically kept?

Good question but can usually be addressed.

> >
> > How many people will know the passphrase?

As few as possible. Ideally only two, maybe three core developers. One
could also only allow a single person to hold the passphrase and divide
it into parts between two or more. This is commonly done in financial
circles. The exact details will be mostly driven by the key approach
that is picked.

> >
> > Who will be responsible for signing the files? Is there a backup person?
> >

This is important to make sure that any backup people are properly
included in the "web of trust" from the very beginning.

> > Will it be a signing-only key? What size? Should it expire?
> >

Keys should always expire. If you want to allow for one year, two year,
or even maybe three years, that's fine. Nonetheless, expiration should
always be built in, especially on a project like this where people may
be more transient.

> > How is verification of the files before signing accomplished?
> >

The person creating the initial package release should also initially
sign it. From there, the web of trust for the people signing it can
work as designed. Once the initial package has been generated, it
should not leave his eyes until it has been signed.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Tue, 2003-02-04 at 12:02, Rod Taylor wrote:
> On Tue, 2003-02-04 at 12:55, Kurt Roeckx wrote:
> > On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:
> > > On Mon, 3 Feb 2003, Kurt Roeckx wrote:
> > >
> > > > I'm not saying md5 is as secure as pgp, not at all, but you can't
> > > > trust those pgp keys to be the real one either.
> > >
> > > Sure you can. Just verify that they've been signed by someone you trust.
> >
> > I know how it works, it's just very unlikely I'll ever meet
> > someone so it gives me a good chain.
> >
> > Anyway, I think pgp is good thing to do, just don't assume that
> > it's always better then just md5.
>
> Not necessarily better -- but it's always as good as md5.

Even improperly used, digital signatures should never be worse than
simple checksums. Having said that, anyone that is trusting checksums
as a form of authenticity validation is begging for trouble. Checksums
are not, in of themselves, a security mechanism. I can't stress this
enough. There really isn't any comparison here. Please stop comparing
apples and oranges. No matter how hard you try, you can not make orange
juice from apples.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
>
> Even improperly used, digital signatures should never be worse than
> simple checksums. Having said that, anyone that is trusting checksums
> as a form of authenticity validation is begging for trouble.

Should I point out that a "fingerprint" is nothing more than a
hash?

> Checksums are not, in of themselves, a security mechanism.

So a figerprint and all the hash/digest function have no purpose
at all?

> There really isn't any comparison here.

I didn't say you could compare the security offered by both of
them. All I said was that md5 also makes sense from a security
point of view.

Should I also point out that md5 really isn't a "checksum",
it's a digest or hash. I have to agree that a real checksum,
where you just add all the bytes, offers no protection.

Kurt

On Tue, 4 Feb 2003, Kurt Roeckx wrote:

> I know how it works, it's just very unlikely I'll ever meet
> someone so it gives me a good chain.

One postgresql conference is all it takes.

> Anyway, I think pgp is good thing to do, just don't assume that
> it's always better then just md5.

I think it is. Even if you can't personally trust the signature properly,
it offers much more opportunity to discover a forgery because if you grab
the signing key when it's first published, the aquisition of the key and
the potentially forged binary are separated in time, making substitution
of both much more difficult.

Someone can easily change an MD5 signature file that's sitting right next
to a binary on an FTP server. Someone can not easily change a PGP key that's
already sitting in your keyring on your computer.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Tue, 4 Feb 2003, Kurt Roeckx wrote:

> > There really isn't any comparison here.
>
> I didn't say you could compare the security offered by both of
> them. All I said was that md5 also makes sense from a security
> point of view.

MD5, or any other unsigned check, makes sense from a security point of
view only if it is stored independently from the thing you are checking.
So NetBSDs package system MD5 hashes help a little with security.
(You'd have to modify both those on the NetBSD FTP server or anoncvs or
whatever *and* the binary on an independently run FTP server.)

If the "security token" is stored with the item to be secured (i.e.,
on the same FTP server) and is unsigned, it is just as subject to
modification as the item itself, and provides no extra security.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote:
> On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
> >
> > Even improperly used, digital signatures should never be worse than
> > simple checksums. Having said that, anyone that is trusting checksums
> > as a form of authenticity validation is begging for trouble.
>
> Should I point out that a "fingerprint" is nothing more than a
> hash?
>

You seem to not understand the part where I said, "in of themselves."
Security is certainly an area of expertise where the devil is in the
details. One minor detail can greatly effect the entire picture.
You're simply ignoring all the details and looking for obtuse
parallels. Continue to do so all you like. It still doesn't
effectively and reliably address security in the slightest.

> > Checksums are not, in of themselves, a security mechanism.
>
> So a figerprint and all the hash/digest function have no purpose
> at all?
>

This is just getting silly and bordering on insulting. If you have
meaningful comments, please offer them up. Until such time, I have no
further comments for you. Obviously, a fingerprint is derivative piece
of information which, in of it self, does not validate anything.
Thusly, the primary supporting concept is the "web of trust", associated
process and built in mechanisms to help ensure it all makes sense and
maintained in proper context. Something that a simple MD5 checksum does
not provide for. Not in the least.

A checksum or hash only allows for comparisons between two copies to
establish they are the same or different. It, alone, can never reliably
be a source of authentication and validation. A checksum or hash,
alone, says nothing about who created it, where it came from, how old it
is, or whom is available to readily and authoritatively assist in
validation of the checksummed (or hashed) entity or the person who
created it.

I do agree that a checksum (or hash) is better than nothing, however, a
serious security solution it is not. Period. Feel free to be lulled
into complacent comfort. In the mean time, I'll choose a system which
actually has a chance at working.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote:
> On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
> >
> > Even improperly used, digital signatures should never be worse than
> > simple checksums. Having said that, anyone that is trusting checksums
> > as a form of authenticity validation is begging for trouble.
>
> Should I point out that a "fingerprint" is nothing more than a
> hash?

Since someone already mentioned MD5 checksums of tar files versus PGP
key fingerprints, perhaps things will become a bit clearer here if I
point out that the important point is not that these are both hashes of
some data, but that the time and means of acquisition of that hash are
entirely different between the two.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Tue, 2003-02-04 at 18:27, Curt Sampson wrote:
> On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote:
> > On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
> > >
> > > Even improperly used, digital signatures should never be worse than
> > > simple checksums. Having said that, anyone that is trusting checksums
> > > as a form of authenticity validation is begging for trouble.
> >
> > Should I point out that a "fingerprint" is nothing more than a
> > hash?
>
> Since someone already mentioned MD5 checksums of tar files versus PGP
> key fingerprints, perhaps things will become a bit clearer here if I
> point out that the important point is not that these are both hashes of
> some data, but that the time and means of acquisition of that hash are
> entirely different between the two.

And that it creates a verifiable chain of entities with direct
associations to people and hopefully, email addresses. Meaning, it
opens the door for rapid authentication and validation of each entity
and associated person involved. Again, something a simple MD5 hash does
not do or even allow for. Perhaps even more importantly, it opens the
door for rapid detection of corruption in the system thanks to
revocation certificates/keys. In turn, allows for rapid repair in the
event that the worst is realized. Again, something a simple MD5 does
not assist with in the least.

Thanks Curt.

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

----- Original Message -----
From: "Kurt Roeckx" <Q(at)ping(dot)be>
>
> Should I point out that a "fingerprint" is nothing more than a
> hash?
>

If somebody shows you their passport to prove who they are and then gives
you a fingerprint of their PGP key, they have implicitly signed that
fingerprint. By contrast, a simple MD5 checksum of a binary sitting on the
same server is effectively unsigned.

You might like to do a little reading on PKI and how it works, before you
make further comment.

cheers

andrew

On Tue, Feb 04, 2003 at 23:13:47 +0100,
Kurt Roeckx <Q(at)ping(dot)be> wrote:
>
> So a figerprint and all the hash/digest function have no purpose
> at all?

The purpose of both is to reduce the amount of material in a way that
makes it hard to generate some other material that would result in the
same hash or fingerprint. This allows you to reduce the cost of transmitting
the data or making computations (in particular signing) on the data.

On Wed, 4 Feb 2003, Greg Copeland wrote:

> If three people are required to sign a package prior to release,
> what happens when one of them is unavailable for signing (vacation,
> hospital, etc). This is one of the reasons why having a single project
> key which the core developers sign may appear to be easier.

I don't see that it makes that much difference. So the release is signed
only by, say, only three people instead of four. It's still signed.

> > One hopes that situations like last week's "ousting" of one of the
> > core FreeBSD developers are rare but if such a situation were to
> > arise, a shared project key would be Very Bad (tm).
>
> If a revocation key has been properly generated (as it should of been),
> this is not a problem at all.

Actually, it is still a problem. Revocations are not reliable in PGP,
and there's really no way to make them perfectly reliable in any system,
because you've got no way to force the user to check that his "cached
data" (i.e., the key he holds in his keyring) is still valid. This is why
we generally expire signing keys and certificates and stuff like that on
a regular basis.

This one element alone makes me think that individual signing is a
better thing. (With individual signing you'd have to compromise several
keys before you have to start relying on revocation certificates.)

> > > Who will actually hold the key? Where will it be physically kept?
>
> Good question but can usually be addressed.

It can be addressed, but how well? This is another big issue that I
don't see any plan for that I'm comfortable with..

> > > How many people will know the passphrase?
>
> As few as possible. Ideally only two, maybe three core developers.

Um...I'm not sure that this is a relevant question at all. The
passphrase is not part of the key; it's just used to encrypt the key for
storage. If you know the passphrase, you can make unlimited copies of
the key, and these copies can be protected with any passphrases you like,
or no passphrase, for that matter.

> One could also only allow a single person to hold the passphrase and
> divide it into parts between two or more. This is commonly done in
> financial circles.

Hm. Splitting the key into parts is a very interesting idea, but I'd
be interested to know how you might implement it without requiring
everybody to be physically present at signing.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Wed, Feb 05, 2003 at 15:22:12 +0900,
Curt Sampson <cjs(at)cynic(dot)net> wrote:
> On Wed, 4 Feb 2003, Greg Copeland wrote:
>
> Hm. Splitting the key into parts is a very interesting idea, but I'd
> be interested to know how you might implement it without requiring
> everybody to be physically present at signing.

The simple way to do this is to make it known to the community that
postgresql releases should be signed by at least X of the developers.

On Wed, 2003-02-05 at 00:22, Curt Sampson wrote:
> On Wed, 4 Feb 2003, Greg Copeland wrote:
>
> > If three people are required to sign a package prior to release,
> > what happens when one of them is unavailable for signing (vacation,
> > hospital, etc). This is one of the reasons why having a single project
> > key which the core developers sign may appear to be easier.
>
> I don't see that it makes that much difference. So the release is signed
> only by, say, only three people instead of four. It's still signed.
>

Note that I said "appear to be easier", not that it actually is easier
an any meaningful way. Some of the more paranoid will look for
consistency from those that sign the package in question. The fact
different people sign may be the cause of additional footwork for some.
Which probably isn't such a bad thing. Nonetheless, it could be a sign
of alarm for a few.

> > > One hopes that situations like last week's "ousting" of one of the
> > > core FreeBSD developers are rare but if such a situation were to
> > > arise, a shared project key would be Very Bad (tm).
> >
> > If a revocation key has been properly generated (as it should of been),
> > this is not a problem at all.
>
> Actually, it is still a problem. Revocations are not reliable in PGP,
> and there's really no way to make them perfectly reliable in any system,
> because you've got no way to force the user to check that his "cached
> data" (i.e., the key he holds in his keyring) is still valid. This is why
> we generally expire signing keys and certificates and stuff like that on
> a regular basis.
>

When a package is released which has a new key signing it, revocation
should normally be found fairly quickly. This is especially true if
it's included in the package AND from normal PKI routes. Revocation
should accompany any packages which later follow until the key in
question has expired.

> This one element alone makes me think that individual signing is a
> better thing. (With individual signing you'd have to compromise several
> keys before you have to start relying on revocation certificates.)
>
> > > > Who will actually hold the key? Where will it be physically kept?
> >
> > Good question but can usually be addressed.
>
> It can be addressed, but how well? This is another big issue that I
> don't see any plan for that I'm comfortable with..
>

The reason I was vague is because it depends on the key route.
Obviously, if each person signs, each person must protect their own
key. If there is a central project key, it's simply a matter of
determining which box is used for signing, etc...while important, it's
certainly not difficult to address.

> > > > How many people will know the passphrase?
> >
> > As few as possible. Ideally only two, maybe three core developers.
>
> Um...I'm not sure that this is a relevant question at all. The
> passphrase is not part of the key; it's just used to encrypt the key for
> storage. If you know the passphrase, you can make unlimited copies of
> the key, and these copies can be protected with any passphrases you like,
> or no passphrase, for that matter.
>

If you're concerned about this to that extent, clearly those people
should not part of the web of trust nor should they be receiving the
passphrase nor a copy of the private key. Remember, trust is a key (pun
intended) part of a reliable PKI.

> > One could also only allow a single person to hold the passphrase and
> > divide it into parts between two or more. This is commonly done in
> > financial circles.
>
> Hm. Splitting the key into parts is a very interesting idea, but I'd
> be interested to know how you might implement it without requiring
> everybody to be physically present at signing.
>
> cjs

I was actually talking about splitting the passphrase, however,
splitting the key is certainly possible as well. Having said that, if a
private key is shared, it should still be encrypted. As such, a
passphrase should still be considered; as will splitting it.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Tue, Feb 04, 2003 at 06:19:42PM -0600, Greg Copeland wrote:
>
> I do agree that a checksum (or hash) is better than nothing, however, a
> serious security solution it is not.

Which really is all I'm saying.

Kurt

On Thu, 5 Feb 2003, Greg Copeland wrote:

> > > > > Who will actually hold the key? Where will it be physically kept?
> > >
> > > Good question but can usually be addressed.
> >
> > It can be addressed, but how well? This is another big issue that I
> > don't see any plan for that I'm comfortable with..
>
> The reason I was vague is because it depends on the key route.
> Obviously, if each person signs, each person must protect their own
> key. If there is a central project key, it's simply a matter of
> determining which box is used for signing, etc...while important, it's
> certainly not difficult to address.

It seems to me extremely difficult to address. Unless you are physically
monitoring someone, how do you prevent someone from copying the key off
of that machine. At which point anybody with the passphrase can use it
for anything.

> > > > > How many people will know the passphrase?
> > >
> > > As few as possible. Ideally only two, maybe three core developers.
> >
> > Um...I'm not sure that this is a relevant question at all. The
> > passphrase is not part of the key; it's just used to encrypt the key for
> > storage. If you know the passphrase, you can make unlimited copies of
> > the key, and these copies can be protected with any passphrases you like,
> > or no passphrase, for that matter.
>
> If you're concerned about this to that extent, clearly those people
> should not part of the web of trust nor should they be receiving the
> passphrase nor a copy of the private key. Remember, trust is a key (pun
> intended) part of a reliable PKI.

In that case, I would trust only one person with the key. Making copies of
the key for others gives no additional protection (since it takes only one
person out of the group to sign the release) while it increases the chance
of key compromise (since there are now more copies of the key kicking around,
and more people who know the passphrase).

Keys cannot be transfered from one person to another since, being digital
data, there's no way to ascertain that the original holder does not still
(on purpose or inadvertantly) have copies of the key. So in the case where
we want to transfer trust from one person to another, we must also generate
a new key and revoke the old one.

This is now exactly equivalant to having each developer sign postgres
with a signing key (signed by his main key) for which the other
developers (or appropriate authority) have a revocation certificate.

And back to the passphrase issue, once again, can't you see that it's
completely irrelevant? At some point, someone who knows the passphrase is
going to have to be in a position to use that to decrypt the key. At that
point he has the key, period. Changing the passphrase does no good, because
you can't change the passphrase on the copy of the key he may have made.

A passphrase is like a lock on your barn door. After you've given
someone the key and he's gone in and taken the cow, changing the lock
gives you no protection at all.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To answer some of my earlier questions, here is one specific way of doing it:

Tom Lane creates a PostgreSQL key, signing only, DSA, 1024 bits, that expires
in 3 years. It ends up looking something like this:

pub 1024D/0BB10D1D 2003-02-07 PostgreSQL (PostgreSQL signing key) <key(at)postgresql(dot)org>

Tom keeps a close watch on the commits list and waits for a new version to be
released. When the tarball is made, he checks it out and when satisfied, he
signs it with the key. (Other people can look it over and verify it by referring
to its sha1sum).

Once signed, the small text file that is created is mailed to the web group (or
just posted to the list). Somebody adds it to the web page, and from there to all
the mirrors. Tom keeps the key secure, preferably by not keeping it on a box connected
to the net. He generates a revocation certificate and gives it to Bruce, who
squirrels it away until needed. Tom signs the key with his own, and perhaps with
other developers who have PGP keys. People meet Tom at the conferences, exchange keys,
the Web of Trust grows, and all is good in the world again.

I chose Tom because he is part of the core and has (IMO) the best ability to
detect problems in the source code and verify a final tarball.

It doesn't really matter who has the key, actually, as long as they are sufficiently
careful/paranoid about keeping it safe and offline, and at least one person in
the core group has the ability to revoke it in case of an emergency.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200302071451

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+RBJovJuQZxSWSsgRAh3XAJ47eL56YmSKXJCtdAsyYzByMi+m2QCcCNjm
b1tQyp1zLxkpGjhUer6FpZQ=
=Hfpu
-----END PGP SIGNATURE-----

Curt Sampson writes:

> MD5, or any other unsigned check, makes sense from a security point of
> view only if it is stored independently from the thing you are checking.

So you put the MD5 sum into the release announcement email. That is
downloaded by many people and also archived in many distributed places
that we don't control, so it would be very hard to tamper with. ISTM that
this gives you the same result as a PGP signature but with much less
administrative overhead.

--
Peter Eisentraut peter_e(at)gmx(dot)net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> So you put the MD5 sum into the release announcement email. That is
> downloaded by many people and also archived in many distributed places
> that we don't control, so it would be very hard to tamper with.
> ISTM that this gives you the same result as a PGP signature but with
> much less administrative overhead.

Not the same results. For one thing, the mailing announcement may be
archived on google, but asking people to search google for an MD5 sum
as they download the tarball is hardly feasible. Second, it still does
not prevent someone from breaking into the server and replacing the
tarball with their own version, and their own MD5 checksum. Or maybe
just one of the mirrors. Users are not going to know to compare that
MD5 with versions on the web somewhere. Third, is does not allow a
positive history to be built up due to signing many releases over time.
With PGP, someone can be assured that the 9.1 tarball they just
downloaded was signed by the same key that signed the 7.3 tarball
they've been using for 2 years. Fourth, only with PGP can you trace
your key to the one that signed the tarball, an additional level of
security. MD5 provides an integrity check only. Any security it
affords (such as storing the MD5 sum elsewhere) is trivial and
should not be considered when using PGP is standard, easy to implement,
and has none of MD5s weaknesses.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200302102250
-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+SA4AvJuQZxSWSsgRAhenAKDu0vlUBC5Eodyt2OxTG6el++BJZACguR2i
GGLAzhtA7Tt9w4RUYXY4g2U=
=3ryu
-----END PGP SIGNATURE-----

Well said. I'm glad someone else is willing to take a stab at
addressing these issues, since I've been down with the flu. Thanks
Greg.

As both Gregs have pointed out, hashes and checksums alone should only
be used as an integrity check. It is not a viable security mechanism.
A hash does not provide for authentication and even more importantly,
verification of authentication. These concepts are key to creating a
secure environment.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Mon, 2003-02-10 at 21:57, greg(at)turnstep(dot)com wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > So you put the MD5 sum into the release announcement email. That is
> > downloaded by many people and also archived in many distributed places
> > that we don't control, so it would be very hard to tamper with.
> > ISTM that this gives you the same result as a PGP signature but with
> > much less administrative overhead.
>
> Not the same results. For one thing, the mailing announcement may be
> archived on google, but asking people to search google for an MD5 sum
> as they download the tarball is hardly feasible. Second, it still does
> not prevent someone from breaking into the server and replacing the
> tarball with their own version, and their own MD5 checksum. Or maybe
> just one of the mirrors. Users are not going to know to compare that
> MD5 with versions on the web somewhere. Third, is does not allow a
> positive history to be built up due to signing many releases over time.
> With PGP, someone can be assured that the 9.1 tarball they just
> downloaded was signed by the same key that signed the 7.3 tarball
> they've been using for 2 years. Fourth, only with PGP can you trace
> your key to the one that signed the tarball, an additional level of
> security. MD5 provides an integrity check only. Any security it
> affords (such as storing the MD5 sum elsewhere) is trivial and
> should not be considered when using PGP is standard, easy to implement,
> and has none of MD5s weaknesses.
>
> - --
> Greg Sabino Mullane greg(at)turnstep(dot)com
> PGP Key: 0x14964AC8 200302102250
> -----BEGIN PGP SIGNATURE-----
> Comment: http://www.turnstep.com/pgp.html
>
> iD8DBQE+SA4AvJuQZxSWSsgRAhenAKDu0vlUBC5Eodyt2OxTG6el++BJZACguR2i
> GGLAzhtA7Tt9w4RUYXY4g2U=
> =3ryu
> -----END PGP SIGNATURE-----
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
> On Thu, 5 Feb 2003, Greg Copeland wrote:
>
> > > > > > Who will actually hold the key? Where will it be physically kept?
> > > >
> > > > Good question but can usually be addressed.
> > >
> > > It can be addressed, but how well? This is another big issue that I
> > > don't see any plan for that I'm comfortable with..
> >
> > The reason I was vague is because it depends on the key route.
> > Obviously, if each person signs, each person must protect their own
> > key. If there is a central project key, it's simply a matter of
> > determining which box is used for signing, etc...while important, it's
> > certainly not difficult to address.
>
> It seems to me extremely difficult to address. Unless you are physically
> monitoring someone, how do you prevent someone from copying the key off
> of that machine. At which point anybody with the passphrase can use it
> for anything.
>

This issue doesn't change regardless of the mechanism you pick. Anyone
that is signing a key must take reasonable measures to ensure the
protection of their key.

> > > > > > How many people will know the passphrase?
> > > >
> > > > As few as possible. Ideally only two, maybe three core developers.
> > >
> > > Um...I'm not sure that this is a relevant question at all. The
> > > passphrase is not part of the key; it's just used to encrypt the key for
> > > storage. If you know the passphrase, you can make unlimited copies of
> > > the key, and these copies can be protected with any passphrases you like,
> > > or no passphrase, for that matter.
> >
> > If you're concerned about this to that extent, clearly those people
> > should not part of the web of trust nor should they be receiving the
> > passphrase nor a copy of the private key. Remember, trust is a key (pun
> > intended) part of a reliable PKI.
>
> In that case, I would trust only one person with the key. Making copies of
> the key for others gives no additional protection (since it takes only one
> person out of the group to sign the release) while it increases the chance
> of key compromise (since there are now more copies of the key kicking around,
> and more people who know the passphrase).
>

Which brings us back to backups. Should the one person that has the key
be unavailable or dead, who will sign the release? Furthermore, making
*limited* copies of the key does provide for additional limited
protection in case it's lost for some reason. This helps mitigate the
use of the revocation key until it's absolutely required. Also provides
for backup (of key and people).

Basically, you are saying:
You trust a core developer
You trust they can protect their keys
You trust they can properly distribute their trust
You don't trust a core developer with a key

Hmmm...something smells in your web of trust...So, which is it? Do you
trust the core developers to protect the interests of the project and
the associated key or not? If not, why trust any digital signature from
them in the first place?

Can't stress this enough. PKI is an absolute failure without trust.
Period.

> Keys cannot be transfered from one person to another since, being digital
> data, there's no way to ascertain that the original holder does not still
> (on purpose or inadvertantly) have copies of the key. So in the case where
> we want to transfer trust from one person to another, we must also generate
> a new key and revoke the old one.
>

No one is talking about transferring keys. In fact, I've previously
addressed this topic, from a different angle, a number of times. We are
talking about shared trust and not transfered trust. The transferring
of trust is done by signing keys, not transferring keys.

> This is now exactly equivalant to having each developer sign postgres
> with a signing key (signed by his main key) for which the other
> developers (or appropriate authority) have a revocation certificate.
>
> And back to the passphrase issue, once again, can't you see that it's
> completely irrelevant? At some point, someone who knows the passphrase is
> going to have to be in a position to use that to decrypt the key. At that
> point he has the key, period. Changing the passphrase does no good, because
> you can't change the passphrase on the copy of the key he may have made.
>

So you trust the core developer to sign the package but you don't trust
him to have the key that's required to sign it? You can't have it both
ways.

> A passphrase is like a lock on your barn door. After you've given
> someone the key and he's gone in and taken the cow, changing the lock
> gives you no protection at all.

I can assure you I fully understand the implications and meaning of
everything I've said.

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

On Wed, 11 Feb 2003, Greg Copeland wrote:

> On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
>
> [Re: everybody sharing a single key]
>
> This issue doesn't change regardless of the mechanism you pick. Anyone
> that is signing a key must take reasonable measures to ensure the
> protection of their key.

Right. Which is why you really want to use separate keys: you can determine
who compromised a key if it is compromised, and you can revoke one without
having to revoke all of them.

Which pretty much inevitably leads you to just having the developers use
their own personal keys to sign the release.

> Basically, you are saying:
> You trust a core developer
> You trust they can protect their keys
> You trust they can properly distribute their trust
> You don't trust a core developer with a key

Not at all. I trust core developers with keys, but I see no reason to
weaken the entire system by sharing keys when it's not necessary. Having
each developer sign the release with his own personal key solves every
problem you've brought up.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

On Tue, 2003-02-11 at 18:27, Curt Sampson wrote:
> On Wed, 11 Feb 2003, Greg Copeland wrote:
>
> > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
> >
> > [Re: everybody sharing a single key]
> >
> > This issue doesn't change regardless of the mechanism you pick. Anyone
> > that is signing a key must take reasonable measures to ensure the
> > protection of their key.
>
> Right. Which is why you really want to use separate keys: you can determine
> who compromised a key if it is compromised, and you can revoke one without
> having to revoke all of them.
>
> Which pretty much inevitably leads you to just having the developers use
> their own personal keys to sign the release.
>
> > Basically, you are saying:
> > You trust a core developer
> > You trust they can protect their keys
> > You trust they can properly distribute their trust
> > You don't trust a core developer with a key
>
> Not at all. I trust core developers with keys, but I see no reason to
> weaken the entire system by sharing keys when it's not necessary. Having
> each developer sign the release with his own personal key solves every
> problem you've brought up.
>
> cjs

You need to keep in mind, I've not been advocating, rather, clarifying.
The point being, having a shared key between trusted core developers is
hardly an additional risk. After all, either they can be trusted or
they can't.

At this point, I think we both understand where the other stands.
Either we agree or agree to disagree. The next step is for the
developers to adopt which path they prefer to enforce and to ensure they
have the tools and knowledge at hand to support it.

Anyone know if Tom and Bruce know each other well enough to sign each
other's keys outright, via phone, via phone and snail-mail? That would
put us off to an excellent start.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

I hate to poo-poo this, but this "web of trust" sounds more like a "web
of confusion". I liked the idea of mentioning the MD5 in the email
announcement. It doesn't require much extra work, and doesn't require a
'web of %$*&" to be set up to check things. Yea, it isn't as secure as
going through the motions, but if someone breaks into that FTP server
and changes the tarball and MD5 file, we have much bigger problems than
someone modifying the tarballs; our CVS is on that machine too.

---------------------------------------------------------------------------

Greg Copeland wrote:
> On Tue, 2003-02-11 at 18:27, Curt Sampson wrote:
> > On Wed, 11 Feb 2003, Greg Copeland wrote:
> >
> > > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
> > >
> > > [Re: everybody sharing a single key]
> > >
> > > This issue doesn't change regardless of the mechanism you pick. Anyone
> > > that is signing a key must take reasonable measures to ensure the
> > > protection of their key.
> >
> > Right. Which is why you really want to use separate keys: you can determine
> > who compromised a key if it is compromised, and you can revoke one without
> > having to revoke all of them.
> >
> > Which pretty much inevitably leads you to just having the developers use
> > their own personal keys to sign the release.
> >
> > > Basically, you are saying:
> > > You trust a core developer
> > > You trust they can protect their keys
> > > You trust they can properly distribute their trust
> > > You don't trust a core developer with a key
> >
> > Not at all. I trust core developers with keys, but I see no reason to
> > weaken the entire system by sharing keys when it's not necessary. Having
> > each developer sign the release with his own personal key solves every
> > problem you've brought up.
> >
> > cjs
>
> You need to keep in mind, I've not been advocating, rather, clarifying.
> The point being, having a shared key between trusted core developers is
> hardly an additional risk. After all, either they can be trusted or
> they can't.
>
> At this point, I think we both understand where the other stands.
> Either we agree or agree to disagree. The next step is for the
> developers to adopt which path they prefer to enforce and to ensure they
> have the tools and knowledge at hand to support it.
>
> Anyone know if Tom and Bruce know each other well enough to sign each
> other's keys outright, via phone, via phone and snail-mail? That would
> put us off to an excellent start.
>
>
> Regards,
>
> --
> Greg Copeland <greg(at)copelandconsulting(dot)net>
> Copeland Computer Consulting
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, 11 Feb 2003, Bruce Momjian wrote:

>
> I hate to poo-poo this, but this "web of trust" sounds more like a "web
> of confusion". I liked the idea of mentioning the MD5 in the email
> announcement. It doesn't require much extra work, and doesn't require a
> 'web of %$*&" to be set up to check things. Yea, it isn't as secure as
> going through the motions, but if someone breaks into that FTP server
> and changes the tarball and MD5 file, we have much bigger problems than
> someone modifying the tarballs; our CVS is on that machine too.

Its so rare that it happens, but I do agree with Bruce :)

Justin, one thought ... storing the MD5s in the database for the
postgresql.org site, so that ppl can compare the two places? We'd
*really* have to be compromised for that to fail, but adding the md5s
would be easy enough ...

On Tue, 2003-02-11 at 20:17, Bruce Momjian wrote:
> I hate to poo-poo this, but this "web of trust" sounds more like a "web
> of confusion". I liked the idea of mentioning the MD5 in the email
> announcement. It doesn't require much extra work, and doesn't require a
> 'web of %$*&" to be set up to check things. Yea, it isn't as secure as
> going through the motions, but if someone breaks into that FTP server
> and changes the tarball and MD5 file, we have much bigger problems than
> someone modifying the tarballs; our CVS is on that machine too.
>
> ---------------------------------------------------------------------------
>
> Greg Copeland wrote:
> > On Tue, 2003-02-11 at 18:27, Curt Sampson wrote:
> > > On Wed, 11 Feb 2003, Greg Copeland wrote:
> > >
> > > > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
> > > >
> > > > [Re: everybody sharing a single key]
> > > >
> > > > This issue doesn't change regardless of the mechanism you pick. Anyone
> > > > that is signing a key must take reasonable measures to ensure the
> > > > protection of their key.
> > >
> > > Right. Which is why you really want to use separate keys: you can determine
> > > who compromised a key if it is compromised, and you can revoke one without
> > > having to revoke all of them.
> > >
> > > Which pretty much inevitably leads you to just having the developers use
> > > their own personal keys to sign the release.
> > >
> > > > Basically, you are saying:
> > > > You trust a core developer
> > > > You trust they can protect their keys
> > > > You trust they can properly distribute their trust
> > > > You don't trust a core developer with a key
> > >
> > > Not at all. I trust core developers with keys, but I see no reason to
> > > weaken the entire system by sharing keys when it's not necessary. Having
> > > each developer sign the release with his own personal key solves every
> > > problem you've brought up.
> > >
> > > cjs
> >
> > You need to keep in mind, I've not been advocating, rather, clarifying.
> > The point being, having a shared key between trusted core developers is
> > hardly an additional risk. After all, either they can be trusted or
> > they can't.
> >
> > At this point, I think we both understand where the other stands.
> > Either we agree or agree to disagree. The next step is for the
> > developers to adopt which path they prefer to enforce and to ensure they
> > have the tools and knowledge at hand to support it.
> >
> > Anyone know if Tom and Bruce know each other well enough to sign each
> > other's keys outright, via phone, via phone and snail-mail? That would
> > put us off to an excellent start.
> >
>

Bruce,

Since you just got back in town I'm not sure if you've been able to
follow the thread or not. Just the same, I wanted to remind you that
using MD5 is not a security mechanism of any worth. As such, this
thread was an effort to add a layer of authenticity. Again, this is not
something that MD5 is going to provide for, now or in the future.

If it sounds confusing, it's only because you've never done it.
Honestly, once you take the 20-minutes to do it the first time, you'll
understand what's going on. Beyond that, you won't have to sign
additional keys until you can validate them or as they expire. It only
takes minutes once you understand what's going on after that.

The time to actually sign packages is more or less the same as creating
your hashes.

Lastly, don't forget that your site is mirrored all over the place. As
such, you're not the only place open to attack. Just because you have
additional software running on this box is no reason to throw your hands
in the air and say, "I don't care." Simple fact is, it only takes one
site to become compromised to significantly effect PostgreSQL's
reputation. And that site doesn't have to be yours. If it's an
official mirror, it reflects (oh...a pun!) accordingly on the project.

Regards,

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting