Subject: [saag] The meaning of a signature

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 Jul 2011 16:31:24 -0700

Folks,

A minor debate has arisen that is best resolved with a query to an august body 
of experts, even though it's only july:

Simply put:  What is the meaning of a signature on a bag of bits?  The question 
is meant as a matter of official semantics.

For OpenPGP:

      1.  What does its signature on a mesage mean?

      2.  If "authentication" is claimed, what exactly is authenticated and by whom?

      3.  Where are these signature semantics defined precisely?

For S/MIME:

      4.  What does its signature on a mesage mean?

      5.  If "authentication" is claimed, what exactly is authenticated and by whom?

      6.  Where are these signature semantics defined precisely?

These are not meant as trick questions.  I think there is less accuracy and 
precision about this topic than folks realize.  My spontaneous survey is meant 
either to demonstrate that or to correct my own misunderstanding.

Thanks!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 09 Jul 2011 18:05:31 +1200

Dave CROCKER <[email-masked]> writes:

>Simply put:  What is the meaning of a signature on a bag of bits?

It means that at some point in time, some device somewhere, possibly with the
knowledge of a key holder, performed a mathematical operation like a modexp on
the bag of bits usig a key that may or may not be held solely by the purported
own, and the bag was possibly the same bag of bits that the keyholder is aware
of.  Nothing more, nothing less.

>These are not meant as trick questions. 

That was not meant as a trick answer :-).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 9 Jul 2011 09:29:14 +0300

> That was not meant as a trick answer :-).

Well, yeah, and a pen-based signature means that at some point in time, someone used a pen or some other device with ink to scribble something remotely resembling letters on a page. 

And yet we assign meaning to these signatures. We take them as evidence that someone is willing to be bound by the text on the page. Similarly, S/Mime signatures are taken as evidence that the one who composed the letter is the entity named in the certificate. Both kinds of signatures might be forged, although by different means.

---

From: Mouse <[email-masked]>
Date: Sat, 9 Jul 2011 04:04:43 -0400 (EDT)

> The question is meant as a matter of official semantics.

Well, first, I assume the signature verifies.  If not, it means that
either someone corrupted either the signature or the bag-of-bits, or
someone attached a bogus signature.  (Throughout this discussion,
"someone" really means software agents, whether acting on the behalf of
the human they appear to have been acting on the behalf of or not.)

Otherwise, it means that either someone has broken the crypto in
question (unlikely enough to be ignored in most cases) or gotten
incredibly lucky (unlikely enough to be ignored in damn near all cases)
or that someone in possession of the secret key data in question
computed the signature over the bag of bits in question.

Note that in many cases, the signature is actually computed over a hash
of the overt bag of bits.  This offers more leeway for trouble,
especially if the hash used is known to be weak (eg, simple MD5), but
is fairly necessary in most cases.

Note also that the "someone" may not be the purported holder of the
secret key data; there are various failure modes that can lead to that,
such as the secret key data having been illicitly copied or some system
having been subverted to the point that the data the user thought was
being signed over isn't the data which actually got signed over.

> For S/MIME:

I don't know enough to answer any of these, except to remark that the
"where are these signature semantics defined precisely?" questions are,
I would hope, answered in the specs for the protocol in question.  Not
that know that much about the specs for either.

> These are not meant as trick questions.  I think there is less
> accuracy and precision about this topic than folks realize.

Probably, I'd say.

To the extent that "folks" in general know anything at all about
digital signatures, I suspect they are mostly taken as "this really is
from whom it says it's from".  This is a workable approximation in many
cases, but far from all - especially for the cases where signatures are
most necessary/appropriate.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 09 Jul 2011 20:20:56 +1200

Yoav Nir <[email-masked]> writes:

>Well, yeah, and a pen-based signature means that at some point in time,
>someone used a pen or some other device with ink to scribble something
>remotely resembling letters on a page.

No, the two are very, very different.  My signature and/or initials on a
contract indicate my active participation in the contract-signing process (and
if I really want to dispute it there's the standard questioned-documents
process and tons of legal precedent).  My digital "signature" on a document
doesn't necessarily indicate any participation in the process, even with the
best possible intentions the fact that my PDF reader and your PDF reader
display different information means that we could end up signing different
documents.  With pen and paper there's no way for someone to create an
absolutely perfect signature in my actual handwriting on a document without my
knowledge.  With a digital "signature" it's not that hard to do.  We already
have widespread banker trojans that do exactly this (although without using
digital "sigs", but adding "sigs" wouldn't change anything).

(Note that I've used the word "signature" in quotes above because it's really
quite some way removed from a standard pen-and-paper signature.  Like
"nonrepudiation", it's another case of crypto guys hijacking a term with a
well-established meaning for something with rather different semantics).

I would feel quite comfortable going to court to defend a disputed 
pen-and-paper signature.  I wouldn't ever want to become the test case for 
defending a disputed digital "signature" (unless I was one of the lawyers).

Peter.

---

From: Josh Howlett <[email-masked]>
Date: Sat, 9 Jul 2011 11:41:51 +0000

>That was not meant as a trick answer :-).

  "I don¹t know what you mean by 'glory,' " Alice said.

  Humpty Dumpty smiled contemptuously. "Of course you don't ‹ till I tell
you. I meant 'there¹s a nice knock-down argument for you!' "

  "But 'glory' doesn¹t mean 'a nice knock-down argument'," Alice objected.

  "When I use a word," Humpty Dumpty said, in a rather a scornful tone,
"it means just what I choose it to mean ‹ neither more nor less."

  "The question is," said Alice, "whether you can make words mean so many
different things."

  "The question is," said Humpty Dumpty, "which is to be master - that¹s
all."

  Alice was too much puzzled to say anything, so after a minute Humpty
Dumpty began again. "They¹ve a temper, some of them ‹ particularly verbs,
they¹re the proudest - adjectives you can do anything with, but not verbs
- however, I can manage the whole lot! Impenetrability! That¹s what I say!²

[Through the Looking-Glass, Lewis Carroll]

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 09 Jul 2011 07:14:33 -0700

Folks,

First, MANY thanks for the quick followup, including the offline notes.

Second, this thread is unfortunately a good demonstration of why survey research 
is difficult.  In spite of trying to ask the questions carefully, the nature of 
what I am asking appears to have been interpreted a bit differently than I intended.

Most folk read the questions in very narrow terms.  For example:

 > of.  Nothing more, nothing less.

The core of the answer presents the narrowest possible meaning of signature, by 
casting it in term of the pure mechanics of data integrity.  More than one 
response focused on this.  The issues of a signature's basic mechanics and 
validity are, of course, essential, but I really meant to take all of that as a 
given and, instead, ask more about the "why" (or the policy) of different 
signatures.  Signatures often have a context beyond protecting the bits from 
manipulation.

The "Nothing more, nothing less" suggests that my question might have had a 
larger scope, as indeed I had meant.  The narrow definition really casts the 
purpose of a signature as only for ensuring data integrity between signing and 
verify.

However...

On 7/8/2011 7:25 PM, Jeffrey I. Schiller wrote:
> The complications arise when we attempt to associate control of the
> private key with a person or process AND with how we know that the
> associated public key represents the entity that it claims to AND who
> or what says so!
...
> In particular if I make a commitment in a signed message, how
> enforceable is that commitment. Is it as enforceable as a legal
> contract? Does adding a signature to a statement make it a signed
> legal document? I am not a lawyer...

