Chapter 10

Advanced PKI

This book has focused on public key infrastructure operations as they are today, from the short history of asymmetric cryptography to the plethora of various standards and specifications. More importantly, we have not addressed any particular products in this book, as each software and hardware solution have their own issues and lifecycles. Each product itself, might be worth its own book. Regardless, some products follow standards and specifications pragmatically, and some might have technology gaps, while others might have proprietary solutions. In general, this book has identified various issues managing PKI systems.

• In Chapter 1, the “Introduction,” we described PKI cryptonomics consisting of legal, business, technology, and cryptography functional areas that need to interact and complement each other within a PKI framework. Inconsistency between these areas and a lack of adequate controls can introduce vulnerabilities or unexpected operational glitches.
• In Chapter 2, “Cryptography Basics,” we discussed certificate validation processes for walking the certificate chain, verifying signatures, and checking validity dates and certificate status. Recognition of certificate purposes for more granular authorization controls are often needed to avoid unauthorized access controls.
• In Chapter 3, “PKI Building Blocks,” we presented various cryptographic protocols that provide key management, data encryption, and entity authentication services. However, protocols often operate at lower network layers transparent to applications such that little or no information is available for business decisions.
• In Chapter 4, “PKI Management and Security,” we provided guidelines on how to write a certificate policy (CP) and certificate practice statement (CPS). The CP and CPS focus on PKI operations and not the application or business flow. On the other hand, representation from the organization’s various lines of business is important for addressing different application needs.
• In Chapter 5, “PKI Roles and Responsibilities,” we described various functional positions and the associated separation of duties. But again, these roles do not necessarily address the application or business processes that depend upon the certificates.

Cybersecurity from an information technology perspective is heavily dependent on PKI operations, in which applications are dependent on cybersecurity, and business processes are consecutively dependent on applications. Thus, applications and business are increasingly reliant on PKI. However, over the past lustrum, PKI has been under attack [B.7.19]. If we call the current state of PKI, version 1.0, then perhaps we need to consider what the next-generation PKI 2.0 might be like [B.7.18]. This chapter first considers a few industry initiatives and then several advanced PKI controls that address cybersecurity, applications, and business controls.

10.1 Industry Initiatives

Some industry initiatives have gained adoption, while others are pilot programs and paper exercises. For example, Extended Validation (EV) certificates are in widespread use today. We mentioned EV certificates in Chapter 4, “PKI Management and Security,” on the topic of auditing standards, again in Chapter 7, “Operational Considerations,” on the issues of external versus internal PKI hierarchies, and once more in Chapter 9, “PKI Governance, Risk, and Compliance,” on the subject of the Certificate Authority Browser Forum* (CAB Forum). Historically, Secure Socket Layer (SSL) certificates were issued by commercial certificate authorities (CAs) based on proprietary subject authentication procedures, but an industry issue arose in 2002 that birthed the concept of EV certificates. The premise that the subject name in the SSL certificate was fully validated came under scrutiny by the industry.

An unnamed CA was issuing low-cost SSL certificates with a proprietary X.509 extension indicating that the subject had not been fully validated. However, because the extension was marked noncritical, browsers ignored the extension such that validated certificates were accepted under the presumption that the subject information was accurate. In June 2002, an invitation-only PKI summit meeting was held in Washington, DC, sponsored by the American Institute of Certified Public Accountants,† the Canadian Institute of Chartered Accountants,‡ and the PKI Forum—now the Organization for the Advancement of Structured Information Standards IDtrust§ Member Section. No meeting minutes were ever officially published; however, it was rumored that allegations of tortious interference were exchanged. Subsequently, a Department of Justice investigation was conducted the following year in February 2003. Two years later, the CAB Forum was established in 2005 whose initiatives included the WebTrust for Certification Authorities—Extended Validation Audit Criteria (WebTrust for EV) Guidelines establishing subject validation standards that would be applied to commercial CAs.

