The basci requirements for this system stem from our use of customer credit cards on our websites.

	* The requirements are simple, the apps need to be able to collect the data.
	* The Business Units need to be able to retrieve and use the data.
	* The data needs to be protected from exposure to unauthorized parties.

There are a few common scenarios for dealing with such data.

	* Just pass the data stright through via email to the appropriate party.
	* Store the data in local files, with an admin cgi to retrieve the data.
	* Store the data in a database, with an admin cgi to retrieve the data.

Before I came to Scripps, that is how it was handled.  Those methods are all bad.  While they protect the data from casual exposure to unauthorizes parties, nearly any successful attempt at cracking any of our webservers would have exposed the data, and anyone with sniffer access to the traffic at any point between the browser and our server, or between our servers and any of the SMTP servers along the email route, or between the business user and their email server, etc could capture the data. 

In 1998 I set our to remdy this situation.  In particular, I added one more requirement to the list above:

	* not only should the data be protected from crackers, but I should be protected from the data.

What I mean by that is that, should a cracker gain access to the data, that no one on our staff should be considered a suspect.  To accomplish this, we created FormHandler.  FormHandler's most important feature was that it used PGP to encrypt credit card data.  Further, it refused forms that contained creditcard data unless that data was submitted via a secured connection.

In order to spur adoption, we added several features that should save the webmasters at the OU's time - specifically, it contained various validation routines for credit cards, etc, was FormMail compatible, could interface with email, local files or databases.

By forcing all credit card data to be encrypted using the public keys for pairs we had not generated, the data was protected from the point it left the customer's browser to the point where User at the Business Unit retrieved it.

This system was successful for a number of years, but has fallen out of favor because of a couple of reasons:

	* employee turnover lack of education of new staff
	* lack of documentation
	* difficulties keeping compatible versions of PGP at the server of busines units, spurred by patent lawsuits, royalty systems, etc.
	* difficulties arising from the fact that only one person can possibly decrypt the data once encrypted - when that person leaves the company or is ill or on vacation, what can you do?

There are two more contemporary approaches to handling this type of data today:

	* symmetrc encryption of data at the web tier method.
	* the ole, "Throw it over the firewall" method in which no data is kept at the web tier.

These are certainly improvements over the old methods, but each suffers from problems again.  Specifically, symmetric encryption at the web tier merely prevents casual exposure of the data.  Since the key for encrypting and decrypting the data is the same, anyone with access to that system will have access to the key needed to decrypt the data.  It should be noted that some systems claim to use asymmetric encryption, but if the encryption and decryption occur on the same box, then obviously the private key is on that box negating the security that asymmeetric encryption would normally provide.

The second system is better, but suffers when the application get more advanced and need to provide information about the data to users over the internet, for instance to third party fullfillent houses.  Certainly, holes can be poked in the firewall for the fullfillment house, but that increases our potential exposure, creates a second tier web infrastructure, and requires that the fullment house have a static IP, or some such technology.

The solution I provide is this CCPKI proposal in which the data is stored at the web tier, but only in an asymmetric manner.  The decryption keys are never exposed to the web tier, but are instead kept either behind the firewalls or at the fullfillment house.  Internally, private keys are managed in such a way to negate the need for synchronizing keys or even versions of PGP between client machines, and the keys can be shared between users with similar roles.

It does not addres issues of non-repudiation, and while all of the private keys are themself encrypted, the key to decrypting them is on the box that is behind the firewall.  However, that box is in a protected environment and is locked down for no other services than decryption.  Further, all access is tied to authenticated and authorized accounts which themselves have individual passwords not stored on the box.  So in short, it is passed an authentication token, a cycpher block and a keypair id.  The box verifies you are who you say, verifies you have access to that keypair, uses the private key to decrypt the cyphertext, and returns the results.  All over an SSL connection.

In this manner, the use of private keys can be shared, but the actual keys never leak to anywhere.