Hi Nelson, welcome to this fun debate :)
Nelson B Bolyard wrote:
Ian G wrote, On 2008-11-20 07:53:
Graham Leggett wrote:
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.
Really? It seems to me that ANY prudent person would ask that question
when asked to sign anything.
Maybe they do; as you and I agree, many people do not. That includes
many businesses. There is good reason for this. One example: when the
guy comes in a truck and hands you a package, and asks you to sign his
clipboard, there is no reason to ask "what am I signing". It is more or
less for delivery, with the "more" including some agreement you weren't
shown, and the "less" for protection of the driver in case of loss.
There are many places in the world where you don't want to have signed
a document agreeing to certain things. You don't want to sign something
critical of the government in China. You don't want to sign something
sympathetic to radical Islam in the USA. You don't want to sign something
taking sides in one of the ancient disputes in regions such as the former
Yugoslavia or Czechoslovakia, in may parts of the world. People don't need
to be lawyers to be aware of the risks of blindly signing things.
You misunderstand my point. When I say, business people looking at
agreements and systems of agreements should not ask the question "what
exactly am I signing" as the primary question, I am not offering a
wholesale licence to run around and sign people up for the next jihad.
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. (Although, the reason it isn't is quite perverse and obscure.)
It may be a personal need or a lawyer's need, but that simply isn't at
issue.
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.
IIRC, crypto.signtext produces a "document" that is in an IETF standard
format, known as "Cryptographic Message Syntax" (CMS, originally known
as PKCS#7), which is also the signature format used in S/MIME. There is
lots of software in the world that can read such documents and verify
the signatures.
OK, this was also pointed out in various mails, so to answer them all:
Of course, we are all sure that a PK digsig operation produces a
signature over a hash over a document, and if I download blah-blah
software and run some crypto-whizz-bang transformation over it, I'll be
able to claim some wonderful thing about mathematics. We all know about
PKs.
That wasn't my question. Here's my question again: How do you show any
person afterwards that the person signed it?
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 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. That system has yet to evolve to the point
where it makes a serious agreement useful or sustainable.
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
b. Bob can check what Alice signed for him for a long time
c. Trent can be presented by either Alice or Bob with a signed doc.
(Note the oddity that there is no d.: anyone can check the signature is
valid cryptographically.)
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. Then,
in the Key Management section of Firefox, there should be a "show my
signed docs." Add some sugar like export, print, new. Duplicate for Bob.
Now we have a system.
(Note that one of the important points of a signing protocol is that it
memorialises the document. I'm afraid I am travelling at the moment,
and can't look up all the other points.)
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. Secondly, the
signature is likely only valid & useful within the context of the
original business (Anders' point).
It isn't a security risk unless the business says it is a business risk,
*and* they accept the security solution.
My employer has a LONG list of "acceptable business practices". Employees
are forbidden to do a whole bunch of things, including making agreements
with parties taking positions against other parties. It's surprising how
many people will try to get you to sign a statement condemning certain
nations (or religions or ethnicities) of the world, as a condition of doing
business with them. My employer promotes the use of digital signatures,
and it's particularly important not to sign something like the documents to
which I've alluded above. I don't think these requirements of my employer
are exceptional.
All very good, but it doesn't address the original statements.
Anders is correct, you are wrong.
I think such statements are supposed to begin with the word "Fiat".
Sorry, I don't parse that. You may be referring to my extremely blunt
language, which was there to counterbalance an earlier equally blunt but
wrong claim?
If you approach this
problem as if "security" can solve it, you're in trouble from day one.
Seriously.
So, you're saying that making the content of the document being signed
visible to the signer is to be "in trouble", and not a contribution to
the signer's security?
Noooo.... it's fine to do that (and useful in some contexts) but it is
not the essence.
A good signing system should preserve the original document being agreed
to and make it available; however the purpose is not "to read it", but
to use it in event of business, up to and including dispute. Reality
dictates that most people don't read those documents, and making them
"visible" doesn't make them "read."
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...)
E.g., S/MIME is useless for human signing because its sigs are required
to distro the keys, and to ensure message integrity. Therefore they
should not be construed in a human signing operation (not to mention all
the other flaws).
There has been some claim that web signing is now a popular application,
I would suspect that they are constructed of PKI, smoke & mirrors.
E.g., Anders' admission that his signing experiment doesn't nail down
the real document. (Which again is *not* the same thing as saying the
business won't work...)
(and I don't exclude my own designs from the claim of smoke & mirrors:
http://iang.org/papers/ricardian_contract.html )
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
