Have you looked into this paper?
http://webpki.org/papers/wasp/wasp-faq.html
Unfortunately I believe there are too many uncoordinated views on this matter
to return a fruitful discussion but let me tell you how it works in Sweden: In
Sweden all the banks supply proprietary signature clients that essentially have
the same (limited) capability as crypto.signText (). Now to the "fun". Since
a tax declaration is a fairly complex document, a text/plain view is rather
useless. The tax department's solution is brilliant. In the signature
text/plain window they show an XML version of the tax declaration while the
user is presented a nice HTML version in another browser window. Naturally
there is no cryptographic binding between the HTML view and the XML (which is
signed). Anyway, Swedish security experts (-AR) claim that this is the optimal
version of digital signatures. WYSINWYS. This situation was one of the
inspirations to the WASP concept.
Now over to some of the topics:
Michael Ströder 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.
>But it's the main issue! If you don't address this it's simply worth
>nothing. And you're bashing S/MIME use. Ah well...
I expressed this wrongly. You MAY use a "trusted viewer" that would abort or
warn suspicious requests. My implementation doesn't because of the fact that I
consider it unnecessary for the primary target which is governments, banks, and
in-house work-flow. From a Platform point-of-view it is also about 30 Mb (The
Austrian solution which is "umständlish") versus a 0.5 Mb increase of the
browser executable.
>Real-world example: A company has many point-of-sale systems placed at
>external partner companies. Guess what? They have legal fights going on
>about real money. The question debated is whether the POS software
>itself worked correctly. Digital signatures wouldn't help in this
>situation since the partner would simply claim that what was displayed
>on screen was different from what was signed by the software. (They have
>a lab where each and every version of the software is installed for
>testing by assessors.)
As you say, there is no solution to the problems you just described so why
would I or anybody else spend time on that?
>Also when signing a contract by hand I usually get a physical copy of it
>which I can archive. That's not the case when doing web-signing. That's
>another important flaw of that scheme.
I have heard that many times but Web Signing is not S/MIME, it is better :-)
Good web applications always offer you a receipt that tells what the service
thought the deal was about and when it received it.
The receipt may be delivered on-line or through e-mail or as it typically is,
both ways. Try the on-line version:
http://upi-using-service.webpki.org/IncomeDeclaration
click the "I" icon to get proper PIN when asked to sign or authenticate.
>> OK, then, how does the browser manage the signed text?
>It just sends the PKCS#7 blob along with the form. The server-side
>application has to validate the signature and parse the input data from
>the simple HTML which was signed.
This is exactly how WASP does NOT work. The server generates static HTML (and
calculates hashes) and sends that to the client who signs the HTML and returns
the signature only. Very simple, very efficient, and completely universal with
respect to media type. Yes, could sign "Flash" if you felt that this is what
the market wants :-)
Graham Legget wrote:
>Signing a "form" is completely meaningless, because the user is not
>given a full, complete and unambiguous entity for them to sign.
I don't understand the meaning of the second line. BTW, in WASP you don't sign
forms, you sign "static views".
>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.
It's really not that simple. Nothing prevents a signature requester not
including the "fine print" or write the request in such a way that they user is
tricked. Even producing a very long document is a way to screw the poor user.
That is, if the user is dissatisfied, it is up to the service to replicate the
situation and if that shows that the service actually has erred one of the
purposes of signatures has indeed been met.
Anders
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
