Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Aug 29, Sergey A. Lipnevich [sergey AT optimaltec.com] wrote:
> Quoting "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>:
> 
> > content.  The three they list are authenticity, integrity, and
> > non-repudiation.  Non-repudiation is the closest to the kind of single
> > meaning you're trying to attach to signing something, but again, a digital
> > signature only functions in that regard to establish that the signee was
> > the one that signed something.  What the act of signing meant and what 
> > they
> 
> What you're saying is that signing something doesn't mean anything except 
> that
> it was signed by <person>. Why then your signature on a blank piece of paper
> different from a signature on a contract?

Because of the legally agreed context of the contract.  Contracts and other
legal documents usually make this explicit, with language like "we, the
undersigned parties...", and also an explicit list in the terms of the
contact of who is involved.  That list combined with the non-repudiation of
the signature is what binds the signee to the terms of the contact, not the
signature by itself.  I can go out and sign my name on whatever contracts I
want but if I'm not a listed party to the contact it doesn't really mean
anything beyond that I wrote my name on a piece of paper.

Even things like mailing invoices usually contain language to make it clear
if you're signing that you just received a box vs. have inspected and
agreed that the contents match the invoice.  And even that doesn't say you
can't return it if it proves to be other than what was promised just
because you signed that the initial inspection said it looked ok.  The
meaning of the signature depends on the context in which it was provided,
and if the parties don't agree on that context later and take it to court,
the one who wants the stricter interpretation is going to have to prove
that their desired context is reasonable.

> > noted before, even our own grimoire and sorcery tarball signatures fit 
> > this
> > broader model.  The primary use and meaning of a cryptographic signature 
> > is
> > in point of fact transmission integrity verification.  Non-repudiation is 
> > a
> 
> Sorry, but this is not true. Use a differerent channel to pass a hash
> value for your content and you'll achieve the same purpose: integrity is
> verified. If I have to send a file to you, the easiest way to check
> integrity would be to send the file by email and either send hash with it
> or send hash via ICQ for instance. Or publish this hash value on a widely
> known server and allow copying it everywhere, like ISO publishers usually
> do. In all cases, integrity means that the file is not altered in
> transmission. Signature claims something *in addition* to that.

Using a secondary channel or saturation method for hash distribution is
only the easiest method if a dual key method is not available.  If keys
have been exchanged and verified prior to the transmission, you can do the
whole thing with one communication, without any risk of MitM attacks.  This
is obviously easier than alternatives.

But my original statement there has nothing to do with what is easiest.  I
said that the primary use and meaning of a cryptographic signature is
transmission integrity verification.  That has nothing to do with if there
are other methods to accomplish the same thing.

> >> > I ask again, would it make you feel any better to use a key that did 
> >> > not
> >> > have your name on it, but instead had a name indicating it was a source
> >> > integrity verification key only.
> >>
> >> If you have a good plan for managing such a key so that developers cannot
> >> willingly or unwillingly frame each other, I'd like to hear it.
> >
> > I wasn't suggesting a common key, I was suggesting individual keys that
> > would make it completely clear that it isn't "Sergey's key", it's "a
> > distribution download integrity verification key".
> 
> If it's my personal key, no. It doesn't matter what it says. If it's somehow
> shared (I don't know if it's possible with GPG), than see my question above
> about the plan to manage it.

Well if it's a shared key than "framing" means nothing anyway, because
there's no longer non-repudiation at the individual level.  And all of
these things already assume our own developers are trusted; if someone
wants to be malicious there are much easier things to attack.  I believe
those with the access already share keys for the tarballs we distribute.

Attachment: pgpn4oFlN4P_Z.pgp
Description: PGP signature