Digital signatures have a big problem with meaning

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com