The Notary Based PKI

Download PDF
33 downloads 250719 Views 269KB Size Report
Comment
Digital signatures provide authenticity and integrity for digital documents. A .... practical because the current profiles of advanced electronic signatures prevent.
The Notary Based PKI A Lightweight PKI for Long-Term Signatures on Documents Mart´ın A. G. Vigil1? , Cristian T. Moecke1 , Ricardo F. Cust´odio2 , and Melanie Volkamer1 1

Technische Universit¨ at Darmstadt Hochschulstraße 10, 64289 Darmstadt, Germany [email protected] {cristian.moecke,melanie.volkamer}@cased.de 2 Laborat´ orio de Seguran¸ca em Computa¸ca ˜o Universidade Federal de Santa Catarina Caixa Postal 476, 88040900 Florian´ opolis, Brazil [email protected]

Abstract. We propose a new Public Key Infrastructure model for longterm signatures. It is based on X.509 and the real world of handwritten signatures. In the model, notaries certify that a signer’s certificate is trustworthy to verify a particular signature at a specific time. An end user issues his own X.509 certificate, whose validity period is meaningless and whose trustworthiness is accepted only if the certificate was certified by a notary. After the certification, the certificate remains trustworthy even if later keys are compromised or notaries disappear. The benefits for signed document users are: i) the maintenance of a document signature is simple and only necessary to prevent the obsolescence of cryptographic algorithms; ii) the overhead to store and verify a document signature does not increase significantly in the long term; and iii) there is only one trust decision when verifying a document signature. Keywords: PKI, long-term archiving, notary, notarisation

1

Introduction

As technology steps forward, the society converges to digital media as an efficient means to preserve information. For instance, land registers in Europe (e.g. [1,2]) have digitalized and stored documents to save physical space. Preserving information is useless if authenticity, integrity and datedness 3 cannot be ensured ?

3

Mart´ın A. G. Vigil is supported by Coordena¸ca ˜o de Aperfei¸coamento de Pessoal de N´ıvel Superior (Bolsista CAPES/Brasil). Also known as proof of existence, this property provides a date and time at which an object existed [3].

c

2013 Springer. The final publication is available at http://link.springer.com/ chapter/10.1007%2F978-3-642-40012-4_6.

in the long term, i.e. forever. To address this need, digital signatures [4] and Public Key Infrastructures (PKI) [5] have been utilized. A common used model of PKI is based on the X.509 certificate [6]. We refer to this model as the PKIX model. We refer to a PKI that adheres to the PKIX model as a PKIX. The PKIX model requires a constant maintenance of document signatures to avoid that authenticity, integrity and datedness fade out. This is caused by the weakening of cryptographic algorithms and the expiration of certificates. The conventional countermeasure is the regular addition of timestamps on document signatures. As a consequence, it is necessary to rely on several public keys and there is an ever-growing overhead to store and verify document signatures. We are interested in making the long-term maintenance of document signatures simpler and more intuitive than in the PKIX model. Contribution We present a new PKI model that is named Notary Based PKI (NBPKI). It is closer to the real world of handwritten signatures than the PKIX model. We propose that end users use self-signed X.509 certificates to create and verify document signatures. These certificates are only trustworthy if certified by a notary (i.e. a trusted party) in regard to a particular signature and a specific time. After certified, trustworthiness is ensured no matter what happens to the signer’s keys. Therefore, the validity period4 of a self-signed certificate is meaningless. A different notary can recertify the trustworthiness of a given self-signed certificate for the same signature and time. Therefore, the trust in a single notary is enough to rely on a self-signed certificate. As benefits, our approach simplifies the maintenance of document signatures, which does not need timestamps and is only necessary before cryptographic algorithms become insecure. As a consequence, the use of signed documents requires less trusted public keys, storage space, and processing time. Outline This paper starts with a succinct analysis of the problems concerning long-term signatures in the PKIX model (cf. Sect. 2). Based on these problems, we present the related work in Sect. 3. We introduce our proposal in Sect. 4 and we describe it in Sects. 5 to 7. We provide the trust assumptions about our proposal in Sect. 8. Section 9 presents our conclusions and future work.

2

Problems of Using Long-Term Signatures

