Path validation and validity models

In this section we explain how the validity of a certification path is evaluated. The outcome of path validation determines, whether a relying entity considers the public key certified within an end entity certificate as authentic or not.

There are two requirements for the validity of a certification path. The first is that for each digital signature on a certificate in the path, the corresponding verification algorithm Ver on input of the signature, the certificate (which is the signed message) and the issuer’s public key must output 1, i.e., the signature is a valid signature under the given public key. This basic requirement is assumed to hold in the following.

The second requirement is the semantic correctness of the certification path. It is evaluated according to a validity model. The validity model specifies how the revo- cation information and the validity periods of the involved certificates are evaluated. In literature, three validity models can be found [6], which we shortly explain.

Shell model _{To formally describe the models let n ∈ N be the length of the} certification path. C1is the self-signed certificate of the Root CA. Cnis the certificate

of the end entity. We denote by Ti(k) the starting date of the validity period of Ck

and by Te(k) its expiration date. Tv denotes the time of verification. The shell

Def inition 2.1 (Shell model). A certification path is valid at verification time Tv

if all certificates in the certification path are valid at time Tv: Ti(k) ≤ Tv ≤ Te(k)

for all 1 ≤ k ≤ n and no certificate is revoked at time Tv.

time Root CA certificate Sub CA certificate end entity certificate Ts Tv

Figure 2.2: Shell model. The signature generation time is Ts and the verification time is Tv. Vertical arrows show the point in time used for validation of the certificates.

For a successful verification, all certificates in the path have to be valid at the time of verification. Thus, a relying entity can use the public key pk_n certified in Cn

to encrypt messages or to verify signatures (depending on the allowed key usage) during the time period where all certificates are valid. Currently, most applications implement the shell model for certification path validation [6]. In particular, RFC 5280 [83] establishes the shell model as the standard validity model for the Web PKI.

Note that in the shell model a certification path becomes invalid once one of the certificates in the path expires or is revoked. This subsequently invalidates all signatures generated by subordinate entities. However, there are scenarios where this is not acceptable. For example, when data authenticity and non-repudiation are desired security goals. These properties must often be preserved for indefinite time periods. Therefore, two additional validity models have been defined for (end entity) signature validation. These models explicitly consider the points in time, where signatures have been generated.

Extended shell model In the following, let Ts be the time of signature generation

by an end entity. Note that while the knowledge of Tv is trivial for a verifier (the

relying entity), the knowledge of Ts is not, because Ts is not provided by a digital

signature and thus requires a trustworthy time information, such as a time-stamp by a trusted third party (see Section 2.2.7). The end entity signature is also assumed to be a valid signature under the end entity’s public key. Then, the extended shell model is defined as follows. Figure 2.3 depicts the model.

Def inition 2.2 (Extended shell model). A digital signature is valid at verification time Tv if all certificates in the certification path are valid at time Ts: Ti(k) ≤ Ts ≤

Te(k) for all 1 ≤ k ≤ n and no certificate in the path is revoked at time Ts.

time Root CA certificate Sub CA certificate end entity certificate Ts Tv

Figure 2.3: Extended shell model. The signature generation time is Tsand the verification time is Tv. Vertical arrows show the point in time used for validation of the certificates.

In the extended shell model (also called hybrid or modified shell model) Ts is

used instead of Tv during validation. This means that the certificates in the path

are checked for validity and revocation status at generation time of the end entity signature.

To implement this model, the signature generation time needs to be tied to the signature such that it can be checked that the certificates in the path were not revoked and were valid at that time. Furthermore, as the expiry of a certificate does not invalidate previously generated signatures, revocation information for the involved certificates must be preserved beyond certificate expirations, which in gen- eral is not necessary when applying the shell model. This also holds for the chain model explained in the following.

Chain Model The chain model is defined as follows and depicted in Figure 2.4.

Def inition 2.3 (Chain model). A digital signature is valid at verification time Tv

if:

1. The end entity certificate Cnis valid at the signing time Ts: Ti(n) ≤ Ts ≤ Te(n)

and Cn is not revoked at time Ts.

2. Every CA certificate in the certification path is valid at the issuance time of the subordinate certificate in this path: Ti(k − 1) ≤ Ti(k) ≤ Te(k − 1) and the

certificate Ck−1 is not revoked at time Ti(k) for all 2 ≤ k ≤ n.

In the chain model, any signature in the certification path is validated using its signature generation time, i.e. the issuance time of the certificate. The start date

time Root CA certificate Sub CA certificate end entity certificate Ts Tv

Figure 2.4: Chain model. The signature generation time is Ts and the verification time is Tv. Vertical arrows show the point in time used for validation of the certificates.

of the validity period can be used as an approximation. Thus, this date must lie within the validity period of the superordinate certificate.

If time-stamps are used in the implementation of the chain model, one time-stamp is required for every signature within the certification path [6]. This is because different dates prior to the signature generation time of the end entity signature have to be considered for the path validation. Both, the extended shell model as well as the chain model allow signature validation at any point in the future.