non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn.Wheeler at firstdata.com]

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 at speedy.rtfm.com>@rtfm.com on 07/07/2001 11:54:44 AM

Please respond to EKR <ekr at rtfm.com>

Sent by:  ekr at rtfm.com


To:   Lynn Wheeler/CA/FDMS/FDC at FDC
cc:   Greg Broiles <gbroiles at well.com>, jamesd at echeque.com, James M Galvin
      <galvin at acm.org>, cryptography at wasabisystems.com,
      ansi-epay at lists.commerce.net
Subject:  Re: non-repudiation, was Re: crypto flaw in secure mail standards


Lynn.Wheeler at 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 at rtfm.com]
                http://www.rtfm.com/






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