Anne & Lynn Wheeler wrote: > But SET Lite and MOSET critically alter the SET 1.0 architecture and > soften SET's rock-hard security - all for the sake of convenience. For > example, the technologies abandon the idea that each online consumer is > going to have a bank-issued SET digital certificate for credit-card > encryption. This certificate was to be the main means of verifying the > consumer's real identity on the Internet.
note that the bank-issued consumer SET digital certificate ... wasn't used for credit-card encryption. the original set had this terribly convoluted process where the consumer encrypted some of the stuff with the *merchants* public key and other stuff with the *processors* public key. the consumers relying-party-only digital certificate http://www.garlic.com/~lynn/subpubkey.html#rpo was used for the client to perform "something you have" authentication ... aka digitally signing with the corresponding private key (aka the verification of the digital signature implies that the signer has access and use of the private key) since it wasn't an x.509 identity certificate, didn't contain any personal information, and was purely a relying-party-only certificate ... there was no real identity on the internet (avoiding raising horrible privacy and liability issues). futhermore, since it was a simple relying-party-only certificate, it is trivial to demonstrate that it is redundant and superfluos ... aka just flow the transaction thru to the consumer's bank ... and they can validate the digital signature using the onfile public key. it isn't necessary for the consumer to repeatedly append a relying-party-only certificate to possibly thousands of transactions ... for transmission back to the issuing institution ... which has the original *onfile*; especially when the redundant and superfluous relying-party-only certificate can represent a payload bloat of one hundred times. note that the referenced article is dated 1999/3/22 and references the original SET 1.0 deployment (full blown redundant and superfluous relying-party-only customer certificates) two years earlier (spring 1997). The draft 1.0 specification had appeared spring 1996, initial prototype appeared early fall 1996, and dedicaed demo systems showed up at floor shows by the end of 1996. the other reference indicates that browsers with ssl support appeared late 1994 with big announcement the spring of 1995. http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and authentication a trivial side-note ... since the SET specification wasn't issued by a sanction standards body ... it wasn't a Standard in the official sense. one of the operational differences between SET and x9.59 financial industry standard ... http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy is that x9.59 has an operational rule that account numbers used in x9.59 transactions can't be valid in non-x9.59 transactions .... which eliminates the requirement for horrendous amounts of cryptography as countermeasure for evesdropping of transactions during transmission (since evesdropping of the transactions doesn't provide an attacker with sufficient information to perform fraudulent transactions). As a by-product, it also eliminates the threats and vulnerabilities from data-breaches ... where there is sufficient information in logged transactions for a crook to perform fraudulent transactions. In the SET scenario ... even when the transaction is authenticated using digital signature ... there was still a requirement for horribly complex cryptographic implementation as countermeasure to attacker evesdropping the transaction and using the gained information to perform fraudulent transactions. There is an issue where both account fraud and identity fraud have been lumped under global identity theft label. In the strict account fraud case, the attacker just needs to obtain sufficient information to perform fraudulent transactions (against existing accounts) w/o necessarily obtaining any real personal information. While SET avoided the horrible privacy and liability issues with real x.509 identity certificates by using relying-party-only certificates ... it was still subject to account fraud where crooks obtaining access to information from transaction (either *data-in-flight* or *data-at-rest* .... aka data breaches) have access to sufficient information for performing fraudulent transactions. In contrast, x9.59 is signifcantly simpler and represents significantly lighter payload ... and even eliminates the need to provide security confidentiality for transactions as countermeasure against attackers (both in the *data-in-flight* as well as the *data-at-rest* cases) looking at performing account fraud transactions. past posts mentioning x9.59 & business rules: http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#cfppki11 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf? http://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?) http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug? http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe??? http://www.garlic.com/~lynn/2001j.html#0 E-commerce security???? http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site http://www.garlic.com/~lynn/2002n.html#14 So how does it work... (public/private key) http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network Security", Paul Reid http://www.garlic.com/~lynn/2005k.html#26 More on garbage http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]