and

On 7/9/2011 1:20 AM, Peter Gutmann wrote:
> doesn't necessarily indicate any participation in the process,
...

These point into the larger scope I am looking for.  OpenPGP and S/MIME don't 
really define the meaning of their signatures.  For example, S/MIME repeatedly 
uses the word 'authentication' but never defines what it is that is authenticated.

The term I've recently seen used, to describe the statement of "meaning" for a 
signature is "claims".  For example, when I sign a contract, the meaning of the 
signature is commitment to the contract's terms and conditions.

On the average, folk who see a signature on an email believe that the signature 
is validating either or both of the author or the content -- but then there are 
multiple possible meanings to "validating content"...)  These larger meanings 
are certainly the typical beliefs about OpenPGP and S/MIME signatures.  However 
note that it is definitely NOT the correct interpretation for DKIM.

Yet the specs for S/MIME and OpenPGP imply, rather than define, their meanings:

S/MIME (rfc5751):

> but that a careful attacker could have changed
>    the unauthenticated portions of the encrypted message

and

>  id-aa is the arc with all new authenticated and unauthenticated
>  attributes

But what does it mean to be authenticated?  It doesn't say.

OpenPGP:

> If the verification is successful, the message is accepted as
>        authentic.

and

> Thus, if Alice is authenticating herself to Bob with a signature, it
>    makes sense for her to use a hash algorithm that Bob's software uses.

Hmmm.  "authenticating herself" certainly means more than the narrow, data 
integrity interpretation.  But, again, it's not explained.

So my survey is meant to ask after these broader semantics that are commonly 
imparted to a signature for these two, popular message-signing mechanisms.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 09 Jul 2011 07:26:06 -0700

Folks,

Sorry.  Meant to include a reference to a short commentary I wrote for a recent
workshop that touched on this:

    Tailored Signatures with DOSETA
    <http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_1.pdf>

Introduction

What does a signature mean? In the paper world, it might mean authorization for
a charge on a credit card, or acknowledgment that a letter has been received, or
the sale of a house. The language surrounding the signature defines its meaning.
In the digital world, existing signature mechanisms typically are not as
flexible. The meaning is built into the specification for a particular signature
and the effort to create a new type of signature is typically quite high.
Consequently, there is a very small range of digital signatures performed on the
Internet today.

What if it were easy to define a new type of signature with new semantics? This
is not an issue of basic algorithms, but of defining the semantics and the
packaging, along with a small matter of a certificate authority, to start the
trust hierarchy, and of deployment and use effort. DOmain SEcurity TAgging
[DOSETA] provides this flexibility and ease. It is based on the core mechanisms
from [DKIM], extracted into a library of protocol components that minimize the
incremental effort to develop a purpose-built data signature mechanism. This
protocol design library is used by a signature protocol designer to provide a
high point of specification departure, primarily limited to definition of
semantics and mapping from a template to the specifics of the environment for
the new signature.

-- 

   Dave Crocker

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 9 Jul 2011 11:04:07 -0400

Hi,

On Sat, Jul 9, 2011 at 4:20 AM, Peter Gutmann <[email-masked]> wrote:
> process and tons of legal precedent).

I dunno. Seems to me that a digital signature can be almost exactly
like your pen and ink signature on a document written in some language
you didn't understand at all...

> My digital "signature" on a document

Well, the duplicability is about like sealing a document with your
signet ring or, in many oriental countries, stamping it with you chop.
And really, it is quite easy to produce a good visual forgery of a pen
and ink signature. As has been noted in the case of FAX signatures,
much of the security for real world transactions is very dependent on
confirmation by other paths and the whole context in which the
"signing" occurs.

What about people who authorize others to sign for them or use rubber
stamp signatures? Legally, in order to bind the signer, I believe that
what you are thinking of as an elaborate, personal, and unique
exercise of the signers muscles with pen and ink need only be *any
mark* by which the signer intended to be legally bound. For example,
if I were illiterate and made a very simple X mark intending to be
bound, I would be legally bound thereby. Or if I were to authorize you
to sign my signature, I would be bound thereby regardless of how
similar or different it looks from when I sign it. Of course, proof
might depend on witnesses, etc., but dependence on other factors to
support or attack the credibility of a signature is always possible
and sometimes necessary.

> defending a disputed digital "signature" (unless I was one of the lawyers).

Going back to the original question of a signatures meaning, it has
essentially none unless it is within some system where the bits signed
have a defined structure and a field giving the semantics.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

> Peter.
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Mouse <[email-masked]>
Date: Sat, 9 Jul 2011 11:13:03 -0400 (EDT)

> Second, this thread is unfortunately a good demonstration of why
> survey research is difficult.  In spite of trying to ask the
> questions carefully, the nature of what I am asking appears to have
> been interpreted a bit differently than I intended.

> [...]  The issues of a signature's basic mechanics and validity are,
> of course, essential, but I really meant to take all of that as a
> given and, instead, ask more about the "why" (or the policy) of
> different signatures.  [...]

> For example, when I sign a contract, the meaning of the signature is
> commitment to the contract's terms and conditions.

Yes, but that's because that's the nature of contracts, not the nature
of (pen-and-paper) signatures.

Digital signatures are no different.  My take on it is that my digital
signature on a bag-o'-bits has - at least roughly - the same meaning as
my ink signature on a printed copy of that same bag-o'-bits.  Depending
on the content of those bits, it could mean assent to a contract,
authentication and non-repudiation of a letter, or any of the various
other things physical signatures mean.  (The legal force of it, of
course, remains to be determined; statute law has not caught up and
case law *definitely* has not caught up.)

> On the average, folk who see a signature on an email believe that the
> signature is validating either or both of the author or the content
> -- but then there are multiple possible meanings to "validating
> content"...)  These larger meanings are certainly the typical beliefs
> about OpenPGP and S/MIME signatures.  However note that it is
> definitely NOT the correct interpretation for DKIM.

