The Internet Encyclopedia (Volume 3)

P1: JDV

Merkow WL040/Bidgolio-Vol I WL040-Sample.cls June 20, 2003 12:46 Char Count= 0

SET APPEARS ON THEMARKET 253

Table 1Certificate Types Summary

Certificate and CRL

Certificate Types Digital Signature Key Encryption Signing

Cardholder X

Merchant X X

Payment Gateway X X

Cardholder Certificate X X X

Authority

Merchant Certificate X X X

Authority

Payment Gateway Certificate X X X

Authority

Brand Geo-Political X X

Certificate Authority

Brand Certificate Authority X

Root Certificate Authority X

Digital certificates can aid in the effort to keep private

keys secure while aiding in the dissemination of the re-

lated public keys (which together form the key pair). If

a private key is disclosed (either by cryptanalysis or by

theft), that fact needs to be shared so that the recipients

of messages signed with the stolen key know to reject or

disregard them. The mechanism that X.509 dictates and

SET uses to determine if a private key has been compro-

mised and reported is called the Certificate Revocation

List, or CRL.

SET digital certificates attest to the binding of an end

entity’s public key to the end entity itself. Suppose Charles

presents his payment instructions using his Visa Platinum

Card from Bank A. When a merchant receives his message

and subsequently forwards it for processing, both the mer-

chant and the payment gateway can verify Charles’ claim

that the message and the certificate are his and no one

else’s. Because the private key tied to the Visa brand cer-

tificate was used to sign Charles’ credit-card-based certifi-

cate, and Charles’ message can only be decrypted using

Charles’ public key from the certificate, two things must be

true; the message must have come from Charles, and upon

successful certificate validation within the Visa brand tree

of trust, the certificate must have been signed by the Visa

brand certificate and no other.

In their basic forms, digital certificates contain the

private-key holder’s public key (half of the keypair), his or

her name, the certificate’s expiration date, a serial number,

the name of the authority that issued the certificate, the

policies under which certificate use is permissible, and

any other information the issuer deems vital or useful.

Most important, it contains the digital signature of the

issuer. SET Certificates follow the ITU Recommendation

X.509 for Version 3 certificates.

Summary of Certificate Types

SET’s public key certificate hierarchy, or tree of trust, is

an arrangement of certificate authorities (CAs) that im-

plements the needs of each SET participant brand (Visa,

Mastercard, etc.). These CAs hang off a root CA, operated

by SETCo, which operates as SET’s managing authority.

The possible certificate types that may be present in the

tree are summarized in Table 1.

SET APPEARS ON THE MARKET

With the release of Version 0.2 in 1997, developers be-

gan exploring how SET might be developed as a suite

of products that covered the entire span of relationships

mandated by SET. By 1998, new SET-compliant products

appeared, such as the following:

Cardholder E-wallets

Integrated SET merchant POS systems and e-commerce

systems

Payment gateway software for acquiring banks and card

processors

Cardholder E-wallets

The first e-wallets appearing on the scene as SET-

compliant immediately created an untenable situation for

banks and cardholders. Banks do not tend to be very good

at distributing software and software updates to millions

of users. This fact, coupled with consumer skepticism

of e-commerce as it existed in 1997 and the size of e-

wallet download files, which ran up to 10MB downloaded

over dial-up connections, led to downright uninterest and

anger from cardholders.

Merchant POS Servers

The first suites of products intended to satisfy merchant

requirements for SET could only be touched by those with

the greatest patience and deepest pockets. Implementa-

tion would mean tens or hundreds of thousands of dollars

in new hardware and software purchases in order to meet

the stringent requirements for security. Banks did little to

offer incentives to merchants to build SET compatibility

into e-commerce, and at the same time, SSL-based secu-

rity of credit card data over the Internet was thoughtgood

enough. Merchant uninterest in SET soon followed.