[17372] in cryptography@c2.net mail archive
Re: Digital signatures have a big problem with meaning
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Mon Jun 6 21:41:10 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 06 Jun 2005 15:48:14 -0600
From: Anne & Lynn Wheeler <lynn@garlic.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: cryptography@metzdowd.com, dan@geer.org, rsalz@datapower.com
In-Reply-To: <E1DeCzy-00023L-00@medusa01.cs.auckland.ac.nz>
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@metzdowd.com
