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

the consumers relying-party-only digital certificate

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. the limits of crypto and

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 ...

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

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: Thin PKI won - You lost Simple PKI Erst-Freedom: Sic
Semper Political Cryptography DNSSEC (RE: Software
for PKI) CFP: PKI research workshop Who's afraid of Mallory Wolf? Maybe It's Snake Oil All the
Way Down SSL, client certs, and MITM
(was WYTM?) What happened with the
session fixation bug? payment system fraud, etc the limits of crypto and
authentication Net banking, is it safe??? E-commerce security???? Symmetric-Key Credit Card
Protocol on Web Site So how does it work...
(public/private key) Cirtificate Authorities 'CAs',
how curruptable are they to New Method for Authenticated
Public Key Exchange without Digital Certificates REVIEW: "Biometrics for Network
Security", Paul Reid More on garbage The Worth of Verisign's Brand

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to