Graham Leggett wrote:
Ian G wrote:
I'm saying this is a business problem, and not a security problem.
Look at the business of signing, and you will see that the problems
are solved in general. E.g., when signing something, there are two
copies, one given to each party.
If you try and turn this into an "infosec" problem, then you will
likely lose, as has been shown by practically every effort at general
purpose signing from the cryptographic world. e.g., the crypto.sign()
function seems to lack the ability to preserve the document for the
signing party, and if so, the signing function is probably
compromised. (Which is *not* the same thing as saying the business
won't work...)
Can you explain how the signing process is compromised?
The problem is best seen as a failure of understanding of the
application. Crypto people think of the task as duplicating or
imitating the manuscript signature. However this is a mistake. The
essence of the application is to crystallise the agreement.
So, in Netscape's crypto.sign() function, there is perfect recording of
a mark of some form, and delivery to one of the parties. That's fine,
but it has missed the more important part which is the agreement. What
was the agreement and how is that preserved?
Hence, from the pov of law, we would say that the essence is to firstly
make sure that the agreement is initially intended by the parties and
thence effected. So the document should be available to all, with an
appropriate gravity. Secondly (and only secondly) we also look to
bolster that agreement with certain other symbols so as to clarify
intent. E.g., signature (or mark or whatever that means) is one way to
do this. Another way is to send a postal letter Another way is to
attach a seal, and have a witness.
Which is to say that the signature is only one of a group of secondary
things, the agreement is primary, and without a proper attention to the
primaries, the secondaries cannot support.
There is nothing stopping your application from disseminating the signed
text to anybody that is interested, including all the parties involved.
Right. The application should do that. Anything else is nice. However
the crypto.sign() thing doesn't do that. It's an adjunct, an assist,
and its use in an application is neither necessary or sufficient. In
fact it is entirely optional.
The law does not care what you do with signed paper contracts, it
doesn't care how many copies exist. The law is only interested in
whether at least one contract can be proved to exist.
OK, so this is where the layman's view tends to miss the subtleties of
the law. Note that I am not a lawyer, I've just built contract systems
and had to learn all this stuff over time. I've made my share of
embarrassing blunders ;)
Law doesn't so much care for the document as the agreement. The purpose
of contract law is to efficiently facilitate *agreement* not promote
marks on documents, and the contract is the virtual expression of the
agreement.
Popularly, people think of the document as the contract, but this is
wrong. The contract is the sum of the parts, and the document is
generally the best evidence we have of the contract, but it is also
augmented by other things, depending on the day.
So, for example, a proper analysis of the contract would happily include
all the web pages that were shown to the user before some "click now to
sign" is presented. If the user were to screenshot them all and present
them, then they might be incorporated in to the contract by the court,
at its whim (how and whether it does that is irrelevant to today's
discussion, the important thing is that it can and does).
If on the other hand the user were *not given a copy of some text*,
signed or otherwise, by the other party, the court might drop that
document as not being relevant to the agreement. If, after all the
parties do not have the text, then it is a serious question as to how it
could have been part of the agreement. (How this conclusion is reached
in court is also beyond the scope today, the point is that it can be
reached.)
IOW, shared documentation is (IMNLO) more important that any technical
mark like a digsig. This is in contrast to the simplistic and wrong
view that the digsig is the beginning, middle and end of contracts.
(IMNLO == in my non-lawyer's opinion)
Digitally signed text is no different.
Digital text is not particularly different to manuscript text, perhaps,
and courts have pretty much nailed that one by now.
Digital signatures are a world apart from manuscript signatures, and to
claim that they are the mark of agreement is a stretch indeed (and
courts have no way to confirm this positively); At this point, to work
out what courts have said on this, I need to look at the books, but that
will have to wait a week or two.
Then, digital contracts is an entirely other issue, and again we need to
look at the cases.
Particularly, there tends to be differences between anglo-common law and
european civil code views.
Conclusion: the contract is misunderstood in general by the
cryptographic software community, and in particular, the signature is
the focus of that misunderstanding. Having a digital signature does not
a contract make.
iang
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