Digital signatures provide authenticity and integrity for digital documents. A signer signs a document and a verifier verifies the mathematical correctness of the document signature, i.e. he checks whether the signature is valid under the signer’s public key. The verifier needs to rely on the signer’s public key to verify the document signature. Therefore, a Public Key Infrastructure (PKI) is necessary to provide 4

A period in which the certificate issuer has the responsibility to indicate the validity of the certificate, e.g. by providing updated revocation status [6].

the verifier with a trustworthy public key. A Certification Authority (CA) certifies a public key by signing a certificate that binds the public key and a subject. The most prominent standard for certificates is the X.509. A certificate has a limited lifetime, after which the certificate expires and the corresponding public key is no longer trustworthy. A CA revokes an unexpired certificate if the corresponding public key became untrustworthy. If the verifier trusts in a CA’s public key, then the verifier relies on any public key whose certification chain steams from the trusted public key. We refer to trusted public keys as trust anchors. The verifier needs to verify whether the signer’s public key is trustworthy before relying on it. If it is trustworthy, then the verifier can infer the semantic correctness for the document signature. The public key is trustworthy if the certificates from the public key until the verifier’s trust anchor were valid when the document signature was created. That is, the certificates were neither expired nor revoked. However, the time when the document signature was created is hard to guarantee. Therefore, the verifier verifies whether the certificates are still valid at the verification time. Thus, the document signature is considered trustworthy if the mathematical and semantic correctness is ensured. The semantic correctness is easily verified for short-term signatures, but not for long-term signatures. The reason is that certificates expire, revocation data becomes obsolete or unavailable, and cryptographic algorithms fade out over time. Therefore, datedness is necessary to ensure that certificates existed and were trustworthy at a time in the past. Timestamps provide datedness. A Timestamp Authority (TSA) certifies that an object existed at a particular time by signing an X.509 timestamp [3] that binds the object with the current time. A timestamp is trustworthy if the timestamp signature is valid and the TSA’s public key is trustworthy. Notice that a single timestamp cannot ensure datedness for the long term. To do so, timestamps are chained to extend datedness. Consequently, the process of maintaining a document signature trustworthy by using timestamps is endless. As a result, timestamps, certificates and revocation data are accumulated. We refer to these accumulated objects as protection data. Also, since PKIs have a limited lifetime, the process will request timestamps from TSAs in new PKIs. Therefore, verifiers will have to rely on an ever-growing number of trust anchors. In this context, we point out the following open problems. Problem 1. The amount of protection data to store and verify is not optimal. The protection data accumulated since the creation of a document signature should be stored. Also, it should be completely verified upon checking the document signature. Therefore, the older the document signature, the more storage and verification overhead. Problem 2. Dealing with trust anchors is hard for verifiers. For instance, trust anchors may not be available in the future because current profiles of advanced electronic signatures (e.g. XAdES [7]) do not store them. Also, it is not clear how verifiers will infer whether old trust anchors were indeed trustworthy. Yet, such inference can be even worse when there are cross-certifications, which yield

a non-deterministic net of trust criticized by Guttmann [8] as a “spaghetti of doubt”.

3

Related Work

In literature there are many proposals to improve the PKIX model. We present the works in regard to the problems 1 and 2. The amount of protection data is proportional to the length of a certification chain [9]. In that sense, Nested Certificates [10] address Problem 1 by shortening certification chains. Given a certification chain G of length n, a shortcut is created between two certificates i and j, being 0 ≤ i < j + 1 < n. Such a shortcut is a new certificate issued by the subject of j, certifying that certificates i, i + 1...j − 1 are trustworthy. This approach is attractive, however in the long term timestamps are still necessary, so that problems 1 and 2 remain. Certification Authorities issue Certificate Revocation List (CRL) [11] to revoke certificates. Protection data can be reduced by using schemes that are more efficient than CRL in regard to Problem 1. A straightforward approach is to eliminate the need for revocation by using Short-Term Certificates [12]. That is, certificates that are trustworthy for short periods (e.g. a day), so that their probability of being revoked is almost zero. Nevertheless, these certificates are not practical for a CA because once a CA’s certificate expires, all subordinate certificates have to be reissued. Certificate Revocation Tree [13], Tree-List Certificate Validation [14], Online Certificate Status Protocol [15] and Novomodo [16] provide revocation data that is smaller and easier to evaluate than CRL. Although revocation data is reduced, there is still the need to accumulate timestamps, so that problems 1 and 2 remain in the long term. Protection data can be verified and, if valid, totally replaced by a signed validation receipt that is smaller and easier to evaluate than the whole protection data. Such verification and receipt creation are done by a notary, i.e. a trusted party. An example of this notarial approach is the Optimized Certificate (OC) [17]. The OC is an X.509 certificate and its validity period comprises a single instant, being the fields NotBefore and NotAfter equal. A notary issues an OC to claim that a signer’s certificate is trustworthy to verify a specific signature at a given time reference. The OC can then replace the signer’s certificate and corresponding revocation data, thereby addressing Problem 1. An OC can replace another OC, hence addressing Problem 2. Nevertheless, this approach is not practical because the current profiles of advanced electronic signatures prevent certificate replacements.

