On Fri, 2003-10-17 at 00:58, John S. Denker wrote:
> Tangentially-related point about credentials:
> In a previous thread the point was made that
> anonymous or pseudonymous credentials can only
> say positive things.  That is, I cannot discredit
> you by giving you a discredential.  You'll just
> throw it away.  If I somehow discredit your
> pseudonym, you'll just choose another and start
> over.
> This problem can be alleviated to some extent
> if you can post a fiduciary bond.  Then if you
> do something bad, I can demand compensation from
> the agency that issued your bond.  If this
> happens a lot, they may revoke your bond.  That
> is, you can be discredited by losing a credential.
> This means I can do business with you without
> knowing your name or how to find you.  I just
> need to trust the agency that issued your bond.
> The agency presumably needs to know a lot about
> you, but I don't.

One can claim this is what a credit card does for the consumer .... the
name on the card is somewhat tangential to it being a credential; it is
there so that the merchant can authenticate the credential by cross
checking the name on the card with names on other credentials that you
might be carrying. If you have enuf credentials with the same name ...
then it eventually satisfies the merchant that it is your credential.

Some number of places are taking the name off the card .... as part of
improving consumer privacy at point-of-sale. They can do this with debit
.... where the PIN is a substitution for otherwise proving it is your
credential. however, as previously posted there is a lot of skimming
going an with the information for making a counterfeit card as well as
skarfing up the corresponding PIN is being done.

This is also being done with some kinds of chip cards .... where a PIN
is involved .... but since the infrastructure "trusts" the cards ....
the counterfeit cards are programmed to accept any PIN .... see the "yes
card" at the bottom of the following URL.
The issue is that technique used to skim static data for making
counterfeit magstripe cards also applies to skimming static data for
making counterfeit "yes cards".

The claim in X9.59 is that the signature from something like an asuretee
card ... can both demonstrate two (or three) factor authentication as
well as proving that the transaction hasn't been tampered with since it
was signed.

In this case, while the card may still look like an (offline) credential
from pre-1970s (with printed credential revokation lists mailled out
every month to all merchants) .... it, in fact does an online
transaction. The digital signature proving 2/3 factor authenticaiton
(and no transaction tampering during transit) is then accepted (or not)
by the financial institution which reports back real-time result to the
relying party (merchant).

This is a move from the ancient offline paradigm that has been going on
for hundreds of years (with credentials as substitute for real-time
interaction) to an online paradigm. While the form-factor may still
appear the same as the rapidly becoming obsolete offline credential; it
is actually operating as a long-distance 2/3 factor authentication
mechanism between the consumer and their financial institution .... with
the merchant/relying-party getting back a real-time response as to
whether the institution stands behind the request. 

The difference between the x9.59/asuretee implementation and the "yes
card" implementation is that there is no static data to skim (and use
for creating counterfeit cards/transactions).

misc. x9.59 refs:

misc. aads chip strawman & asuretee refs:

The integrity of the chipcard and the integrity of the digital signature
substitutes for requiring the merchants to cross-check the name on the
card with the names on an arbitrary number of other "credentials" until
they are comfortable performing the transaction. 

The current (non-PIN card) infrastructure is sort of half way between
the old style "everything is a credential" and the new "everything is
onlin"e .... to a fully trusted online infrastructure. The magstripe
does an online transaction and the institution will approve the
transactions with some number of caveats regarding it not being a
counterfeit/fraudulent transaction. For the non-PIN transactions, the
merchant (can) uses the name on the card to cross check with as many
other credential names until the merchant becomes comfortable.

This is similar to the scenario with the existing SSL domain name
certificate issuing process (using names mapping to common/real-world
identities in order to achieve authentication). The domain name system
registers the owner's name. The CA SSL certificate issuer obtains a name
of the certificate requester .... and then the CA attempts to map the
two names into the same real world identities as a means of achieving
authentication. The drastically simpler solution is the domain name
system registers a public key at the same time as registering the domain
name. THen the SSL certificate issuer, instead of having to map real
world identities in order to achieve authentication .... can just use
the registered public key to achieve authentication. The catch22 is that
if the SSL certificate issuer can use the registered public key for
authentication (instead of the much harder problem of trying to map
names into the same real word identities) ... then lots of other
entities can also use the registered public key for authentication ....
significantly decreasing the need for such a SSL certificate.  

The integrity of the chipcard and the integrity of the digital signature
substitutes for requiring the merchants to cross-check the name on the
card with the names on an arbritrary number of other "credentials" until
they are confortable performing the transaction.  

recent threads discussing identification when all that is needed is
http://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security
took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into
a meaning

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

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to