The CAB Forum EV program continues to evolve and is not without its problems. For example, server SSL EV certificates are often indistinguishable from non-EV certificates; there are often no specific object identifiers (OIDs) for a browser to determine an EV from a non-EV certificate; rather browser manufacturers have incorporated root CA whitelists into their products. The CAB Forum has established several specific OIDs for inclusion in EV certificates; however, the CA needs to align its certificate practice statements (CPS) so the corresponding WebTrust for CA and EV audits reflect accurate information. As another example, a recent real-world server SSL certificate was observed to contain the CAB Forum’s EV OID and the root CA was identified as an EV entity in the CPS and auditor’s report; however, the issuing CA did not contain the EV OID, and both the CPS and the auditor’s report indicated that it was a non-EV issuing CA. Look very closely at CAs issuing EV certificates as their hierarchies are not necessarily all reviewed and certified. When the CA documentation is inconsistent with the actual CA hierarchy, it results in uncertainty and doubt.

Inconsistent CA documentation can leave a trail of confusion in its wake.

Other industry initiatives have had less notoriety such as certificate pinning. The basic idea is for an application to “pin” an acceptable SSL root certificate such that any other certificates issued by other hierarchies would be rejected. Essentially the CA certificate chain is no longer used in a standard certificate validation. The SubjectPublicKeyInfo X.509 field contains a hash of the SSL public key and the hash algorithm identifier such as SHA1 or SHA256. However, pinning is not without its issues. There must be a preexisting relationship between the client and server SSL entities to trust the SSL certificate¶; however, when the relationship changes, then the certificate needs to be changed. Furthermore, when certificates are hard-coded in applications, then the software needs to be updated, which necessitates the involvement of the application manufacturer. Also, applications may need to be custom coded to support certificate pinning, but many apps incorporate cryptographic libraries to establish the SSL connections that do not allow for certificate pinning. Mozilla,** Android,†† Microsoft,‡‡ McAfee,§§ and many other PKI product manufacturers have experimented with certificate pinning.

A more recent industry initiative is certificate transparency¶¶ sponsored by Google and under Internet Engineering Task Force*** development [B.3.53]. The stated aims are to remedy certificate-based threats (misused certificates, rogue CA, and stolen certificates) by making the issuance and existence of SSL certificates open to scrutiny. The scheme is composed of three software components: certificate logs, log monitors, and log auditors. The certificate log is based on a Merkle Hash Tree [B.7.21] patented by Ralph Merkle [B.7.22]. Integrity of the certificate log can be cryptographically verified by log monitors and log auditors. Monitors are publicly run servers that periodically contact all of the log servers and watch for suspicious certificates. Auditors are lightweight software components that verify logs are behaving correctly and that a particular certificate appears in a log. However, certificate transparency might not be without problems.

An organization such as the ABC Corporation using a commercial CA might monitor or audit a certificate log for its own certificates, but cannot necessarily detect a counterfeit certificate without constantly reconciling a known list against a certificate log. For example, if an ABC insider obtained an illegal certificate from the commercial CA, the certificate would be added to the certificate log by the CA as legitimate. The ABC Corporation might discover the new certificate in the certificate log but misinterpret it as legit. Furthermore, any relying party checking the log would likewise mistakenly interpret the ABC certificate as legit. Ironically, the CA and registration authority (RA) compromises discussed earlier in this book and mentioned in the certificate transparency claims were based on stolen credentials that allowed valid but illegitimate certificates to be issued within the regular security controls. Since the stolen credentials were still valid the same attacks would have updated the certificate log accordingly and likely gone undetected.