Yeah.  That's more like - to stretch an analogical point - the local
postmaster's signature on an envelope saying (perhaps explicitly,
perhaps by convention) that it really was sent by the person whose
address appears in the return-address spot.  (I think.  I don't really
know DKIM, but I don't think it signs over content, just headers.)

The digital world is different; we shouldn't expect to find close
meatspace analogies for everything digital signatures are good for, any
more than we should expect to find digital analogies for everything
physical signatures are good for (autographs might be an exmaple).

>> but that a careful attacker could have changed the unauthenticated
>> portions of the encrypted message

> But what does it mean to be authenticated?  It doesn't say.

No.  It also doesn't say what it means to be "changed".

"Authenticated" has a well-established meaning, both in normal English
and a very closely related one as a technical term in cryptography; I
see no need for the specs to quote those definitions any more than I
see a need to define "attacker" or "portion".

> So my survey is meant to ask after these broader semantics that are
> commonly imparted to a signature for these two, popular
> message-signing mechanisms.

I don't use either, but I do occasionally use (pre-"Open") PGP.  The
meaning I usually intend, and expect others to understand, when I
PGP-sign an email is "this really did come from me"; further meaning,
if any, depends on the content of the email.  I don't sign things other
than email often enough to have any established conventions for them;
the one time I can recall when I had occasion to do something of the
sort, I didn't sign the other blob; rather, I embedded its hash as text
in a signed email which explicitly stated what the meaning of the
signature was ("By signing this email, I certify that...").

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 9 Jul 2011 11:13:58 -0400

On Sat, Jul 9, 2011 at 10:14 AM, Dave CROCKER <[email-masked]> wrote:
> Folks,
>
>
> ...
>
> For example, when I sign a contract, the meaning
> of the signature is commitment to the contract's terms and conditions.

Really? What if you write the word "Witness" above your signature? Or
put it in a box with a date and time and the words "Time
Certification"? What if the contract is clearly between named parties
and your signature is at right angles in the margin, clearly legible,
and corresponds to none of the parties in the contract? What if your
signature is accompanied by words that appear to be written in a
language other than the contract and of which the interpreter is
ignorant? What if your signature is preceded  by the words "Signed
under protest" or words that purport to change some detail of the
contract? What if ...

Donald

---

From: Mouse <[email-masked]>
Date: Sat, 9 Jul 2011 11:20:45 -0400 (EDT)

> What if it were easy to define a new type of signature with new
> semantics?  This is not an issue of basic algorithms, but of defining
> the semantics and the packaging, along with a small matter of a
> certificate authority, to start the trust hierarchy,

CA?  Trust hierarchy??  To think that every signature needs to involve
a CA and hierarchical trust is to severely restrict the idea already.

I trust CAs and other hiearchical mechanisms substantially less than I
trust non-hierarchical mechanisms such a PGP signatures or ssh
identities.  (ssh identities are actually an interesting case, often
(usually?) depending on signatures in the cryptographic-technical sense
but not in the wider sense you seem to be talking about here.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 09 Jul 2011 10:15:23 -0700

On 7/9/2011 8:13 AM, Donald Eastlake wrote:
> On Sat, Jul 9, 2011 at 10:14 AM, Dave CROCKER<[email-masked]>  wrote:
>> Folks,
>>
>>
>> ...
>>
> Certification"?

What I particularly like about your response is that while it correctly 
demonstrates the problem with my loose phrasing, it also demonstrates the 
correctness of the issue I am asking about.

What you highlighted are different meanings.

If alternate phrasing will help, folks should try this:

      What is the intended meaning of a duly authorized actor
      when they affix a signature?

So, take it as a given that all of the basics of proper and robust digital 
signature mechanics have been performed and that, for example, non-repudiation 
of originator is not an issue.

Besides knowing that you can trust the bits weren't changed between signing and 
verifying, WHY did that duly authorized agent sign the thing?

I believe that most recipients of an email signed with OpenPGP or S/MIME believe 
that verification means that the signer was the author of the message or that 
the signer has vetted the authenticity of the From: field.

By contrast, DKIM states an entirely different meaning.

d/
-- 

   Dave Crocker

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Jul 2011 13:42:21 -0500

The semantics of a digital signature on a blob of bits is what we say
it is.  Specifically it depends on a) the semantics of the bits being
signed, b) the semantics of the signer's public key (i.e., how we
associate a private/public key pair with some entity that we agree can
sign things, and what we allow that that key pair to be used for).

(a) is relevant whether the blob of bits is signed or not, though we
might ascribe different semantics to that blob depending on whether it
is signed, and by what key (e.g., a piece of legislation has different
meaning when it is signed by the relevant executive officer versus
when it's awaiting the executive's signature or veto, and not just
anyone could sign it and transform it into law).  Being able to
recognize what type of blob of bits that blob is is critical to
understanding its semantics.  Sometimes the context matters, but when
the meaning of a digitally signed blob depends on context then you
have to worry about the context changing.

Now throw in everything else that's been said (e.g., about how weak
hashes are often used) :)

I do see significant parallels to meatspace.  It is always important
to define the semantics of these things.  We don't necessarily have to
be rigorous (so PGP and S/MIME say little about who is authenticated
and what that means?  but if most people derive a good enough meaning
from the words themselves, that's probably good enough) but it
probably helps to be.

Nico
--

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 09 Jul 2011 13:45:49 -0700

On 07/09/11 10:15, Dave CROCKER wrote:
> when they affix a [digital] signature?

Short answer: It depends.

Longer answer:  It depends on what the key-holder (or someone authorized 
to act on their behalf) has previously said about the meaning of 
signatures with that key.

IMHO the "extended key usage" x.509 attribute touches on this question;
see, for instance, http://tools.ietf.org/html/rfc5280#section-4.2.1.12

If an entity wants to distinguish two different reasons for signing 
something, it's best if it uses separate keys for these two purposes.

My quick feedback on:

http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_1.pdf

is that I disagree with your advice to use the same key for multiple 
purposes.

					- Bill

---

From: Joe Touch <[email-masked]>
Date: Sat, 9 Jul 2011 17:58:34 -0700

On Jul 9, 2011, at 10:15 AM, Dave CROCKER <[email-masked]> wrote:

> What I particularly like about your response is that while it correctly demonstrates the problem with my loose phrasing, it also demonstrates the correctness of the issue I am asking about.
> 

That is usually specified *inside* the doc being signed. 

I've recently signed legal docs digitally, where the method included "type this number in to confirm the terms". It's all about the contract itself, as with a pen and ink dignature. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 09 Jul 2011 22:54:54 -0700

Hi, all,

To summarize my view:

1) a digital signature's meaning regarding the doc is determined by the 
doc, as with *any* signature

i.e., the doc typically says "the undersigned agrees to..." or "by 
signing I, (name), affirm that...", or somesuch. When it's not stated 
explicitly, it's implicit in the type of document. A lawyer would 
provide more context on the specifics of explicit and implicit meaning 
like this.

2) the signature itself represents a capability against forgery, just 
like any other signature; the extent of that capability depends on the 
nature of the signature itself - just like with pen-and-ink signatures.

I.e., an "X" suffices in some contexts where the "CA" is known or 
assumed (e.g., a witness, or in the presence of an executor, etc.); in 
other cases, the CA needs to be further authenticated (e.g., a notary). 
Sometimes self-asserted times are sufficient; other times, events are 
printed as notice (e.g., legal notices in newspapers)

None of this seems to be particularly interesting or new for digital 
signatures, AFAICT.

Joe

On 7/9/2011 5:58 PM, Joe Touch wrote:
>
>
> On Jul 9, 2011, at 10:15 AM, Dave CROCKER<[email-masked]>  wrote:
>
>>
>>

---

From: Jon Callas <[email-masked]>
Date: Sat, 9 Jul 2011 23:01:58 -0700

Dave,

I a bit late to the party, but here are a few comments. 

Over a decade ago, Bruce Schneier and I wrote an article called "Why digital signatures are not signatures" for The Industry Standard. I know there is a version of that article on Bruce's web site still. Many of the points we made in it have been made by Peter Gutmann and others, but I both refer you to that article and want to say some more. 

