Re: Web signing?
Nelson B Bolyard wrote: 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. Right. As it is a business to business issue, in this case, likely your employer didn't have a leg to stand on. But there are non-signed solutions to this problem. If that happened to me, I would not use that shipper again. Secondly, that's what insurance is for. 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. Right. On the slippery slope. The feature adds a digsig to a document and sends it to a server. Does that make it a digital signing feature? That depends on the definition of signing (which is subtly different to adding a signature). Does that make it a contracts feature? No, for some of the reasons I outlined. A contract has six elements, so say the law books, and a signature is approximately but not exactly one of them. (No, I don't know them all myself, but they start off with offer, acceptance, delivery, consideration ...) The point then being that sure, it might help some applications, but thinking of it bottom up: digsig - post to server - digitally signed - contract is not the way to architect this system. Or any system. It's a trap that people fall into too regularly, and it leads them to miss the essence of the real application. 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. Indeed. It's perhaps the toughest of fincrypto apps. And trying to do it generally just makes it go from hard to darn-near-impossible. I know this because I have succeeded in doing it, but only in an extremely limited context. Taking the lessons from that limited context to a generalised context is IMO unworkable. (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. I know :) This thread is already too long without getting into a reverse engineering of the institution of the law. ... 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. Right, that's getting closer. 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. OK, we are in accord. This was my comment that the function wasn't a system. My further comment is that the signature objective is now compromised, without some serious thinking and additional work. Just because some function created a digsig over a document doesn't mean they have a signed and agreed contract. 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 penpaper, 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
Re: Web signing?
Ian G wrote: 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? This is a very valid question and probably you will find my answer pretty insufficient, but WASP was deliberately designed for service-providers who want to automate and improve credibility of exiting systems, not creating a new fancy tool for emulating contract writing in the physical world. The latter represents a technical and legal challenge I'm not ready for :-) Converted to practical terms that means that the service provider is asking you to grant something, and then it should in some way provide you with a receipt that depending on the actual use-case may contain not only the original document, but additional details such as when it was received. A patent filing application would fit this description, while an in-house purchasing application would not since such systems keep all data available on-line for any authorized user to view like existing purchase operations. Saving a signed document locally would not really make much of a difference since you technically can create arbitrary off-line data and sign it. If you OTOH required that requests are signed by service-providers it would more sense (at least legally) since then you could prove what you where requested to sign which I believe was the primary objection to what I'm currently implementing. However, trying to squeeze in peer signature scenarios would IMO be dumb; such a scheme needs to be designed from the ground and up! Patent-filing, in-house purchasing, and tax declarations are not really peer scenarios, because the associated service providers set all the rules. WASP adheres to this unilateral notion :-) Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
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
Re: Web signing?
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 penpaper, 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
Re: Web signing?
What *user* could need is a copy of what was requested to be signed but that is useless unless the request is also signed since a user can fabricate whatever data he/she wants and sign it. But seriously (as Graham Legget wrote), the real use-case needs a receipt (hotel booking, patent filing, purchase) which is already standard for serious providers and unserious won't get very far with your signature. Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Thanks Nelson for explaining this. 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. 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. That is, in spite of all the legal trauma associated with signatures, authentication is actually MUCH more critical because there is nothing to repudiate in the case somebody cracked your medical file etc. You may be interested (still awake?) knowing that payment operations in brick-and-mortar shops is ultimately the most important application for the suggested scheme. Since this list doesn't really work with payments, I won't bore you to death with how this is supposed to work, but it does! Anders If you really want to test Web Signing you can try this proxy setup http://upi-using-service.webpki.org/IncomeDeclaration use PIN 1234 :-) - Original Message - From: Nelson Bolyard [EMAIL PROTECTED] To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Thursday, November 20, 2008 00:07 Subject: Web signing? Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. Mozilla implements this with a javascript extension known as crypto.signtext. I think IE implements it with an ocx (an Active-X module). There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. What's missing is the definition of the way (syntax) by which to invoke it in the browser. If I recall correctly, Anders has proposed something for that purpose, and perhaps he has developed some software for that purpose. There are some fundamental issues with this stuff, such as, how does the user know what he's being asked to sign? How does he know that he's not being asked to sign a document conveying the deeds for all his real property to the web site owner? In some countries where digital signatures have the full force of law, just like a real signature, this could be a serious issue. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
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. 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. 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?. 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. Signing a form is completely meaningless, because the user is not given a full, complete and unambiguous entity for them to sign. 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. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. Mozilla implements this with a javascript extension known as crypto.signtext. I think IE implements it with an ocx (an Active-X module). Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? What's missing is the definition of the way (syntax) by which to invoke it in the browser. If I recall correctly, Anders has proposed something for that purpose, and perhaps he has developed some software for that purpose. Right, Anders pointed me to this in private email: http://upi-using-service.webpki.org http://webpki.org/ There are some fundamental issues with this stuff, such as, how does the user know what he's being asked to sign? How does he know that he's not being asked to sign a document conveying the deeds for all his real property to the web site owner? Right. In some countries where digital signatures have the full force of law, just like a real signature, this could be a serious issue. And in other countries, how do we know that it is a sign of intent? I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. Well, my first thought was: this can't work, for all the normal reasons why digital signatures don't work. My second thought was, gee, I need it in a project I'm working on. Oops! Hmmm... I wonder what my third thought will be... Seriously though, I can see lots of applications for it, but the infrastructure required makes this less of a tech concept and more of a legal / document management management concept is missing in most contexts. This is a business problem not a tech problem. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
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. 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... You may be interested (still awake?) knowing that payment operations in brick-and-mortar shops is ultimately the most important application for the suggested scheme. Since this list doesn't really work with payments, I won't bore you to death with how this is supposed to work, but it does! 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.) 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. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. [..] There are some fundamental issues with this stuff, such as, how does the user know what he's being asked to sign? How does he know that he's not being asked to sign a document conveying the deeds for all his real property to the web site owner? In some countries where digital signatures have the full force of law, just like a real signature, this could be a serious issue. Yupp. Glad you already wrote what I wanted to say. When thinking it to the end it even gets more messy than the S/MIME stuff. Especially since web designers and marketeers come into the way when talking about the user interface. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. The German signature law and the accompanying directive tried to protect the user by specifying minimal requirements for the signature process and components used. I guess that's what Anders calls (German nfluences...) monstrosity in his other posting. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. Mozilla implements this with a javascript extension known as crypto.signtext. I think IE implements it with an ocx (an Active-X module). Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? Yes, more or less. There are several approaches in proprietary products. With Netscape's form signing the web application had to generate simple HTML from the form content which was displayed in a separate popup-window. I vaguely remember that the HTML displayer was restricted to avoid white on white or similar faking. The simple HTML blob was then signed (PKCS#7). There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? No. This is a business problem not a tech problem. Exactly! Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? The crypto.signtext() function is given a text string, and the browser UI pops up a dialog box that invites the user to read the text, and then if the users agrees with the content of the text, they are invited to sign the text with their digital certificate. The signed text is then placed into a form field, and is returned to the server on POST. The server can then ask the question is this text the text I wanted signed?, followed by is this text signed by the user using a cert trusted by the CA(s) I have in my hand?. For example, the server generates a piece of human readable text along the lines of: The following claim note has been APPROVED for payment: Claim note: Y / XYZCN / CARGO - Breakage Paid To: Z Date: 01-Sep-2008 Amount: (X) VAT: X Total: (X) If the user agrees with the text, they sign it. If they disagree with the text, they don't. In this particular application, they can sign a new declaration that withdraws a previous declaration, so they can change their mind. The text between the inverted commas represents the complete and only thing the user is agreeing to. If it doesn't appear in the text block, it doesn't get signed. There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? No, this can happen over an insecure http connection. The connection between the browser and server has nothing to do with the crypto.signtext() function. Typically, you would probably want to run it over an https connection, but the point is there is no relationship between the signing of the text and the transport over the network. There is also no relationship between the CA used to trust the server connection, and the CA used to trust the user's signature. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. In law in the jurisdiction in which the application above runs, a digital signature has the same legal weight in law as a paper signature. A checkbox with the words I agree is not a signature. You can define in law a contract which becomes enforceable as soon as somebody performs a specific action. That action might be parking your car in a parking space (and in the process you agree to the terms on the sign at the entrance to the car park, if you disagree, don't park there), or that action might be opening the seal on some packaging (if you open this package you agree to the following software agreement, if you disagree, don't open the package), or that action might be a checkbox saying I agree (if you disgree, don't click on I agree). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
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 bitsbytes 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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: 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? Yes they did. I think you underestimate just how well recognised digital certification is in legal systems around the world. Internet ecommerce is not new, and digital certification is not new to lawyers or the legal system either. 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. Google more. We use the Bouncy Castle libraries to verify the signature on the text, because our system is inherently Java based, but you could use any other crypto library, including NSS. None of this stuff is new, crypto.signtext() has been around for ten years or more, and the crypto libraries that support it, longer than that. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Graham Leggett wrote: Ian G wrote: Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? The crypto.signtext() function is given a text string, and the browser UI pops up a dialog box that invites the user to read the text, and then if the users agrees with the content of the text, they are invited to sign the text with their digital certificate. The signed text is then placed into a form field, and is returned to the server on POST. The server can then ask the question is this text the text I wanted signed?, followed by is this text signed by the user using a cert trusted by the CA(s) I have in my hand?. For example, the server generates a piece of human readable text along the lines of: The following claim note has been APPROVED for payment: Claim note: Y / XYZCN / CARGO - Breakage Paid To: Z Date: 01-Sep-2008 Amount: (X) VAT: X Total: (X) If the user agrees with the text, they sign it. If they disagree with the text, they don't. In this particular application, they can sign a new declaration that withdraws a previous declaration, so they can change their mind. The text between the inverted commas represents the complete and only thing the user is agreeing to. If it doesn't appear in the text block, it doesn't get signed. Thanks for the explanation! There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? No, this can happen over an insecure http connection. The connection between the browser and server has nothing to do with the crypto.signtext() function. Typically, you would probably want to run it over an https connection, but the point is there is no relationship between the signing of the text and the transport over the network. There is also no relationship between the CA used to trust the server connection, and the CA used to trust the user's signature. Wow, that is nice. So the java script is running the crypto access completely separately from the HTTPS stuff? OK, then, how does the browser manage the signed text? Store it somewhere? Verify it somehow? Without some sort of management, I'd worry that the system would not survive scrutiny. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. In law in the jurisdiction in which the application above runs, a digital signature has the same legal weight in law as a paper signature. OK, and is it a technologically neutral law? If so, then a checkbox / agreement will work fine. Or is it the European qualified thing, in which case, we enter a world of pain? Or, even worse, in Germany, where they take the qualified thing seriously, and suffer inordinately. A checkbox with the words I agree is not a signature. A check in a box can be an intent to agree, the check is a mark of agreement, ergo it is a signature, and of course digital. What it is not is a manuscript signature. The differences are subtle, sure, but important. You can define in law a contract which becomes enforceable as soon as somebody performs a specific action. That action might be parking your car in a parking space (and in the process you agree to the terms on the sign at the entrance to the car park, if you disagree, don't park there), or that action might be opening the seal on some packaging (if you open this package you agree to the following software agreement, if you disagree, don't open the package), or that action might be a checkbox saying I agree (if you disgree, don't click on I agree). Right, precisely. Checkboxes can do agreements fine. Whether you need more than that depends on the circumstances, somewhat. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: This requires a client-certificate HTTPS connection to the webserver to make it happen? No, this can happen over an insecure http connection. The connection between the browser and server has nothing to do with the crypto.signtext() function. Typically, you would probably want to run it over an https connection, but the point is there is no relationship between the signing of the text and the transport over the network. There is also no relationship between the CA used to trust the server connection, and the CA used to trust the user's signature. Wow, that is nice. So the java script is running the crypto access completely separately from the HTTPS stuff? Yes. 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. Store it somewhere? Verify it somehow? Nope. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
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. I know, lots of people will sign anything they are asked to sign, and most of them do not suffer, because most people who ask for signatures are not trying to achieve evil ends. But I read every document that I am asked to sign in its entirety, and I would be stunned if a person who is asked to sign a document with a company issued credential would not ask the same. 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. 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. Seriously, it is a business risk. It may also be a personal risk. 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. Anders is correct, you are wrong. I think such statements are supposed to begin with the word Fiat. 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? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote, On 2008-11-20 06:04 PST: Nelson Bolyard wrote: Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? Well, I can only speak for what Mozilla browsers do. They generate a document that contains the signed text and the digital signature and the certificate chain with which the digital signature can be verified (or repudiated), in the CMS format. That document is sent. There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? It's completely independent of https. The browser *may* use the same cert for signing a document as for https client auth, or there may be no https client auth at all (and indeed, no https at all). The signed document can be verified on its own without regard to the channel through which it was sent. It's essentially a little S/MIME message, minus the MIME. :) (SMIME = MIME + CMS) What's missing is the definition of the way (syntax) by which to invoke it in the browser. If I recall correctly, Anders has proposed something for that purpose, and perhaps he has developed some software for that purpose. Right, Anders pointed me to this in private email: I wrote a lengthy response about how/why some proposals get adopted and widely deployed in the web, and others do not, but it's too long for this thread. Maybe I'll send it separately in another thread. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. Where you live, maybe. In other parts of the world, a digital signature is a signature (the strongest form, in fact), and some server's log file claiming that the user checked the checkbox here is worthless. Well, my first thought was: this can't work, for all the normal reasons why digital signatures don't work. My second thought was, gee, I need it in a project I'm working on. Oops! Hmmm... I wonder what my third thought will be... Me too. :) Seriously though, I can see lots of applications for it, but the infrastructure required makes this less of a tech concept and more of a legal / document management management concept is missing in most contexts. This is a business problem not a tech problem. Clearly it is a problem in both spaces simultaneously. Clearly, the ability to produce wonderful signed documents with lots of wonderful properties (effectively unforgeable, alterations are all detectable) is useless if no-one puts them into use (witness both S/MIME and PGP), but by the same token, without the technology to provide some resistance to forgery and alteration, (or even replay/playback), the business world will not take the risk of using technologies that produce documents that are easy to forge, alter or replay (in contexts where documents are of sufficient value that others may be tempted to engage in such things). ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
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 penpaper, 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
