10.2.6 X.509 trust model

Generally speaking, there are three steps in verifying a certificate:

• Verify that the certificate has not been revoked
• Verify that the certificate is valid (for instance, verify the certificate’s extensions and its validity period)
• Verify the signature of the CA over the certificate

As discussed earlier, the first step consists of either consulting a CRL or an OCSP server. But to verify the signature over a certificate (or a CRL or an OCSP response), we need an authentic copy of the CA’s public key – in other words, we need another certificate, in which the original CA is the subject. In X.509, these CA certificates are issued by a higher-order CA, which in turn has a certificate from an even higher-order CA, so that a hierarchical tree structure emerges with a Root CA at the top, which certifies itself (see Figure 10.4).

Figure 10.4: X.509 hierarchical trust model. An arrow from X to Y means that X certifies Y . EE stands for End Entity

The Path Length Constraint within the Basic Constraints extension field limits the number of CA certificates that may follow a CA certificate down the tree until the EE certificate under consideration is reached. For CA0 in Figure 10.4, for example, the path length constraint could be set to 0, whereas for CA1, the path length constraint should be at least 1, lest verification of the end entity certificates for C,D, and E fails.

In practice, a CA is rarely certified by another, independent CA. Rather, there are instances within the same company that act as root CAs for their own intermediate CA instances. From a security perspective, this is equivalent to a CA self-signing its own public key. This means that, in most cases, the relying parties cannot transfer the question of whether to trust a particular CA to some independent higher-order instance, but must base their trust decisions entirely on the publicly available information about a CA, for example, the CPS. Although modern browsers contain lists of trusted CAs, it is not entirely clear how these lists come about, and they should be no substitute for making your own decisions.

10.4 Rogue CAs

If a CA is compromised, it will issue certificates for web servers with a fake identity, and impersonation attacks are the consequence, breaking entity authentication within TLS. The most serious incident of this kind goes by the name of Operation Black Tulip: In July 2011, an attacker took control of the Dutch CA DigiNotar (for more details, see Section 19.5.2 in Chapter 19, Attacks on Cryptography) and issued fraudulent certificates for *.google.com and other important domains [199].

The main target of the attack seemed to be 300,000 Iranian Gmail users, who lost their credentials for various Google services, including Google Mail and Google Docs due to the attack. The real source of the attack was never disclosed. Initially, many signs pointed toward the Iranian government, but later on, the well-known security researcher Bruce Schneier also blamed the NSA [41].

How should we deal with a rogue CA, especially the certificates issued by it? Of course, a CA compromise is a valid reason for certificate revocation, but we can neither trust a CRL nor an OCSP response signed by a rogue CA. Moreover, in most cases, we cannot rely on some independent, higher-order CA to revoke the certificate of the rogue CA. There is, however, a list of trusted CAs within modern browsers (see Figure 10.6), and indeed, trust in the DigiNotar CA was withdrawn by all major browsers by September 2011.

Figure 10.6: List of trusted CAs within Firefox

This example shows that the major browser manufacturers do have the potential to act like some global root CA. In 2015, Mozilla introduced OneCRL, where CA certificate revocation information is gathered centrally, then pushed out to client browsers on an almost daily basis. For this, all available CRLs are crawled, and revoked CA certificates as well as revoked high-profile end entity certificates, which may have a large impact on Firefox users, are included. Moreover, following a security incident such as Black Tulip, CA certificates may be entered manually into OneCRL [60]. Google’s Chrome browser uses a similar mechanism known as CRLSets. The basic idea behind both OneCRL and CRLSets is to concentrate on CA certificates to reduce the size of the lists and to rely on OCSP stapling for end entity certificates.

Another promising innovative initiative from browser manufacturers is called CRLite [108]. CRLite aims to include all revoked certificates and is currently being tested by Mozilla [89]. In CRLite, the browsers locally store certificate revocation information in a compressed form that needs only a few megabytes of storage. The browser downloads daily updates, taking up storage space in the order of kilobytes. Most importantly, these lists can be held locally, so that no privacy issues arise from checking the status of a certificate.

10.5 Digital certificates in TLS

Now we will take a look at how certificates are handled within the TLS handshake protocol. We start by discussing TLS extensions, which provide a way to transport data in request-response type message exchanges within TLS. The rest of the section is broadly organized according to the TLS extensions dealing with digital certificates and certification authorities.

10.5.1 TLS extensions

Some TLS messages include the tag-value data structure shown in Listing  10.1 and referred to as an extension. The extension˙type field specifies the type of the extension, and the extension˙data field stores the corresponding data.

