X.509 was developed from the X.500 standard. X.500 is a directory service standard that was ratified by the International Telecommunications Union. The objective was to develop an accessible, easy-to-use electronic directory of people provided for all Internet users. The X.500 directory standard specifies a common root of a hierarchical tree.
Picture an upside down tree, the root of the tree is at the top level, and all other containers are below it. A CN= before a username represents it as a common name, a C= precedes a “country” and an O= precedes “organization.” Each X.500 local directory is considered a directory system agent.
The DSA can represent either single or multiple organizations. Each DSA connects to the others through a directory information tree which is a hierarchical naming scheme that provides the naming context for objects within a directory. X.509 is the standard used to define what makes up a digital certificate.
Certificate Policies and Rules
A CA can assign a certificate for various reasons, but must specify exactly what the certificate will be used for. The set of rules that illustrate how certificates may be used is called a certificate policy. The X.509 standard defines certificate policies as “a named set of rules that indicates the applicability of a certificate. Different organizations have different security requirements:
- Digital certificates are used for securing e-mail.
- TestKing wants a digital certificate for their online store.
- The Department of Defense wants a digital certificate to secure top-secret information on nuclear submarines.
- The certificate policy is a plaintext document that is given a unique object.
Certificate Practice Statements: It’s vital to have a policy in place to convey what is going to be done. A CPS describes how the CA strategy in managing certificates it issues. If a CA does not include a CPS, users should consider finding another CA.
Revocation: Certificates are rendered void when the information contained in the certificate is outdated or no longer trusted. This can occur when a company switches Internet Service Providers, relocates, or the administrator listed on the certificate has changed. Some policies are technically-oriented and others outline the process followed to create and manage certificates. With security systems, it’s important to make certain the CA has a policy covering each item required.
One of the main reasons to revoke a certificate would be if the private key has been compromised in any way. A key that has been compromised should be revoked immediately in addition to notifying all certificate users of the date that the certificate will no longer be valid. Once users are notified, the CA then has the responsibility to immediately change the status of the certificate as revoked.
Also, the date of revocation needs to be published including the last date that communications were considered trustworthy. When a certificate revocation request is sent to a CA, the CA is required to authenticate the request with the certificate owner. Once that is done, the certificate is revoked and notification is sent out.
A certificate issued by a CA lists an expiration date that specifies how long the certificate is valid. If a certificate needs to be revoked prior to that date, the CA can be instructed to add the certificate to its CRL. When a certificate is revoked, the CA administrator must provide a reason code. PKI-enabled applications are designed to check CAs for their updated CRL, and do not operate if they cannot verify that the certificate has not been added to the CRL.
PKI Standards and Protocols
Without standards and protocols, PKI would become unsustainable. The Public-Key Cryptography Standards (PKCS) are established protocols used for securing the exchange of information through PKI. The PKCS standards were developed by RSA laboratories:
- PKCS #1: RSA Cryptography Standard outlines the encryption of data using the RSA algorithm. The purpose of the RSA Cryptography Standard is in the development of digital signatures and digital envelopes. PKCS #1 also describes syntax for RSA public keys and private keys. The public-key syntax is used for certificates, while the private-key syntax is used for encrypting private keys.
(#2 and #4 merged with #1)
PKCS #3: Diffie-Hellman Key Agreement Standard outlines the use of the Diffie-Hellman Key Agreement, a method of sharing a secret key between two parties. The secret key is used to encrypt ongoing data transfer between the two parties. Whitfield Diffie and Martin Hellman developed the Diffie-Hellman algorithm in the 1970s as the first asymmetric cryptographic system. Diffie-Hellman overcomes the issues of symmetric key systems because management of the keys is less difficult.
PKCS #5: Password-Based Cryptography Standard defines a method for encrypting a string with a secret key that is derived from a password. The result of the method is an octet string (8-character string).
PKCS #6: Extended-Certificate Syntax Standard deals with extended certificates. Extended Certificates are made up of the X.509 certificate plus additional attributes. The additional attributes and the X.509 certificate can be verified using a single public-key operation. The issuer that signs the extended certificate is the same as the one that signs the X.509 certificate.
PKCS #7: Cryptographic Message Syntax Standard is the foundation for Secure/Multipurpose Internet Mail Extensions (S/MIME) standard. Is also compatible with Privacy-Enhanced Mail and can be used in several different architectures of key management.
PKCS #8: Private-Key Information Syntax Standard describes a method of communication for private-key information that includes the use of public-key algorithms and additional attributes. PKCS #8 is primarily used for encrypting private keys when they are being transmitted between computers.
PKCS #9: Selected Attribute Types defines the types of attributes for use in extended certificates (PKCS#6), digitally signed messages (PKCS#7), and private-key information (PKCS#8).
PKCS #10: Certification Request Syntax Standard describes syntax for certification requests. A certification request consists of a distinguished name, a public key, and additional attributes. Certification requests are sent to a CA, which then issues the certificate.
PKCS #11: Cryptographic Token Interface Standard specifies an application program interface for token devices that hold encrypted information and perform cryptographic functions, such as Smart Cards and USB pigtails.
PKCS #12: Personal Information Exchange Syntax Standard specifies a portable format for storing or transporting a user’s private keys and certificates. Ties into both PKCS #8 (communication of private key information) and PKCS #11 (Cryptographic Token Interface Standard). Portable formats include diskettes, Smart Cards, and Personal Computer Memory Card International Association (PCMCIA) cards.
PKI standards and protocols are “living documents”, meaning they are fluid and always changing. Additional standards are always being suggested, but before they can be recognized as standards they are put through extensive testing and scrutiny.