4

NBPKI - Overview

The Notarial Based Public Key Infrastructure (NBPKI) is a PKI model that is based on the real world of handwritten signatures and notaries. Legally recognized in many countries as a trusted party, a notary verifies the authenticity of signatures (e.g. by using graphometry [18]) and certifies them as trustworthy if

they are authentic. Given a signature and its certification, an individual checks whether the certification was done by a notary in the individual’s jurisdiction, instead of doing the complex process of verifying the signature again. In theory, notaries mutually trust each other. We refer to our proposed model as the NBPKI model. We refer to a PKI that adheres to our model as an NBPKI. The NBPKI model is based on trusted parties named Notarial Authorities (NA). They certify that an end user’s certificate is trustworthy for verifying a particular signature at a specific time. End users rely on NA’s public keys and use self-signed certificates for creating and verifying document signatures. Thus, given a signed document, the signature and the certified signer’s certificate, a verifier needs only to check the mathematical correctness of the document signature. The semantic correctness is implicit if the verifier relies on the NA’s public key. An NA can recertify a certificate based on the mutual trust among NAs. This allows for a trust configuration in which notarial certifications are renewable and replaceable. The problems described in Sect. 2 are addressed in the NBPKI model as follows. Problem 1 is solved because a notarial certification reduces the protection data. This reduction is done by removing CA’s certificates, timestamps, and revocation status because such data is not necessary after an end user’s certificate is certified by an NA. Problem 2 is not present in the NBPKI model because of the mutual trust between NAs. That is, because an NA can recertify an end user’s certificate based on a former certification, trust anchors can be replaced. Therefore, a verifier relies only on a single trust anchor upon checking a document signature. We describe the NBPKI model in details in the following, presenting its components (cf Sect. 5) and protocols (cf. Sect. 6).

5

NBPKI - Components

The NBPKI model comprises end users, Registration Authorities (RA), and Notarial Authorities. End users sign and verify documents using self-signed X.509 certificates (cf. Sect. 5.1). Registration Authorities verify the binding between end users and their public keys (cf. Sect. 5.2). Notarial Authorities certify end users’ certificates with the help of RAs (cf. Sect. 5.3). 5.1

End users

In the NBPKI model there is no CA, therefore end users sign their own X.509 certificates. An end user signs a document and he attaches his self-signed certificate to the signature. The protection data is minimal, thereby addressing Problem 1. Given a signed document, the signature and the signer’s self-signed certificate, a verifier is unable to verify whether the document signature is trustworthy. This is because the verifier lacks information to check whether the public key in the signer’s certificate is trustworthy. Notarial Authorities (NA) and Registration

Authorities (RA) provide such information. It is conveyed by a notarial certification. The verifier attaches the notarial certification to the document signature to allow for future verifications of that signature. Details on how end users request notarial certification and verify signed documents are presented in Sects. 6.1 and 6.3 respectively. 5.2

Registration Authorities

In the NBPKI model, the RA is a trusted party. It has physical offices where end users enroll themselves, presenting their self-signed certificates and proving the ownership of their private keys. An RA is associated with one or more NAs. An RA verifies the binding between an end user and his public key. If successfully verified, the RA informs all associated NAs that the end user’s self-signed certificate is currently trustworthy. Additionally, the RA informs all associated NAs when a certificate is no longer trustworthy. This happens when the end user requests revocation or the cryptographic algorithms used in the certificate become insecure. Based on the certificate status provided by an RA, associated NAs are able to certify the certificate as trustworthy. 5.3

