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 [EMAIL PROTECTED]