Listing 10.1: Data structure of a TLS extension

struct {
   ExtensionType extension_type;
   opaque extension_data<0..2^16-1>;
} Extension;

Typically, TLS extensions are used in a request-response message exchange: client Bob sends an extension request in his ClientHello message, and server Alice replies with an extension response in her ServerHello, EncryptedExtensions, HelloRetryRequest, or Certificate message.

If server Alice sends an extension request in her CertificateRequest message, client Bob may respond with a Certificate message.

10.5.2 Encrypted extensions

In TLS 1.3 handshake, server Alice sends the EncryptedExtensions message immediately after her ServerHello message. At this point, Alice and Bob have agreed on a secret and have subsequently derived a shared key. The EncryptedExtensions message is the first encrypted message in the TLS handshake. The data structure is shown in Listing 10.2.

Listing 10.2: TLS encrypted extension data structure

struct {
   Extension extensions<0..2^16-1>;
} EncryptedExtensions;

10.5.3 Certificate request

If server Alice authenticates herself to client Bob using a certificate, she may request Bob to present his certificate too. This request must be sent directly after EncryptedExtensions and the corresponding message has the structure shown in Listing 10.3.

Listing 10.3: Server Alice’s certificate request

struct {
   opaque certificate_request_context<0..2^8-1>;
   Extension extensions<2..2^16-1>;
} CertificateRequest;

The preceding is a good illustration of how optional interaction between communicating parties can be added to a cryptographic protocol to further improve security, if this is desired by Alice and Bob. Requiring client Bob to also prove his identity, in this case using a digital certificate, results in a mutual authentication where both client Bob as well as server Alice can verify each other’s identity and so know whom they are communicating with.

10.5.4 Signature algorithms in TLS certificates

In Chapter 9, Digital Signatures, we learned that TLS 1.3 has two extensions for client Bob to specify which signature algorithms shall be used in the TLS session with server Alice:

• The signature˙algorithms extension specifies algorithms to be used for signatures in CertificateVerify messages
• The signature˙algorithms˙cert extension, if used, specifies algorithms to be used for signatures in certificates

The signature˙algorithms extension was introduced in TLS version 1.2 so that the client can indicate to the server which signature algorithms and hash algorithms can be used in digital signatures of that particular TLS session.

The signature˙algorithms˙cert extension was added in TLS version 1.3 so that TLS endpoints that support different sets of algorithms for certificates and in the TLS itself can clearly communicate their capabilities. RFC 8446 specifies that TLS 1.2 implementations should also process this extension.

In these extensions, the extension˙data field contains a list of SignatureScheme values in a descending order of client Bob’s preference. Each such value is a single signature algorithm that Bob is willing to verify.

Bob may use signature˙algorithms˙cert extension to tell Alice which certificate-specific signature algorithms he wants to use to validate X.509 certificates. Otherwise, if the signature˙algorithms˙cert is omitted, algorithms specified in signature˙algorithms are also used for calculating and verifying digital signatures in certificates.

As a result, using the signature˙algorithms˙cert extension, TLS clients that support different sets of algorithms for certificates and in the TLS itself can signal this to a TLS server in an unambiguous way.

If client Bob wants server Alice to authenticate herself using a certificate, he must send at least the signature˙algorithms extension (optionally, Bob may also send Alice the signature˙algorithms˙cert extension).

If server Alice can only authenticate herself using a certificate but client Bob sends no signature˙algorithms extension, then Alice immediately aborts the TLS handshake and sends a missing˙extension alert.

10.5.5 Certificates and TLS authentication messages

Recall that at the end of the TLS 1.3 handshake, client Bob and server Alice exchange authentication messages shown in bold in Figure 10.7. The same set of messages is used whenever client Bob and server Alice perform certificate-based authentication (authentication based on a pre-shared key happens as a side effect of the key exchange).

Figure 10.7: Full TLS 1.3 handshake with authentication messsages shown in bold

The set of authentication messages is composed of the Certificate, CertificateVerify, and Finished messages, as shown in Listing 10.4. These messages are protected using keys derived from client˙handshake˙traffic˙secret and server˙handshake˙traffic˙secret. Upon receiving server Alice’s authentication messages, client Bob responds with his authentication messages.

Listing 10.4: Authentication messages in TLS handshake

enum {
   X509(0),
   OpenPGP_RESERVED(1),
   RawPublicKey(2),
   (255)
} CertificateType;