First, a digital signature and an ink signature are not the same thing at all. A digital signature is a thing, an ink signature is an act. If I sign (with ink) a contract or credit card receipt, it is the act that makes it legal, not the ink. It doesn't matter what you sign, it is the fact that you signed it. An "X" at the bottom, properly authenticated is completely legal and binding. I commonly sign those touch screen, so-called electronic signature things with the word "Signature".  That is completely legal and binding. Again, it doesn't matter what you sign, it matters that *you* sign it. 

In contrast, a digital signature is a thing, more akin to a seal than a signature, and the world would be a better place if digital signatures had been called seals rather than signatures. 

Everyone intuitively knows that if you put an ink image exactly like a signature on a document, the person whose signature that is did not sign the document. Yet, us techie types would say that if you produce a document that collides with another, then they are both digitally signed. 

We all know that there is no danger in lending someone your pen, but we all know that there is danger in letting someone else use your private key. 

If we consider a signed contract, what makes it important is not that it is signed, it is that it is a contract. If you write a contract on a page with an autograph, it is not suddenly valid. But if you find bits that hash to the right thing, then the digital signature is valid. Or is it?

The real question you are asking is about symantics and the standards you quote are all about syntax. I know that OpenPGP intentionally punted the semantic question. That is why "authenticated" and related terms are not defined. What they mean depends on semantics, not on syntax. 

The person who quoted Humpty Dumpty from Alice probably has the best answer. A signature means what it is agreed upon to mean, nothing more and nothing less. These is a very real sense in which trying to add meaning to a digital signature is fraud in the very same way that writing a contract around a page with an autograph is fraud. Of course, fraud itself is a semantic thing, because it is a term that we use to describe an abuse of signatures and authentication and so on. 

DKIM differs from other signature standards in that it at least tries to address the semantic issue. It may be a bit squishy, but it doesn't punt the issue. 

It is entirely possible that this message is signed in OpenPGP format with my key. In fact, I will go so far as to say that it probably is signed. My PGP Universal server is set up to sign lots of my messages. I think it will sign this one. Let us just assume it is signed. 

What does the signature mean? Does it mean that I wrote it? Does it mean I believe what is in this message? Does it mean I am somehow bound by its content? Something else? The answer depends completely on the semantic content of this message as well as the constellation of human events surrounding it. 

Perhaps belaboring the point, if I sign a card that reads "all the best to you in the joyful holiday season" I'm really only sending a card. It resembles what DKIM means more than any discussion of contract law. The signed card means whatever it means because there is no semantic social context surrounding what cards mean. A card is not a contract because a card is not a contract. This signed email means whatever a signed email means. 

Jon

Sent from my iPad

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 10 Jul 2011 18:29:01 +1200

Jon Callas <[email-masked]> writes:

>In contrast, a digital signature is a thing, more akin to a seal than a
>signature, and the world would be a better place if digital signatures had
>been called seals rather than signatures.

I would call what's discussed in crypto texts and standards "assertions"
rather than "seals": "Bob presents the signature to the judge and the judge
says 'Clearly Alice is guilty'", when what'll really happen is that the 60-
year-old judge with the liberal arts degree will peer at Bob through his tri-
focals and say "Huh?".

Just as a general question (not specifically addressed to Jon), hasn't all
this material been done to death 10-15 years ago?  I'm kinda surprised to see
it all coming up again now, rather than people just referring to the huge
amount of stuff that's been written about this in the past (including quite a
bit by real, live lawyers who actually know how this works under law rather
than on a whiteboard)

>A signature means what it is agreed upon to mean, nothing more and nothing
>less.

Exactly.  The original question was far too vague, like asking how long is a
piece of string.  For what purposes are you signing, who are the relying
parties, what do they expect from a signature, how much is at stake, under
what conditions are the sigs generated and verified, does it need to stand up
in court (the acid test that differentiates a real "signature" from a mere
assertion) in which case you need to ask lawyers and not security geeks, etc.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 10 Jul 2011 09:48:52 +0300

> In contrast, a digital signature is a thing, more akin to a seal than a signature, and the world would be a better place if digital signatures had been called seals rather than signatures. 

That depends. A digital signature on a bag-o-bits is a thing. An ink signature on a page you have received through the mail, the fax machine or a scanned image sent in email is just as much a thing as a digital signature. If I see you applying a digital signature to a bag-o-bits, it becomes an act as well, although that's not the usual way of using digital signatures.

> Everyone intuitively knows that if you put an ink image exactly like a signature on a document, the person whose signature that is did not sign the document. Yet, us techie types would say that if…

No, they're not. The "MD5 Collisions Inc." was not a properly signed certificate. It was just a perfect forgery.

> We all know that there is no danger in lending someone your pen, but we all know that there is danger in letting someone else use your private key. 

You can't generate a signature identical to mine with my pen. You need my hand (or is it the wrist). That's a technological difference, not an essential one. 
> If we consider a signed contract, what makes it important is not that it is signed, it is that it is a contract. If you write a contract on a page with an autograph, it is not suddenly valid. But i…

No. You're just a clever cryptographer, similar to people who can forge anybody's signature.

> Perhaps belaboring the point, if I sign a card that reads "all the best to you in the joyful holiday season" I'm really only sending a card. It resembles what DKIM means more than any discussion of…

Isn't it binding?  I wonder is somebody has ever tried to sue a card sender if their holiday season was not joyful.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 10 Jul 2011 10:07:50 +0300

> year-old judge with the liberal arts degree will peer at Bob through his tri-

Bob doesn't present ink-based signatures either. If there's an actual case where Bob has a signed document and Alice claims she never signed it, then either Bob has to testify that he saw Alice sign the document, or he has to bring in an expert witness. This is true regardless of whether the expert witness is a handwriting expert or a crypto expert. The judge will not consider himself an expert on either.

In practice this kind of court case is rare. The cases are usually about the semantics of the contract rather than the history of the signature.

> bit by real, live lawyers who actually know how this works under law rather

Yes, it's been done to death, but no, there hasn't been a good answer from all this doing to death. We know that digital signatures are merely an anti-counterfeiting measure, much like seals. We know that courts have ruled that clicking a button (with zero bits of security) is equivalent to a signature ("the software is installed --> the user clicked the EULA --> the user agreed to all the terms in the EULA --> The user must hand over his firstborn son to us.  QED"). Similarly, clicking a button that says "proceed to checkout" is good enough for online stores to take money from me. Yes, I can deny I made the transaction and get the money back, but that just means that it's easy to make it seem like I entered the agreement when I didn't. It doesn't mean that clicking that button is not equivalent to a signature. Similar things exist with mail-order catalog orders, where the signatures are all pen-based.

It could be that in some jurisdiction (or maybe in the future) it would be harder to deny a signature made with a private key than it would be to deny a signature made by clicking a button. But that is just because of the relative ease of forging one vs forging the other. All three are valid ways to sign contracts.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Jul 2011 04:00:23 +1200

Yoav Nir <[email-masked]> writes:

>Yes, it's been done to death, but no, there hasn't been a good answer from
>all this doing to death.

I would call that a pretty conclusive answer then.

Peter.

---

From: Sean Turner <[email-masked]>
Date: Sun, 10 Jul 2011 12:38:09 -0400

On 7/9/11 10:14 AM, Dave CROCKER wrote:
> Second, this thread is unfortunately a good demonstration of why survey
> research is difficult. In spite of trying to ask the questions
> carefully, the nature of what I am asking appears to have been
> interpreted a bit differently than I intended.
>

