X.509 Certificates and Certification Authorities

The following is excerpted from the RSA Security FAQ Version 3.0 ITU-T Recommendation X.509 specifies the authentication service for X.500 directories, as well as the widely adopted X.509 certificate syntax. The initial version of X.509 was published in 1988, version 2 was published in 1993, and version 3 was proposed in 1994 and considered for approval in 1995. Version 3 addresses some of the security concerns and limited flexibility that were issues in versions 1 and 2. Directory authentication in X.509 can be carried out using either secret-key techniques or public key techniques, with the the latter is based on public key certificates. An X.509 certificate consists of the following fields: version serial number signature algorithm ID issuer name validity period subject (user) name subject public key information issuer unique identifier (version 2 and 3 only) subject unique identifier (version 2 and 3 only) extensions (version 3 only) signature on the above fields This certificate is signed by the issuer to authenticate the binding between the subject (user's) name and the user's public key. The major difference between versions 2 and 3 is the addition of the extensions field. This field grants more flexibility as it can convey additional information beyond just the key and name binding. Standard extensions include subject and issuer attributes, certification policy information, and key usage restrictions, among others. The X.509 standard is supported by a number of protocols, including PEM, PKCS, S-HTTP, and SSL. The SSL (Secure Socket Layer) Handshake Protocol was developed by Netscape Communications Corporation to provide security and privacy over the Internet. The protocol supports server and client authentication. The SSL protocol is application independent, allowing protocols like HTTP, FTP (File Transfer Protocol), and Telnet to be layered on top of it transparently. The SSL protocol is able to negotiate encryption keys as well as authenticate the server before data is exchanged by the higher-level application. The SSL protocol maintains the security and integrity of the transmission channel by using encryption, authentication and message authentication codes. The SSL Handshake Protocol consists of two phases, server authentication and client authentication, with the second phase being optional. In the first phase, the server, in response to a client's request, sends its certificate and its cipher preferences. The client then generates a master key, which it encrypts with the server's public key, and transmits the encrypted master key to the server. The server recovers the master key and authenticates itself to the client by returning a message encrypted with the master key. Subsequent data is encrypted with keys derived from this master key. In the optional second phase, the server sends a challenge to the client. The client authenticates itself to the server by returning the client's digital signature on the challenge, as well as its public-key certificate. An X.509 certificate binds an identity to a pair of electronic keys that can be used for encrypting and signing digital information. The pair consists of two related keys - a public key and a private key. The public key can be used by anyone to verify a message siged with the private key or to encrypt a message that can only be decrypted using the private key. The private key must be kept secure and protected against unauthorized use. Certificates are issued by a Certification Authority (CA), which is a trusted party that vouches for the identity of those to whom it issues certificates. In order to prevent forged certificates, the CA's public key must be trustworthy. The CA can either widely publicize its public key or provide a certificate from a higher level CA which attests to the validity of its public key. The latter leads to a hierarchy of CAs. To obtain a certificate, an individual generates his own key pair and sends the public key to the CA with proof of his identity. Different CAs may issue certificates with different levels of identification requirements. For example, Verisign is a commercial CA that offers four classes of certificates, with increasing levels of assurance (and cost) Using the requirements for the particular level applied for, the CA checks the identification and then sends the requestor a certificate attesting to the binding between the requestor and his public key, along with (possibly) a hierarchy of certificates verifying the CA's public key. The National Institute of Standards and Technology (NIST) is taking a leadership role in the development of a Federal Public Key Infrastructure that supports digital signatures and other public key-enabled security services In doing this, NIST is coordinating with industry and technical groups developing PKI technology such as the Federal PKI Steering Committee and its Technical Working Group (TWG), CommerceNet, Internet's PKIX, and the Open Group. NIST chairs the TWG, which is composed of technical representatives from Federal agencies and industry. Active since October 1994, the TWG has developed initial versions of a requirements document, a concept of operations, a technical security policy, an X509 v3 certificate profile, and an interoperability report. Laboratory activities include the development of a Reference Implementation and the initial implementation of a root Certification Authority (CA) for the Federal PKI. To protect agaist long-term factoring attacks, a certificate has a validity period which should be shorter than the expected factoring time. The validity period, together with the need for security and the expected strength of an attacker, determines the appropriate key size which should be chosen when generating the key pair. In the event that someone's private key is compromised before it expires, he must let others know by adding the associated certificate to a Certificate Revocation List (CRL). The CRL is maintained by the Certification Authority that orginally certified the key. When verifying a signature, one can check the CRL to make sure the signer's key has not been revoked. Someone who obtains the private key of a CA could then forge certificates. Thus, a CA must ensure that its private key is extremely secure, for example by keeping it in a tamperproof box called a Certificate Signing Unit, or CSU. Furthermore, to protect against long-term factoring attacks, a CA should use very long keys and change keys regularly. An individual can use a certificate to identify himself to secure servers such as membership-based or access-controlled Web servers. Multiple certificates can be attached to a message or transaction, forming a certificate chain in which each certificate attests to the authenticity of the previous certificate. The top-level CA in the chain must be independently known and trusted by the recipient. When installed in a Web browser, a certificate functions as electronic credentials, eliminating the need for typing in a username and password. Similarly, a secure Web server uses its own certificate to assure clients that the server is run by the organization claimed and to verify the integrity of the provided documents. X.509 client certificates are currently supported by Netscape in its Navigator 3.0 browser. Microsoft has also announced support for X.509 certificates in its client applications. X.509 server certificates are currently used in server products from IBM, Microsoft, Netscape, OpenMarket, and Oracle.