Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • Cc: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support
  • Date: Tue, 30 Aug 2005 16:14:25 -0700

On Tue, Aug 30, 2005 at 04:43:40PM -0400, Sergey A. Lipnevich wrote:
> Quoting Seth Alan Woolley <seth AT positivism.org>:
>
> > Furthermore, the recipient may wish to be certain of the originator's
> > identity.
> >
> >Who sent it!
>
> So let me break it you if that's still not clear: I don't want to be
> the originator of any tarball I didn't read the code of. And no,
> originator is not just who sent it. The build engineer is the
> originator, and if they're not willing to sign it, I am not in a
> position to second-guess them.

Technically, from the Forward and Abstract of FIPS-186:

"Applications: The DSA authenticates the integrity of the signed data
and the identity of the signatory. The DSA may also be used in proving
to a third party that data was actually signed by the generator of the
signature."

^^^^^^^^ ^^ ^^ ^^^^^^^^^^ (save "identity of the signatory" for later)

"generator of the signature", too.

Integrity, authentication, non-repudiation again, as well, but I like the
sentence that immediately follows:

"The DSA is intended for use in electronic mail, electronic funds
transfer, electronic data interchange, software distribution, data
storage, and other applications which require data integrity assurance
and data origin authentication."
^^^^^^^^ ^^^^^^^^^^^^ w00t!
^^^^ ^^^^^^ ^^^^^^^^^^^^^^
Data origin authentication. The origin is the name given by the owner
of the keypair. PGP only authenticates against that. It doesn't
authenticate against an ultimate originator (I feel like I'm in an
Aquinas-style religious argument now). It authenticates against the
"identity of the signatory". If our program says, "checked valid
against a guru (but not the original vendor)" our responsibility is met,
and in fact, this is what we intended to do the whole time.

It authenticates the identity of the signatory, not the identity of the
ultimate source. It can't technically do that unless the ultimate
source == the signatory, regardless of what people think it does.

Origin does not always mean ultimate origin. Origin just means "sender"
in their framework.

You make a moral argument that the ultimate source should be the only
signatory. I desire signatories at as many places as possible.
Ultimate source signatories are excellent and have a higher desirability
than other signatures, but that doesn't make lesser signatures
inherently wrong. It just makes them not as good.

Let's assume somebody gets the source and your signature of it.

They extract it from the source mage context, open it up and,
interestingly, it comes from you! That's what the signature says!

If it's removed from the web of trust, as I suggested, there's no issue
here. He can't verify the signature chain and must get verification
back to gurus.gpg. Moreover, since your signature identity says, "See
signing policy at http://sourcemage.org/security-guru-pgp-policy";, the
person removed from the context still knows where to find the signing
policy, as ALL OpenPGP-compliant systems will show the authenticated
identity. It's the validation chain that matters. I would find that
just as good a middle-ground as DETAILS signing, which is even less
vague about what the signature actually means. They might assume
DETAILS signature is just that you've included something else with it,
but that, hey, you wouldn't sign a spell with this hash unless you
checked it out to be secure, right?

I think we can do this with less complexity than you desire. With my
suggestion of having a standard policy url in the Comment field of the
identity, we should be able to please both you and the others, or is
there still an objection?

>
> It's a good thing you're reading standards, but let me ask about your
> entitlements. Disclosure: I don't have any security-related
> certifications. Do you? If we're just two guys argueing about merits
> of the standard, then I'm afraid we read remain at a disagreement.

Did you just admit that you'd take the decision of somebody who is paper
certified over your own?

>
> I am also not confusing things as you suggested. I am trying to
> explain them to those who are willing to listen. I am also trying to
> have my choice back.

I hope the suggestion above will be a good compromise?

Seth

>
> Sergey.
>

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733

Attachment: pgpQGk0TRlwYA.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page