Validity Models of Electronic Signatures and their Enforcement in Practice

Transcription

1 Validity Models of Electronic Signatures and their Enforcement in Practice Harald Baier 1 and Vangelis Karatsiolis 2 1 Darmstadt University of Applied Sciences and Center for Advanced Security Research Darmstadt, Mornewegstraße 32, D Darmstadt, Germany baier@cased.de 2 Technische Universität Darmstadt, Department of Computer Science, Hochschulrstraße 10, D Darmstadt, Germany karatsio@cdc.informatik.tu-darmstadt.de Abstract. An electronic signature is considered to be valid, if the signature is mathematically correct and if the signer s public key is classified as authentic. While the first property is easy to decide, the authenticity of the signer s public key depends on the underlying validity model. To our knowledge there are three different validity models described in various public documents or standards. However, up to now a formal description of these models is missing. It is therefore a first aim of the paper at hand to give a formal definition of the common three validity models. In addition, we describe which application in practice requires which validity model, that is we give a mapping of use cases to validity models. We also analyse which standard implements which model and show how to enforce each model in practice. Keywords: X.509 certificate, signature validity, certification path validation, validity models, certificate revocation. 1 Introduction Electronic communication disseminates more and more in our private and commercial life. In order to achieve classical security goals like authenticity, integrity, and non-repudiation, asymmetric electronic signatures are used in practice. However, the question if an electronic signature is valid is not as trivial to answer as one may believe at a first glance. It is a common approach to postulate two properties for an electronic signature to be valid: First, a signature has to be mathematically correct. This means that the mathematical algorithm (e.g. RSA [RSA78], DSA [NT94], ECDSA [ANS05]) verifies the signature successfully using the signer s public key. Second, the signer s public key classifies as authentic and the corresponding private key is under exclusive control of its owner. In this paper we concentrate on the second aspect of validity of digital signatures, that is we exclude the algorithmic level and concentrate on the semantical

2 level. The topic we are addressing is therefore whether a mathematically correct digital signature is also valid. There are different reasons why a mathematically correct signature may be considered to be invalid. For instance, let PubKey S be the signer s public key which is certified in a public key certificate that has expired regularly at a certain point of time (say e.g. T e ). Does the validation procedure of a signature at time T v with T v > T e using PubKey S yield the value valid or invalid? Alternatively, let the certificate of PubKey S be marked as revoked at T r. Is a digital signature which is verified at T v > T r valid or invalid? And if there may be different validation answers, which answer is the best with regard to the use case? In general, the validity of a digital signature depends on the underlying model. If the verifier switches the validity model, a valid signature may become invalid and vice-versa. In different PKI standards, books, and publications three different validity models are mentioned: The shell model (e.g. PKIX working group, [CSF + 08]), the modified shell model ([PPR08]), and the chain model ([BNe]). However, to our knowledge, a formal definition is missing. It is therefore a first aim of this paper to formalize the three known validity models. Our next aim is to provide the technical details for implementing these models and enforcing therefore validity of electronic signatures. We see that the necessary steps require different techniques, like time-stamping, building of certification paths, and collecting revocation information as well as archiving services. We also briefly discuss the effect of the use of the different models on the revocation methods of a PKI. Additionally, although the validity property of an electronic signature is of fundamental importance for use in practice, there is no discussion, which practical application requires which validity model. Our next contribution is therefore the classification: Use Case Security Goal Validity Model. For instance, in several contexts it is desired to create a digital signature which can be verified in the long term. The current PKI standard that is used in the internet ([CSF + 08]) does not allow this. According to [CSF + 08], digital signatures can only be validated successfully as long as the certificates in the certificate chain are valid. This paper is organised as follows: In order to discuss the validity models, we define a sample public key infrastructure and our notation in Section 2. Then, in Section 3 we formalize the three validity models, discuss their details, and give a comparison of them. Section 4 discusses the details of the technical realisation of the three models, that is how to implement them. The effect of revocation on these models is examined in Section 5. The applicability of the models in different contexts is discussed in Section 6. We conclude our paper in Section 7. 2 A Sample Public Key Infrastructure and Notation In order to discuss each validity model, we consider a sample public key infrastructure (PKI) as follows: Our sample PKI has one root certification authority (CA). This CA is the trust anchor and has issued a self-signed certificate. The

