다음을 통해 공유

The PKI Revocation Infrastructure

  • 아티클

One of the benefits of leveraging PKI is the ability to revoke a certificate.  PKI is a loosely coupled system that outsources trust to organizations in charge of asserting identities of otherwise unknown systems.  At times, these external entities may become compromised thus requiring revocation of their provided certificate.  Unfortunately, this feature also tends to be the one most likely to cause an outage in PKI.  A lack of valid revocation information in many cases marks the certificate as revoked.  That said it is important to ensure availability of all revocation information locations provided on the certificate as well as any revocation sources explicitly specified elsewhere on the operating system or application validating the certificate.

Certificate revocation information is available in various forms; I will cover these in an evolutionary manner starting with the Certificate Revocation List (CRL).

Certificate Revocation List (CRL)

The CRL, originally defined in RFC 1422, is a flat file containing the serial numbers of certificates revoked by the signing certificate authority (CA).  Two versions of the CRL format exist; however, version 1 is unlikely to be found today.

CRL version 1

Originally defined in the 1988 ITU standard for PKI (section 10.2.6), version 1 of the CRL format was suitable for directory services use only.  In its initial version, the CRL was expected to exist in a predictable location in directory services and provided two multivariate values: certificateRevocationList and authorityRevocationList.

  • Certificate Revocation List
    An array of certificate serial numbers corresponding to certificates revoked by a certificate authority.  Each entry is formatted as follows:
    • Signature
      A digital signature to prevent unauthorized tamper of the CR
    • Issuer
      The name of the CRL issue
    • Last Update
      The UTC time of the CRL update
    • Revoked Certificates
      A signed certificate revocation entry containing the certificate issuer, serial number, and revocation date
  • Authority Revocation List
    Though rarely implemented, the Authority Revocation List (ARL) provides a revocation mechanism for trusted certificate authorities.  This functionality is effectively replaced through adding compromised root CAs to the untrusted certificate authorities container in Windows.

