Posted by arlene

Assuming your certificate makes it through the entire period of time it is valid without the need for revocation, you will need to renew it. The good news is that, just like at the DMV, you do not have to prove your identity again to get a new certificate. As long as the certificate is in good standing, and you are renewing the certificate with the same CA, you can use the old key to sign the request for the renewed certificate. The reason behind this is that since the CA trusts you based on your current credentials, there is no reason why they should not trust your request for a renewed certificate. There is a second method of renewal, called key update, where a new key is created by modifying the existing key. The key renewal process that is used will depend on the user and most likely the requirements of the CA.

The renewal process is also true of a CA’s key pair. Eventually, a CA will need to renew its own set of keys. Again, a CA can use its old key to sign the new key. As discussed earlier, a root CA signs its own keys. Since end users (and subordinate CAs) use the root CA’s keys to validate the responses from the CA, there must be a procedure in place to notify end users that the CA’s key is up for renewal. The CA renewal process is performed by creating three new certificates:

1. The CA creates another self-signed certificate. This time, the CA signs the new public key using the old private key that is about to retire. This allows for relying parties to trust the new key on the basis that it is signed by the old key

2. Next, the CA server signs the old public keys with the new private key. This is done so that there is an overlap between when the new key comes online and when the old key expires; users who trust the new key will also trust certificates issued under the old key

3. Finally, the new public key is signed with the new private key. This will be the new key that will be used after the old key expires.

The reason for this process is two-fold. First, since a CA verifies the credentials of other parties, there has to be a degree of difficulty to renewing the CA’s own certificate. Second, creating all of these keys makes the changeover from old keys to new keys transparent to the end user.

Public Key Destruction

As we saw during the dot-com bust, there comes a time for some companies when they no longer need their key pairs. When the famous chocolate-covered cockroach Web site, www.chocolatecrunchies.com, went out of business, they most likely had a certificate issued to them for their online store. To get rid of some capital, they sold off some of their Web servers without clearing the data off of them. On those Web servers were copies of Chocolate Crunchies‘ public and private keys. No a hacker buys a server off of the company and now has possession of their keys. The hacker can now potentially impersonate Chocolate Crunchies by using their key pair.

The point is, when there is no longer a need for a key pair, all record of the key pair should be destroyed. Before a server is sold, the media needs to be erased and overwritten so that there cannot be recovery of the keys. Paper copies of the keys also need to be properly disposed of. Not only should the keys be destroyed, the CA must be notified that Chocolate Crunchies has gone out of business, and the certificate should be deregistered.

Public Key Key Usage

In today’s networking environment, key pairs are used in a variety of different functions. This discusses topics such as virtual private network (VPN), digital signatures, access control (SSH), secure Web access (Secure Sockets Layer [SSL]), and secure e-mail (PGP, S/MIME). Each of these topics implements PKI for managing communications between a host and a client. In most PKI implementations, only single key pairs are used. However, certain situations may be presented where you have to offer users multiple key pairs.

Public Key Multiple Key Pairs (Single, Dual)

Sometimes it becomes necessary for a CA to generate multiple key pairs. Normally, this situation arises when there is a need to back up private keys, but the fear of a forged digital signature exists. For example, consider Joe the backup operator. Joe is responsible for the backup of all data, including user’s private keys. Joe comes in after a long weekend and decides that he deserves a raise. Since Joe has access to all of the private keys, he can recover the CIO’s private key, send a message to the Human Resources department requesting a raise, and sign in using the CIO’s certificate. Since the CIO’s digital signature provides non-repudiation, the Human Resources manager would have no reason to question the e-mail.

To circumvent this problem, many PKIs support the use of dual keys. In the example above, the CIO has two separate key pairs.The first key pair is used for authentication or encryption, while the second key pair is used for digital signatures. The private key used for authentication and encryption can still be backed up (and therefore recovered) by Joe for safekeeping. However, the second private key would never be backed up and would not provide the security loophole that using single keys creates. The CIO could continue using his second private key for signing e-mails without fear of the key being misused.

Possibly related posts: (automatically generated)
Public Key Renewal

• Web Technology & Ecommerce Online Solutions
• Ecommerce revolution, Online Marketing
• Public-key Certificates and Certificate Authorities
• Electronic Commerce Payment Concern
• PKI (public key infrastructure) Management and Certificate Lifecycle
• The New Rules of the Online Renaissance
• Email Marketing
• IT Consulting New York
• New Rules of Engagement
• Ten Essential E-merchandising Techniques