While there have been and likely will be other PKI industry initiatives, before we explore several advanced PKI concepts of our own, we will first reconsider the Online Certificate Status Protocol (OCSP). When OCSP was being developed, there were many conversations about problems with using the certificate revocation list (CRL) as a negative file. CRL was actually based on the payment industry restricted card list (RCL) for canceled credit cards. Before point-of-sale terminals became widely adopted, payment authorization was partially based on a printed RCL booklet distributed by Visa and MasterCard. Once payments went online (the original electronic commerce program), the RCL was distributed electronically and updated hourly, and if not on the RCL, the financial institution looked up the card account number in a positive file to authorize the payment. OCSP was originally envisioned to be a combination of positive and negative files—every certificate issued or revoked by a CA was added to the OCSP database such that a good response meant the certificate was valid and unrevoked, a revoked response meant the CA revoked the certificate, and an unknown response meant the certificate was not found, so its status was indefinite. However, most OCSP responders only get CRL data feeds such that a good response means no news is good news and only a revoked response is accurate.

10.2 Certificate Trust Levels

As discussed in Chapter 2, “Cryptography Basics,” when the subject sends its certificate to the relying party, the validation process includes walking the certificate chain. Figure 10.1 provides a certificate chain example consisting of three certificates: the entity certificate issued to John Q. Public (JQP) by the intermediary XYZ CA; the issuing XYZ CA certificate issued by the XYZ root CA; and the self-signed XYZ root CA certificate, also called the XYZ trust anchor (TA). One or more of the certificates are installed in the ABC trust store. Sometimes only the trust anchor (TA) is preinstalled on the relying party’s system; other times the certificate chain is preinstalled.

For example, when an ABC browser connects to a JQP server, the browser has the XZY intermediate CA certificate, and the TA preinstalled on the ABC workstations and receives the JQP certificate during the Transport Layer Security (TLS) handshake. If any of the CA certificates are missing, the browser will typically display a warning and ask if the certificates should be installed. The TLS protocol supports download of the server-side certificates, beginning with the JQP certificate, then the intermediary XYZ certificate, and finally the TA. Once the certificate chain is completed, the TLS connection is established.

As another example, when an ABC server connects to a JQP server, the XZY intermediate CA certificate and the TA are preinstalled on the ABC server. When the JQP certificate is sent from the JQP server to the ABC server, if any of the CA certificates are missing, the TLS connection will fail. However, if the certificate chain is installed, the connection is established. Other examples include verifying digital signatures or establishing symmetric keys.

However, if the ABC relying party system accepts any end-entity certificate with any certificate chain merely based on the existence of a preinstalled TA, then the corresponding applications are vulnerable to unauthorized access. Another end-entity certificate, say issued to Jane Z. Doe (JZD) by the same XZY intermediary CA, would be authenticated to the TA, but Jane Doe might not be authorized. As another example, the entity certificate issued to John R Doe (JRD) by a different XYZ intermediary CA would still be authenticated to the TA, and again John Doe would have unauthorized to access the ABC relying party system. However, the JRD certificate issued from a different XYZ intermediary CA might not even be intended for use with the ABC relying party system. For the purposes of this book, we call accepting any certificate from any chain with only a specific trust anchor a Level 1 certificate trust ranking.

The next higher level is when any certificate is acceptable from only a specific chain with only a specific trust anchor, which we call a Level 2 certificate trust ranking. Thus, from the previous example, the JQP and JZD certificates issued from the same XYZ intermediary CA would be implicitly authorized. However, the JRD issued from a different chain would not be accepted.

A Level 3 certificate trust ranking is when only recognized certificates from only a specific chain with only a specific trust anchor are accepted. Continuing with our example, not only would the JRD certificate not be accepted, the JZD certificate would be denied but the JQP certificate would be accepted as an authorized entity. However, the authorization of the JQP certificate is still implicit; there is still not anything in the JQP certificate that explicitly authorizes its acceptance by the ABC relying party system.

The next level is when attributes are added to the entity certificate. Level 4 certificate trust ranking includes Level 3 recognition controls with attributes that identify the functional purpose for the certificate and its corresponding private key. The ABC relying party system only accepts the JQP certificate if the certificate chain is preinstalled and the certificate attribute matches the functional control. The attributes might be provisioned in the certificate within an X.509 v3 extension. As an example, we introduce the concept of the relying party unit (RPU).

