PKI Certificates and the X.509 Standard


In my previous post in the PKI series we covered some history of asymmetric cryptography as well as some of the basic uses of PKI.  In this post, we will cover a bit more on how the cryptographic relationship in PKI works as well as how to request a new certificate.  All content in this post assumes that the reader is familiar with the concepts discussed in the previous post in the series.  If you are new to PKI and find yourself unfamiliar with terminology used in this post please read its predecessor, http://blogs.technet.com/b/option_explicit/archive/2012/03/10/pki-series-part-1-_2d00_-basics-and-history-of-pki.aspx.

So, what is PKI?

PKI is a system that leverages certificates and asymmetric cryptography to exchange encryption keys paired with trustworthy attributes through use of a hierarchical trust system and revocation infrastructure.  The entire basis of PKI surrounds the certificate, a document containing the public key of the asset being certified (the one holding the corresponding private key) as well as a number of attributes about that system digitally signed by (in most cases) a certification authority (CA) that chains up to a trusted source (commonly a root CA).  The attributes on these certificates are used to prove different aspects about the user or computer with the associated private key to include:

  • A subject (or subject alternative name) which can be used to match an identity associated with a certified asset (i.e. DNS name, user name, e-mail address, etc.)
  • A validity period for the certificate
  • A location where revocation information for the certificate could be found
  • A location where the certificate issuer’s certificate can be found to validate the relationship

The X.509 Certificate

The basis of any PKI is the X.509 certificate.  This certificate contains a number of values used to identify the certified entity and prove its validity and trust to the remote end. 

History of the X.509 Standard

