Responding to two at once!
Graham Leggett wrote:
Anders Rundgren wrote:
I also understand your worries regarding what to sign and I would
be very dishonest if I said I have "solved" it. In fact, my design
doesn't even address this issue (!) except that if of course builds
on the assumption that at least the "viewer" works as expected.
Now, why don't I feel that this is a huge limitation?
First a legal issue. Based on *actual* court cases you can indeed be
convicted based on IP addresses if you are found downloading forbidden
data. I.e. digital signatures are simply a stronger evidence.
Technically correct, but it doesn't suggest a conclusion that it will
work. Practically, we might need something that looks like a signature
on a document, and -- correct me if I am wrong -- I didn't see it in the
tax invoice demo. I'm thinking here of some document that is sent to
the user with some token attached that says "you signed this" ... but it
could be anything.
Now onto Graham's surprising response!
I suspect you have spent too long in the fluffy "who cares" world where
when presented with an agreement to sign, you just blindly click on the
"accept" button trusting that the agreement that was never read
contained nothing harmful to you in any way.
Seems like we've all spent some fluffy time :)
Having designed a system that includes "web signing" using
crypto.signtext() for an insurance company to handle claim approvals, I
can tell you that the primary question of the business people who used
the system was "just what are we signing exactly?".
OK, that's interesting but equally worrying that the business people
were asking that question, above all others. If so, this would suggest
to me that your business people had spent too long in the fluffy "do
what lawyers say" world, and had forgotten they had a business to run?
Lawyers have a particularly perverse reason to say what they are saying
"just what are we signing exactly," and business people would do well to
learn why that is.
Did your business people ask about the evidentiary aspects? Disputes?
Contracts? Basis in law? Risks? Fraud? Document management?
Customer relations? Work-flow?
In the case of crypto.signtext(), the end user is presented with a piece
of human readable text, and the end user can choose to sign or not sign
that human readable text, as appropriate. That user readable text is the
beginning and end of what they are asked to sign.
OK, and how do you show afterwards that they signed it? I did a little
googling and found something called the "Netscape verification tool" ...
I would hope there is more to it than that, to put it mildly.
Signing a "form" is completely meaningless, because the user is not
given a full, complete and unambiguous entity for them to sign.
"completely meaningless" would be a strange way to describe the reality
of how most people agree to stuff, including those people who dispute
the agreements (a.k.a. the courts).
Then a practical issue. If a crooked site asks you to sign a form
that in some way is camouflaged (using overlaid HTML) into
something else, the question is really what the crooked site can
do with that unless the crooked site actually is a genuine representative
of your government, bank, or employer.
Seriously, if you cannot fathom the security risk posed by someone
asking you to sign an agreement when you cannot see the full agreement
you are signing, then you seriously should not be trying to design any
secure systems at all. Seriously.
Seriously, it is a business risk. It isn't a security risk unless the
business says it is a business risk, *and* they accept the security
solution. Anders is correct, you are wrong. If you approach this
problem as if "security" can solve it, you're in trouble from day one.
Seriously.
It is a common mistake to grasp onto an issue that is amenable to a
bits&bytes treatment, and then ramp it up from an issue to a security
risk to a business risk to an imperitive. This is the typical mid-1990s
hubris of all things being solved by crypto. Those systems, so
designed, pretty much all fell to basic failings. C.f., phishing. Or
didn't achieve any reasonable deployment. C.f., S/MIME.
iang
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