3 root CA has issued two certificates to two other subordinate CAs. The subordinate CAs issue certificates only to end-entities. This setup is depicted in Figure 1. Root CA Subordinate CA 1 Subordinate CA 2 End-Entity A End-Entity B Root CA End-Entity C Fig. 1. A sample PKI structure Subordinate Subordinate In Figure 2 sample validity periodsca of1three certificatesca are 2 given. In what follows, we make use of the following notation: The common PKI standard X.509 ([IT05]) makes use of the two certificate fields NotBefore and NotAfter to define the validity Root CAperiod of the certificate. By T i we denote the date as given by NotBefore Subordinate CA (time 1 of issuance) End-Entity and bya T e we End-Entity denote the B date asend-entity given byc NotAfter (date of regular expiry). For example, we consider the certificate of the root End-entity A CA. From Figure 2 we conclude T i = and T e = (for presentation reasons, we neglect the time within a day). We make use of this t hierarchy and validity periods for the rest of this work in all our examples Root CA Subordinate CA 1 End-Entity A t Fig. 2. Certificate of entities and their validity The validity of a digital signature is of interest for the entity who verifies the signature. We call this entity the verifier or relying party. The point in time when the relying party verifies the signature is called the verification time. We denote the verification time by T v. On the other hand, the time when a signature

4 is calculated is called signing time. If a signature is generated by an end-entity, we denote the signing time by T s. However, if the signature is calculated by a CA over a certificate, we assume that the signing time is the issuance time and we denote it as above by T i. We assume that the verification time is always later than the signature time, that is T v > T s holds. We assume that every certificate in the chain has a mathematical correct digital signature. Moreover, the signer is always end-entity A while the verifier is always end-entity C. In addition, signatures calculated by the end-entity over data structures are also mathematically correct. Finally, the certification path starts with the self-signed certificate of the root CA which is the trust anchor for both the signer and the verifier. Note that the validation algorithm specified in [CSF + 08, Sec. 6] does not contain the certificate of the trust anchor in the certification path. We further discuss this behaviour in Section 4. To formalize our presentation we subscript each certificate holder with respect to his location within the certification path. Let N be the length of the certification chain (in our sample PKI, we have N = 3). Then we assign the index k = 1 to the root CA and the index k = N to an end-entity. We write Cer(k) for the k-th certificate in the chain. By T i (k) and T e (k) we denote the issuance date and expiry date of Cer(k), respectively. We assume T i (k) T i (k + 1) for all 1 k N 1 (typically this means that a CA certificate is valid when this CA issues a certificate). Finally, we define two validity periods: First, by Val S we denote the time period, when an end-entity may generate a valid signature for a document (that is the signature is valid for T v = T s ). Second, by Val V (T s ) we denote the time period, when a signature generated at T s Val S is verified successfully by the relying party. 3 The Three Common Validity Models in Literature In this section we introduce formally the three validity models which may be found informally in literature. 3.1 The Shell Model This model is the one commonly met in most PKI applications. It is used, for instance, in [IT05] or [CSF + 08] to verify digital signatures. In this model the verification time T v of a digital signature is the basis for the validation decision. Definition 1 (Shell Model). A digital signature is valid at verification time T v if: 1. All certificates in the certification chain are valid at T v : T i (k) T v T e (k) for all 1 k N and no certificate is revoked at T v. 2. The end-entity certificate Cer(N) is valid at signing time T s : T i (N) T s T e (N) and it is not revoked at T s.