struct {
   select (certificate_type) {
       case RawPublicKey:
           /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
           opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
       case X509:
           opaque cert_data<1..2^24-1>;
   };
   Extension extensions<0..2^16-1>;
} CertificateEntry;

struct {
   opaque certificate_request_context<0..2^8-1>;
   CertificateEntry certificate_list<0..2^24-1>;
} Certificate;

struct {
   SignatureScheme algorithm;
   opaque signature<0..2^16-1>;
} CertificateVerify;

struct {
   opaque verify_data[Hash.length];
} Finished;

The Certificate message contains either Alice’s or Bob’s certificate and any per-certificate extensions. This message is omitted by server Alice if certificate-based authentication is not used in that TLS session and by client Bob if Alice did not send the CertificateRequest message (which would indicate that Alice wants Bob to authenticate himself using his digital certificate).

The CertificateVerify message carries the digital signature over the entire TLS handshake. The signature is generated using the private key that corresponds to the public key in the respective Certificate message. As an example, the signature in Alice’s CertificateVerify message is generated using Alice’s private key. Alice’s corresponding public key is contained in the certificate that Alice sends to Bob in her Certificate message. If certificate-based authentication is not used, this message is omitted.

The Finished message contains a so-called Message Authentication Code (MAC) over the entire TLS handshake. We will cover message authentication codes in detail in the next chapter on Hash Functions and Message Authentication Codes. For now, it suffices to know that they can be used as cryptographically secure checksums.

With this, Alice and Bob use the Finished message to verify that all handshake messages sent by Bob were not manipulated en route and were indeed received by Alice, and vice versa. As a result, the Finished message provides key confirmation, binds the identities of Alice and Bob to the exchanged secret keys, and, if the pre-shared key mode is used, authenticates the TLS handshake.

More generally, the Finished message illustrates a best practice in the design of cryptographic protocols where at the end of the protocol, the communicating parties verify that they had the same view of their interaction, for example, that no other messages were received except those that were actually sent and that no messages were lost.

10.5.6 The Certificate message

The Certificate message contains the endpoint’s – server Alice’s or client Bob’s – certificate chain.

Server Alice sends the Certificate message to client Bob whenever the key exchange Alice and Bob agreed upon uses certificate-based authentication. This is the case for all TLS 1.3 key exchange methods except TLS handshake based on a pre-shared key.

Client Bob sends a Certificate message if and only if server Alice has requested him to authenticate himself using the CertificateRequest message. If Alice requested Bob authenticate himself using a certificate, but Bob has no suitable certificate at hand, he sends a Certificate message containing no certificates. More precisely, Bob sends a Certificate message with the certificate˙list field having a length of zero. The structure of the Certificate message is shown in Listing 10.5.

Listing 10.5: Structure of the Certificate message

enum {
   X509(0),
   RawPublicKey(2),
   (255)
} CertificateType;
struct {
   select (certificate_type) {
       case RawPublicKey:
           /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
           opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
       case X509:
           opaque cert_data<1..2^24-1>;
         };
   Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
   opaque certificate_request_context<0..2^8-1>;
   CertificateEntry certificate_list<0..2^24-1>;
} Certificate;

If the Certificate message is received in response to a CertificateRequest message, the certificate˙request˙context variable stores an identifier for the certificate request. When server Alice requests client Bob authenticate himself using a certificate, Alice can supply an additional context, which client Bob would return to bind his certificate to Alice’s request. If client Bob does not authenticate himself using a certificate (which is the most common case on the internet), certificate˙request˙context has a length of zero.

The certificate˙list field contains a chain of CertificateEntry data structures. Each CertificateEntry stores a single digital certificate together with its corresponding set of extensions.

The extensions field consists of certain extension values for a CertificateEntry, including OCSP status for server certificates and the SignedCertificateTimestamp extensions. The extensions in the Certificate message from server Alice must match those found in client Bob’s ClientHello message. Similarly, extensions in the Certificate message from client Bob have to match those in server Alice’s CertificateRequest message.

Server Alice’s certificate˙list must never be empty. In contrast, client Bob may send an empty certificate˙list if he has no appropriate certificate to respond to server Alice’s authentication request with.

10.5.7 The CertificateVerify message

The CertificateVerify message provides explicit proof that the sender—either client Bob or server Alice—indeed has the private key corresponding to its certificate. Moreover, the CertificateVerify message allows you to verify the integrity of the TLS handshake up to this point. Listing 10.6 shows the structure of the CertificateVerify message:

Listing 10.6: Structure of the CertificateVerify message

struct {
   SignatureScheme algorithm;
   opaque signature<0..2^16-1>;
} CertificateVerify;

The algorithm field in Listing 10.6 holds the signature algorithm used to generate the signature. The content covered by the signature includes the TLS handshake context and the certificate.

The signature is computed over a concatenation of the following data:

• A string consisting of 64 bytes having a value of 32
• The TLS 1.3, server CertificateVerify string for server Alice’s signature and the TLS 1.3, client CertificateVerify string for client Bob’s signature
• A single byte having value 0 that acts as a separator
• The content to be signed

The context string secures TLS against cross-protocol attacks by providing a way to differentiate between the signatures generated in different contexts.

Server Alice sends the CertificateVerify message when she authenticates herself to client Bob using a certificate. Client Bob sends CertificateVerify whenever he authenticates himself using a certificate. If sent, the CertificateVerify message is transmitted immediately after the Certificate message and immediately before the Finished message.

For example, if the transcript hash consists of 32 bytes having the value 01, the content covered by the signature in server Alice’s CertificateVerify message reads like this:

2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966
79
00
0101010101010101010101010101010101010101010101010101010101010101

The sender of the CertificateVerify message computes the signature by taking the following data as input:

• The data covered by the signature
• The private key corresponding to the public key in the sender’s certificate transmitted in the previous TLS message

When server Alice sends the CertificateVerify message, the digital signature algorithm Alice uses must be one of the algorithms that client Bob specified in his signature˙algorithms extension.

When client Bob sends the CertificateVerify message, the digital signature algorithm must be among those specified in the supported˙signature˙algorithms field of the signature˙algorithms extension in the CertificateRequest message.

The above illustrates how TLS addresses potential compatibility issues in a heterogeneous environment where different clients must communicate with different servers, with the endpoints likely supporting different digital signature algorithms.

The receiver of the CertificateVerify message verifies the digital signature. The verification process takes the following data as input:

• The data covered by the signature
• The public key in the certificate from the corresponding Certificate message
• The digital signature in the received CertificateVerify message

If the verification is not successful, the receiver terminates the TLS handshake and sends a decrypt˙alert alert to the other communicating party.

10.5.8 Server certificate selection

When server Alice sends her certificate to client Bob, the certificate must have the following properties:

• The certificate must be an X.509v3 certificate (unless Alice and Bob negotiate a different certificate type).
• The public key of the server must be compatible with the selected authentication algorithm from client Bob’s signature˙algorithms extension. Possible signature algorithms are RSA, ECDSA, or EdDSA.
• The Certificate Key Usage field (discussed earlier in this chapter, in the X.509V3 Extension Fields section), must include the digitalSignature value. The signature algorithm must match the signature scheme specified in Bob’s signature˙algorithms and signature˙algorithms˙cert extensions.
• The server˙name and certificate˙authorities extensions are used to select the certificate.

All certificates sent by server Alice must be signed by the digital signature algorithm specified by client Bob. Self-signed certificates are not validated and, therefore, can be signed with any digital signature algorithm.

If server Alice is not able to provide a certificate chain where all certificates are signed using the signature algorithms specified by client Bob, she continues the TLS handshake by sending Bob a certificate chain of her choice that might use signature algorithms not supported by client Bob.

If Bob is not able to construct a valid certificate chain using the certificates provided by Alice and decides to abort the TLS handshake, he sends a corresponding certificate-related alert. The default alert is unsupported˙certificate.

10.5.9 Client certificate selection

When client Bob sends his certificate to server Alice, Bob’s certificate must have the following properties:

• The certificate must be an X.509v3 certificate (unless Alice and Bob negotiate a different certificate type).
• If the certificate˙authorities extension was present in the CertificateRequest message, at least one of the certificates in Bob’s certificate chain should be issued by one of the specified certification authorities.
• The certificate must be signed using one of the digital signature algorithms specified in the signature˙algorithms extension of the CertificateRequest message.
• If the CertificateRequest message from server Alice has a non-empty oid˙filters extension, the client certificate must contain all extension OIDs recognized by client Bob. This extension is covered in detail in the next subsection, OID filters.

This concludes the list of requirements on client certificates in TLS. These requirements become relevant only if server Alice sends a CertificateRequest message to client Bob.

10.5.10 OID filters

Using the oid˙filters extension, server Alice can send client Bob a set of pairs (Object Identifier (OID), value) that Bob’s digital certificate should match. If Alice decides to do so, she sends the oid˙filters extension in her CertificateRequest message.