This simple format was modified in 1993 prior to being formally implemented in RFC 1422 along with the first version of the X.509 certificate (https://tools.ietf.org/html/rfc1422, section 3.5).

CRL version 2

As the possibilities associated with PKI were realized, it became apparent that version 1 of the CRL was insufficient for the wide array of purposes it could serve.  In response, CRL version 2 was developed and published along with the new X.509 v3 certificate standard in RFC 2459 (https://tools.ietf.org/html/rfc2459, section 5).  The format added the following fields:

  • Version
    This field is used to denote format used for the CRL
  • Revoked Certificates {crlEntryExtension}
    The optional crlEntryExtension attribute was added to the revokedCertificates type to allow the CA to note reason codes and revocation dates associated with certificate revocation entries.  This class contains the following fields:
    • Reason Code
      The reason code is an integer value noting the reason why the certificate was revoked
    • Hold Instruction Code
      This feature shows that a CA is now able to place a certificate on hold, a state whereby the certificate is to be treated as revoked, however not necessarily permanent.  One interesting feature of this field is the ability to have the validating entity contact the issuer if the certificate is encountered.
    • Invalidity Date
      This is the date that the certificate was deemed invalid
    • Certificate Issuer
      This is a very important field noting the issuer of the revoked certificate by its subject.  If this field is empty it is assumed that the revoking entity was the same as the CRL issuer.
  • CRL Extensions
    Version 2 of the CRL format was improved much in the same way as version 3 of the X.509 certificate.  This field holds values defined as extensions in RFC 5280, the same RFC used to define certificate extensions.  A discussion of some of the extensions available for use is available in part 2 of the PKI series.  Extensions designed specifically for use with CRLs are discussed below.

CRL Extensions

Version 2 of the CRL added a few extensions specifically designed for improving validation capabilities.  Some of these extensions include the following:

  • Authority Key Identifier
    Like the X.509 certificate, the authority key identifier is a string value used to uniquely identify the key pair used to sign the CRL.  This value is most commonly populated with a hash of the public key.
  • Issuer Alternative Name
    A CA administrator can use the issuer alternative name to specify identities other than the subject that the signing CA may be known by.  Essentially, this is the same as the X.509 subject alternative name field except applying to the issuer rather than the certified asset.
  • CRL Number
    CRL number is a serial number associated with the current CRL.  This number should be sequential and incremented by one with every new CRL published.
  • Delta CRL Indicator
    The delta CRL is a differential revocation list designed to improve performance of revocation checking, especially in the instance of large or fast-growing revocation lists.  This functionality is discussed below.
  • Issuing Distribution Point
    This field identifies where the CRL is published for consumption and should match the CRL distribution point (CDP) field of the associated certificate.  This path must be either HTTP or LDAP.

Delta CRL

Version 2 of the CRL improved revocation checking through implementing the concept of a delta CRL.  Bandwidth can become an issue when revocation lists change frequently or grow lengthy with revoked certificates.  To address this concern the standard created the ability to use delta CRLs; differential revocation lists published on a more regular basis than the CRL.

Without delta CRLs, a client must download potentially large revocation lists (100 MB is possible) every time the CRL expires.  This causes the CA administrator to need to choose between bandwidth and timely revocation information (clients will not need to obtain a new CRL until the old one expires, therefore it may take weeks before the revoked credential is treated as such by clients).

The delta CRL was designed to alleviate these concerns by providing a smaller differential CRL containing all certificates revoked since the publishing of the main CRL that could be published more regularly and required less bandwidth to download.

An important note regarding the use of delta CRLs is that a valid copy of both the main CRL and the delta CRL must be available to perform a successful revocation check.  Because of this, an empty delta CRL must be published whenever a new CRL is published.  By default, in a Windows CA the delta CRL is published with the same name as the CRL with a “+” appended.

Online Certificate Status Protocol (OCSP)

Despite improvements realized from the use of delta CRLs, the revocation process was still bandwidth and resource intensive.  Clients wishing to validate the revocation status of a certificate needed to download one or two files (CRL and an optional delta CRL), load these potentially large files into memory, perform a signature and trust verification, and finally search them for a serial number.  Though this may not sound terribly resource intensive consider a situation such as smart card login for a domain controller.  Due to the security implications associated with domain authentication, revocation information is sought at every authentication attempt.  If multiple CAs provide user certificates for logon purposes each will have their own CRLs and delta CRLs.  This scenario compounded with the morning logon rush and large (50+ MB) revocation lists and performance will quickly degrade.

In 1999, Entrust’s RFC for OCSP (https://www.ietf.org/rfc/rfc2560.txt) was published in an effort to solve all of these issues.  The vehicle used to perform revocation checks using OCSP is defined loosely (no transport mechanism is mandated per RFC), however almost all implementations of OCSP use HTTP or HTTPS.

OCSP Request

An OCSP request is formatted using ASN.1 syntax with DER encoding in alignment with the formatting of most other PKI communication.  The basic format of the OCSP request is as follows:

  • Version
    The version of the OCSP protocol used
  • Requestor Name
    An optional string value representing the identity of the requestor
  • Request List
    A multivariate attribute containing one or more certificates to validate.  This is an important improvement that allows a single request to validate multiple certificates.  Individual requests are sent using a hash of the issuer name, a hash of the issuer’s public key, and the serial number of the certificate to be validated.

Optionally, the entire request can be digitally signed to prove the identity of the owner as well as the integrity of the message (without this, it is possible to use a man-in-the-middle attack to modify the request in-transit and change the certificates being validated thus damaging the integrity of the system).

OCSP Response

Once the OCSP responder has accepted the request, it searches the revocation information it has stored and generates an individual response for each revocation request returned as an array of responses.  In addition to these responses, the responder has the ability to provide response status codes.  Per RFC 2560 the approved response codes are:

  • (0) Successful
  • (1) Malformed Request
  • (2) Internal Error
  • (3) Try Later
  • (5) Signature is Required (and wasn’t provided as part of the request)
  • (6) Unauthorized

Each certificate revocation request entry is provided an individual response (for example, if four certificates were sent for validation the response will contain four OCSP response entries).  Each individual entry is digitally signed and is listed as either good, revoked, or unknown along with the last and next update of revocation information.  If the certificate is revoked, the revocation time is provided along with (optionally) the reason for revocation.

OCSP Responder Certificates

Right about now I’m sure some of the security geeks out there are thinking of all of the scenarios that could result from obtaining a trusted certificate for OCSP purposes.  To address the potential issue whereby an attacker could trick a victim into trusting revocation information through using an OCSP responder certificate from a well-known trusted certification authority the standard mandates that the OCSP responder certificate must have been issued from the CA it is answering on behalf of (RFC 2560 section 4.2.2.2).  This is important from an implementation perspective as it means one cannot just stand up an OCSP responder and feed it CRLs from CAs they do not own.  For organizations with heavy revocation checks against organizationally external CAs this likely means reliance on WAN links for activities that require positive revocation responses (i.e. smart card logon).  To solve this issue, some OCSP responder vendors have developed systems whereby OCSP responses are pre-signed and downloaded to on-site OCSP responder instances thereby alleviating reliance on the WAN.  In addition, Microsoft provides an option on Windows 7 \ Windows Server 2008 R2 and later clients to allow the OCSP responder to use any trusted OCSP responder certificate for a CA.

Now a chicken-and-the-egg issue arises: if the OCSP responder certificate is issued by the CA and also responds on behalf of the CA how do we obtain revocation information for that certificate?  The answer here: we don’t.  This means that the compromise of an OCSP responder certificate is a critical security breach.  To address this issue, OCSP responder certificates should be issued with a very short lifespan.  By default, the Active Directory certificate template used for OCSP specifies a validity period of two weeks.

Nonce

One question that tends to arise when customers  configure OCSP is an option called “include nonce”.  According to RFC 2560 “The nonce cryptographically binds a request and a response to prevent replay attacks”; an abstract term that leads most to only becoming more confused, enabling nonce, then potentially experiencing revocation outages.  The nonce extension prevents the OCSP responder from using a cached revocation response.

Using the nonce extension forces an administrator to decide that the integrity of the revocation response is so important that it is worth risking the availability thereof.  Using this option prevents use of the previously-mentioned OCSP response caching systems, will increase the CPU utilization on the OCSP responder, and increase the time it takes to receive a revocation response. 

If the nonce extension is configured and the OCSP responder is unable (either through configuration or lack of an OCSP responder certificate) to provide this capability it will reject the request with an “unauthorized” error.

Locating an OCSP Responder

OCSP responder addresses can be stamped as part of the certificate’s properties; however, they are not where most would expect to find it.  If a CA has an OCSP responder available, it can stamp the address of the OCSP responder in the Authority Information Access extension (not the CRL Distribution Point).

In some cases, organizations may add an OCSP responder after implementing PKI or offer an on-site OCSP responder to improve performance and decrease WAN utilization.  For these situations, Microsoft provides the option to configure OCSP addresses through group policy (Windows Vista or later).  OCSP responder information is configured on a per-CA basis in the certificate store, whether in Group Policy or locally.  For detailed information on how to configure an OCSP responder with Group Policy please refer to https://technet.microsoft.com/en-us/library/ee619786(v=WS.10).aspx.

Last, if your organization has down-level (Windows XP \Server 2003 R2 or prior) you may need to rely on a third-party OCSP responder client to provide this functionality.

Comments

  • Anonymous
    January 01, 2003
    @Jason Thank you for that find!  You are correct, the default OCSP responder template issues the certificate for two weeks.  I am updating the site now.

  • Anonymous
    January 01, 2003
    @Nate thank you for that find!  Updating now.

  • Anonymous
    September 08, 2012
    Well written and useful - I thought the OCSP response signing template defined a two week lifetime by default though?

  • Anonymous
    September 25, 2012
    > As of this writing, the Microsoft-provided OCSP responder does not provide this capability. Can you provide some background for that?  The documentation suggests that this feature is included, but not enabled by default: blogs.technet.com/.../implementing-an-ocsp-responder-part-iii-configuring-ocsp-for-use-with-enterprise-cas.aspx