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]