There is a definition in RFC 4949 (The Internet Security Glossary) for 
digital signature, electronic signature, and digitized signature.  I 
guess it doesn't talk about "meaning", but I don't think the definition 
for digital signature is too far off from what Peter wrote.  I'll 
include it here to save everybody running it down ((I) - means it's the 
RECOMMENDED definition):

  $ digital signature
       1. (I) A value computed with a cryptographic algorithm and
       associated with a data object in such a way that any recipient of
       the data can use the signature to verify the data's origin and
       integrity. (See: data origin authentication service, data
       integrity service, signer. Compare: digitized signature,
       electronic signature.)

> The core of the answer presents the narrowest possible meaning of
> signature, by casting it in term of the pure mechanics of data
> integrity. More than one response focused on this. The issues of a
> signature's basic mechanics and validity are, of course, essential, but
> I really meant to take all of that as a given and, instead, ask more
> about the "why" (or the policy) of different signatures. Signatures
> often have a context beyond protecting the bits from manipulation.

I think a digital signature is a mechanism and that's it.  What you 
derive from the outcome of validating that signature and examining the 
contents (claims) of the thing that was signed is something else.  I 
guess that's the "meaning" you're looking for.

> The "Nothing more, nothing less" suggests that my question might have
> had a larger scope, as indeed I had meant. The narrow definition really
> casts the purpose of a signature as only for ensuring data integrity
> between signing and verify.

See above.

> These point into the larger scope I am looking for. OpenPGP and S/MIME
> don't really define the meaning of their signatures. For example, S/MIME
> repeatedly uses the word 'authentication' but never defines what it is
> that is authenticated.

I'm not sure that they should.  S/MIME is a general purpose profile of 
CMS for email.  So, all it needs to say is what is signed.  In CMS it 
talks about the use of signed-data:

    The typical application of the signed-data content type represents
    one signer's digital signature on content of the data content type.

It later goes on to talk about what are steps to involved to get a 
signed-data.  It also later goes on to talk about the signature field 
(where the actual signature goes):

    signature is the result of digital signature generation, using the
    message digest and the signer's private key.  The details of the
    signature depend on the signature algorithm employed.

For authentication, assuming the digital signature verifies you'd know 
the private key holder is the entity that composed the contents of the 
message and it's contents were not modified.

> The term I've recently seen used, to describe the statement of "meaning"
> for a signature is "claims". For example, when I sign a contract, the
> meaning of the signature is commitment to the contract's terms and
> conditions.

I've heard that too, but I think that you've got think about the 
contents of the thing that is signed - that's the claim.  Actually, the 
definition of authenticate and authentication in RFC 4949 include the 
term "claim".

> signature is validating either or both of the author or the content --
> but then there are multiple possible meanings to "validating
> about OpenPGP and S/MIME signatures. However note that it is definitely
> NOT the correct interpretation for DKIM.

Yep that's right because in S/MIME and OpenPGP the key holder is almost 
always tied to a person while DKIM is for domains.  Don't forget for 
S/MIME there's also RFC 5750 (Certificate Handling) and it in states:

    Sending agents SHOULD make the address in the From or Sender header
    in a mail message match an Internet mail address in the signer's
    certificate.  Receiving agents MUST check that the address in the
    From or Sender header of a mail message matches an Internet mail
    address, if present, in the signer's certificate, if mail addresses
    are present in the certificate.  A receiving agent SHOULD provide
    some explicit alternate processing of the message if this comparison
    fails, which may be to display a message that shows the recipient the
    addresses in the certificate or other certificate details.

So I can see why somebody might believe that both are validated.

>> the unauthenticated portions of the encrypted message

This comes from the section that discusses why you'd want to encapsulate 
an EnvelopedData with a SignedData.  EncryptedData doesn't provide any 
kind of authentication; hence, why you'd wrap it in a SignedData - and 
not the other way around.

> But what does it mean to be authenticated? It doesn't say.

This is talking about two fields: authenticated attributes (authAttrs) 
and unauthenticated attributes (unAuthAttrs).  The attributes are either 
included as part of the signature process (authenticated attributes) or 
not (unauthenticated attributes).

spt

---

From: Jon Callas <[email-masked]>
Date: Sun, 10 Jul 2011 10:13:48 -0700

> That depends. A digital signature on a bag-o-bits is a thing. An ink signature on a page you have received through the mail, the fax machine or a scanned image sent in email is just as much a thing…

Which is precisely that particular point. These days, the cool kids are all doing contracts by send each other PDFs of documents. The ink and the bits that are the scan of the ink are representations of the act that is the contract. 

> No, they're not. The "MD5 Collisions Inc." was not a properly signed certificate. It was just a perfect forgery.

Okay, that's great. That's how it should be. 

> You can't generate a signature identical to mine with my pen. You need my hand (or is it the wrist). That's a technological difference, not an essential one. 

Are you *really* saying that if I just had technology good enough, then the contract I signed you up for is valid? Not only does that disagree with what I understand contract law to be, it disagrees with what you said above. Thank you for the Aristotelian language here -- the signature is *essential*, not technological.

> Isn't it binding?  I wonder is somebody has ever tried to sue a card sender if their holiday season was not joyful.

People have made jokes about that very thing; no, it's not binding because it isn't actually a statement of intent, it is merely protocol. 

Similarly, consider this exchange:

Alice: Good morning, Bob, how are you?

Bob: I'm fine, Alice, how are you?

Alice: I'm fine as well. 

This is not a discussion about health. It's exactly the same thing as SYN, ACK, SYN. It establishes a conversation similarly to the way a TCP connection is opened up. Its surface structure might look like that, but that's not what it means. The essence is mere protocol. Five minutes from now, when Bob mentions that his sciatica is flaring up again, he's not confessing to a lie, he's performing selective disclosure. 

We could sort all this human protocol stuff out in the digital signatures, but it would require intent flags and other stuff that it is hard to get consensus on. We will probably get the sarcasm bits into Unicode first. 

Jon

---

From: SM <[email-masked]>
Date: Sun, 10 Jul 2011 10:17:36 -0700

Hi Jon,
At 23:01 09-07-2011, Jon Callas wrote:
>First, a digital signature and an ink signature are not the same 
>thing at all. A digital signature is a thing, an ink signature is an 
>act. If I sign (with ink) a contract or credit card receipt, it is 
>the act that makes it legal, not the ink. It doesn't matter what you 
>sign, it is the fact that you signed it. An "X" at the bottom, 
>properly authenticated is completely legal and binding. I commonly 
>sign those touch screen, so-called electronic signature things with 
>the word "Signature".  That is completely legal and binding. Again, 
>it doesn't matter what you sign, it matters that *you* sign it.

Would an ink signature be a mark that denotes informed consent?

>The person who quoted Humpty Dumpty from Alice probably has the best 
>answer. A signature means what it is agreed upon to mean, nothing 
>more and nothing less. These is a very real

I liked that answer.

Regards,
-sm

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 10 Jul 2011 14:24:24 -0400

> I believe that most recipients of an email signed with OpenPGP or S/MIME believe that verification means that the signer was the author of the message or that the signer has vetted the authenticity of the From: field.
> 