Notarial Authorities

A Notarial Authority is a trusted party in the NBPKI model. In an NBPKI, an NA trusts other NAs. Moreover, based on the help of associated RAs, an NA issues notarial certifications for trustworthy end user’s certificates. Yet, NAs sign their own certificates. An NA provides an online service that allows end users to request notarial certifications for self-signed certificates. An end user submits the digest of a signed document, the document signature, and the signer’s self-signed certificate. The NA checks the current status provided by the associated RA for the signer’s certificate. If the certificate is still trustworthy, then the NA signs a dated notarial certification and returns it to the end user. The notarial certification confirms that the signer’s certificate is trustworthy only for the submitted document signature at the time when the notarial certification was issued. Also, the notarial certification confirms the existence of the document signature. In Sect. 6.1 we describe in details the notarial certification request and its data structure. An end user can request an NA to certify a self-signed certificate whose status the NA does not know. That is, the certificate owner is not enrolled in any associated RA. In this case, the requested NA looks for5 another NA that knows the certificate status. If such an NA is found and the certificate is currently trustworthy, the requested NA certifies the certificate as explained above. Note that this approach shifts trust decisions from the end user to NAs. 5

In this paper we do not describe how this search is done, however, an NA can know other NAs, for instance, by using a Trusted service Status List.

This is because the requested NA decides whether relying on other NAs that end users may not know. A notarial certification is a signed data structure, therefore the security of cryptographic algorithms is a concern in the long term. Before they become insecure, the signed document holder is supposed to request an NA to renew (i.e. reissue) the notarial certification with new cryptographic algorithms. Given a self-signed certificate and corresponding notarial certification, the NA verifies whether the notarial certification is still trustworthy and indeed related to the certificate. If the verification succeeds, a new notarial certification is issued using up to date cryptographic algorithms. The old notarial certification is discarded by the signed document holder, thereby removing the need to rely on the former NA’s public key and addressing Problem 2. In Sect. 6.2, we describe the renewal of notarial certifications in detail.

6

NBPKI - Protocols

We propose three main protocols in the NBPKI model. In Sect. 6.1 we present the protocol that allows an end user to obtain a notarial certification from an NA. Additionally, we describe the data structure of a notarial certification. In order to allow end users to extend the lifetime of a document signature beyond the lifetime of a notarial certification, there is the protocol described in Sect. 6.2. The protocol in Sect. 6.3 performs the verification of a document signature. 6.1

Certifying Self-Signed Certificates

Given a signed document and the signer’s certificate, an end user obtains a notarial certification from an NA as follows. First, the end user submits to an NA: i) the document signature; ii) the signed document digest; and iii) the signer’s certificate. The NA checks the current status provided by the associated RA for the signer’s certificate. If the binding between signer and his public is still valid and the cryptographic algorithms of the signer’s certificate remain secure, then the NA returns a signed notarial certification to the end user. The notarial certification is an evidence that: i) the signer’s certificate was trustworthy when the notarial certification was issued; and ii) the document signature existed at a given time. Note that the NA does not verify the mathematical correctness of the document signature. The structure of a notarial certification is depicted in Fig. 1 and described as follows. The field First Certification Date contains the date when: i) the notarial certification was issued by the first time; ii) the self-signed certificate was trustworthy; and iii) the document signature existed. Such a time value is obtained from the NA’s clock. Certificate Digest comprises a digest of the selfsigned certificate. Document Digests consists of digests of the signed document. Each digest is calculated using a different digest algorithm. Document Signature is a copy of the document signature.

A notarial certification is signed content, therefore a signature container is necessary (Fig. 1). This container is an advanced electronic signature (e.g. XAdES) and has three main fields. The field Signing Time states the moment when the notarial certification was signed. The field NA Identification consists of the issuing NA’s identification (e.g. a digest of the NA’s public key). The field NA Signature comprises the NA’s signature on the notarial certification, Signing Time, and NA Identification. Signature Container Notarial Certification First Certification Date Certificate Digest Document Digests Document Signature Signing Time NA Identification NA Signature

