Re: non-repudiation, was Re: crypto flaw in secure mail standards
specific ref. http://www.garlic.com/~lynn/aepay3.htm#sslset1 in a thread with one of the SET people from visa ... they stated that it was not designed to prevent a valid merchant from getting the PAN . in fact, that there are standard credit card businness process that require the merchant to have the PAN and that the PAN was alwas returned to a valid merchant from the payment gateway. I had made the assertion that possibly the SET option could have been overriden ... which would have inhibited the ability of the merchant to perform normal credit card business processing ... and was corrected that it was always designed that the PAN be returned to a valid merchant (and not to inhibit the merchant from being able to execute standard business processes). misc. set references from past discussions http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) http://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on DSTU X9.59 http://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping http://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more) http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 XML, encryption and certificates http://www.garlic.com/~lynn/aepay3.htm#sslset1 SSL SET Query ... from usenet group http://www.garlic.com/~lynn/aepay3.htm#sslset2 SSL SET Query ... from usenet group http://www.garlic.com/~lynn/aepay4.htm#visaset Visa Delicately Gives Hook to SET Standard http://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard http://www.garlic.com/~lynn/aepay4.htm#3dssl VISA 3D-SSL http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption http://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help http://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO! misc. electronic commerce discusions http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Eric Rescorla [EMAIL PROTECTED]@rtfm.com on 07/07/2001 11:54:44 AM Please respond to EKR [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Lynn Wheeler/CA/FDMS/FDC@FDC cc: Greg Broiles [EMAIL PROTECTED], [EMAIL PROTECTED], James M Galvin [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards [EMAIL PROTECTED] writes: one of the biggest problems that has led to most of the regulations is the ease that account-number harvesting can occur and then the account number used in fraudulent, non-authenticated transactions. The SET-like protocols didn't address this issue. How so? In at least one mode, SET denied the merchant the PAN. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: non-repudiation, was Re: crypto flaw in secure mail standards
for a fuller discussion of SSL SET discussion ... set x9a10 mailing list archives http://lists.commerce.net/archives/ansi-epay/199905/maillist.html the above has the postings in reverse cronological order. but, basically the bottom line is that there are a number of merchant credit card business process that require the merchant to have the PAN (or merchant credit card stuff doesn't work). specific posting (from somebody at visa): http://lists.commerce.net/archives/ansi-epay/199905/msg9.html Eric Rescorla [EMAIL PROTECTED]@rtfm.com on 07/07/2001 11:54:44 AM Please respond to EKR [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Lynn Wheeler/CA/FDMS/FDC@FDC cc: Greg Broiles [EMAIL PROTECTED], [EMAIL PROTECTED], James M Galvin [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards [EMAIL PROTECTED] writes: one of the biggest problems that has led to most of the regulations is the ease that account-number harvesting can occur and then the account number used in fraudulent, non-authenticated transactions. The SET-like protocols didn't address this issue. How so? In at least one mode, SET denied the merchant the PAN. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: non-repudiation, was Re: crypto flaw in secure mail standards
true ... but it wasn't standard business practice ... there were all sorts of options ... the issue was what were the standard business practices actually followed. I believe that there is a thread from two years ago on this specific subject ... where somebody associated with SET explicitly stated that the standard business practices were not designed to preclude the merchant from having the PAN. I can look up the discussion if you are interested. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: non-repudiation, was Re: crypto flaw in secure mail standards
one of the biggest problems that has led to most of the regulations is the ease that account-number harvesting can occur and then the account number used in fraudulent, non-authenticated transactions. The SET-like protocols didn't address this issue. However, there is a huge amount of stuff going on about the need for implementing absolute perfect security at the millions of merchant sites scattered all over the world ... where there is an absolute guarentee that at each and every site, harvesting by either external agents and/or internal agents would absolutely never occur. by contrast the X9.59 standard (US ANSI financial standards bodies and pushing forward to international ISO) does address this issue ... where it allows that the probability of absolte security and each and every web-site implemented in the world never fails and that there still won't be fraudulent transactions in association with any kind of (internal or external) account number havesting (aka charter given the X9A10 working group in the definition of X9.59 was to preserve the integrity of the financial infrastructure for all retail, account-based, electronic transactions. The claim also is that X9.59 definition is also identity agnostic and can suppurt EU regulations/guidelines that retail transactions need to not have identity information (i.e. name information embossed on the plastic and recorded on the magstripe). misc. ref: http://www.garlic.com/~lynn/ The X9.59 standard can be obtained from the ANSI publication web site. http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9%2E59%2D2000 [EMAIL PROTECTED] on 7/5/2001 wrote: Implementing non-repudiation as a countermeasure versus spurious do not recognize chargebacks seems to depend on all of the following: (a) development and widespread adoption of a secure platform for key storage and Internet use, like the system whose user interface and underlying technology is such that the signature is unlikely to be forged . . described by James Donald above (b) merchants forcing customers to adopt that platform and SET-like procedures in order to carry out transactions (c) changing the Fair Credit Billing Act to make it more difficult or impossible for consumers to dispute items on their bills. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: non-repudiation, was Re: crypto flaw in secure mail standards
... and the x9.59 solution was designed to be applicable to all account-based, electronic payments not just credit ... but all. much of the regs. are specific to credit (because of the ease that account-number harvesting can lead to fraudulent, non-authenticated transactions) ... while the x9.59 approach can not only be used to address credit but debit as well (one of the other account-based, electronic payments). an example is the completed nacha pilot again refs at http://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: non-repudiation, was Re: crypto flaw in secure mail standards
[EMAIL PROTECTED] writes: one of the biggest problems that has led to most of the regulations is the ease that account-number harvesting can occur and then the account number used in fraudulent, non-authenticated transactions. The SET-like protocols didn't address this issue. How so? In at least one mode, SET denied the merchant the PAN. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
