9622Re: [soapbuilders] Re: Super-Encryption AND Digital Signatures
- Dec 3, 2003
> You are correct, but sender-2-recipient is secured AFAIK, e.g., using SSL toSince VISA is liable for any fraud if they publish your ccard number,
> send credit card info to a processor doesn't guarantee the processor isn't
> publishing the information to a chat room, but you inherently trust that VISA
> isn't doing that. Only the sender and the intended recipient can see/decrypt
> the information. Right!?!
there is strong incentive for them to not do that kind of thing.
Similarly, there are strict rules and penalties for disclosure of
personal information. Now, SET was worried about this, and they made
sure that things were encrypted every-which-way, so that, e.g., the
Merchant never saw your CCard number, but passed it along to the
CreditCard clearinghouse, who *could* see the number, but couldn't see
some merchant info, etc. etc. It all turned out to be too heavyweight,
and the existing legal framework (plus incentives from the CCard
companies to merchants) was enough to support "just use SSL."
Anyhow, when I posted the weakness I said it's something you *might*
care about. As long as the sender is is not concerned about the
possibility of receiver fraud (even if the receive has been compromised
by an adversary), than it doesn't matter. Whether or not that is an
issue depends on the application. But it certainly makes the technique
inapplicable for widepsread general use.
> This is a good discussion.Yup. Hope we're not boring everyone else. :)
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
- << Previous post in topic Next post in topic >>