Fig. 1. The layout of a signed notarial certification

There are two remarks on the notarial certification and signature container. The field Document Digest comprises an array of digests instead of a single digest. The fields First Certification Date and Signing Time are equal, seeming redundant. The reason for this configuration is presented in Sect. 6.2.

6.2

Renewing Notarial Certifications

A notarial certification is trustworthy as long as the used cryptographic algorithms remain secure. Before they fade out, an end user requests a new notarial certification from an NA. Given a signed document, the signer’s certificate, and the notarial certification, an end user calculates the signed document digest using an up to date digest algorithm. He submits to an NA: the signed document digest, the signer’s certificate and the notarial certification. The requested NA verifies whether the used cryptographic algorithms are still secure. If they are, then the requested NA looks for the public key of the NA that issued the submitted notarial certification. This search is based on the field NA Identification (cf. Sect. 6.1). If the public key is found and the signature on the submitted notarial certification is valid under that key, then the requested NA issues and returns a new notarial certification to the end user. Details on the security verification of cryptographic algorithms, and the issuance of notarial certifications are given in the following.

An NA checks the security of digest and signature algorithms. In the field Document Digests, the NA verifies whether there is at least one document digest whose algorithm is still secure. This verification is necessary to prevent intentional collisions for the signed document. An alternative to avoid collisions is to submit the signed document instead of its digest to the NA, however this procedure is not practical and raises privacy concerns. The NA checks whether the cryptographic algorithms used to sign the notarial certification are still secure to ensure the authenticity of the notarial certification signature. If both verifications succeed, then the NA issues a new notarial certification as follows. Using an up to date digest algorithm, the NA calculates the signer’s certificate digest. The NA makes a copy of the submitted notarial certification. In the copy, the NA assigns the signer’s certificate digest to Certificate Digest. The NA includes the submitted digest of the signed document in Document Digests in the copy. The previous digests in Document Digests remain. The NA creates a signature container over the copy, assigning the current time to Signing Time and the NA’s identification to NA Identification. The NA signs the notarial certification using secure cryptographic algorithms. Note that First Certification Date remains unchanged, otherwise the original datedness for the document signature is lost. 6.3

Verifying Document Signatures

In order to verify a signature on a document in the NBPKI model, a notarial certification is required. If it is not available, a verifier needs request it to an NA. Afterwards, the verifier checks the mathematical and semantic correctness for the document signature as described in the following. Given a signed document, the signature, the signer’s certificate, a notarial certification, and the NA’s certificate, the mathematical verification is performed as described in Sect. 2. That is, the signature on the document is verified under the signer’s public key available in the signer’s certificate. If the verification succeeds, then the verifier infers the mathematical correctness for the document signature. The semantic correctness is ensured if the signer’s public key was trustworthy when the first notarial certification was created (i.e. at the time stated in the field First Certification Date). The public key is trustworthy if all the following conditions are true: i) the notarial certification matches the signed document, the signature, and the signer’s certificate; ii) the notarial certification signature is mathematically correct; and iii) the used cryptographic algorithms are still secure. The verification of these conditions is detailed in the following. A verifier ensures that a notarial certification matches the signed document, the signature, and the signer’s certificate if the following steps succeed. The verifier calculates digests of the signed document and compares them with the digests in field Document Digests in the notarial certification. Note that this verification prevents collision attacks after a cryptographic algorithm is no longer secure. He compares the signature on the document with the field Document

Signature. He calculates the digests of the signer’s certificate and compares it with the field Certificate Digest. The verification of a signature on a notarial certification considers only the mathematical correctness. That is, the signature is verified under the corresponding NA’s public key. The semantic correctness for the signature is taken for granted because the NA’s public key is a trust anchor. A verifier checks the security of the used cryptographic algorithms as follows. He checks whether the cryptographic algorithms used by the issuing NA to create the signature on the notarial certification remain secure. He verifies whether at least one digest algorithm used in the field Document Digest remains secure. Both verifications require means to check the current security status of cryptographic algorithms (see [19] for an example). If all verifications for mathematical and semantic correctness succeed, then the verifier infers that the signature on the document is trustworthy and existed at the time given in the field First Certification Date.

7