The structure of the oid˙filters extension is shown in Listing 10.7. The filters variable holds a list of certificate extension OIDs with their corresponding values as defined in RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

Listing 10.7: Structure of the oid_filters extension

struct {
   opaque certificate_extension_oid<1..2^8-1>;
   opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;

struct {
   OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;

If server Alice sends client Bob a non-empty oid˙filters extension, the certificate included in Bob’s response must contain all specified extension OIDs that Bob recognizes.

All specified values must be present in server Bob’s certificate for every extension OID that Bob is able to recognize. According to the TLS 1.3 specification, Bob must ignore any unrecognized certificate extension OID.

If client Bob ignores some of the required certificate extension OIDs and, as a result, the certificate that Bob presents to server Alice does not satisfy her request, Alice may either continue with the TLS handshake without appropriate certificate-based client authentication or terminate the TLS handshake and transmit the unsupported˙certificate alert.

10.5.11 Receiving a Certificate message

TLS endpoints have to follow certain rules when validating digital certificates. If client Bob receives an empty Certificate message from server Alice, Bob must immediately terminate the TLS handshake and send the decode˙error alert.

If, on the other hand, client Bob sends an empty Certificate message to server Alice, Alice is free to decide whether she continues the TLS handshake without proper authentication of client Bob—or, more precisely, a party claiming to be Bob—or terminates the TLS handshake and sends the certificate˙required alert.

Moreover, if the certificate chain received from client Bob is flawed—as an example, if it is not signed by a certification authority that Alice knows and trusts—Alice may continue or terminate the TLS handshake as she prefers.

If Alice or Bob receives a certificate that they would need to validate using any signature algorithm that uses the insecure MD5 hash function, they must immediately terminate the TLS handshake and send the bad˙certificate alert. The TLS 1.3 specification recommends Alice and Bob do the same if they receive a certificate that must be verified using a SHA-1 based signature algorithm.

Instead, the TLS 1.3 specification recommends all TLS endpoints transition to signature algorithms that use SHA-256 or stronger hash functions. In addition, TLS 1.3 allows a digital certificate that contains a key for one signature algorithm to be signed with a different signature algorithm.

10.3 Main components of a public-key infrastructure

A Public-Key Infrastructure (PKI) is a system that is able to issue, distribute, and validate certificates. While a CA is an important part of a PKI, the two terms are not the same. In order to limit the potential damage in case of a compromise, it is customary that the various operational tasks of a PKI are taken over by logically separate functional entities within the PKI, which have their own private keys. One of these is the CA. We will now take a closer look at all these entities:

• Certification Authority (CA): Within a PKI, the CA is responsible for creating, signing, and issuing the certificates. Moreover, all certificates issued by the CA should be archived in a secure manner.

When looking at Figure 10.4, it quickly becomes clear that a CA is a single point of failure within a PKI. It is therefore mandatory to run the CA within a specially secured environment with strictly enforced access control rules. Nevertheless, there have been incidents in the past where CAs have been compromised by an attacker, and we will discuss one such incident in the next section.

• Registration Authority (RA): The RA is the instance Alice sends her certificate signing request in the course of the enrollment. The RA checks the data provided by Alice in the CSR. Depending on the security level of the requested certificate, this check can happen online or offline (for example, by Alice having to appear in person at the RA and present her passport). If the check is successful, the data is forwarded to the CA, which generates a corresponding certificate.
• Directory Server (DIR): The directory server stores the certificates issued by the CA and makes them publicly available over a searchable directory.
• Validation Authority (VA): The VA is responsible for issuing CRLs and/or running the OCSP server. As such, they form another critical component of the PKI and should be secured accordingly.
• Time Stamping Server (TSS): A TSS signs documents along with the current time and date. Therefore, it can be used to prove that a document existed at a certain time. If Alice, for example, loses her private key and revokes her certificate, it is important to know which of the documents Alice has signed previously already existed before she revoked her certificate. Otherwise, Alice could claim that basically all documents she has ever signed were actually not signed by herself but by an attacker who stole her private key.

Another application is the so-called Signed Certificate Timestamps (SCTs). By way of an SCT, the CA records the exact time a certificate was issued. SCTs can be delivered to a relying party either by directly embedding them into the certificate’s extension (see Figure 10.5), by sending them in a TLS extension during the TLS handshake or as part of a response to an OCSP stapling request [51].

Figure 10.5: SCTs embedded in a certificate