Re: Digital signatures have a big problem with meaning
Rich Salz [EMAIL PROTECTED] writes: Peter's shared earlier drafts with me, and we've exchanged email about this. The only complaint that has a factual basis is this: I don't want to have to implement XML processing to do XML Digital Signatures I don't want to have to re-implement Apache in order to do an SSL implementation. I don't want to have to re-implement MS Exchange in order to do a PGP implementation. I don't want to have to re-implement ext2fs in order to encrypt a file. Makes sense to me. The other problem with XML sigs (also pointed out in the writeup) is the fact that it gives you 10 ways to do everything, of which only 1 is actually correct/secure/usable, but is indistinguishable from the other 9. Since ease of use/secure-by-default is a major goal of my work, I'm rather reluctant to implement something that lets users blow their feet off in a dozen different ways without even knowing it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
I don't want to have to re-implement Apache in order to do an SSL implementation. ... Those analogies aren't apt. XML is a data format, so it's more like I don't want to have to implement ASN1/DER to do S/MIME Which is a nonsensical complaint. Makes sense to me. The other problem with XML sigs (also pointed out in the writeup) is the fact that it gives you 10 ways to do everything, of which only 1 is actually correct/secure/usable, but is indistinguishable from the other 9. I don't see it. Yes, XML DSIG makes it possible to sign parts of an XML document. And there are broken applications. Er, so what? Is the lack of certificate validation in outlook proof that S/MIME is broken? reluctant to implement something that lets users blow their feet off in a dozen different ways without even knowing it. So have your API take an XML document and output a signature that signs the exclusive canonicalization of that document, and includes the signer's certificate in the keydata. Problem solved. And that's a fair comparison, since S/MIME is just a profile of PKCS#7 applied to email, right? So use WS-Security which is a profile of XML DSIG applied to SOAP messages, for example. In other postings, you've pointed out that nobody re-generates the DER, but instead keeps it around to verify the signature. In the XML world we do it all the time; recreating and re-canonicalizing works. I guess that proves S/MIME and PGP are fundamentally broken. :) /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Ben Laurie [EMAIL PROTECTED] writes: Anne Lynn Wheeler wrote: Peter Gutmann wrote: That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. this was one of the big issues in the asn.1 encoding vis-a-vis xml encoding wars. asn.1 encoding provided deterministic encoding for signed material, You mean it _would_ have done if anyone could implement it correctly. Sadly, experience shows that no-one can. Right, but that's lead to a de-facto encoding rule of The originator encodes it however they like, and everyone else re-encodes it (if required) using memcpy(). The advantage of the format is that it's never tried to be anything other than a pure binary-only format, so moving it over text-only channels is handled at the next layer down (usually base64), rather than trying to make the encoding itself text-only-capable and then finding yourself in a world of pain when half the systems the stuff passes through mangle the text. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Peter Gutmann wrote: Yup, see Why XML Security is Broken, http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt, for more on this. Peter's shared earlier drafts with me, and we've exchanged email about this. The only complaint that has a factual basis is this: I don't want to have to implement XML processing to do XML Digital Signatures The others are just blowing smoke, or proof by snarkiness. :) /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Ian G wrote: On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote: Ian G writes: | In the end, the digital signature was just crypto | candy... On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. Yes, indeed! The thing about a signature is that *it* itself - the mark on paper or the digital result of some formula - isn't the essence of signing. The essence of the process is something that lawyers call intent (I'm definately not clear on these words so if there are any real lawyers in the house...). And, when the dispute comes to court, the process is not one of proving the signature but of showing intent. Perhaps this is a good moment to remind people of my paper Signatures: an Interface between Law and Technology (written with Nicholas Bohm, a lawyer) which discusses this and other issues. http://www.apache-ssl.org/tech-legal.pdf Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Anne Lynn Wheeler wrote: Peter Gutmann wrote: That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. this was one of the big issues in the asn.1 encoding vis-a-vis xml encoding wars. asn.1 encoding provided deterministic encoding for signed material, You mean it _would_ have done if anyone could implement it correctly. Sadly, experience shows that no-one can. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Peter Gutmann wrote: Yup, see Why XML Security is Broken, http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt, for more on this. Mind you ASN.1 is little better, there are rules for deterministic encoding, but so many things get them wrong that experience has shown the only safe way to handle it is to do an exact bit-for-bit copy from A to B, rather than trying to re-code at any point. I've frequently commented that there is only one workable rule for encoding objects like X.500 DNs, and that's memcpy(). there was another issue with digital signatures supposedly acquiring attributes of human signatures aka implication that human had actually read, understood, approves, agrees, and/or authorizes the content ... as well as intent. so at least some financial institutions in the mid-90s were realizing that x.509 identity certificate ... potentially overloaded with enormous amounts of personal information, represented significant liability and privacy concerns ... were looked at switching to relying party only certificates ... basically containing some sort of database record locator (where all the real information was located) and a public key. however, it was trivial to demonstrate that such certificates were redundant and superfluous. http://www.garlic.com/~lynn/subpubkey.html#rpo there was another issue involving the typical 4k-12k byte size of such certificates ... when appended to a typical payment transaction of 60-80 bytes ... besides being redundant and superfluous ... also would represent horrendous payload bloat. now the certificate crazed periods of the 90s also had something called the certificate non-repudiation bit ... which large segments of the market was interpreting as meaning that digital signatures with appended certificates containing the non-repudiation bit ... couldn't be repudiated by the person making the digital signature. in the retail payments scenario ... the task was to convince consumers to pay $100/annum for redundant and superfluous, payload bloating relying party only certificates with the non-repudiation bit set. supposedly the scenario being sold retail merchant industry was that while the current retail payment environment had the burden of proof (in any consumer dispute) placed on the merchant ... if the consumer would be so kind to append an redundant and superfluous, enormous payload bloating certificate with the non-repudiation bit set ... the burden of proof in a dispute would be shifted from the merchant to the consumer. there was some hypothetical investigation that even if the consumer did digitally sign a retail payment transaction and appended a redundant and supefluous, payload bloating relying party only certificate ... w/o the non-repudiation bit set that merchants could possibly substitute a similar certificate which did have the non-repudiation bit turned on ... possibly harvested from some convenient, cooperating LDAP trusted certificate repository. besides all the other practical and legal issues about digital signatures being interpreted as simply something you have authentication ... from 3-factor authentication model http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are and NOT as human signature implying intent, read, understood, agree, approve, and/or authorize ... there was the issue that the non-repudiation bit within a certificate was supposedly creating liability on behalf of the digital signer ... however the PKI protocols contained no provision for proving what specific certificate the person applying a digital signature had actually appended to any specific transaction ... aka the digital signature was only on the transaction itself ... and there was no digital signature armoring/binding which digital certificate might actually have been originally appended to any specific digitally signed transaction (possibly allowing merchants to substitute non-repudiation certificates when none had been intended). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Rich Salz [EMAIL PROTECTED] writes: I think signatures are increasingly being used for technical reasons, not legal. That is, sign and verify just to prove that all the layers of middleware and Internet and general bugaboos didn't screw with it. That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Peter Gutmann wrote: That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. this was one of the big issues in the asn.1 encoding vis-a-vis xml encoding wars. asn.1 encoding provided deterministic encoding for signed material, although some of the more common applications of digital signature have what is transmitted is the original encoded material along with the signature of that encoded material. fstc/e-check project wanted to digital sign stuff that was xml encoded ... but not transmit the xml encoded fields. they wanted to take standard financial transaction fields ... momentarily xml encode the standard fields, digitally sign the encoded material ... and then append the resulting digital signature to the (original) standard transaction for transmission. the problem was that xml didn't have a deterministic definition for encoding fields. when the recipient/relying party received the transmission ... they had to take the standard transaction fields and re-encode in xml in order to verifiy the digital signature. fstc/e-check came up with fsml for deterministic encoding of fields ... so that the encoding done by the originator (of the digital signature) and the encoding done by the relying party (for verifying the digital signature) would have identical bit patterns. fsml was subsequently contributed to the xml digital signature project. xml is descendent of gml invented by G, M, and L in 1969 at the science center http://www.garlic.com/~lynn/subtopic.html#545tech and then standardized at ISO in the 70s http://www.garlic.com/~lynn/subtopic.html#sgml - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Anne Lynn Wheeler [EMAIL PROTECTED] writes: the problem was that xml didn't have a deterministic definition for encoding fields. Yup, see Why XML Security is Broken, http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt, for more on this. Mind you ASN.1 is little better, there are rules for deterministic encoding, but so many things get them wrong that experience has shown the only safe way to handle it is to do an exact bit-for-bit copy from A to B, rather than trying to re-code at any point. I've frequently commented that there is only one workable rule for encoding objects like X.500 DNs, and that's memcpy(). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. Even mere hash checks are turning up obscure data corruptions. Some people reported that BitTorrent would never finish certain files, getting to 99.9% and stalling. The problem is that their NAT box was replacing its external IP address with its internal address -- anywhere in a packet. This is called Game mode in some NAT boxes. Their router was corrupting random binary data (and altering the TCP, UDP, and Ethernet packet checksums!). They never noticed until BitTorrent used end-to-end application-level SHA1 hash checks and retransmission to detect and correct it. http://azureus.aelitis.com/wiki/index.php/NinetyNine John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote: Ian G writes: | In the end, the digital signature was just crypto | candy... On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. Yes, indeed! The thing about a signature is that *it* itself - the mark on paper or the digital result of some formula - isn't the essence of signing. The essence of the process is something that lawyers call intent (I'm definately not clear on these words so if there are any real lawyers in the house...). And, when the dispute comes to court, the process is not one of proving the signature but of showing intent. And as the transaction gets bigger, the process of making and showing intent gets more involved, more complex. So it is naturally ramped up to the transaction, in a way that digsigs just totally miss out on. Which means that the digital signature school got it completely wrong. A digital signature is only just one more element in a process that is quite complex, involved, and goes back into history more years than we can count. It is therefore completely unlikely that a digsig will ever replace all that; however it is quite possible that a digsig could comfortably add a new element to that process. (Speaking here of common law, which is not universally applicable...) And, of course, proving anything by way of dueling experts doesn't provide much predictability in a jury system, e.g., OJ Simpson. And this is where we found for example the OpenPGP cleartext digital signature to be the only one that has any merit. Because it can be printed on paper, and that piece of paper can be presented to the jury of an O.J.Simpson style case, or even a Homer Simpson style case, this carries weight. An OpenPGP clear text signature carries weight because it is there, in black and white, and no side would dare to deny that because they know it would be a simple matter to go to the next level. But any other form of non-printable digital signature is not presentable to a jury. What are you going to do? Throw a number in front of a jury and say its a signature on another number? It's a mental leap of orders of magnitude more effort, and there are many ways the other side could sidestep that. iang PS: To get this in x.509, we coded up cleartext sigs into the x.509 format. -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
[EMAIL PROTECTED] wrote: On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. And, of course, proving anything by way of dueling experts doesn't provide much predictability in a jury system, e.g., OJ Simpson. the bigger the transaction that the digital signature verifies the more the relying party is going to be interested in fundamental integrity issues surrounding the digital signature generation from 3-factor authentication paradigm * something you have * something you know * something you are simple digital signature verification is basically something you have authentication ... implying that the originator has access to and use of the corresponding private key (in addition to the transaction not having been modified in transit). fundamental issues surrounding digital signature can be the integrity level of the infrastructure preventing compromise of the private key aka is the private key protected in a software file, is the private key in a hardware token, was the private key generated in a hardware token and can never leave the hardare token. also if it is a hardware token, is a pin/password also required to make the token operate correctly i.e. knowing characteristics of the hardware token, the relying party might be able to infer two-factor authentication and assess the risk/threats involved. also what is the integrity level of the infrastructure in which the digital signature was generated ... for instance some of the EU finread standard http://www.garlic.com/~lynn/subpubkey.html#finread which try and specify the minimum constraints for generation of a digital signature on a financial transaction. this isn't so much proving anything ... this is risk management ... what is the likelyhood/exposure of a compromise for the relying party ... or security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 standard types of things that you would find at financial institutions and/or insurance institutions. part of the confusion possibly is because of the extensive deployment of PKI literature ... which tends to focus the attention on the certification process ... as opposed to the integrity of the authentication process. the issue is that for the majority of business operations ... the PKI certificate process tends to be duplication of extensive relationship management business process that they already have in use (and therefor is redundant and superfluous) ... and there is much less focus on the basic risk, threat and vulnerability issues related directly to the authentcation. and as i've frequently postulated ... that same may have an interest in creating semantic confusion ... implying that because the term digital signature includes the word signature ... that it somehow bears some relationship to human signatures. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. I think signatures are increasingly being used for technical reasons, not legal. That is, sign and verify just to prove that all the layers of middleware and Internet and general bugaboos didn't screw with it. People seem to be building systems that assume proper operation, and use signatures as an application-level way to check, and also as a line of defense to screen out outsiders, rather than hold insiders liable. Loosly coupled, tightly contracted. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Ian G writes: | | In the end, the digital signature was just crypto | candy... | On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. And, of course, proving anything by way of dueling experts doesn't provide much predictability in a jury system, e.g., OJ Simpson. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
