[8983] in cryptography@c2.net mail archive
Re: non-repudiation, was Re: crypto flaw in secure mail standards
daemon@ATHENA.MIT.EDU (Lynn.Wheeler@firstdata.com)
Mon Jul 9 17:42:52 2001
To: EKR <ekr@rtfm.com>
Cc: Greg Broiles <gbroiles@well.com>, jamesd@echeque.com,
James M Galvin <galvin@acm.org>, cryptography@wasabisystems.com,
ansi-epay@lists.commerce.net
From: Lynn.Wheeler@firstdata.com
Date: Sun, 8 Jul 2001 10:39:32 -0700
Message-ID: <OFE087AD78.B4D9B07E-ON88256A83.005FC8FF@fdcsg.1dc.com>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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 <ekr@speedy.rtfm.com>@rtfm.com on 07/07/2001 11:54:44 AM
Please respond to EKR <ekr@rtfm.com>
Sent by: ekr@rtfm.com
To: Lynn Wheeler/CA/FDMS/FDC@FDC
cc: Greg Broiles <gbroiles@well.com>, jamesd@echeque.com, James M Galvin
<galvin@acm.org>, cryptography@wasabisystems.com,
ansi-epay@lists.commerce.net
Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards
Lynn.Wheeler@firstdata.com 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 ekr@rtfm.com]
http://www.rtfm.com/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
