The Certificate Authority (CA) is the entity that manages the digital certificates that are used in authenticating other entities. The Certificate Authority will create a public/private key pair when a certificate is requested by any entity that wishes to be "verified" by that authority. The CA will then give the private key credential to the entity wishing to be verified. The public key is then stored by the CA and made available to everyone. This allows any other entity to validate their credentials.
For example, Alice wishes to buy a T-shirt from e-Liberty.org. Alice obtains e-Liberty.org's public key, encrypts her order with it, and sends the order to e-Liberty.org. e-Liberty.org would receive the message and validate Alice's public key with the CA. If the CA authenticates Alice's public key, e-Liberty.org will decrypt the message and process the order.
In some situations a Registration Authority is used to verify user requests for a digital certificate and determine if the CA should issue a certificate. The RA does not sign or issue the certificate, it merely helps lessen the burden imposed on the CA. The RA can be thought of as a proxy between each entity and the CA.
The digital certificate used under PKI is developed out of the X.509 standard which is used to create unique identifiers that can be associated with individuals or companies. The X.509 standard assocaites the Distinguished Name with the corresponding public key. The Distinguished Name is allocated to each user by the Naming Authority. The Distinguished name is then used by the Certificate Authority as the Unique Name that is associated with the issued certificate.
To easily view the layout of a certificate, simply go to a site that uses encryption and right click on the lock that appears in the navigation bar. Select "view certificate" and viola, all of the certificate information appears. Here are some common things found in digital certificates:
- Subject Name - Who the certificate is issued to, possibly includes state, region, or country.
- Issuer Name - Who issued the certificate and their location
- Serial Number - A unique number that identifies the Issuer
- Signature Algorithm - The type of algorithm that was used to create the signature, such as MD5.
- Not Valid Before - The date the certificate becomes valid
- Not Valid After - The date that the certificate expires
- Public Key Algorithm - The type of algorithm used to create the public key
- Public Key - The string of characters that makes up the public key
- Signature - The string of characters that makes up the signature
- Certificate Policy - Object Identifier that denotes what the purpose of the certificate is and how it is used. Sometimes multiple policies will exist for each certificate.
Under the X.509 standards each Certificate Authority is responsible for publishing a Certificate Revocation List. This list will be comprised of all of the certificates that they have revoked. However, it does not include certificates that have simply expired. These certificates were simply not renewed, and could still be considered safe. However, one should carefully consider sending confidential information to a user or company that does not keep up with their certificates. It could be a sign of dysfunctional management. On the other hand, revoked certificates have been taken away for a reason. The business may have changed URL, hosting service, owners, or their private key may have been compromised.
Each Certificate Authority will issue their Certificate Revocation List(CRL) to all end users that would be involved in transactions. This will simply be a file that lists information about the revoked certificates. In order to keep each end user up-to-date, delta's are issued with information about new certificate revocations. This system is used mostly in a corporate setting, where the CRLs will be much smaller than on the Internet.
The CRL system becomes very bloated, especially for individual users who are not concerned with knowing about every certificate that has ever been revoked since Al Gore invented the Internet. Thus, the Online Certificate Status Protocol was developed. This protocol issues the querying user information about revoked certificates on a per case basis. Basically, Alice wants to know if the e-Liberty.org's certificate is valid so that she knows her T-shirt purchase will not result in her credit card information being stolen. Therefore when she looks at the certificate the OCSP responder from the issuing Certificate Authority will tell her if the certificate is valid, revoked, or unknown. The OCSP will also send information regarding when the certificate was last checked and when it will be checked again. This information is located under the "Issuer" section of the viewable certificate, however, most browsers will prompt the user with a warning if the status of the certificate is unknown or revoked.
In order to securely distribute and authenticate keys each Certificate Authority will either use a single CA model or the hierarchical CA model. A Certificate Authority using the Single CA model will send their public key to anyone who requests it through the Registration Authority. This helps validate the trust relationship between the CA and the end user and will identify the subscriber that the user wishes to contact.
The Hierarchical model uses a a top-level authority or root authority that controls all of the CAs that are under it. The root is also called the trust anchor because any subordinate CA that is linked to it is considered trusted because it is connected to the "anchor."
The root CA must then create its own certificate in which it is the Issuer and the Subject Name. This certificate is then given to all subordinate CAs. By doing this the trust that was given to the root CA is transferred to the subordinate CAs. These subordinate CAs will then issue certificates to the CAs that are below them in the hierarchy. These machines are called leaf CAs. The leaf CA's job is to issue certificates to end users.
It is important for the root CA to be very, very secure, because a compromised root CA will mean a tremendously tedious and long process for revoking all certificates that are associated with the root CA, and it could possibly invalidate the certificates of the subordinate CAs. However, under most circumstances the root CA certificate is used only to verify a subordinate. The subordinate will then verify the leaf CA that is below it, and the leaf will verify the end users that request certificates, or wish to verify certificates with the CA.
Another way that root CAs keep there keys secure is to use Key Escrow. Key Escrow works by dividing the root CAs private key into two parts and storing those parts on different machines. Both in secure locations, that allow minimal access both physically and from the network. In order to a key to be compromised at least two people would have to come together at two different locations, making it much harder for any attacker to be successful.
There also exists the Web Trust Model, which is the model of choice for PGP. This model builds trust relationships by validating users based on personal relationships between each user. Therefore a user will sign a certificate validating their knowledge that, the key holder is who they say they are. Thus, the more people who validate a user, the greater the trust. The number of people involved in each trust relationship is compounded when considering the number of people who have validated every other individual that validates another user. Simply put, if John verifies Sally's identity and Sally verifies Brooke's identity, Brooke has trust built from the trust relationship between herself and Sally and between John and Sally. The same idea applies to ebay, however a credit card is used to validate a user and the trust is built on a peer rating system after transactions have taken place.
In order to provide certain guidelines for how PKI is instituted RSA laboratories developed encryption standards that are used for securing PKI. The standards are called the Public-key Cryptography Standards. RSA provides a complete list of the active PKCS standards.
Public Key Infrastructure is a valuable source for completing transactions over a network and it can be implemented in a variety of ways. PKI has been invaluable in creating the ability for end users to participate in secure transactions and developing trust among companies and customers.