10.3 Relying Party Unit

The relying party unit (RPU) is an X.509 v3 extension provisioned by a relying party for inclusion in the subject certificate. As shown in Figure 10.2, the entity John Q. Public would submit a request (1) to the ABC Corporation for an RPU. The response (2) would be coordinated per a contractual agreement with proper authorization and due diligence. The RPU would be included in the certificate signing request submitted to the CA (3) that would be encapsulated in the certificate (4) issued to the end entity and (5) provided to the relying party.

The RPU also shown in Figure 10.3 consists of four data fields: an object identifier (RPU-identifier), the name of the subject (RPU-subject), a set of one or more attributes (RPU-attributes), and a signature (RPU-signature) over the identifier and all of the attributes. Each attribute in the RPU is a functional control value meaningful to the ABC Corporation, but since a certificate might contain more than one RPU from other organizations, the object identifier in the RPU is specific to the ABC organization. While possibly proprietary, the attributes are not necessarily secret as they are signed by the ABC Corporation, and the RPU is itself contained in the JQP certificate signed by the XYZ certificate authority.

The Abstract Syntax Notation One (ASN.1) for the X.509 v3 extension is as follows. Each extension consists of three fields: an object identifier (extnID) indicating its purpose, a flag (critical) indicating its processing rules, and the actual extension value (extnValue). The OID is relatively unique to an industry standard or organization, so the ABC Corporation might use its own OID. Each extension is designated as either critical (TRUE) or noncritical (FALSE) such that if the extension is recognized, then it must be processed; otherwise, if TRUE, then the certificate must be rejected, and if FALSE, the extension can be ignored [B.7.20] and [B.3.50].

Extension ::= SEQUENCE {

extnID	OBJECT IDENTIFIER,

critical	BOOLEAN DEFAULT FALSE,

extnValue	OCTET STRING

}

The certificate extension identifier (extnID) arc is defined as {joint-iso-ccitt (2), ds (5), 29} with dozens of successive object identifiers. A new OID would be needed such as {2, 5, 29, 90} although the OID would need to be registered as an X.509 v3 extension. Applications would need enhancing to recognize the RPU extension identifier and process it accordingly.

The extension should be marked critical so that the relying party system would not ignore the field. Since each RPU contains an OID, the relying party can process its own RPU but ignore other organization’s RPU without ignoring the overall extension. Applications would need enhancing to recognize and accept its own or whitelisted OID and reject unknown or blacklisted OID. The whitelist and blacklist would need adequate management controls to prevent unauthorized access, additions, deletions, or other illicit modifications.

The extension value would contain the relying party unit object defined as one or more relying party unit (RPU) objects. Each RPU object consists of the RPU-signature and three data fields: RPU-identifier, RPU-subject, and RPU-attributes. The RPU-identifier field contains the OID recognized by the relying party. The RPU-subject field contains the certificate subject name to deter anyone from copying the RPU to another certificate. The RPU-attributes field contains one or more functional control values provided by the relying party. The RPU-signature field contains the relying party’s digital signature over the RPU fields to prevent modification. The ASN.1 is shown as follows:

RelyingPartyUnits ::= SEQUENCE (1..MAX) OF RPU-object

RPU-object ::= SEQUENCE {

RPU-identifier	OBJECT IDENTIFIER

RPU-subject	Name

RPU-attributes	SEQUENCE SIZE (1..MAX) OF OCTET STRING

RPU-signature	OCTET STRING

}

After the certificate chain shown in Figure 10.1 is validated by the ABC relying party system, the JQP certificate is checked for the occurrence of the RPU. If the RPU does not contain the appropriate attribute, the message is rejected despite that the certificates are cryptographically valid. In this manner, a Level 4 trust relationship might be established depending on an application’s recognition and processing of the RPU extension.

10.4 Short-Term Certificates