Management of Trust Anchors

The public keys of NAs are trust anchors in the NBPKI model. Notarial Authorities can join or leave an NBPKI as they are created or cease operations respectively. In order to make the management of trust anchors transparent for end users and NAs, we suggest the use of the so-called Trusted service Status List (TSL) [20]. The entity that controls an NBPKI updates the TSL, including or removing NA’s public keys. The entity signs the TSL. To support long-term verifications of notarial certifications, a TSL should also provide the public keys of NAs that ceased operations. Nevertheless, the public key of an NA can be removed from the TSL after the public key algorithm and key size are no longer secure. This removal mitigates the growth of the TSL without preventing end users from renewing old notarial certifications (cf. Sect. 6.2).

8

Trust Assumptions

Like for any PKI, we assume that a cryptographic algorithm used in an NBPKI do not suddenly become insecure. Otherwise, all signatures that rely on that algorithm become untrustworthy. The reason is that a verifier is not able to know whether a signature was created before the algorithm became insecure. Registration Authorities are assumed to be honest and carefully verify selfsigned certificates. The NBPKI model has to ensure the authenticity of a selfsigned certificate status. Therefore, we assume that either there is a secure communication channel between an RA and an NA, or an RA signs the status data, which is then properly verified by an NA. If the exchange of status data can be compromised, then there is the risk of forgeries. An NA is a trusted party in the NBPKI model. We assume that the private key of an NA is not be compromised. The effects of the compromise of such a key

would be comparable to the compromise of a Timestamp Authority (TSA). Like timestamps, all notarial certifications ever signed by a compromised NA would become untrustworthy. We assume that an NA provides always the correct time, as a conventional TSA is expected to do. Otherwise, verifiers cannot rely on the notarial certification as datedness evidence for a document signature. In the PKIX model, advanced electronic signatures accumulate protection data, allowing verifiers to evaluate authenticity, integrity and datedness at any time reference since the signature creation. In the NBPKI model, however, a long-term signature contains only the last notarial certification. Therefore, we assume that NAs correctly check the status of a signer’s certificate before issuing a notarial certification (cf. Sect. 5.3), and verify the security of cryptographic algorithms before reissuing notarial certifications (cf. Sect. 6.2). If NAs do not properly perform these verifications, then a verifier may rely on an untrustworthy signature. For instance, if an NA does not verify the security of cryptographic algorithms, an attacker will succeed in asking the NA to recertify an old notarial certification for a colliding signed document digest.

9

Conclusions & Future Work

All in all, our proposed PKI model is closer to the real world of handwritten signatures than the PKIX. Our model facilitates the use of a long-term signature by reducing and shifting from a verifier to notaries the complexity of relying on public keys. Also, the maintenance of the long-term signature is easier than in the PKIX model. Instead of all protection data (e.g. certificates, CRLs and timestamps) accumulated over time, only a single notarial certification is stored in our model. A notary issues the notarial certification, with which the notary claims that the signer’s certificate is trustworthy to verify a particular document signature at a specific time. Moreover, our model avoids accumulating trust anchors over time by using self-signed certificates and renewing notarial certifications. From the scalability point of view, an NA is comparable to a Timestamp Authority. Upon the request of a notarial certification, the NA verifies the status of a document signer’s certificate and, if it is valid, the NA timestamps the that certificate, the signed document and corresponding signature. Yet, an NA can query a certificate status from an RA whenever a notarial certification is requested. By doing so, the NA ensures the freshness of the certificate status. Because this approach can be a bottleneck of infrastructure, we propose that the RA pushes a certificate status to all related NAs whenever the status changes. From the structural point of view, we can compare an NA to a Root CA whose private key is used to sign end user’s certificates and revocation status. However, since using self-signed certificates and replaceable certifications, the verification of a document signature in the NBPKI model does not depend on a fixed trust anchor. This is attractive to deal with the creation and disappearance of Root CAs in the long term. In regard to trust assumptions, verifiers assume that CAs and TSAs provide trustworthy certificates and timestamps respectively in the PKIX model. That