I think this is exactly the point that Peter and Jeff were making: The semantic associated with a signer and signature depend on the application.

S/MIME / OpenPGP: signer ~ From, signature ~ "message is from me"
DKIM: signer ~ domain, signature ~ "message is from my domain"

It's natural for signatures to mean different things in S/MIME vs. OpenPGP vs. DKIM, because they are defined to mean different things.  You'll note that signatures in TLS, IPsec, PKIX, and DNSSEC also mean rather different things that the above.

--Richard

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 09 Jul 2011 10:12:52 -0700

d/
-- 

   Dave Crocker

---

From: Mouse <[email-masked]>
Date: Mon, 11 Jul 2011 11:15:40 -0400 (EDT)

>       What is the intended meaning of a duly authorized actor when
>       they affix a signature?

"That depends."  Like a paper signature, I would say it depends on the
thing being signed, in general - though there are special cases (like
DKIM) where other, contextual, information provides that meaning.  (The
meaning of a DKIM signature cannot be inferred from the content signed
over; it comes from the way the signature is encapsulated.)

> So, take it as a given that all of the basics of proper and robust
> digital signature mechanics have been performed and that, for
> example, non-repudiation of originator is not an issue.

Um, at least sometimes, non-repudiation of originator *is* the intended
meaning and thus is at issue even if there are no forgeries (then!) in
sight.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Jul 2011 08:28:48 -0700

> over; it comes from the way the signature is encapsulated.)

I believe that most uses of OpenPGP and S/MIME for signing email are not 
contingent on the message content or even the recipient list.  Yet the signature 
has some meaning.

What does the signer intend to mean and what does the recipient take it to mean? 
  (These could be different.)

> meaning and thus is at issue even if there are no forgeries (then!) in

ack.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Jul 2011 08:32:30 -0700

On 7/10/2011 11:24 AM, Richard L. Barnes wrote:
> I think this is exactly the point that Peter and Jeff were making: The
> semantic associated with a signer and signature depend on the application.
>

ack.

just to be picky, does the 'me' refer to the name and/or address in the 
rfc5322.From field?

> DKIM: signer ~ domain, signature ~ "message is from my domain"

DKIM is a transit-signing mechanism.  Any entity that touches the message along
the way might sign it.  Hence 'from' means 'along the path' rather than
'originator'.

In fact, a DKIM signature might be made by an entity that is NOT part of
transit, such as with a third-party vetting service.  For example, an originator
could hand the message to the vetting service, get back a signature, affix it to
the message, and send it on.  A receiver could validate the sig and use it for
assessment.  (This was, in fact, exactly how the Goodmail model worked.)

d/

-- 

   Dave Crocker

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 11 Jul 2011 11:45:15 -0400

> assessment.  (This was, in fact, exactly how the Goodmail model worked.)

Well, either way, the message passed through the signer.  So you could say something like:
signature ~ "message passed through my domain"

That statement could of course be overloaded with statements like "I wouldn't have allowed this to pass through my domain without a virus scan."  But that starts to get layer-9-ish.

--Richard

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Jul 2011 08:48:51 -0700

On 7/11/2011 8:45 AM, Richard L. Barnes wrote:
> Well, either way, the message passed through the signer.  So you could say
> something like: signature ~ "message passed through my domain"

+1

> That statement could of course be overloaded with statements like "I wouldn't
> have allowed this to pass through my domain without a virus scan."  But that
> starts to get layer-9-ish.

possibly not that low in the stack...

more seriously:  all sorts of policies might apply for a particular signer, but 
the basic DKIM standard communicates none of them.  ADSP is an example of 
attempting to communicate a specific, additional policy.

d/

-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Jul 2011 22:06:06 -0400

...
> more seriously:  all sorts of policies might apply for a particular signer,
> but the basic DKIM standard communicates none of them.  ADSP is an example
> of attempting to communicate a specific, additional policy.

I want to stress that this is a core point of Dave's line of
questioning here: separating what the signing protocol does, what the
semantics of the signature are (as defined in the protocol), and what
extra inferences one might make, or what extra assurances one might
give out of band.

A key point is that those extras might be useful and sensible, but
they're not part of the protocol.

Barry

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 21:14:55 -0500

> they're not part of the protocol.

The premise behind DOSETA, IIUC is that digitally signed documents are
a better analog of meatspace signatures than electronic signatures
(i.e., clicking on a button) POSTed over secure channels.  If
meatspace signatures are an action, and there is no specific need for
sealing documents, then arguably electronic signatures over a secure
channel (we already have both) are the better analog.  Now, perhaps
things are so hopeless that digitally signed documents would be
better, but even granting that, when you consider the time and cost to
switch to the DOSETA model, are we really better off than making the
current tech we have work better?

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2011 08:58:26 -0700

> sign things, and what we allow that that key pair to be used for).

I agree with (a). As I said before, the meaning of a mark on a doc is 
defined by the doc, either explicitly (the undersigned agrees to...) or 
implicitly (e.g., on a bill of sale).

I disagree with (b). (b) isn't about semantics; it's about how trusted 
the resulting signature is, i.e., the value applied to the signature's 
properties. The properties themselves can limit that trust, but don't 
define it.

E.g., within USC, email from my account is often sufficient to assign a 
grade. As others have noted, a mark ("X") can suffice for a handwritten 
signature.

This is all well-established elsewhere (e.g., in law); there's no 
significant difference here except in the level of trust and challenge.

Joe

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 12 Jul 2011 09:14:24 -0700

> I agree with (a). As I said before, the meaning of a mark on a doc is defined by
> the doc, either explicitly (the undersigned agrees to...) or implicitly (e.g.,
> on a bill of sale).

Folks,

Apparently I was not sufficiently clear about the nature of the survey.  It is 
not intended to query the meaning of digital signatures in general.  The survey 
was meant to refer to a particular type of scenario that uses digital signatures.

Although not really in mass-scale use, OpenPGP and S/MIME are regularly used to 
sign messages.  Their use often is entirely automated, so that every message 
sent by the user is signed.

Nothing about such a mechanism depends upon the content of the message.  Every 
email gets a signature.  So the intended 'meaning' of putting a signature there 
cannot be based on the content of the message.

So a rephrasing of the questions:

    1.  When a user's mail agent is configured to sign every outgoing message, 
what is the (intended) "meaning" of that signature?

    2.  For such mail, what meaning should a receiver attribute to a validated 
signature of this type.

Please note that validating a signature and imparting/deriving meaning to it are 
entirely separate from the next phase of processing, which assesses the 
trustworthiness/goodness of the agent responsible for the signature.

So, for example, there is a fundamental difference between a 'meaning' such as 
"the owner of the identity responsible for signing this message claims that the 
author From: field is valid", versus an assessment which says "the identity 
responsible for signing this message is a Good Actor and I can trust what they 
put into their email."

d/
-- 

   Dave Crocker

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2011 09:28:13 -0700

Hi, Dave,

On 7/12/2011 9:14 AM, Dave CROCKER wrote:
>> defined by
> Apparently I was not sufficiently clear about the nature of the survey.
> It is not intended to query the meaning of digital signatures in
> general. The survey was meant to refer to a particular type of scenario
> that uses digital signatures.
>
> Although not really in mass-scale use, OpenPGP and S/MIME are regularly
> used to sign messages. Their use often is entirely automated, so that
> every message sent by the user is signed.
>
> Nothing about such a mechanism depends upon the content of the message.
> Every email gets a signature. So the intended 'meaning' of putting a
> signature there cannot be based on the content of the message.