5 The German Federal Network Agency (GFNA) has published a presentation (see [BNe]) for illustrating the shell model. The GFNA explicitly requires that all certificates in the certificate chain are valid at signing time, too. We show, that this is equivalent to our definition. First, let the agency s definition hold. Then all certificates in the chain are valid at signing time T s, that is our definition holds. Now let property 2 of our definition be true and assume a signature is valid at verification time T v. Then the property T i (k) T i (k + 1) for all 1 k N 1 in the certificate chain and property 2 of Definition 1 imply that all certificates in the certificate chain are valid at signing time. We consider the example of Figure 2 and suppose that the end-entity has signed a document at T s = If the relying party verifies this signature at T v = this signature is classified as valid within the shell model. However, if the same signature is verified at T v = , it is considered to be invalid, because T v > T e (1), that is the certificate of the root CA is expired. Note that the validity periods Val S and Val V of the shell model are Val S = N [T i (k), T e (k)] = [T i (N), min{t e (k) : 1 k N}] and (1) k=1 Val V (T s ) = [T s, min{t e (k) : 1 k N}] for all T s Val S, (2) if no certificate in the chain is revoked. Our sample PKI yields Val S = [ , ] (3) Val V (T s ) = [T s, ] for all T s Val S. (4) We point out that the most prominent standard which uses the shell model (the PKIX standard, [CSF + 08]) does not require the second property of Definition 1. We assume that this is due to the fact that the typical application of [CSF + 08] is verifying the authenticity of a claimed identity during the handshake of an internet protocol. Then one may assume T s T v, and property 1 of Definition 1 implies property 2. We call this variant of the shell model the internet shell model. However, if we abandon this demand, an invalid created signature may become valid. An example of such a signature in our sample PKI is one created by end-entity A at and verified at The internet shell model is mostly used by applications that do not store or do not evaluate the signature time. Such an application is the PKIX validation algorithm [CSF + 08, Sec. 6]. The signing time T s is not provided as an input and therefore it is never evaluated. A detailed overview of this validation algorithm is given in Section The Modified Shell Model This model is sometimes called hybrid model, too. Although not explicitly stated, it is found e.g. in [PPR08]. In the modified shell model the signing time T s is the basis for the validation decision.