is, verifiers believe that a CA properly verifies the binding between a public key and a subject, and a TSA uses the correct time. In contrast to the PKIX model, there are additional trust assumptions in the NBPKI. Namely, verifiers believe that an NA properly evaluates a certificate status received from an RA, and correctly checks the security of cryptographic algorithms. Yet, an NA is assumed to be resistant to attackers, which is a strong assumption in many PKIs (see the DigiNotar incident [21] for an example). Means to reduce trust assumptions in the NBPKI model is an interesting question. For example, how to avoid that an end user and an NA collude to certify untrustworthy certificates and forged signatures? Our initial idea is to prevent a direct interaction between an end user and a particular NA. That is, an end user cannot know in advance which NA will attend his request for a notarial certification. In the other way around, the NA should not be able to identify the end user. Yet, an alternative is the use of Byzantine protocols to tolerate faulty NAs, as Maniatis et al. propose in [22] for Timestamp Authorities. Acknowledgments. We thank Johannes Braun and Daniel Cabarcas for the useful discussions, and the anonymous reviewers for their comments that helped to improve the final version of this paper.

References 1. Minist`ere de la Justice: Livre Foncier. https://www.livrefoncier.fr Accessed: 22/07/2012. 2. Centre of Registers and Information Systems: e-Land Register. http://www. egov-estonia.eu/e-land-register Accessed: 20/09/2012. 3. Adams, C., Cain, P., Pinkas, D., Zuccherato, R.: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161 (Proposed Standard) (August 2001) 4. Diffie, W., Hellman, M.: New directions in cryptography. Information Theory, IEEE Transactions on 22(6) (1976) 644–654 5. Stallings, W.: Cryptography and network security - principles and practice (3. ed.). Prentice Hall (2003) 6. ITU-T: Recommendation X.509 information technology - open systems interconnection - the directory: Authentication framework. Technical report, ITU-T (2005) 7. ETSI: XML Advanced Electronic Signatures (XAdES). 1.8.3 edn. Number TS 101 903. (jan 2010) 8. Gutmann, P.: Pki: It’s not dead, just resting. IEEE Computer 35(8) (2002) 41–49 9. Martinez-Pel´ aez, R., Satiz´ abal, C., Rico-Novella, F., Forn´e, J.: Efficient certificate path validation and its application in mobile payment protocols. In: Availability, Reliability and Security, 2008. ARES 08. Third International Conference on, IEEE (2008) 701–708 10. Levi, A., Caglayan, M., Koc, C.: Use of nested certificates for efficient, dynamic, and trust preserving public key infrastructure. ACM Transactions on Information and System Security (TISSEC) 7(1) (2004) 21–59 11. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., Polk, W.: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard) (May 2008)

12. Rivest, R.: Can we eliminate certificate revocation lists? In: Financial Cryptography, Springer (1998) 178–183 13. Kocher, P.: On certificate revocation and validation. In: Financial Cryptography, Springer (1998) 172–177 14. Lim, T., Lakshminarayanan, A., Saksen, V.: A practical and efficient tree-list structure for public-key certificate validation. In: Applied Cryptography and Network Security, Springer (2008) 392–410 15. Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. RFC 2560 (Proposed Standard) (June 1999) 16. Micali, S.: Scalable certificate validation and simplified pki management. In: 1st Annual PKI Research Workshop. (2002) 15 17. Cust´ odio, R.F., Vigil, M.A.G., Romani, J., Pereira, F.C., da Silva Fraga, J.: Optimized certificates - a new proposal for efficient electronic document signature validation. 5057 (2008) 49–59 18. Justino, E., Bortolozzi, F., Sabourin, R.: Off-line signature verification using hmm for random, simple and skilled forgeries. In: Document Analysis and Recognition, 2001. Proceedings. Sixth International Conference on, IEEE (2001) 1031–1034 19. Kunz, T., Okunick, S., Pordesch, U.: Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC). RFC 5698 (Proposed Standard) (November 2009) 20. ETSI: Electronic Signatures and Infrastructures (ESI); Provision of harmonized Trust-service status information. Technical report, ETSI (2006) 21. The H Open: Fake Google certificate is the result of a hack. http://h-online. com/-1333728 (2011) Accessed: 01/11/2011. 22. Maniatis, P., Giuli, T.J., Baker, M.: Enabling the long-term archival of signed documents through time stamping. CoRR cs.DC/0106058 (2001)