In that case it's defined by the signer.

For one signer, it can mean "I read and agree to the terms in the email".

To another signer, it can mean "I assure that this came from me".

However, if the doc itself says "if this is signed, it means X", then 
AFAICT you'd be in a courtroom needing to argue why you blindly signed 
everything without reading it.

> 1. When a user's mail agent is configured to sign every outgoing
> message, what is the (intended) "meaning" of that signature?

IMO, that's (at best) determined by the signer, not the signature 
itself. And, as above, it can be determined by the content when explicit 
(even if not intended that way by the signer).

> 2. For such mail, what meaning should a receiver attribute to a
> validated signature of this type.

I generally assume it means "I assure that this message came from me 
intact", i.e., it was not forged or altered, unless told otherwise.

> Please note that validating a signature and imparting/deriving meaning
> to it are entirely separate from the next phase of processing, which
> assesses the trustworthiness/goodness of the agent responsible for the
> signature.

Agreed - a doc signed with a key I haven't validated means nothing to me.

Joe

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 12 Jul 2011 09:49:26 -0700

> In that case it's defined by the signer.

How is the verifier to know the intended meaning?

> For one signer, it can mean "I read and agree to the terms in the email".

I don't know what that means.  What "terms in the email"?

Remember that this mechanism applies to /all/ email from the user.  Notes to 
their grandmother, reports to their boss and replies to a mailing list.

> However, if the doc itself says "if this is signed, it means X", then AFAICT
> you'd be in a courtroom needing to argue why you blindly signed everything
> without reading it.

Perhaps your mailstream is different from mine, but I believe I've never seen 
/any/ message with language like that in it and certainly none from a stray user 
with an automated S/MIME or OpenPGP signature.

Consequently, the offered example doesn't resolve much of the real-world use of 
S/MIME or OpenPGP...

> IMO, that's (at best) determined by the signer, not the signature itself. And,
> as above, it can be determined by the content when explicit (even if not
> intended that way by the signer).

Protocols work poorly when there is no shared meaning in the exchange.  Both 
ends of the exchange MUST make the same interpretation.

Absent a means by which the verifier can know precisely the intended meaning of 
the signature, the "authentication" mechanism is not a useful protocol.

> I generally assume it means "I assure that this message came from me intact",
> i.e., it was not forged or altered, unless told otherwise.

I suspect that your use of the "me" refers to the person indicated in the 
rfc5322.From field and that the email address in that From: field matches the 
identifier in the signature...?

d/
-- 

   Dave Crocker

---

From: Mouse <[email-masked]>
Date: Tue, 12 Jul 2011 12:50:01 -0400 (EDT)

> [[T]he survey] is not intended to query the meaning of digital
> signatures in general.  The survey was meant to refer to a particular
> type of scenario that uses digital signatures.

> Although not really in mass-scale use, OpenPGP and S/MIME are
> regularly used to sign messages.  Their use often is entirely
> automated, so that every message sent by the user is signed.

> Nothing about such a mechanism depends upon the content of the
> message.  Every email gets a signature.  So the intended 'meaning' of
> putting a signature there cannot be based on the content of the
> message.

I think I probably disagree with that last.  I don't have such a setup
and can't really speak for those who do, so the AA bit is clear on this
email, but I rather suspect that the automated signatures are intended
for only certain types of content and applying them uniformly is done
because it avoids needing to either mechanically detect that type of
content or count on a human to remember.  (In some cases it may also be
done in an attempt to avoid leaking information, to avoid indicating to
unrelated third parties which messages contain the relevant kind(s) of
content.)

See above.

> validated signature of this type.

"This mail passed through the auto-signer" is really about the only
meaning I can justify attributing to it.  In most cases this is
probably operationally very close to "this mail is from whom it says it
is and didn't get corrupted in transit", but that, particularly the
part before the "and", depends on the details of the auto-signer setup.
(I suspect the latter is approximately what most people _do_ interpret
such signatures to mean.  Personally, I can't recall the last time I
even bothered to verify any kind of signature on an email; I don't do
very much emailing for which strong signatures are relevant.)

> So, for example, there is a fundamental difference between a
> 'meaning' such as "the owner of the identity responsible for signing
> this message claims that the author From: field is valid", versus an
> assessment which says "the identity responsible for signing this
> message is a Good Actor and I can trust what they put into their
> email."

I suspect the latter interpretation may be statistically defensible, in
that I suspect use of such a setup correlates positively with being
honest and competent.  (I also suspect the correlation is weak enough
that I wouldn't count on it in any particular case.  And, of course, I
could very well be wrong in my suspicions.)

There's also the problem - from the recipient's point of view - of
distinguishing auto-signer signatures such as you describe from
delibrately affixed one-off signatures.  In isolation (ie, given
nothing but a single email to examine), there's no way to tell the
difference in general, after all.  Since you seem to be ignoring this
issue, I am too, but depending on why you're asking it may need at
least thinking about.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jul 2011 09:54:14 -0700

On Jul 12, 2011, at 9:28 AM, Joe Touch wrote:

> IMO, that's (at best) determined by the signer, not the signature itself. And, as above, it can be determined by the content when explicit (even if not intended that way by the signer).
> 
> I generally assume it means "I assure that this message came from me intact", i.e., it was not forged or altered, unless told otherwise.

Those look correct. In fact, the first one is correct even for a mail agent that is configured for non-automatic signing. There are no concrete, well-accepted semantics for signing email, although there is at least one reasonably-well accepted semantic for a signature on a transmitted message whose signature validates.

--Paul Hoffman

---

From: Mouse <[email-masked]>
Date: Tue, 12 Jul 2011 13:00:59 -0400 (EDT)

> AFAICT you'd be in a courtroom needing to argue why you blindly
> signed everything without reading it.

But, given a history of signing everything, especially if that is known
to the actual sender, and a reason for doing so, I doubt it would stand
up, any more than it would if I were to send a message to this list
saying "If handled by mail.ietf.org, this mail means ...".

> [...].  And, as above, it can be determined by the content when
> explicit (even if not intended that way by the signer).

Um, I don't think the intended meaning of a signature can be one not
intended by the signer.

> Agreed - a doc signed with a key I haven't validated means nothing to

I do attribute meaning to such a signature, though it's a fairly weak
meaning and bears more on the sender's psychology and attitudes than it
does on the content of the particular message in question.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Mouse <[email-masked]>
Date: Tue, 12 Jul 2011 13:33:20 -0400 (EDT)

> Remember that this mechanism applies to /all/ email from the user.
> Notes to their grandmother, reports to their boss and replies to a
> mailing list.

Some senders don't send notes to grandmothers, reports to bosses, and
replies to mailing lists.  If the only things that user - that email
identity, perhaps even that human - sends is things for which "terms in
the email" makes sense, then this may be entirely correct.

>> However, if the doc itself says "if this is signed, it means X",
> Perhaps your mailstream is different from mine, but I believe I've
> never seen /any/ message with language like that in it

