Next: Setting up a CA, Previous: Introduction, Up: Top [Contents]
X.509 was created by CCITT (later ITU) for the X.500 directory service. Today, X.509 discussions and implementations commonly reference the IETF’s PKIX Certificate and CRL Profile of the X.509 v3 certificate standard, as specified in RFC 3280.
ITU continues to develop the X.509 standard together with the IETF in a rather complicated dance.
X.509 is a public key based security system that has associated data stored within a so called certificate. Initially, X.509 was a strict hierarchical system with one root. However, ever evolving requiments and technology advancements saw the inclusion of multiple policy roots, bridges and mesh solutions.
x.509 can also be used as a peer to peer system, though often seen as a common scenario.
There are several flavors of certificate in X.509.
Trust anchors are strictly not certificates, but commonly stored in a certificate format as they become easier to manage. Trust anchors are the keys that an end entity would trust to validate other certificates. This is done by building a path from the certificate you want to validate to to any of the trust anchors you have.
End entity certificates are the most common types of certificates. End entity certificates cannot issue (sign) certificate themselves and are generally used to authenticate and authorize users and services.
Certificate authority certificates have the right to issue additional certificates (be it sub-ordinate CA certificates to build an trust anchors or end entity certificates). There is no limit to how many certificates a CA may issue, but there might other restrictions, like the maximum path depth.
Remember the statement "End Entity certificates cannot issue certificates"? Well that statement is not entirely true. There is an extension called proxy certificates defined in RFC3820, that allows certificates to be issued by end entity certificates. The service that receives the proxy certificates must have explicitly turned on support for proxy certificates, so their use is somewhat limited.
Proxy certificates can be limited by policies stored in the certificate to what they can be used for. This allows users to delegate the proxy certificate to services (by sending over the certificate and private key) so the service can access services on behalf of the user.
One example of this would be a print service. The user wants to print a large job in the middle of the night when the printer isn’t used that much, so the user creates a proxy certificate with the policy that it can only be used to access files related to this print job, creates the print job description and send both the description and proxy certificate with key over to print service. Later at night when the print service initializes (without any user intervention), access to the files for the print job is granted via the proxy certificate. As a result of (in-place) policy limitations, the certificate cannot be used for any other purposes.
Before validating a certificate path (or chain), the path needs to be constructed. Given a certificate (EE, CA, Proxy, or any other type), the path construction algorithm will try to find a path to one of the trust anchors.
The process starts by looking at the issuing CA of the certificate, by Name or Key Identifier, and tries to find that certificate while at the same time evaluting any policies in-place.
Next: Setting up a CA, Previous: Introduction, Up: Top [Contents]