Ian G wrote, On 2008-11-20 16:24: > Hi Nelson, welcome to this fun debate :)
Thanks. :) > Nelson B Bolyard wrote: >> 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. Interesting that you should mention that case. One of the very first legal issues with which I became involved at my place of business early in my career was in fact over my signature of a paper on a driver's clipboard. It was, in fact, that very incident that taught me to read every document before I sign it. The driver had delivered damaged merchandise, two computer terminals (in a shipment of about 12) with broken CRTs because he had driven the fork of his fork lift right through them. So, he arranged the boxes so the broken ones were in the center and could not be seen even by walking around the pile of boxes. When I arrived, he asked me to sign for receipt of the boxes. I didn't read it. After all, I was just signing a driver's clipboard. 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. > 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. 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. > (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. > 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. Well, if you run a server that routinely asks people to sign some document before (when, as) they upload it to your server, one imagines that you will also possess the software with which to validate that signature. One imagines that your server would not act on that document as genuine without having first done so. > 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. > 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. > 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. When you sign something with your browser, your pen is some combination of your browser and your private key. 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). This lack of persistent storage for signed documents that the user generates or upon which he relies is an issue for the browser. 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.) > 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. 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. > 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. > 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. Servers are very good at keeping logs of transactions, including copies of any relevant documents. Browsers are less so, now, IMO. > 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. >>> 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). > 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. Rest snipped. This is already quite long. _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
