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]

Reply via email to