the limits of crypto and authentication

Anne & Lynn Wheeler lynn at garlic.com
Mon Jul 18 12:07:47 EDT 2005


ref:
http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and
authentication

one of the issues raised in the x9.59 business rule case was whether
there are sufficient PANs (account numbers) to be able to temporarily be
able to issue two PANs for every account; one PAN useable against
account in X9.59 transactions and one PAN useable against account in
non-X9.59 (legacy, non-authenticated) transactions.

there was some issues raised about having multiple PANs pointing at the
same account ... but that is in wide-spread use already as normal
business practice.

Note that during any transition to secure x9.59 transaction ... the
worst case scenario is that there would be two PANs in existance for
every account. The issue raised whether the account number space is
large enuf to have two PANs for every account (note that if this turns
out to be a real issue ... it would also be a much larger problem for
one-time-PAN implementations ... where you might have hundreds of PANs
mapped to the same account number).

The problem for an X9.59 transition is actually somewhat less severe.
Part of the current PAN strategy is stacked against re-use of a PAN.
However, in the x9.59 transition case, I would claim that PAN re-use is
much less of a problem

1) re-use of any PAN for x9.59 use .... automatically disables the PAN
for all non-x9.59 use (if the PAN had some lingering legacy attachment
... that woulc be disabled as soon as it was assigned for x9.59 use)

2) re-use of a previously assigned x9.59 PAN for x9.59 use ... could
happen on somewhat accelerated schedule ... since the previous x9.59 PAN
use would have been associated with a public key that was no longer active.

the lingering issue as dangling business process associated with old
transactions that are bound to a specific PAN. re-use of PANs need to
after any such dangling business processes have been assured to have
expired.

the upside is that any transition to x9.59 would then give the consumer
some choice and/or control ... strict use of x9.59 transactions would
give the consumer some protection against most skimming, havesting and
data breach threats and vulnerabilities. such a consumer might then want
any non-x9.59 PANs to have very strict use limits (akin to some of the
customer specified limits available on pin-debit accounts ... or what is
available on dependent cards).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list