Re: PGP Lame question

Unruh <unruh-spam@physics.ubc.ca> writes:
> He has a signed confession anyway even if she signed afterwards. He
> gives the press a) the signed encrypted email. and b) the session
> key to unencrypt the message. This is the session key, which is a
> non-reused random number so does NOT reveal any of his own
> secrets. The press can then decrypt the email and since it is signed
> they have her "signed confession".

so there has been this thing for various payment protocols ... being
able to sign anonymously to demonstrate that it was a valid coin
... but not tell who signed it.

this is also one of the issues in some EU standards. at one point EU
made the statement (in the spirit of EU data privacy directive) that
all point-of-sale, retail electronic payments should be as anonymous
as cash ... but at the same time, dictating that all digitally signed
transactions are required to have an appended x.509 identity
certificate. in x9.59, it is possible to have a digitally signed
transaction, a public key on file at the consumer's financial
institution, and no requirement for appending x.509 identity
certificates on every point-of-sale, retail transactions.
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

one could imagine that the conflicting eu direction of privacy
everywhere and x.509 identity certificates for everything digitally
signed would resolve it by forbidding retail point-of-sale
transactions to be implemented with digital signatures (w/o having to
qualify/modify any past directions).

in contrast, x9.59 standard just claims to be privacy agnostic ... the
financial transaction is bound to an account ... leaving no direct
identity information laying around at retail, point-of-sale. to the
extent any identification may exist at all is whether or not anonymous
accounts are allowed.

in some sense, public key authentication for domain names is what has
broken the ssl domain name trust model. the enduser/client was suppose
to provide the url/domainname ... and the server was suppose to
authenticate with a digital signature and a valid digital certificate
for that domain name. as URLs are pushed into the infrastructure ...
away from direct enduser awareness, the attackers provide both the URL
and the certificate ... and assert some binding to some construct the
enduser does know about. the public key and certificate only provides
the binding to the URL .... and nothing is left proving any binding
between the URL and any external construct that the enduser is aware
of (somehat analogous to proving that gold is valuable and then
asserting what i'm giving you is gold ... and therefor what you are
getting is valuable; w/o having to prove what you received was
actually gold).

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/