[Enigmail] On Signatures, Part II

[Robert J. Hansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In Part I a proof structure was drawn showing that there is no
informational content to be found in a bad signature.  Here we will draw
a (looser) proof structure showing there is no informational content to
be found in an untrusted signature.

=====

A certificate is, by itself, simply a collection of numbers.  Even user
IDs are an afterthought; there is no requirement that user IDs be in any
way meaningful.  Present, sure.  Meaningful, no.

A good signature indicates that a particular message has been tightly
associated with a given certificate.  Seeing a good signature on this
message lets you be assured that keys 0x5B8709EB and 0xFEAF8109 were
used to process this message sometime between the time the message was
written and the time you received this message.

So far, this is all well and good.  But what does that gain us?
Certificates are easy to make.  Email addresses are easy to spoof.  By
itself, a certificate is meaningless.  The message is tightly bound to a
certificate, great.  The certificate is tightly bound to some user IDs,
great.  But there's no meaning to it, and you can't infer anything from it.

In fact, you can't even infer that the person who owns 0x5B8709EB and
0xFEAF8109 wrote this message!

Imagine that I'm someone nefarious and I want to fool people.  I share
my private certificate with other people.  While I'm sipping mai-tais on
a South Pacific beach surrounded by hundreds of witnesses, my
conspirator engages in a bunch of high-risk stock speculation, signing
it all with my certificate.  When I get back I look at the profit and
loss.  If I made a profit, I say "yep, that was me, all right."  If I
suffered a loss, I say "wait, I couldn't have made those trades!  A
hundred people saw me sipping mai-tais on a South Pacific beach where I
had no internet access!  I demand my broker refund my money and crack
down on internet fraud perpetrated over their systems!"

Certificates can be shared.  Above and beyond that, you cannot tell when
a signing operation was applied to the message.

Imagine that Alice writes a message and doesn't sign it.  She sends it
to Bob, but Mallory intercepts it.  Mallory is nefarious and wants Bob
to be lulled into a false sense of security in his messages with Alice,
and vice-versa.

When Alice sends a message to Bob, Mallory encrypts it with Bob's public
key and signs it with a certificate that purports to be Alice's private
key.  Bob gets an encrypted and signed email, pulls down the appropriate
key for fake-Alice/Mallory, and says "oh, this message has an 'UNTRUSTED
Good signature'.  It's a good signature, so that means I can trust it,
right?"  When Bob sends an email back to Alice, Mallory does the same
attack in reverse.

Those of you who have heard of man-in-the-middle attacks will recognize
that this is a classic MitM attack.  The reason why it's a classic is
because it's so -effective-.  This attack works very well on people who
think that an 'untrusted good signature' has some informational content.

So let's summarize!  An untrusted good signature means at least one of...


1.  The signature and message really are from the person the certificate
claims it's from.

2.  The signature and message are part of a conspiracy.

3.  The signature and message are part of a man in the middle attack.

4.  The signature and message are from a certificate stolen from the
person who really owns the cert.

5.  ... I could go on and on, but you get the idea.


In the absence of a validated key, there is absolutely no reason to
believe any of those over the others.  You cannot distinguish between
the various cases except by guessing and hoping you're right.  That
means an untrusted good signature cannot assert the provenance of a message.

Which means an untrusted good signature really isn't much of a signature
at all, and we should really think about whether we wish to use language
(like "good signature") which implies otherwise.

===

The way out of this thicket is to validate the key.  That means to
introduce a new fact into the domain of discourse.  For instance, if I
introduce as a fact "I know that the certificate with ID 0x608D2A10
really belongs to John Clizbe", then I can immediately wipe off #3 from
the list of options.  I know I'm not being man in the middled.

For this reason, key validity--which is to say, introducing a new fact
into the domain of discourse which connects a certificate with a
person--is a necessary precondition to the signature having
informational value.

No validity?  No informational value.  No informational value?  Then
it's noise.

===

The final step is to determine trust (which is different from
ownertrust).  If I trust that John is not conspiring against me and if I
trust that he's keeping good control of his key, then I can conclude
from a valid and good signature that John at the very least witnessed
this message and affixed his consent to it.

Now, unfortunately, GnuPG doesn't have a good concept of trust.  (It has
ownertrust, which is how much you trust someone to introduce you to
other people.)  For the most part, trust calculations are done entirely
within your own noggin.

We're not responsible for making sure users do the last step (trust
evaluation) correctly.  Human beings are generally pretty good at this step.

We are responsible for making sure we present the user with the most
information and the least noise possible.  Valid good signatures /may/
rise to the level of information, /if/ trust is present.  For that
reason, we need to present valid good signatures so that the user can do
the last step on their own.

But if it's a bad signature or an invalid signature... then there's no
information.  And maybe we should consider how to convey to the user
that there is no information to be gleaned here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkdfW8oACgkQf2XByo0Cu7PpDADeOF+YgNsUdcn6bP9rtJwJIqFk
C5DPlfsPmoaggQDeJkGl5UUD0ZSvaJO95qYPkaaU8CKIGXTUkD+OGYkBHAQBAQgA
BgUCR19bygAKCRC3APSC/q+BCX9ECAC82j+niugWOj7jhKjfFeT9kSAoH0kdhpO+
8vD0grBzsFy78X0Yb0gZxVean1a+F8n9N/YOv+XOKpds0djiEF9uTeD+PLIdycRY
jlgYrZp/MX8y+lGaldKOqGYD9w9XhR0BgAHUCVYXUdxCqjrKd6lB6Bz+Le2bketx
XRs0PGX+s67ePs23g/+jOaG6XQnKpjOgYg6YPK/Gl5exLU4FuV1CLCweH5Nf5gdD
YBo1brSZdFFgEQC1HLbXE0I6sKG3BFpo22UaM0GSziCezMPJbR5vPAt1p1X2Sth2
RintdbJwW91ESiqWA5TfVQjZCMMHLipfEyZQdfhVjuenVaxUE6rb
=rFr8
-----END PGP SIGNATURE-----