One of the reoccurring PKI problems is checking certificate status. Some applications do not check, while other times the CRL or OCSP responder might be unavailable. Assuming the application checks the certificate validity period, the risk window of relying upon a certificate when it has been revoked is limited to the certificate’s validity period, the validity period of the CRL, or how often the OCSP responder is updated. This risk can be decreased by using short-term certificates such that the validity period limits the potential exposure. Furthermore, if the validity period is short enough, the need for revocation checking is reduced as the certificate’s time to live can be less than the revocation process and CRL distribution. However, the certificate issuance cycle becomes paramount to avoid operational outages due expired certificates.

Consider the issuance cycle shown in Figure 10.4. The first certificate (1) is valid not before time periods T1 and not after T3, whereas the second certificate (2) is valid not before T2 and not after T4. The second certificate replaces the first at time T2 such that the first is used during time interval I1 and the second during interval I2. The intervals overlap such that if the second certificate issuance or distribution is delayed, the previous certificate can be continuously used to avoid operational outages. In general, certificate N is valid from TN to TN+2, certificate N+1 is valid from TN+1 to TN+4, but certificate N is used during the IN interval and certificate N+1 is used during the IN+1 interval. The potential exposure occurs when certificate N needs to be revoked but continues to be used during its IN interval. If the intervals are short enough, the risk window can be reduced.

For example, if the certificate is used as an authentication method for access controls, and the corresponding private key is compromised during a 24-hour validity period, the risk window is limited to a 12-hour interval. As another example, if the certificate is used as an encryption method for data confidentiality, and the private key is compromised during an 8-hour validity period, the risk window is limited to a 4-hour interval. However, the certificate validity period only has a not-before and not-after time stamp. There is no interval period and no mechanism to link a new certificate with a previous certificate. We now introduce another X.509 v3 extension, short-term certificate (STC), which is shown in Figure 10.5.

The X.509 v3 extension value would contain the short-term certificate (STC) object, so a new OID would be needed such as {2, 5, 29, 91}, but again it would need to be registered. The STC is one or more occurrences of three fields: the subject key identifier (SKI) for the current certificate (SKI-now), the subject key identifier for the previous certificate (SKI-before), and the short-term certificate period (STC-period). The subject key identifier is another standard v3 extension that is typically a SHA1 hash of the certificate public key. Thus, the SKI-now matches the SKI in certificate N, and the SKI-before matches the SKI in the N–1 certificate. The ASN.1 is shown as follows:

ShortTermCertificate::= SEQUENCE (1..MAX) OF STC-object

STC-object::= SEQUENCE {

SKI-now	OCTET STRING

SKI-before	OCTET STRING

STC-period	Time

}

Further, the STC-period for certificate N whose validity periods not-before are TN and T N + 2 is T N + 1 that reflects the IN and IN + 1 intervals. The relying party application now has sufficient information to rotate short-term certificates and determine the linkage between the current and previous certificate. Since the STC object permits multiple entries, the sequence can be tracked over time. Figure 10.6 shows a sequence of three certificates over consecutive time periods. The first certificate has not-before (TN), STC period (TN + 1), and not-after (T N + 2) time periods. The second certificate has not-before (TN + 2), STC period (TN + 3), and not-after (TN + 4) times. The third certificate has not-before (TN + 4), STC period (TN + 5), and not-after (TN + 6) times. Each certificate might only contain the current STC object or a history of the short-term certificates based on the application lifecycle.

Short-term certificates can be used to reduce risk for some situations such as key compromise or avoiding certificate revocation issues. For situations where CRL or OCSP mechanisms are unavailable or problematic, short-term certificates might be a viable alternative. Basically, shorter validity periods and shorter intervals results in lower risk and thus less need for revocation. Conversely, shorter validity periods increase the number of certificates and consequently increase key generation and certificate issuance overhead.

10.5 Long-Term Certificates

