Nelson B Bolyard wrote:
The paper I signed stated that the packages had been inspected and found
to be in good order, and released him and his employer from all liability
for damage to them. That signature on that paper ultimately cost my
employer about $6k (a lot of $$ in 1978), IIRC, and I learned a big lesson.
Right. As it is a business to business issue, in this case, likely your
employer didn't have a leg to stand on. But there are non-signed
solutions to this problem. If that happened to me, I would not use that
shipper again. Secondly, that's what insurance is for.
Instead, I am pointing out that the requirements for a signing
application should be driven by the business needs, and that isn't one
of them.
I might agree for "a signing application", but here we're talking about a
signing feature of a browser, the most general purpose computer application
in the world, I think. We're talking about a facility that may be used in
some closed business environment for well defined business purposes, yes,
but also WILL be used in lots of other environments, where people are
presented with requests from heaven knows who for signatures on documents
saying heaven knows what.
Right. On the slippery slope. The feature adds a digsig to a document
and sends it to a server.
Does that make it a digital signing feature? That depends on the
definition of signing (which is subtly different to "adding a signature").
Does that make it a contracts feature? No, for some of the reasons I
outlined. A contract has six elements, so say the law books, and a
signature is approximately but not exactly one of them. (No, I don't
know them all myself, but they start off with offer, acceptance,
delivery, consideration ...)
The point then being that sure, it might help some applications, but
thinking of it bottom up:
digsig -> post to server -> digitally signed -> contract
is not the way to architect this system. Or any system. It's a trap
that people fall into too regularly, and it leads them to miss the
essence of the real application.
I'm concerned about the design of a product for use in ALL situations,
not merely by an employee of a business who happens to be dealing with
his employer's computer systems.
Indeed. It's perhaps the toughest of fincrypto apps. And trying to do
it "generally" just makes it go from hard to darn-near-impossible. I
know this because I have succeeded in doing it, but only in an extremely
limited context. Taking the lessons from that limited context to a
generalised context is IMO unworkable.
(Although, the reason it isn't is quite perverse and obscure.)
If you want me (or any of this list's readers) to accept that last part,
you really should spell it out, and let us judge it for ourselves.
I know :) This thread is already too long without getting into a
reverse engineering of the institution of the law.
...
That wasn't my question. Here's my question again: How do you show any
person afterwards that the person signed it?
I think you're asking, how does the browser user show what he signed, or
that he signed it? I agree that that's an important question. IIRC, in
US law, any person required to sign something is legally entitled to
receive a copy of the thing he signed. The "system" must provide that.
I think that means the browser must provide the capability to store a copy
of the signed thing for the local user.
Right, that's getting closer.
I mean: how does Alice look tomorrow in this system to see what she
signed? Next year? How does Bob look next year to see what Alice
signed? How does Trent, some random third party like a judge?
The recipient (server operator) has to answer that question for himself,
and presumably will. Being the business person that he is, he surely
won't go to the bother and expense of asking the browser user to sign a
document and not retain a copy of that signed document.
The browser user has a real issue there. I completely agree.
OK, we are in accord. This was my comment that the function wasn't a
"system". My further comment is that the signature objective is now
compromised, without some serious thinking and additional work. Just
because some function created a digsig over a document doesn't mean they
have a signed and agreed contract.
The system above seems to have none of that. In analogous terms, it
seems that we have invented a new form of ink, but because the business
controls the pen&paper, and has not provided it to the user, we do not
have the essence of signing.
I don't agree with that analogy, but I agree there is something wrong with
signing of content in ALL browsers that support it at present.
When you sign the driver's clipboard, the driver is almost never able to
give you a copy of the page that you just signed. You sign it, and he
puts it away and you never see it again. Thereafter, he has a copy of
your signature, and you don't. (Same goes for signatures given at
polling places, signatures given on petitions, etc.) That, sadly, is
the only model now supported in browsers that offer signing capabilities.
Right. So, one view is that this is what is required -- at the level of
the app. Other views are that it leaves you unprotected. It all
depends on the app. Hence, generalising this in order to add simple
tools to the browser is very difficult; we may add the right tools, but
the chances of them being misused is quite high.
When you sign something with your browser, your pen is some combination of
your browser and your private key.
Well, I created a private key last week. Or did I? Actually, I
followed some instructions and clicked around with my browser. At one
point it said "wait" and flashed a bit. Then, I clicked some more.
Supposedly it created a key. There is an entry at the key place in the
management interface. But I have no real idea what happened ... which
is to say, there is no positive proof to me that I created a key, it was
all stuff done inside Firefox.
At least, at the level of an ordinary user, this is all smoke and
mirrors. If Firefox then uses the key to do a digsig, that's just more
smoke and mirrors.
So I think (right now) you are probably right that the "pen" is a better
analogue than the ink; but the private key is more "of the browser"
than anything I have done. This might be quibbling, or might not,
depending on the legal case at the time.
The paper is less tangible. The browser
doesn't give you even a carbon copy. You may be able to print the page you
were viewing containing the document content to which you agreed (which may
have been supplied in part or in whole by the server or in part or in whole
by you), either just before or just after signing, but that printed page
may not be a true copy of the signed document. For one thing,
your digital signature, which is not graphic in nature, will not be visible
on it (and some icon claiming to bear witness to your signature is unlikely
to prove anything).
Right, so there is no real difference between nothing, fraud, error or a
good signature. This is not good tech. A paper&pen signature achieves
differentiation in those more or less clearly, it beats the digsig on
all those points.
This lack of persistent storage for signed documents that the user generates
or upon which he relies is an issue for the browser.
At least, in the assumptions suggested in the current discussion, yes.
If the function crypto.sign() were going to post the signed doco to the
other party, I would want it to escrow a local copy. And this is a
question I would ask in court.
It is also an issue for the use of the certificates and signatures on which
the user relies when deciding to accept/allow a download to be installed
and/or executed on his computer system. Many think that signed installable
packages give the user some ability to at least identify the party who harms
him, if he is harmed by the thing he downloads, but typically it only gives
the user momentary control, at the moment he makes a decision based on his
browser's validation of that signature. There is typically no record kept.
After the fact, it can be difficult to find the certificate upon which the
user relied. The full solution to that problem is beyond the scope of a
mere browser however. (The term "audit trail" comes to mind.)
(noted.)
That system has yet to evolve to the point
where it makes a serious agreement useful or sustainable.
The existing system CAN be useful to both parties, if it's done right,
but it requires the server doing some things that it may not do.
The server can make a copy of the signed document available for the
browser user after the fact, but if it does not do so, the user presently
has no way to get a copy after the fact.
Let's take a stab at what it would take to do that. Some requirements:
a. Alice can check what she signed for a long time
Requires that Alice have a copy of the document bearing her signature.
b. Bob can check what Alice signed for him for a long time
Requires that Bob retain a copy of the signed document he got from Alice,
which Bob is very likely to have done.
c. Trent can be presented by either Alice or Bob with a signed doc.
Is easy, provided that Alice and Bob each retained a copy of the document
bearing Alice's signature.
(Note the oddity that there is no d.: anyone can check the signature is
valid cryptographically.)
I think you meant to write: Trent can check that the signature is valid.
No, I had it right; there is no requirement to check that the signature
is valid. That's because in most cases, this is not important: either
the signature is not as powerful as the document itself; or the real
investigation (e.g., the courts) have their ways of this.
This is a typical tech-based mistake: we see the signature, we
understand that we can make a cryptographic mark "like that", and assume
that the signature is the apex of the pyramid. It's not; the law and
agreements and courts simply don't work that way. They might tell you
that it works that way, but that's a facade, a simplification. The
truth is more complex, and has inner logics which change the roles quite
dramatically.
Did you ever see that movie, Glengarry Glenross? Half way through there
is a description of how the guy managed to sell an insurance contract to
an old couple; and it is played out in full. He sold it ... but he
didn't get an agreement! Why not? well, that's part of the story, but
the point is, the signature did not make the agreement happen.
There is an analogy to that in the pen & ink world. When Bob takes the
signed check he received from Alice to Trent the bank teller at Alice's
bank and presents it for payment, Trent may pull out Alice's "signature
card" and attempt to verify the signature. That signature card is a
nearly perfect analogy to the certificate used to verify the digital
signature. In the pen and paper world, Trent may be rather easily fooled
with a forged pen and ink signature. Producing an acceptable forgery
with a digital signature is considerably more difficult.
Yes, its an analogy. But ask your bank. Last I heard, cheques (checks)
aren't checked for signatures under $20k. The analogy still holds, but
the practical import is that the system works with far less emphasis on
the token called the signature than one would think. We can exploit
this in design of systems.
So, to meet that requirement, it would seem that the crypto.signtext()
function should also cache the entire document + signature (bound
together, maybe that's CMS) in some place next to the user's PKs.
crypto.signtext is analogous to the pen. It produces the signed document.
A copy of that needs to be kept. Whether that is the responsibility of
crypto.signtext or some other part of the browser that comes later (e.g.
when the document is actually sent) is less clear. One does not expect
a pen to keep a copy of all the documents it signs.
(I'm sure I've heard of some patented design of a pen that records a
document by laser ... :) )
Then, in the Key Management section of Firefox, there should be a "show my
signed docs."
I quite agree that the browser should have a "show me my signed docs"
feature somewhere.
Add some sugar like export, print, new. Duplicate for Bob.
I'm not worried about Bob. He's the one who decided to go to all the
expense and bother of having a server that sends out the pages that
trigger this signing and validates the signature on the response.
He's not likely to throw that money away, which he would be doing if his
server didn't keep a copy of the signed document for which he's paid.
Well, to reverse my earlier position; I'm not "worried" about Bob, but
we can see that he sure needs a good design for this, because while he
is capable of spending all that money, he isn't really capable of seeing
past the fluffy stuff. If we want this to fly, equal attention should
be put on both sides of the protocol to create a balanced arrangement;
agreements are nothing if not balanced.
Servers are very good at keeping logs of transactions, including copies
of any relevant documents. Browsers are less so, now, IMO.
(Another angle is to think of it as a peer2peer design.)
Now we have a system.
(Note that one of the important points of a signing protocol is that it
memorialises the document.
... for one or both parties, as they wish. Typically one party has a
greater immediate interest in obtaining and retaining a copy of the signed
document than the other. Example: a signed credit card slip is immediately
valuable to the merchant and typically less so to the customer.
The proof of the pudding is in the eating; a financial cryptography
system rests like an inverted pyramid on the dispute over the
transaction. If the parties are unequal in a dispute, then the whole
system is unbalanced.
Seriously, it is a business risk.
It may also be a personal risk.
Not denied, although this is not as important. Firstly, it is the
business that goes to the extent of building this system, and the users
are generally smart enough to reject a daft system, so the business is
the one losing the investment when it goes wrong.
In a closed business environment, where a business is using servers and
browsers for its employees to record their activities, yes, the employee
probably doesn't need to fear that his employer is secretly trying to get
him to sign up for jihad (although, maybe that's less certain in some
parts of the world).
But that's not the only environment of interest (to me), since mozilla does
not make business needs its principal aim. In the consumer-to-business
world, the business builds the server at some expense. The user uses the
browser that he downloaded for free. Users are using all manner of daft
systems now (and I'm not referring to ones based on digital signatures).
Right. Welcome to the dilemma. We know how to make good contract
agreements with very limited, tight scope in a digital domain. We know
how to make so-so agreements in a broad scope. Combining those two
isn't really well understood yet.
Secondly, the signature is likely only valid & useful within the context
of the original business (Anders' point).
Time for some "out of box" thinking here. I think your thinking about this
is confined to the box that is the confined world where the signer and the
recipient of the signed document are under the same business umbrella.
Any feature that finds its way into Mozilla browsers must have strong
applicability to people outside that box, I believe.
The two parties are under a wider agreement, yes. With no wider
agreement, I do not know how to solve it. I would say right now, it
isn't solvable technically, and/or not as the technologists suggest it.
Rest snipped. This is already quite long.
Yeah.
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