I wrote one.  One.  Once.  It was for a new NetbSD developer; I think
the language I used was something like "By signing this email, I
certify that this data blob was presented to me by someone who showed
me $DOCUMENT identifying him as $NAME.".  (The data blob in question
was a PGP key or an ssh identity or something of that general ilk.)

> and certainly none from a stray user with an automated S/MIME or
> OpenPGP signature.

Well, there is that.  I use neither S/MIME nor OpenPGP; the signature
in the example above was a pre-"Open" PGP signature, and I neither then
nor now auto-sign(ed) any mail.

> Protocols work poorly when there is no shared meaning in the
> exchange.

This is true.  That's one reason I think auto-signing mail is generally
a bad idea: because the signer's intended meaning often matches up
discouragingly poorly with recipients' interpretation of the signature.

> Absent a means by which the verifier can know precisely the intended
> meaning of the signature, the "authentication" mechanism is not a
> useful protocol.

I disagree.  In the human layer (and, so far, crypto signatures on
email are largely in the human layer), full precision is not necessary
for a protocol to be useful.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Jul 2011 12:46:20 -0500

> for a protocol to be useful.

Precisely so!  (irony intended)

What's the meaning of a signature on an e-mail?  The meaning is agreed
upon by convention among the senders and receivers.

If I see a signed e-mail, and the signature validates, and there's a
trust path for validating the sender's public key and the binding of
it to the sender's name then I "know" that the person in question
("the sender") sent it.

What more could I want?  Would I ever want a signature on an e-mail to
possibly denote something contractual?  Maybe!  But if so it will be
by agreed-upon convention between myself and my correspondents, and
most likely we'd agree to use different keys for different purposes
(because I believe in keeping good key hygiene).

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2011 10:51:58 -0700

> saying "If handled by mail.ietf.org, this mail means ...".

It depends - that's exactly how the loan docs I just digitally signed 
are worded, FWIW (they used a 'type these numbers and it means you agree 
to the terms').

> Um, I don't think the intended meaning of a signature can be one not

AFAICT, IANAL, but that's determined by a court, so all bets are off. 
I'm not saying that's what *should* happen, but AFAICT it can.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2011 11:03:42 -0700

> How is the verifier to know the intended meaning?

a) by assuming the meaning

b) by asking the signer

Both, FWIW, just as with a paper signature.

> I don't know what that means. What "terms in the email"?

Some emails say "reply to this to confirm...". I've signed loan docs 
that say "if confirmed by entering the following code into the following 
link".

*any* action specified in a doc *can* be taken as having meaning. How 
enforceable that is depends on a court decision.

> Remember that this mechanism applies to /all/ email from the user. Notes
> to their grandmother, reports to their boss and replies to a mailing list.

Sure. And if you take a pen and ink and blindly automatically sign the 
bottom of every paper that passes over your desk, you *can* be bound by 
the consequences there too.

It's all a question of the expectation of the meaning of the signature, 
but that's defined by convention (that sets assumptions), the signer 
(when made explicit), the person trying to enforce the interpretation, 
and a court (when there is disagreement).

I simply don't see this as different from a written signature.

Consider that:

- a handwritten pen-and-ink takes deliberate action
	so a simple digital signature might not be taken
	as having that weight, regardless; it might be
	that it "must" include some other info, like
	"by entering this 10-digit number, you agree to...",
	something that requires document-specific
	deliberate action

- automatic signatures - including by machine, and with a stamp - exist 
for ink signatures too
	and can carry as much (e.g., on some receipts I just received
	for a doctor's visit) or as little weight as the legal system
	will bear

>> AFAICT
> Perhaps your mailstream is different from mine, but I believe I've never
> seen /any/ message with language like that in it and certainly none from
> a stray user with an automated S/MIME or OpenPGP signature.

I've noted cases in the past few days in my mailstream that had that 
property. They did depend on more explicit per-document action than just 
an external digital signature, though.

> Consequently, the offered example doesn't resolve much of the real-world
> use of S/MIME or OpenPGP...

There's no resolution of the meaning of a signature in pen-and-ink. Why 
should the digital world be different?

>> itself. And,
> Protocols work poorly when there is no shared meaning in the exchange.
> Both ends of the exchange MUST make the same interpretation.

That's often by assumption, not by explicit exchange.

> meaning of the signature, the "authentication" mechanism is not a useful
> protocol.

Sure. If you want to be picky about it, then a digital signature means 
nothing unless the signer tells you in advance what they intended it to 
mean:
	- they wrote the message
	- they saw the message
	- their system touched the message
	- something else

Strictly speaking, you *know* nothing. But then, the same is true for 
most human transactions. We get by with a lot of assumptions, ultimately.

>> intact",
> I suspect that your use of the "me" refers to the person indicated in
> the rfc5322.From field and that the email address in that From: field
> matches the identifier in the signature...?

Above I intended "me" as the owner of the signature, not the contents of 
what's signed.

Joe

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Jul 2011 13:36:12 -0500

> (because I believe in keeping good key hygiene).

Actually, I'd not want to bother with digital signatures for contractual
purposes unless my counterparties did too.

---

From: "Hilarie Orman" <[email-masked]>
Date: Tue, 12 Jul 2011 18:05:46 -0600

>  From: Nico Williams <[email-masked]>
>  To: Mouse <[email-masked]>
>  Cc: [email-masked]
>  Subject: Re: [saag] The meaning of a signature (mid-course correction)

>  > I disagree. Â In the human layer (and, so far, crypto signatures on

>  it to the sender's name then I "know" that the person in question

Many email accounts are shared.  I think that the most you can hope
for is that the key used to sign the message is "owned" by a person
who might know or care about the content.  Or that person knows
someone who does.  Maybe.

Hilarie

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Jul 2011 20:43:28 -0400

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

> who might know or care about the content.  Or that person knows

It "feels" to me that there should be some difference here between automated signers and systems where I have to perform an act (like entering a passphrase to unlock my pgp secret).

No, I don't know how the recipient knows that I did this (and things get murky with gpg-agent type thing that cache this), but it feels like entering a passphrase is much more like physically signing a document / contract.

This is a surprisingly interesting thread...

W

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Jul 2011 19:56:42 -0500

> No, I don't know how the recipient knows that I did this (and things get murky with gpg-agent type thing that cache this), but it feels like entering a passphrase is much more like physically signi…

But since there's no way for your correspondents to verify that you
did enter a passphrase (or that it and your keys haven't been stolen
or abused by malware)...  This gives you some degree of plausible
deniability should you want to take some e-mail back.

When we sign important documents in meatspace we get the signatures
notarized, and, by implication, witnessed.  It is the act of signing,
and the fact that witnesses can testify to that act, that matters, not
what is actually written.

Therefore I would say that digital e-mail signatures are mostly
uninteresting.  (Using PGP to sign and encrypt e-mail for things like
security vulnerability disclosure *is* interesting.  Using PGP to sign
one's every e-mail is mostly not.)

Is it uninteresting to digitally sign documents?  Well, software
signatures are much more interesting that document signatures.  Is
there demand for and use of digital signature features in office
productivity tools?

> This is a surprisingly interesting thread...

As others have pointed out, it is a bit of a rehash of old arguments.
But yes, it's quite interesting.

Nico
--