18.9 MAKING A SECURE CREDIT CARD PAYMENT ON THE WEB

The Secure Socket Layer (SSL) protocol provides rules for a Client (agkonheim@cox.net) to enter into transactions with a Server (www.amazon.com). These two parties have different issues:

  • The Server is concerned about the Client's willingness to pay, but can check the credit-worthiness of a Client with the issuer of the credit card and receive payment before providing any merchandize or service.
  • The Client is concerned about revealing a credit card number to a fictitious Server, the old fake server as seen in Get Smart!

The SSL protocol described in Section 18.7 is modified to accommodate these different viewpoints. The Server is required to produce a certificate, but the Client is not. The Client does not normally require a certificate in credit-card transactions on the Web.

X.509 provided the mechanism for dealing with this environment which.

18.9.1 Certificate Hierarchies

To authenticate the link between a user's ID and public key, the user's certificate must be obtained and checked. The size of the potential community of users requiring certificates necessitates that multiple certificate authorities must exist. X.500 v1 uses the term directory information tree (DIT)6 to describe the “network” of certificate authorities. Three levels are mentioned:

  • Level 1: Internet Policy Registration Authority (IPRA);
  • Level 2: Policy Certification Authorities (PCA);
  • Level 3: Certification Authorities (CA).

A fragment of this tree is shown ...

Get Computer Security and Cryptography now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.