Although somewhat of a misnomer, at the other end of the spectrum from short-term certificates are long-term certificates. When information has been protected using asymmetric keys, such as digital signatures, code signing, or file encryption, the data lifecycle might exceed the key lifecycle. Consider Figure 10.7, which shows a private key for signing and the public key certificate for verifying the digital signature. The certificate validity period is not-before (T1) and not-after (T2), which corresponds to the private key. This implies that any signature created before T1 or after T2 using private key 1 is invalid, which is controlled by the certificate 1 validity period. However, the signed document might have a much longer lifecycle, extending to time periods T3 and T4 in this example.

Realistically, the private key lifecycle is not the same as the public key lifecycle. For example, data signed using the private key may need to be verified using the public key after the private key is no longer used. Conversely, data encrypted using the public key may need to be decrypted using the private key long after the certificate has expired. The certificate validity period is pertinent for real-time transactions; however, for persistent transactions, the disparity between the private and public keys can be challenging. There are several approaches toward longer data lifecycles that exceed the shorter key lifecycles, but each has its pros and cons:

• Extending the certificate validity period implicitly extends the private key usage period, which is not the goal, allowing additional documents signed at later dates, which exacerbates the problem. For example, documents signed before T2 cannot be verified after T2 when validating the current certificate. Extending the certificate expiration date from T2 to T3 allows more documents signed before T3 that cannot be verified after T3 when validating the extended certificate. Thus, extending the certificate validity period is a substandard approach.
• Retaining the expired certificate in an archive state allows verification of older signatures; however, archive controls as discussed in Chapter 2, “Cryptography Basics,” can be another challenge. Archived keys are never reused in production systems; rather they are only utilized in archival systems. Thus, the signed document needs to be accessible by the key archival system without weakening the archival controls. Therefore, using archived keys is not an optimized approach.

Long-term certificates are really a recursive process whereby the lifecycle for a previously signed document is extended by encapsulating it in another signed object. Figure 10.8 shows the reiterative process. The document is signed using the first private key and verified using the corresponding certificate, and the document, signature, and certificate are combined in an object for the (T1, T2) period. The first object is signed again using a second private key and verified using the corresponding certificate, where the first object, signature, and certificate are combined in a second object for the (T2, T3) period. The second object is signed using a third private key and verified using the corresponding certificate, and the second object, signature, and certificate are combined in a repetitive object for the (T3, T5) period to create a third object, and so on. In this manner, the original document is resigned for each valid key lifecycle where each signature is verified by the corresponding certificate.

The ASN.1 objects described earlier are based on the Cryptographic Message Syntax (CMS) signed data type shown as follows. The original document and each successive object are put into the EncapsulatedContentInfo field, the corresponding certificates are put in the optional Certificates field, and the signatures are put into the SignerInfos field [B.1.13]:

SignedData::= SEQUENCE {

Version	CMSVersion,

digestAlgorithms	DigestAlgorithmIdentifiers,

encapContentInfo	EncapsulatedContentInfo,

certificates	[0] Certificates OPTIONAL,

crls	[1] CRLs OPTIONAL,

signerInfos	SignerInfos

}

The ASN.1 for the long-term certificate (LTC) object is shown as follows. An OID indicating the presence of the LTC object is the first field. The OID might be based on an industry arc that would need to be registered, or a private organization arc. The other field is the list of one or more signed objects. In this manner, the signed documents are recursively encapsulated.

LongTermCertificate::= SEQUENCE {

LTC-identifier	OBJECT IDENTIFER,

LTC-objects	LTC-object

{

LTC-object::= CHOICE {

LTC-data	[0] SignedData,

LTC-data	[1] LTC-object

{

Although in inaccurate term, a long-term certificates, can be used to verify protected data over the data lifecycle when it exceeds the key lifecycle. For example, certificates typically have validity periods of a few years, while conversely, data might have a retention period of decades. Special long-term signature keys with greater key sizes and longer validity periods can also extend the LTC lifecycle and reduce the number of recursively signed objects.

---