6 Definition 2 (Modified Shell Model). A digital signature is valid at verification time T v if all certificates in the certification chain are valid at T s : T i (k) T s T e (k) for all 1 k N and no certificate is revoked at T s. We consider our sample PKI of Figure 2 and suppose that the end-entity has signed a document at T s = If the relying party verifies this signature at T v T s this signature is always classified as valid within the modified shell model. In general, the modified shell model has, in contrast to the shell model, the fundamental property that a signature, which is valid at T s remains valid for all the time. Therefore, the validity period Val V (T s ) is always Val V (T s ) = [T s, [ for all T s Val S. It is easy to see that Val S = N [T i (k), T e (k)] = [T i (N), min{t e (k) : 1 k N}], (5) k=1 if no certificate in the chain is revoked. Our sample PKI yields Val S = [ , ]. 3.3 Chain Model The chain model is e.g. illustrated in [BNe]. Unlike the other two models, the dates when signatures are created by each party (end-entity and certification authorities) are affecting the validity of a signature. Definition 3 (Chain Model). A digital signature is valid at verification time T v if: 1. The end-entity certificate Cer(N) is valid at the signing time T s : T i (N) T s T e (N) and Cer(N) is not revoked at T s. 2. Every CA certificate in the chain is valid at the issuance time of the subordinate certificate in this chain: T i (k 1) T i (k) T e (k 1) and the certificate Cer(k 1) is not revoked at T i (k) for all 2 k N. Again, we have a look at our sample PKI. If the end-entity signs documents at , , or , all signatures are verified successfully within the chain model. The chain model has the same fundamental property as the modified shell model: Once a signature is valid at signing time T s it remains valid for all the time. Thus, again the validity period Val V (T s ) of the chain model is Val V (T s ) = [T s, [ for all T s Val S. Additionally, the signing period Val S is Val S = [T i (N), T e (N)], (6) if the end-entity certificate Cer(N) is not revoked. Our sample PKI yields Val S = [ , ]. We point to an interesting property of the chain model: If the end-entity certificate Cer(N) is issued and Cer(N 1) is valid at issuing time T i (N), a revocation of a certificate Cer(k) (1 k N 1) does not affect the validity of a signature generated by the end-entity.

7 3.4 Additional Constraints Certificate policies of various public key infrastructures do not allow the issuance of certificates with validity longer than their issuer s certificate, that is the policies require T e (k + 1) T e (k) for all 1 k N 1 (see for example [Tha06, Sec ]). Also some applications, like Certificate Services [Tec05], prohibit this behaviour. In this case Val S is determined for all models exclusively by the validity period of the end-entity certificate Cer(N). More precisely, we have Val S = [T i (N), T e (N)]. This is because the certificate Cer(N) is then the first certificate to expire and in all models the end-entity is not able to produce any valid signatures after the expiration of its certificate. For the shell model the Val V (T s ) is limited by the expiration date of the end-entity certificate, that is Val V (T s ) = [T s, T e (N)]. 3.5 Comparison of the Models We end this section with an overview of the periods Val S and Val V for each model (see Table 1). From this table the differences among the three models regarding these periods can be seen. The shell model and the modified shell model have a shorter period for producing a valid signature than the chain model. The modified shell model and the chain model have a longer period for verifying a signature. For this reason these two models are important for the long-term verification of digital signatures. Table 1. Overview of the periods Val S and Val V for all validity models. Shell Model Modified Shell Chain Model Model Val S (from) Val S (until) Val V (T s) (until) Note that the necessity to verify signatures for a long period by using the shell model exists. To address this topic the private key usage period extension was specified in the previous PKIX specification [HPFS02, Sec ]. This extension is not specified at all in the newer PKIX specification [CSF + 08]. With this extension it is possible to limit the signing period for the private key that corresponds to the public key in the certificate. Therefore certificates could be issued with a long validity period (for example 50 years) but a short private key usage period (for example 2 years). Therefore it is possible to validate a signature using the shell model for 50 years but it is possible to sign only for two years. However, this approach is alone not sufficient for implementing the other two models. As we see in the next section, various techniques are necessary for realising the verification of electronic signatures in the long-term.

8 4 Technical Implementation of the Models In this section we show how to put each of the three validity models into practice. We focus on the modified shell model and the chain model as implementations of the shell model are well-known. At the end of this section we discuss alternative implementation algorithms. 4.1 Shell Model The shell model is implemented by most applications. Its implementation is based on the basic path validation algorithm described in Section 6 of the PKIX standard [CSF + 08]. Most implementations ignore the signing time T s. They only consider the special case of the shell model for which the signing time and the verification time are the same, i.e. T s T v. The implementation details of the PKIX validation procedure are well-known and we do not discuss this further. 4.2 Modified Shell Model We propose to implement the modified shell model using the CAdES (CMS Advanced Electronic Signatures) specification. CAdES is an ETSI technical specification [ETS08] and a request for comments [PPR08]. It specifies the mechanisms and the format for electronic signatures that can remain valid for a long period of time. These signatures are called advanced electronic signatures and their format conforms to the Cryptographic Message Syntax specification (CMS, [Hou04]). There are different types of CAdES signatures defined in [PPR08]. We next introduce the signature types which are relevant for our purposes. First, CAdES assumes that a document is signed with the signer s private key. This is the basic electronic signature (CAdES-BES). It is possible to include some attributes which are also signed. For instance the policy according to which this signature should be validated can be included as a signed attribute. This is the explicit policy-based electronic signature (CAdES-EPES). Afterwards this signature is time-stamped (or time marked, but we consider only time-stamping for the rest of this paper). This time-stamp proves that the signature existed before a certain point in time. This is an electronic signature with time (CAdES-T). In order to provide the complete certification path and revocation information, which are necessary to validate the signature, references to this data can be appended to this signature. This is an electronic signature with complete validation data references (CAdES-C). It is also possible to include the referenced data itself, which however leads to increasing the size of the signature. This is an extended long electronic signature (CAdES-X Long). Time-stamps are used to protect the references to the required verification data against future compromise (e.g. of a cryptographic key): Either the whole CAdES-C is time-stamped (CAdES-X-Type 1) or only the references (CAdES- X-Type 2). These two types can be combined with the CAdES-X Long signature,

9 which stores all necessary data, producing two new signature types, namely the CAdES-X Long Type 1 and Type 2. These last two types or the plain CAdES-X Long are finally time-stamped to provide proof of existence before a certain point in time. This is an archival electronic signature (CAdES-A). This signature is regularly time-stamped in order to address weaknesses in cryptographic algorithms or keys. The CAdES specification allows to record the time when a signature is calculated. This is achieved by the first time-stamp. This signature is the CAdES-T. Second, it records all certificates and revocation information, that are necessary for validating a signature, exactly at the point certified by the first time-stamp. This is the CAdES-X Long Type 1 or Type 2 signature which contains a timestamp over this data. Third, this signature is protected for a long period in time by time-stamping it appropriately before the underlying cryptography becomes weak or broken. Therefore, a CAdES-A signature supports verification according to the modified shell model. Our proposed verification procedure is described in Algorithm 1. Algorithm 1 Verification for the Modified Shell Model 1: T s time when a document is claimed to be signed 2: Verify the document signature 3: Verify that the CAdES-T time-stamp matches T s 4: Verify that the CAdES-X Long Type 1 or Type 2 time-stamp matches T s 5: Verify the certification path with revocation checking using the data from the CAdES-X Long Type 1 or Type 2 signature 6: Verify the CAdES-A time-stamp is recent enough 7: Output true if all verifications are correct, false otherwise 4.3 Chain Model We propose to implement the chain model by using CAdES, too. This is due to the fact that CAdES seems to become a broadly accepted standard. However, our algorithm (see Algorithm 2) is more complicated as for the modified shell model. Nevertheless we are not aware of any alternative implementation proposal of the chain model. We explain our algorithm using our sample PKI from Section 2. In this example three CAdES-A signatures need to be calculated. The first is at when the certificate of the subordinate CA 1 is issued. The second is at when the certificate of end-entity A is issued. Finally, the third CAdES-A signature is generated at the signing time T s. The signer (i.e. endentity A) should include the other two CAdES-A signatures. Therefore, the issuing CA (i.e. the subordinate CA 1) should also deliver to end-entity A (along with her certificate) a CAdES-A for this certificate as well as all other CAdES-A signatures that are necessary for verifying the certification path.

10 As a general rule CAdES-A signatures should be managed by the certificate holder. In our example, the first CAdES-A signature from is managed by the subordinate CA 1. This is because it can be re-used by all subordinate end-entities that need to create a signature which can be verified according to the chain model. The CAdES-A about end-entity A s certificate and the one about the document signature are managed by the signer himself. This eliminates the need that a CA administrates CAdES signatures for each certificate that it issues. In addition, the first two CAdES-A signatures can be stored along with each signature that end-entity A creates. For example they can be stored as a signed attribute in the CAdES-BES signature. The advantage of this approach is that these signatures are archived within end-entity A s CAdES-A signature and do not need to be independently archived. Our proposed verification procedure for the chain model is given in Algorithm 2. Algorithm 2 Verification for the Chain Model 1: T s time when a document is claimed to be signed 2: Verify the document signature 3: Verify that the CAdES-T time-stamp matches T s 4: for k = N to 1 do 5: Extract the CAdES-A signature of Cer(k) 6: Verify that the CAdES-A time-stamp is near T s 7: T s T i(k) 8: Verify that the CAdES-T time-stamp of the current CAdES-A matches T s 9: Verify that the CAdES-X Long Type 1 or Type 2 time-stamp matches T s 10: Verify the certification path of length 1 with revocation checking using the data from the CAdES-X Long Type 1 or Type 2 signature 11: end for 12: Verify the CAdES-A time-stamp is recent enough 13: Output true if all verifications are correct, false otherwise For a CA this means practically that every time it issues a certificate it also needs to create a CAdES-A signature for this certificate. Special PKI protocols that support the issuance of CAdES-A signatures when a certificate is issued, as well as their delivery to the end-entity need to be designed. This creates an extreme workload to certification service providers and time-stamping servers. For this reason performance issues need to be addressed and efficient methods that perform these tasks to be developed. 4.4 Alternative Implementations The current wide-spread implementation of the shell model is specified in the PKIX standard [CSF + 08, Sec. 6]. This algorithm has as input a certification path, the current time which is the time of the validation, information about policies and finally information about the trust anchor.

11 There are two important and substantial differences of the PKIX verification algorithm to our Definition 1 of the shell model. First, the validity of the certificate of the trust anchor is not considered at all. This is because the PKIX verification algorithm excludes the certificate of the trust anchor from the certification path. The trusted public key and associated key parameters, the algorithm of the key, the name of the issuer, and the signing algorithm (see also [CSF + 08, Sec ]) are given as input to the algorithm. These are considered valid and trusted by the verifier and they may be extracted from the trust anchor s certificate. A second important difference between the PKIX verification routine and our definition is that the PKIX algorithm does not consider the signing time T s (or it assumes that signing and verification time are identical). Therefore it is possible for users to sign a document, when they do not possess a valid certificate. However, if T i (k) T v T e (k) for all 1 k N, then the signature may be considered to be valid at T v according to the PKIX verification algorithm (if no certificate in the chain is revoked). The PKIX algorithm is implemented by many applications and therefore we modify the PKIX algorithm to verify according to the modified shell model and the chain model. Note that these modifications are on the level of the algorithm. We assume that the certificates and revocation information have been obtained from a reliable source. This source can provide guarantees that this data can be used for the purpose of verifying signatures calculated long before the current date. Moreover, the signing-time of the document is also provided and is trustworthy. The complete and secure technical implementation of those models (without the above mentioned assumptions) has already been given in Sections 4.2 and 4.3. Modified Shell Model It is sufficient to set the signing time T s as input to the PKIX algorithm (instead of the verification time T v ). The rest of the PKIX algorithm remains unchanged. We point out that this modification does not check whether the trust anchor certificate is valid at T s. For changing this behaviour the validity period of the trust anchor s certificate needs to be supplied as an additional input in the Initialization step of the PKIX algorithm and a check needs to be added. This checks whether T s is inside the validity period which was supplied as an additional input. Chain Model In order to implement the chain model using the PKIX algorithm, four steps need to be taken: 1. The current date/time input of the algorithm is deleted as well as those steps of the algorithm that make use of this variable. A new variable is defined. This is the validity period. This variable is initialised with the period between the notbefore and notafter field values of the trust anchor certificate. 2. In step Basic Certificate Processing ([CSF + 08, Sec ]) a check is added whether the value of the validity period variable contains the date located in the notbefore field of certificate i.

12 3. In step Prepare for Certificate i+1 ([CSF + 08, Sec ]) the validity period variable is set to the period between the notbefore and notafter field values of certificate i. 4. In Step Wrap-Up Procedure ([CSF + 08, Sec ]) the validity period variable is set to the period between the notbefore and notafter field values of certificate i. Finally, it is checked whether the validity period contains the date of the signature creation (supplied as an additional input). 5 Revocation and Validity Models In this section we discuss how revocation using a Certificate Revocation List (CRL) affects the validity of electronic signatures within the different validity models. Also two interesting questions in the context of CRLs arise: First, how do we handle certificates in the CRL, which are expired and removed from the CRL? Second, do we need indirect CRLs within the chain model when used for qualified signatures? For the revocation of a certificate there are two important points in time. The first one is the time when a certificate is publicly known to be revoked. We denote this time by T r. In a CRL T r is equal to the CRL field thisupdate. The second one is the time when a revocation is initiated. We denote this point in time by T rd. This is the revocationdate field of a CRLEntry in the CRL. If this field is not set by the CRL issuer then T rd = T r. In the Online Certificate Status Protocol (OCSP), these points in time are expressed by the producedat and thisupdate fields of an OCSP response, respectively. The time period [T rd, T r ] is sometimes referred to as revocation latency. This period should be kept as short as possible. We do not discuss how to keep this time period small or how the point in time T rd is determined by each CA, but rather how this affects the validity of digital signatures. We examine how revocation of a certificate in a certification path invalidates a signature. We assume that the k-th certificate in the chain is revoked in what follows (remember that T v denotes the validation time of the signature and T r (k) the time when the revocation of the certificate becomes publicly known): Shell Model: If T v T r (k) the signature is invalidated, otherwise not. Modified Shell Model: T v T rd (k) T rd (k) < T v < T r (k) T v T r (k) T v T r (k) is not invalidated is not invalidated is not invalidated if T s < T rd (k) is invalidated if T s T rd (k) Chain Model: For all 1 k N 1, the signature is not invalidated if T r (k) > T i (k + 1), otherwise it is. For k = N:

13 T v T rd (N) T rd (N) < T v < T r (N) T v T r (N) T v T r (N) is not invalidated is not invalidated is not invalidated if T s < T rd (N) is invalidated if T s T rd (N) To simplify the presentation we have assumed that there is no revocation latency when CA certificates are revoked, that is T rd (k) T r (k) for all 1 k N 1. In all models revocation latency has an impact on the validity of a signature. If T rd T v < T r, that is the validation time of a digital signature lies inside this period, a signature is not affected at all by the revocation. In the modified shell and chain model a revocation invalidates signatures calculated after the revocation of a certificate, that is T s T rd (N) and T v T r (N). In some applications revocation invalidates signatures only with T s T r (N), that is they ignore the time of the revocation. However, we propose to validate a signature taking the revocation date into account when this information is available. In the shell model all signatures are invalidated after a revocation. This also demonstrates why it is not possible to use the shell model for qualified signatures. Users could just revoke their qualified certificates and invalidate with this action previously calculated qualified signatures. Let us turn to the first question presented at the beginning of this section. The PKIX specification of revocation lists allows to remove expired certificates from a CRL. Applications that implement the modified shell model without using the CAdES specification or a mechanism with similar functionality may face problems. As we have discussed in Section 4.2 CAdES stores at T s within its CAdES-X Long signature data needed for validation, like the CRL. However, if the modified shell model is implemented using the PKIX algorithm, the CRL issued near T s, that lists a certificate in the chain, may not be available. Then, for example, the application uses the CRL issued near the verification time T v which may not list this certificate if it has already expired. For illustrating this, consider that end-entity A (or someone else) calculates a signature at , which may be verified using end-entity A s public key. But assume that the underlying certificate has already been revoked at If a client verifies this signature using the modified PKIX algorithm at T v = using a CRL issued near T v the verifier accepts this signature. This is due to the fact that the revoked certificate has been removed from the CRL since it has expired on The same effect appears when the chain model is used. However, if these models are implemented using CAdES as proposed in this paper it is safe to remove expired certificates from CRLs. The second question is to consider indirect CRLs within the chain model for qualified signatures. An indirect CRL is a revocation list with the property that the CRL issuer and the issuer of at least one revoked certificate in the CRL are different entities. Although they are not very common and few clients support

14 their use, they are mandatory when the chain model is used for verifying qualified signatures. The key observation with regard to revocation is that qualified certificates belong by law only to natural persons. To explain this assertion, we have again a look at our sample PKI. Endentity A can create a valid signature after within the chain model, although the certificate of the subordinate CA 1 has expired on However, it may be necessary to revoke end-entity A s certificate after this date. For this, a valid subordinate CA certificate is needed. But it may not be possible to renew this certificate since it belongs to a natural person who herself or whose private key is no more available. Therefore, in general revocation within the chain model in the qualified context is delegated to another entity leading to indirect CRLs. 6 Validity Model versus Use Case In this section we discuss which practical application (use case) of digital signatures requires which validity model. Electronic signatures always ensure the security goals authenticity and integrity: By authenticity we mean that a claimed (electronic) identity or the originator of an information is confirmed. Integrity denotes that an information is not altered. Both symmetric signatures (Message Authentication Code, MAC) and asymmetric signatures (electronic signatures) guarantee authenticity and integrity. A third security goal in the context of signatures is non-repudiation, which means that a third party may be convinced of authenticity and integrity of an information. Non-repudiation may only be achieved by asymmetric electronic signatures, as a MAC grants access to two or more parties to the signature generation key. It is obvious that non-repudiation implies authenticity and integrity. In order to come up with a relation of use cases and validity models, we distinguish shortterm security goals and long-term security goals. Short-term security means that the security goal must be achieved for some seconds, minutes, or at most hours. On the other hand, long-term security is characterised by the fact that the security goal holds for years. For us, authenticity and integrity (in the absence of non-repudiation) are short-term security goals as only the communication parties have to verify authenticity and integrity. A convenient example is the authentication of browser and web server during the handshake of the TLS protocol [DR08]. Thus both a MAC and an (asymmetric) electronic signature may be used to achieve these goals, that is the shell model as introduced in [CSF + 08] is adequate. However, if non-repudiation (that is long-term security) by each entity in a certification hierarchy is needed, the chain model is appropriate. The reason is that (as described in Section 3.3) once a signature is valid at signing time T s it remains valid for all the time. A practical example is a contract (e.g. concerning a bargain), which must be verified for years to guarantee legal issues like warranty. An application of the modified shell model is described in [Res07] for the management of clinical trials. It states:... Signed documents can be viewed and

15 validated for long periods into the future as the validation uses the time when the signature was made (and not the current time) when computing the validity of the signer s certificates... This is actually an application of the modified shell model in which the signature time is important for the validation of a digital signature. However, requirements deriving from the context of qualified signatures like non-repudiation for each signer, do not apply here. As the modified shell model is easier to implement in practice, it is employed in this case. Our mapping of use cases, security goals, and validity models is summarized in Table 2. Table 2. Mapping of use cases, security goals, and validity models. Use Case Security Goals Validity Model Short-term security Authenticity, integrity Shell Model Long-term security Non-repudiation (full) Chain Model Long-term security Non-repudiation (partial) Modified Shell Model 7 Conclusions We addressed the problem of semantical validity of an electronic signature. We formally defined three validity models and discussed their implementation. We analysed various issues that derive from their use in a PKI. Finally we examined which model is appropriate in various scenarios. Realising the modified shell and the chain model is complex since various issues need to be addressed. Therefore, efficient implementations and PKI protocols that support verification of signatures according to these two models are needed. References [ANS05] American National Standards Institute ANSI. X9.62: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), November [BNe] German federal network agency: A presentation on validity models. Available at [CSF + 08] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF Request For Comments, 5280, May [DR08] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. IETF Request For Comments, 5246, August [ETS08] ETSI. Electronic Signatures and Infrastructures (ESI): Electronic Signature Formats. TS V1.7.4, July 2008.

16 [NT94] [Hou04] R. Housley. Cryptographic Message Syntax (CMS). IETF Request For Comments, 3852, July [HPFS02] R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF Request For Comments, 3280, April [IT05] Recommendation X.509 ITU-T. Information technology Open Systems Interconnection The Directory: Public-key and attribute certificate frameworks, August National Institute of Standards NIST and Technology. FIPS 186 Digital Signature Standard (DSS), May Available at gov/fipspubs/fip186.htm. [PPR08] D. Pinkas, N. Pope, and J. Ross. CMS Advanced Electronic Signatures (CAdES). IETF Request For Comments, 5126, February [Res07] U. Resnitzky. The Directory-Enabled PKI Appliance: Digital Signatures Made Simple, Approach and Real World Experience. In 6th Annual PKI R&D Workshop, April Available at edu/pki07/proceedings/. [RSA78] R. Rivest, A. Shamir, and L. Adleman. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. 21(2): , February [Tec05] Microsoft TechNet. Renewing a certification authority, January Available at [Tha06] Thawte. Certification Practice Statement Version 3.3, November Available at free-guides-whitepapers/pdf/thawte_cps_3_3.pdf.