Lynn,
You are right but the financial institutions now try to leverage
their position as trusted third parties for things outside of
their payment territory. It is hard to see that e-governments
can be realized without a generic ID without huge costs
and user inconvenience. As I have said numerous times
before in this list:
ID <> Payments
But I would also like to mention my addendum
ID >> Payments
That is, a functional ID can in an on-line world replace the need
for most other resources as you by using an ID towards resource
providers "can be whatever you need to be, or have what you
need to have".
To combine ID and Payment cards though opens a can of worms.
If the consumer uses the same PIN for all functions a rogue relying
party app can technically perform advanced "phishing" in the
background while you are paying. Most people don't like
multiple PIN-codes. I'm one :-)
Anders
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Anders Rundgren" <[EMAIL PROTECTED]>
Cc: "'internet-payments'" <[EMAIL PROTECTED]>; "Pekka Honkanen" <[EMAIL PROTECTED]>
Sent: Monday, March 15, 2004 07:12
Subject: Re: A combined EMV and ID card
that was one of the issues that financial institutions and others
discovered ten years about the x.509 identity certificate concept ... the
horrendous leakage of privacy information. it was one of the reasons that
financial institutions tried relying-party-only certificates in the mid-90s
that was restricted to only containing an account number (in part because
of the horrible privacy information leakage).
at least one of the scenarios involved relying-party-only certificate
appended to a digitally signed credit/debit payment transaction. This in
itself created an enormous difficulty resulting in various kinds of extreme
rub golberg designs. the issue was that a typical 8583 financial
transactions as on the oder of 60-80 bytes, ignoring for the moment the
size of an appended digital signature .... the problem was that even a
relying-party-only certificate could be 6k-12kbytes in size. Using
elementary, standard security principles and following standard end-to-end
security and integrity policies .... aka digitally signed message with
appended relying-party-only certificate flowing from consumer
straight-through to the consumer's issuing financial institution resulted
in a 100 times bloat in the message size
aka 60-80 byte message would have a tremendous horrible bloat to one
hundred times larges ( aka typically message of 60 bytes times 100 becomes
six thousand bytes to twelve thousand bytes).
this is one of the places that originated my observation about a
relying-party-only certificate being redundant and superfluous (in addition
to truely horrible size bloat). The useful information in the 12kbyte
relying-party-only certificate is the user's public key and the account
number. Since the account number is also contained in the 8583 transaction,
it is redundant and superfluous to have it in the certificate. Since it is
a relying-party-only certificate, the user's public key is registered in
the institutions account record for that user. When the 8583 transaction
reaches the institution, they can retrieve the public key from the account
record based on the account number in the 8583 transaction to verify the
digital signature. That makes the public key in the relying-party-only
certificate redundant and superfluous. With the only two pieces of useful
information in the relying-party-only certificate shown to be redundant and
superfluous, then the certificate itself is shown to be redundant and
superfluous.
Rather than coming up with a rube goldberg design corrupting elementary,
basic end-to-end security and integrity principles in support of one
hundreds times bloat in message size (attempt to preserve the appending a
redundant and superfluous certificate) .... just eleminate the redundant
and superfluous certificate altogether.
misc. past postings on the subject:
http://www.garlic.com/~lynn/subpubkey.html#privacy
as an aside ... somewhat in support of work on X9 PIA standard ... I've
started a privacy glossary and taxonomy .... complimenting the other
glossaries and taxonomies at:
http://www.garlic.com/~lynn/index.html#glosnote
[EMAIL PROTECTED] on 3/14/2004 12:13 pm wrote
Thanx Pekka,
A slightly disturbing "side effect" of mixing accounts
and IDs using the Finish and Swedish schemes, is that
each time you perform a payment, the POS terminal
can without any PIN-codes etc, also read the user's ID-
certificates (public keys), effectively "leaking" identity
information to parties that should not necessarily have
such information.
Anders
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