PKI is governed by a the X.509 standard published by the International Telecommunications Union (ITU-T) (http://www.itu.int/ITU-T/) as part of the X.500 series of standards governing directory services.  Those of you familiar with Active Directory or Exchange will be familiar with X.500, the standard responsible for LDAP, the Directory Information Tree (DIT), Directory Systems Agent (DSA), and a number of other Active Directory foundations (http://www.itu.int/rec/T-REC-X.500-200811-I).

The X.509 standard is one of the more active X.500 standards undergoing (as of this writing) a total of 20 revisions since its initial publish in November of 1988.  This high level of activity speaks to the level of evolution in the standard driven by its widespread use.  The initial X.509 standard was labeled as  “X.509 : The Directory – Authentication framework” , however this was changed to “X.509 : Information Technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks” in its fourth revision in March of 2000.  This name change reflects the change in use of the X.509 standard due to its widespread use for purposes other than directory authentication.

In the original X.509 standard PKI is referred to as “strong authentication” leveraging a family of cryptographic systems known as Public Key Cryptographic Systems (PKCS).  The standard does not necessitate a specific encryption algorithm, but rather describes itself as a “framework… applicable to any suitable public key cryptosystem” which remains consistent in all subsequent versions of the X.509 standard (http://www.itu.int/rec/T-REC-X.509-198811-S).  This is an important note since it demonstrates that PKI is not a specific cryptographic algorithm, but rather a means to use an asymmetric algorithm of the user’s choosing to prove a set of meta data which enables identification and trust.

Certificate Versions and Attributes

 X.509 certificates are currently in their third format since the original ITU specification.  Each subsequent version of the certificate was designed to be backwards compatible with any prior versions and thus will contain all attributes from the prior version.  Due to this backwards-compatibility attributes will be provided in association with the version in which they were established.  In cases where the purpose or use of the attribute changed over time the change will be noted in the initial declaration of the attribute.

Version 1 (RFC 1422 http://www.ietf.org/rfc/rfc1422)

Version 1 of the X.509 certificate standard was established in 1993 despite being originally established by the ITU in November of 1988.  At this time the focus of the standard was directory services authentication and did not include any mechanisms to obtain the public key or revocation information.  Fields on a version 1 certificate are as follows:

  • Version Number
    The version number field denotes the version of the X.509 certificate.  Version 1 certificates have this value set to 0.
  • Serial Number
    The unique serial number of the certificate assigned by the certification authority.  The size of the serial number (data size) should be consistent for all certificates issued by a certification authority.
  • Signature and Signature Algorithm
    This field holds the digital signature from the issuing authority as well as the algorithm used to perform the signature.  This signature is what protects and proves the integrity of the attributes stored in the certificate.  The signature is verified using the public key of the issuing CA.
  • Issuer Name
    The issuer name was, at this time, the distinguished name of the issuing CA used to uniquely identify the certifying authority for trust validation.  In version 2 of the X.509 standard they realized the rigidity of the standard and established an additional field, issuerUniqueIdentifier, which could be used in lieu of the distinguished name of the CA.
  • Validity Period
    This field contains the start and end of the time period which the certificate will be valid written in coordinated universal time (UTCT) format based on Greenwich Mean Time (GMT).  In addition, it is recommended that the granularity of time used in this field be no more than a minute, however flexibility is permitted.
  • Subject Name
    This field contains the X.500 Distinguished Name (DN) used to uniquely identify the object.  The intent in X.509 version 1 was to tie the entity to a location in a directory, however later modifications of this field now use it as a way to uniquely identify the principal that owns the certificate (for example, the DN does not need to be the same as an object’s DN in Active Directory).  This modification started in X.509v2 (the subjectUniqueIdentifier field was established to allow the authenticating entity to use this field in the event that the DN was reassigned).  To allow additional flexibility, the subjectAlternativeName attribute became available in version 3 (discussed later in this post).
  • Subject Public Key
    This field holds the public key of the subject as well as the algorithm identifier.

Version 2 (ITU-T Recommendation X.509, Nov 1993 http://www.itu.int/rec/T-REC-X.509-199311-S)

Version 2 of the X.509 certificate was very short-lived and rarely used.  In fact, the Internet Engineering Task Force (IETF) did not turn version 2 of the certificate into a RFC standard whatsoever.  The key change from X.509v1 to X.509v2 was the improved flexibility in identifying the issuer and the subject.  Fields added by the X.509v2 standard are the following:

  • Issuer Unique Identifier
    The issuer unique identifier field allowed another (optional) means to uniquely identify the certification authority.

  • Subject Unique Identifier
    As with the issuer unique identifier, the subject unique identifier was an optional field that could be used to provide a unique ID for the subject.  The explanation for this is to allow reassignment of a distinguished name while still maintaining the ability to uniquely identify the subject (see note 2 under section 8)

Version 3 (RFC 2549 http://tools.ietf.org/html/rfc2459)

Version 3 of the X.509 certificate is the most common format found today.  In this version of the certificate a single field was added that allows the extensibility required to support multiple applications and is likely the reason that this version is still in use today.

  • Extensions
    The extensions field of a certificate is defined as a series of data type Extension.  Each extension has three parts:
    • Extension ID (extnId)
      A value designed to hold an object identifier (or OID) which is used to uniquely identify the value that follows
    • Critical
      Critical is a Boolean value with a default value of false.  If set to true, applications processing the certificate will be expected to validate the setting in order to ensure the identity of the certificate holder (in other words, the validation of the extension is critical to properly identifying the certificate holder).
    • Extension Value (extnValue)
      This is a DER-encoded value formatted as specified by the extension type.  For example, if the extension ID was the OID associated with RFC822Name (commonly used to denote e-mail addresses) this value would hold the e-mail address.

Another important thing to note about this standard is the awareness of the upcoming century change.  Note 2 under section 8 specified that two-digit UTC year notations with a value of 00 to 49 would be treated as years 2000 – 2049 while two-digit year notations of 50 – 99 would denote 1950 – 1999.

Extensions (based on RFC 5280, May 2008 http://www.ietf.org/rfc/rfc5280.txt)

With the new capability came a set of new extensions.  At this time we will depart from the historical context behind these changes and focus on the fields and their purposes.

  • Authority Key Identifier
    This field identifies the public key that can be used to verify the issuer of the certificate.  The authority key identifier field enables the use of distinct keys by the same certification authority (for example, in the event of a key renewal).  The three means to identify this key relationship are through the serial number of the issuer’s certificate, a unique ID established by the certification authority, or through use of any manner of identification listed as part of the GeneralName data type.  The GeneralName data type allows the use of any of the means provided by the Subject Alternative Name class.   Most commonly, the AKI is populated with a hash of the public key used by the issuing CA.  The important part of this field is that its value must match that of the subject key identifier on the issuing CA.
  • Subject Key Identifier
    The subject key identifier is used to identify the current public key being certified.  It can be populated with any of the values available to the authority key identifier.
  • Key Usage
    The key usage field is used to define the purposes that the public key can be used.  Values that can exist for key usage are:
    • DigitalSignature
      For verification of digital signatures
    • Non-Repudiation (later named contentCommitment)
      For verifying digital signatures used to prevent false denial of an action (i.e. to identify falsehood in a claim that an action did not occur)
    • Key Encipherment
      For enciphering keys or other security information
    • Data Encipherment
      For enciphering information that does not fall into the category of keys or security information
    • Key Agreement
      For use as a public key agreement key
    • Certificate Signing (keyCertSign)
      For verification of CA signatures on certificates
    • CRLSigning
      For verifying a CA’s signature on a certificate revocation list (CRL) (this topic will be covered in a later post)
    • Encipher Only
      For enciphering data during key agreement (requires the keyAgreement bit)
    • Decipher Only
      For deciphering data during key agreement (requires the keyAgreement bit)
  • Extended Key Usage
    This field may be used in conjunction with or in replacement of the key usages specified above and allows for more specific controls over what purposes the certificate is valid for.  The following list identifies enhanced key usages defined by RFC 5280 (please note, there are many of these that exist and are not listed in the standard):
    • TLS WWW server authentication
    • TLS WWW client authentication
    • Signing of executable code (code-signing)
    • E-mail protection
    • Time stamping
    • OCSP signing
  • Authority Information Access (AIA)
    The AIA field of a certificate is very important to validating the trust chain of a certificate.  This multivariate field contains one or more HTTP or LDAP paths to the signing CA’s certificate.  This field must be reachable by the client to validate the signature of a certificate and trace a path to a trusted root CA.  In addition, this field may conain one or more URLs that point to Online Certificate Status Protocol (OCSP) servers to improve revocation checking performance.  OCSP will be covered in part 4 of the PKI series.
  • CRL Disribution Point (CDP)
    The CDP field is a pointer to HTTP or LDAP distribution points for certificate revocation lists (CRL).  The CRL is a means of ensuring the certificate’s current validity and can cause certificates to be incorrectly identified as revoked if the path is unreachable.
  • Private Key Usage Period
    The maximum period of time that the private key is allowed to be used (deprecated)
  • Certificate Policies
    Entries in this section provide links to the certification authoritiy’s Certification Practice Statement (CPS) as well as the user notice.  The CPS is a legal document governing the practices associated with certificate handling for an organization.
  • Policy Mappings
    This field is used to map certificate policies between the issuing CA and the certified entity by policy ID.
  • Supported Algorithms
    A list of algorithms supported by the certified entity
  • Subject Alternative Name
    The subject alternative name (SAN) field can contain one or more alternate identities for the certified entity.  These entries can be any instance of GeneralName.  Valid types for GeneralName are:
    • Other Name
      Yet another reference to extend the naming capability, use of this allows specification of anything available in the OTHER-NAME information object class
    • RFC 822 Name
      Another name for rfc822Name is the subject’s e-mail address
    • DNS Name
      A DNS name meeting specifications outlined in RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt)
    • X.400 Address
      The X.400 standard governs message handling and look similar to the X.500 directory services standard, however addressing elements such as the country name, organization name, given name, surname, initials, etc.)
    • Directory Name
      This is the distinguished name of the subject
    • Electronic Data Identifier (EDI) Party Name
      The ediPartyName attribute allows the certificate to specify an alternative authority (referred to as a nameAssigner) that has assigned a name to the subject.  An example of where this might be of use is in federation whereby another directory service is asserting the name of a certified entity.
    • Uniform Resource Identifier (URI)
      This field contains a uniform resource identifier, or URI, conforming to RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt).  URIs usually look similar to a uniform resource locator (URL), however they are used to provide a hierarchical association of an attribute.  URIs are commonly used in XML to uniquely identify a schema and are commonly confused with URLs due to their similarity, however a URI does not need to be a reachable networked location.
    • IP Address
      IP address of the certified entity
    • Registered ID
      An object identifier (OID) that can be used to identify the certified entity
  • Issuer Alternative Name
    As with the subject alternative name, the issuer alternative name provides other valid names which may be used to identify a certificate’s issuer.  All names provided by the GeneralNames type (the same one used in the previous Subject Alternative Name field) are valid for this field.
  • Subject Directory Attributes
    The subject directory attributes field contains attributes of the certified entity (for example, perhaps a user’s nationality) and cannot (per standard) be marked as a critical extension.  A good example of how this might be used would be when you want to assert a non-identifying attribute about the certified entity.
  • Certification Path Constraints: Basic Constraints
    This field is used to determine whether the current certificate is a certification authority as well as an integer value limiting the maximum depth allowed in the CA chain.  Put simply, this field can prevent certificates not intended to be used as a CA from acting as one (doing so would add to the path length and violate the certificate’s constraint)
  • Certification Path Constraints: Name Constraints
    The name constraints field can be used to limit what name spaces the CA is authoritative for.  For example, it could enforce that a CA is only valid for names ending in .microsoft.com thus preventing issued certificates from being valid for .live.com addresses, etc.
  • Certification Path Constraints: Policy Constraints
    The policy constraints field can be used to either enforce or prohibit the definition of a CA policy in issued certificates.

The Object Identifier (OID)

Data in X.509 certificate is organized by object identifiers, or OIDs.  OIDs are a hierarchical dotted integer notation used to describe the different types of data stored in a certificate and their associated formatting and have enabled the success of X.509 certificates due to their extensibility (organizations or software wishing to add custom attributes to a certificate are able to by establishing their own unique identifier structure).  As this topic is primarily formatting-related and quite lengthy I will refer anyone interested in digging into this to the Open Group’s specification located here: http://pubs.opengroup.org/onlinepubs/009609799/index.htm.

Common File Formats for X.509 Certificates

Certificate files are written using Abstract Syntax Notation (ASN.1) and require a converter to become human-readable.  The most common encoding of individual certificates are DER encoded binary x.509 or Base-64 encoded X.509, or Public Key Cryptography Standard (PKCS) #7 formats (see RFC 2315 http://tools.ietf.org/html/rfc2315 and RFC 5652 http://tools.ietf.org/html/rfc5652).  PKCS #7 also enables the storage of multiple certificates in a single file and can be useful to establish trusts with non-public certification authorities where the AIA path may not be accessible (this topic will be covered later). 

Comments (2)

  1. dhwani says:

    Thanks…
    Really very useful content, in simple language, helped me a lot…

  2. IS says:

    Is that the correct link for the Open Group’s specification on OIDs? Seems not to mention OID…

Skip to main content