Signatures in the electronic world

Series Part3: When to avoid using PDF Signatures?

By Leslie Glenn Goodman, CISSP

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Copyright notice
This series of documents is protected by copyright and other intellectual property laws. As a rule, information received through these documents may not be displayed, reformatted, and printed. You may not reproduce or retransmit these documents, in whole or in part, in any manner, without the prior written consent of the author with the exception of integral copies, solely for use within the organization that received it from the author. Any copyright or other notices must be preserved. You may also not distribute copies to other parties, whether or not in electronic form, whether or not for a charge or other consideration, without prior written consent of the author and under the conditions specified by the author.

Disclaimer
Technologies and products change constantly. Legislation and its interpretation can also be modified. This paper was written by the author at a certain time and based on information available at that time. Furthermore, these series, as non-commercial informational documents for public institutions, have been written with no other purpose to convey general information and/or personal opinions. In this format, it should never be considered as binding advice. Without any other agreements, the author takes no responsibility for the contents. The author cannot and does not warrant the accuracy, completeness, being up-to-date, non-infringement, or fitness for a particular purpose of the information available through this document series, nor does he guarantee that any future versions will be error-free or available. He can also not be held accountable for the application of ideas or recommendations expressed in these documents by the reader.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Contents
Copyright notice ............................................................................................................................................2 Disclaimer.......................................................................................................................................................2 Summary of conclusions .............................................................................................................................. 4 What is this about? ....................................................................................................................................... 5 Out of scope ............................................................................................................................................. 6 Why PDF? .......................................................................................................................................................7 Why not PDF?................................................................................................................................................ 8 Interdependency of document format and signature ........................................................................... 8 Intertwined document creator and signing software ............................................................................ 8 How to sign other document formats? ............................................................................................... 9 Attached signatures ................................................................................................................................ 10 Automated and non-automated signing and/or validating by a service provider ........................... 10 Long-term preservation of electronic signatures ...............................................................................11 Version and flavors .............................................................................................................................. 12 Dynamic content and full embedding of objects .............................................................................. 13 Can you really trust a PDF qualified electronic signature? .................................................................... 14 Which digital certificates can you trust? ............................................................................................ 14 Which timestamps can you trust?....................................................................................................... 15 Limitations of PAdES in PDF ............................................................................................................... 16 Insecure validation settings ................................................................................................................ 18 Trust list challenges ............................................................................................................................ 20 Validation ambiguity ............................................................................................................................... 22 Liability challenges ..................................................................................................................................23 Evolutionary improvements ...................................................................................................................... 24 About the author .........................................................................................................................................25

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Summary of conclusions
PDF (digital) signatures are well-suited for many use cases and offer a wealth of advantages. However, in the context discussed in this paper the use of such (PAdES) signatures for the purpose of use in legal proceedings, with (automatic) legal effect across the EU as evidence that is either equivalent with a document with (a) handwritten signature(s) or with an official document with an assumption of authenticity, these signatures or seals can be problematic. This is due to many reasons, discussed in this paper. While some can be remediated in the future, others are more fundamental. In particular, in environments without strict central control, due to their validation ambiguity, which makes their perceived validity and trust unreliable and contestable, not only their legal effect is an issue, but also accountability and liability concerns should not be taken lightly to mitigate the risks of losing the (legal) value of these signatures. Even in centrally-controlled environments which rely on outsourced parties acting as (a) (qualified) trust service provider(s)1 for validation and/or extension, and thus mitigate liabilities to (an) expert partner(s), many of the aspects of PDF signatures that are perceived as advantages in more basic use cases, are counterproductive. In this context, validity and trust need to come from (an) on-line (cloud) resource(s) anyway. Especially in such scenarios where the (useful) life of these signatures may need to be longer than the time of a transaction, or where countersignatures or co-signatures may need to be added, or where a large number of automated signatures or seals are needed, the PDF signature (PAdES) format is inefficient and it can turn out to be a lot more costly to scale the preservation process and to maintain the supporting environment than when using document-format independent alternatives. That is why sometimes in contradiction to our intuition when the discussed context is or may someday become an important aspect of your business solution, deliberate considerations need to be given to when to use (possibly in combination with other technology) and when to avoid using PDF-signatures.

Defined by: Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on electronic identification and trust services for electronic transactions in the internal market [COM(2012) 238/2]

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

What is this about?

This paper discusses the aspects of using PDF signatures as a technology for electronic signatures and seals. The concept of electronic signatures and their use, requirements and attributes are described in Series Part1: Concepts and requirements. In short, this part focusses firstly on use cases where electronic signatures are a primarily utilized to record the intent by the signatory to make some sort of commitment2 and in such a way that this can be used as strong evidence in legal proceedings with an equivalent legal effect of a handwritten signature. The second set of use cases focusses on electronic seals of legal persons on electronic documents, again with the main purpose of use as strong evidence in legal proceedings or for official purposes. In this case the requirement is such that, from a legal perspective, the electronic seals guarantee the origin and integrity of electronic documents to which they are linked. As in part 1, the scope is limited to a European context. (This means the European Unions member states and other jurisdictions that closely follow the European approach in this area.) While the current and future draft legislation does not exclude the use of other types of electronic signatures or seals as legal evidence, this paper focusses on so-called qualified3 electronic signatures and seals, because of the legal protection they receive. This protection comes down to the inability of the signatory to successfully refute4 the authenticity of his or her signature. Or in case of a qualified electronic seal, any legal body of any EU member state must accept the authenticity of origin and integrity of the electronic document protected by it. In this context, under the current state of technology and security governance, in practice, qualified electronic signatures and seals will have to be based on a form of digital signatures, though it should be clear that not all digital signatures will be sufficient to create qualified electronic signatures. Nor does this mean that the legislation itself is not technology neutral in principle. In this paper the focus is on the suitability of the different types of digital signatures in PDF and their association with the documents they sign or seal.

Examples include contracts and other agreements, authorship or attribution, approvals or disapprovals, etc. The question whether the EU approach of qualified trust services and qualified certificates & signatures is a good approach which benefits the market and the public, whether it is practical or not, and whether its market adoption will be significant, is not part of the scope of this paper. To better form an opinion about this, see part4 in this series (The qualified label: facts and fiction). 4 In classical paper environments signed documents are often only a part of the evidence and are thus less critical. But in pure e-business / e-government environments the (signed) electronic document may be the only evidence available. Because of this, and because of the threats and vulnerabilities in such e-clouds, the security of electronic signatures is more crucial.
3

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Out of scope
This paper does not have as objective to give a comprehensive and up-to-date description of all the legal and security related issues surrounding the use of electronic signatures. This would probably result in a full-length book. Instead, it builds on concepts and understandings that are either at least in part comprehended by the reader or need to be simply accepted. For the detailed framework, the why and the how of the used concepts and understandings, the other parts of this series may give a broader background, or for areas not covered the author may be contacted for questions and advice. While the paper focusses on this context and the use of electronic signatures for the purpose of creating and if needed using electronic evidence in court some time into the future, it is well recognized that electronic signatures whether based on digital signatures or not can have many other purposes5.

Though it may be argued that many of the other objectives may be achieved (and have been achieved since long) by other means. It can even seem that many vendors are attempting to surf the waves of an electronic signatures hype with approaches and technology that have been re-branded.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Why PDF?
PDF has become more than a de-facto standard6 for electronic documents. We dont need to document the wealth of features that this document format and its writers and readers can offer. This is well known. So lets focus entirely on electronic (digital) signatures. The main strength of PDF signatures in this context is that they at least support a variety of standard-based advanced7 electronic signature AdES formats, namely several different formats of PAdES8. Most of the PDF signatures that claim conformance9 with a PAdES format though not all can be considered as a format compatible with advanced electronic signature requirements. This is a prerequisite for qualified electronic signatures. These signatures thus adhere to a publically available standard which is in the progress of becoming an official European Norm (EN). The standard deals with many of the typical electronic signature challenges (such as long-term validity) but also not all. What is often perceived as (and regularly is) an advantage is that the format bundles the document and signature in such a way that you always have the signature at hand when needed. This seems standard practice and intuitive, but it is not so. The fact that PDF has ubiquitous (and free) readers on many platforms and environments is also a major advantage. PDF and its signatures are feature rich allowing for the inclusion of images, logos, scanned handwritten images and other seemingly useful information. Adobe claims that signatures (and in particular their validation) can be handled off-line. To some extent this is true, though some important remarks and warnings10 need to be added to this. Validation in Adobe reader can be configured to cater to different scenarios and requirements. In a global context this seems like a real advantage. For end-to-end document security11, it offers a solution with a level of protection that is reasonable to high. Finally12, it is all very user-friendly and easy for the end-user.

6 7

See ISO 32000 As defined by the EU Directive and future EU Regulation 8 See ETSI TS 102 778 series: Technical Specification 'Electronic Signatures and Infrastructures (ESI);PDF Advanced Electronic Signature Profiles' 9 Note that there is also still the choice of using non-PAdES PKCS#7 signature formats. These should not be considered as advanced. 10 See the next section 11 As in contrast with the use as evidence with a signature that is as good as non-deniable in court 12 The author recognizes that there are more advantages, but the paper focusses more on the drawbacks because they are far less understood than the advantages.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Why not PDF?

Interdependency of document format and signature
What we have seen is that currently the PDF signature is part of the document it signs. From a paperworld perspective, this seems not only natural but also unavoidable. For PDF signatures, however, this means that the signatures depend on the PDF format itself. Any changes in the format can require an adaption of the signing logic as well. Because of this, the maintenance of external PDF signature handlers can be complex and can cause much unnecessary overhead13. Any party involved with PDF signature handlers must know and keep up-to-date the know-how of the particularities of PDF formats. This is fun for programmers, but this may be inefficient from a business perspective. Best practice: A signature handler should be document type (and version) agnostic. Then the document of other object to be signed can be seen as simply a payload of bits and bytes. This is not the case with (PAdES) PDF signatures.

Intertwined document creator and signing software

In the PDF signature approach, the PDF document is tightly linked to the signature handlers from within the (publically) available readers or the PDF writers. This signature handler is currently almost naturally a PDF signature handler (either PAdES or pre-advanced PKCS#7) and very rarely another type of signature handler that could fulfill the qualified electronic signature needs (like CAdES, XAdES or ASiC), though of course this could change. Though this is not excluded, there are currently thus no distinct layers to neatly separate the applications and workflows that produce these electronic documents and other objects14 (in any format required at any point in time) and the signing that takes place15. Best practice: The signing layer and the application/document layer should be independent of each other to support flexibility. It should be possible to make easy adaptations to the signature requirements and the used signing services providers. This is less evident with the PDF signature approach.

13

Such cases have even been reported in practice in basic scenarios such as automated electronic invoice signing (for electronic seals). 14 For instance multimedia objects like images, audio, video etc. 15 Imagine that in an Adobe Life Cycle implementation either the signature format or the document format would need to be adapted.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

How to sign other document formats?

A result of this could be that the documents of objects that need to be signed, always are expected to be in PDF. But that may not be a good long term business practice16 and it is to be expected that at some point in time other formats need to be used. Obviously, other documents, texts or objects of many different types and formats, including non-textual ones, cannot be signed with a PDF signature (save for some exceptions) unless a conversion first takes place to a PDF format or other signedobject-agnostic signature types are also used in parallel. The first approach can cause an unnecessary overhead and delay. It also makes the use of electronic signatures more complex and imposes PDF as a standard for all electronic documents and other recorded data. While this may further the interest of some vendors, this is not always efficient as we will discover in the following sections. In the second approach, an obvious question would then be Why not use signed-object-agnostic signature types (like CAdES or XAdES) for everything, including PDF documents? A seemingly simple answer to this question may already loose some of its value by looking at the The requirements for and attributes of your signatures section and in particular the sub sections Who should (be able to) validate the electronic signature? and Who is liable for the validity of signatures? of Series Part1: Concepts and requirements. In brief, the main purpose of electronic signatures in this context is the validation of the signed (or sealed) document by an arbitrator like a judge anytime (whenever far into the future the signature and the commitment it stands for is denied), anywhere (within the European areas of jurisdiction). Such validations happen very irregularly but they must be reliable to the highest17 extent. The advantages18 that thus apply when daily security and risk management are at stake, (e.g. making it possible for parties in transactions to easily verify the trust they can have in the authenticity and integrity of documents thus another objective than electronic signatures in this context19), are thus not or much less relevant in this context and can even be counterproductive as will be illustrated in this paper.

16 17

See further on: drawbacks of using signed PDF as archiving format. There is much interesting debate about this though. But not part of the scope of this paper. Please refer to the other parts in this series. 18 Such as the signature and document being bundled, the ubiquity of the readers (that also validate the signature), the features, the off-line capabilities and the user-friendliness 19 Let us again point out at the fact that in other contexts this may be the (only) objective in scope. However electronic signatures or even digital signatures are not necessary to achieve this or already exist since long in other technology used to secure transactions. This is not a judgment but an observation.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Attached signatures
PDF signatures are attached. This means that the data of the document to be signed and the actual signature are bound together and cannot be separated. From a paper world perspective, this seems obvious, desirable and even necessary. For electronic signatures this certainly is not necessary: such signatures can also be detached. As in the case of PDF signatures, the signatures are enveloped. This means that they form an integral part of the document. This may look as a major advantage because you always have the document and the signatures belonging to it together. There is no need to build up any intelligence about the location of signatures starting from the signed document and a way to retrieve the signatures. So what is wrong about that?

Automated and non-automated signing and/or validating by a service provider

In many cases, it may be or become advantageous to make use of an outsourced service (in particular a qualified service provider in the cloud) for signing the documents. For example20, this specialized service provider can take full (contractual) responsibility to ensure that the signatures are and will be qualified. If, however, the signature needs to be a PDF (PAdES) signature, it is then required to transmit the entire document in the cloud to the service provider21. Not only is the combination of PDF signatures and cloud-based signing (and validation) service providers costly and inefficient, but it also adds concerns about the confidentiality of the documents. Of course this can be dealt with, but it adds more overhead, complexity and cost22.

20 21

For other advantages, see Series Part1: Concepts and requirements In other formats this could be limited to the document s digest (for example a 256 bit secure hash) only. Especially in mobile environments with sometimes still limitations in available bandwidth, this by itself is a restricting factor for PDF signatures in the cloud. 22 Real world examples can be given of how this has led to costly scaling exercises.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Long-term preservation of electronic signatures

Especially in this context, when validation may have to happen infrequently but if it happens it must be thoroughly reliable and complete the advantage of attached (enveloped) signatures disappears just because there are no means to separate document and signature. The problem with PDF (PAdES) signatures is that: To be able to support long-term signatures, the format needs to foresee enough space within the document to add additional revocation and validation information. o This is also the case if the signature needs to support countersigning. Thus, either extension23 scenarios or countersigning scenarios cannot be supported or a relatively large space that might as well be wasted needs to be foreseen. But who worries about such a thing this day and age? o First, whether this is relevant or not depends on the number of transactions and documents that will be accumulated year by year: in that case this inefficiency can already become quite substantial24 if a really large amount of signed documents (such as contracts, approvals etc.) must be kept for many years. o But, whats worse, for long term validity all of these signatures may have to be extended every couple of years. This then comes down to25: 1. Having to store the documents in an archive that offers an electronic signature preservation service26 2. Or , having to store the documents in an archive and making use of an electronic signature preservation service by sending the documents to the service whenever they need to be extended The two scenarios each have their advantages and disadvantages. But it must be noted that an electronic signature preservation service is a very specialized service with many complexities. In fact the new EU Regulation foresees such a service by a third party namely a trust service provider which can be recognized to be a qualified trust service provider. By making use of such a qualified trust service provider there is a legal assurance that either the service provider can be relied on to protect the long-term validity of electronic signatures or in case of failure the service provider can be liable to a high extent. Thus, given the economic logic of outsourcing specialized services to specialized providers and given the market trend, the second scenario with a qualified trust service provider for electronic signature preservation in the cloud, seems like the best future scenario in the majority of cases.
23

See part1. Imagine that the amount is doubled or even tripled. 25 Note that other approaches to preserving long-term validity exist, but the standardization of these approaches and thus the official acceptance is not yet the case. Given the complexity and the widespread lack of understanding of this domain it will probably take many years before one can make use of one without worries. 26 Note that certainly not all archiving services (in fact very few) or archiving products offer this. You should not confuse an archive with an electronic signature preservation service.
24

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP In any case, even if the archive and its preservation service are set up in-house, this preservation service will need to rely on external (cloud-based) services anyway: for example an electronic timestamp service from preferably one (or even better more than one) qualified electronic timestamp service provider(s). The issues that then exist are: For the extension of the electronic signatures the stored (or archived) documents have to be retrieved anyway. The intelligence to retrieve the right documents at the right time and thus the mapping with the state of the electronic signatures must exist anyway. The extension of these PDF signatures requires the handling of the entire PDF document for every operation27. This then requires more processing overhead In a cloud scenario, and to some extent also an in-house scenario, the entire PDF documents must be transmitted to the service provider28. This is wasteful and inefficient. Again this can also cause confidentiality concerns, which probably have to be dealt with too.

Long-term preservation of electronic signatures is thus a potential issue for PDF (PAdES) signatures with costly consequences.

Version and flavors

The existence and proliferation of many different versions, handlers and flavors of PDF causes uncertainty about the capability to support different PAdES formats in the (signed) documents that are created by them. Also, since most of these handlers are built by different parties (in an open source fashion or not) a signing service or an extension service may easily encounter compatibility issues. This is excluded in case the signatures are detached and document-type agnostic, because then the signing and validation software really doesnt care what version built by which programmers is used.

27 28

For other formats this is not necessarily so: they can allow handling only the signature file separately. In other formats this could be limited to the documents digest (for example a 256 bit secure hash) only.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Dynamic content and full embedding of objects

PDF supports many features that can make the content of the document dynamic, for example by means of macros or scripts. This can mean that for instance figures and numbers can change over time. Obviously this can raise doubt over what content the signatory actually signed. Mandatory: Dynamic content should not be present in a document signed with an electronic signature in this context. As a result, in practice PDF documents should be presented in PDF/A format without dynamic features, with all necessary object types, such as font types, embedded in the document. Thus, a conversion step may be needed before every signing operation that takes place. This and the fact that embedding all needed objects is required, makes the use of PDF (and ironically in some cases PDF/A in particular) less efficient for archiving with electronic signatures which may have to be extended in time, especially as the signed commitment often in essence could be represented by a simple plain text.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Can you really trust a PDF qualified electronic signature?

Which digital certificates can you trust?
For the signature to be a qualified electronic signature, the digital certificates used for signing must be qualified and on SSCD29. Thus, a signature in this context should only be trusted if it is created with such a digital certificate. The PDF signature handlers do not have a user-friendly way for their associated ubiquitous readers to verify this, simply because: It is policy-dependent whether the on-SSCD/QESCD and/or qualified nature of the digital certificate matters or not30 There is not yet a mechanism available in PDF readers to control the policy that (only) applies for the person using it Even though the PAdES formats (namely PAdES-EPES which is not yet implemented in de PDF standard and Adobe writers and readers) theoretically do support context-sensitive validation by means of a signature policy, and some signature handlers could support this or can allow another selection to be made, the implementation of this in future versions still would not solve the issue for many reasons. For instance, the lack of control over which versions and reader types users will use to read and validate their documents and signatures makes it very likely that the validation will happen in an unreliable way by a signature handler that is policy and context unaware

In practice, this means that this is one reason why a common31 end-user should not trust PDF readers to verify the legal validity of a signature.

29

SSCD: Secure Signature Creation Devices. A more recent term is a QESCD: Qualified Electronic Signature Creation Device that allow for making a distinction with a Qualified Electronic Seal Creation Device. Conformance to this is regulated by the EU Directive to be replaced by the EU regulation and the implementing acts that identify European norms for this purpose. 30 In fact, for most of the users outside of Europe and even many in Europe this does not matter at all because either their legal context is different or their context of use is different. 31 People with particular skills, awareness and patience could perform electronic signature policy-based validations manually. But that was hardly the purpose of digital signatures in PDF one can assume.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Which timestamps can you trust?

The signatures validity may depend on the validity of a timestamp. Whether you trust a certain timestamp for such a purpose is policy and time-dependent. For a timestamp to be trusted in this context, it may have to be a qualified electronic timestamp. The validation must be able to: Make a distinction between different time stamps and trust service providers that issue (qualified) electronic timestamps Make a distinction between digital certificates that sign the timestamps: a digital certificate being qualified is by itself not enough to be trusted to sign timestamps let alone when the digital certificates used are non-qualified Ensure that the digital certificates used to sign the last timestamps are valid and their issuers are trustworthy at the time of validation Ensure that the trust service providers of the last timestamps are still trustworthy at the time of validation In practice all of this means that off-line validation is an illusion in most of the cases in this context: the validation should always happen at the present time and this requires checking trust at the present time

The above policy and context-aware validation approach is of course possible in an automated manner and thus transparent to the validator. However, for the same reason as in the previous point the proliferation of many versions and flavors of PDF readers with potentially different signature handlers as well and the lack of control over them makes it very unfeasible to realize this with ubiquitous PDF readers. In practice, this means that this is one more reason why an end-user should not trust PDF readers to verify the legal validity of a signature. But since this type of validation requires on-line access anyway, it is should not be an issue to use an on-line32 validation method in the first place.

32

This leads to other challenges of trust. But how to deal with these is out of the scope of this paper.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Limitations of PAdES in PDF

Unsupported formats

The PAdES implementation in PDF did not only ignore very useful formats like PAdES-EPES but PAdES itself misses several formats compared to the CAdES technical specification it is based on: The equivalent of the CAdES-C, -X and -XL formats do not exist. The rationale for this was to simplify and to better limit the many variations that exist in the AdES world. This was a noble objective by itself, but also one with unfortunate consequences. In practice this means that in contrast to the other AdES formats PadES does not allow long-term validity of signatures with validation information that is centrally stored. This is important particularly in the case of automated signing e.g. where (qualified) electronic seals are (to be) used on electronic documents33. In such scenarios, usually there will be an ever increasing and high amount of signatures and signed (sealed) electronic documents. As a result: These signed (sealed) electronic documents contain a huge amount of redundant information This can be very wasteful for storage space, processing power, network usage, archiving space, archiving overhead, preservation overhead etc.

In fact this is one more reasons why in contrast to a general perception signed or sealed PDF documents do not make a good format for long-term archiving.

Outdated formats

Older versions of PDF readers may only support the PAdES-Basic format. As a result, there are already many signed PDF documents around with this format. The problem is that it is much disputed whether PAdES-Basic really complies with the legal requirements of being Advanced. For example, there is the certificate substitution vulnerability in this format that at least theoretically makes this indeed questionable. ETSI34 also recommends the discontinuation of use of this format for these reasons, at least in some relying technical specifications. Furthermore, PAdES-Basic certainly does not give a good long-term-validity protection and there is widespread ignorance about this. Some of the problems that can arise from this outdated format are: Signatures in this format on historic document may someday be rejected, though older PDF readers, that may still be around, still can falsely give the impression of trust This problem may even be continued with new signatures if the signature handler (only) supports this format

33 34

Electronic invoicing can be an example where this applies. The European Telecommunications Standards Institute

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP Scenarios with revocation grace periods

PAdES allows for the incorporation of revocation data in the signature at the time of signing. Probably, the idea behind this was to try to avoid that the validator (the person or entity receiving the document) that needs to initially validate the signature needs to go online to do a revocation check on the signing certificate. However, PKI standards35 allow for a delay between the reporting of an incident that leads to the suspension or revocation of the certificate and the proliferation of this information. Therefore any digital certificate-based validation should observe a grace-period or the validator should be sure that the Certificate Policy supports real-time availability of up-to-date and reliable revocation information. It cannot be expected that the common end-user (or even the advanced user) can verify this condition on any signed document he/she receives. Thus, an online revocation check should be done by default. This is not enforced by PDF signatures and their handlers. Adobe reader prefers to ignore this36 and the revocation information included in the signature at the time of signing should not be trusted by the validator! This is one more reason why a common37 end-user should not trust PDF readers to verify the legal validity of a signature. Even if the revocation checking protocol is in real-time, and even if the update of the information is immediate38, it is still a better practice to allow for a grace-period in signature validity checking. It cannot be expected that during an incident that should result in revocation the certificate holder can immediately report the need for revocation. Of course in a person-to-organization transaction, the end-user receiving the signed document could be permitted to accept the probably small residual risk of up-to-date revocation data not yet being included in the signed document. It of course depends also on the value of the transaction. However, given the fact that there will probably be some delay between the sending and receiving plus validation, it is still better to do a revocation check at that time and this should then be enforced. As we have seen in part1, in a business-to-business scenario, the transaction probably takes some additional administration time anyway before it can be concluded (e.g. by sending a good or considering a purchase of a property to be concluded). And thus a second thorough and automated signature validation that does respect a grace period on the revocation data and then also extends the signature into a long-term validity format can and should happen.

35

This is as well as the actual practice. Of course it is possible to accept this risk. But in the authors opinion this is a policy -dependent consideration and it should never be a default. 37 People with particular skills, awareness and patience could perform signature policy-based validations manually. 38 Beware! This does not automatically follow from the previous condition.
36

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Insecure validation settings

As already mentioned, Adobe reader allows for a multitude of configuration settings related to signatures. We will show that this most likely will result in insecure validation settings for this context. It cannot be expected that the common user fully understands or even looks at all the settings that must be selected for this context. Even if this common user understands this configuration, can he/she be expected to configure and possibly re-configure his/her PDF reader every now and then? Are there then other ways around this? The good news is that security settings can be copied from a pre-existing configuration by: Loading these from a server Importing then from a file

But still, the user or an administrator acting on behalf of the user must decide which configuration applies for which context. In addition this raises new questions like: When should the configuration be checked for updates? Should these settings be digitally39 signed to protect their authenticity and integrity against a substitution attack? Which certificates can be trusted for the signing of security settings? How long does this trust last? If the security settings are imported from a file, which measures should be taken to protect the integrity and authenticity of that file?

It is clear that this requires administration and maintenance. If the wrong choices are made or if this administration and maintenance is not good enough, the reliability of the signature validations can already be jeopardized because of this. If the PDF reader or signature handler is considered as client software with necessary central administration, then where does this leave the concept of ubiquitous and independent software? And how can a user trust the particular software (e.g. an open source PDF handler) that he/she is using? Other settings include: Directory server settings Timestamp servers configuration.

39

Here the use case is clearly not related to electronic evidence thus the technical term digital signature is used.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP Updates

Another possible pitfall is the setting of the software updates. If the updates dont happen at the right time, even such fundamental information as trusted roots may be unreliable. Beware that the setting can check for updates automatically, or give a notification, or do nothing at all. Even if automatic updates are selected, it is possible that the next step (installation) is not set as an automatic action after download. Be aware that this can have an important impact on the validation results. Again, it should not be expected that a common user or even a more advanced user is aware of all of this. But the consequences can be dire. The question how the security of these updates is protected also arises. This is not revealed but if (a) secret Adobe master key(s) is used for this purpose, it is everything but a guarantee that attacks can exploit vulnerabilities to poison the trust lists with rogue trust anchors. Different plugins like digital signature plugins can also be selected. Again, this obviously can have an impact on the validation behavior and the results.

Creation and validation settings

The following elements can be problematic and lead to signature validation ambiguity, unreliability or even false results: The signature creation option to include the signature revocation status is set by default. Valid but untrusted signatures are not automatically brought to the attention of the user. The revocation behavior (which can be seen as part of a signature validation policy) is a matter of choice and configuration. o The Adobe default security is an option, but is the common user expected to know what this means? The verification time is a matter of choice. Even signature creation time and expired timestamps can be used. Revocation checking is not automatic and can be disabled. The automatically trust all root certificates in the windows certificate store can be set. The document validation information is not automatically ignored.

One of the possible settings has to be singled out; because it shows that the designers at least had a good sense of humor. For the setting Automatically add verification information the option is Ask when verification information is too big. In short, the above settings provide a nice mine field that can easily make the validation results unreliable in our context.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Trust list challenges

In brief, where it finally comes down to40, when deciding whether you trust an advanced electronic signature or not regardless whether the digital signature is cryptographically valid and the format is conformant with the requirements of being an advanced electronic signature, is whether: The signing certificate was valid and trusted at the time of signing And, the cryptographic validation evidence which supports the validity of the signing certificate is protected in such a way that it is cryptographically valid and trusted at the time of validation

The validity of the signing certificate except for the standard cryptographic validity and revocation checks eventually depends on the trust in the root certificate of the certificate chain of the signing certificate and on the status of the trust service provider which issued in our context the qualified signing certificate. The validity of and the trust in the validation evidence usually depends on a chain of evidence timestamps. Each of the timestamps should provide a proof of existence of the earlier timestamps, their validation data, and where applicable the signatures past validity. Every of these past timestamps must also have been trusted at the time they were created. This can imply that that the timestamp authority must (still) have been a qualified electronic timestamp trust service provider at the time indicated in the timestamp. The above requirements also lead to more requirements regarding the cryptographic algorithms and parameters used in the timestamps. Not only does a new timestamp have to be applied before its certificate expires, but a new timestamp based on stronger cryptographic algorithms and parameters is also due before the last ones become unreliable. For example, if a timestamp based on either unreliable cryptographic algorithm/parameters or on an unreliable timestamp certificate is needed to prove an evidence chain, then it may not be possible to establish a sufficiently reliable proof of existence. Of course, historic algorithm appropriateness should also be part of the validation.

40

This only gives a concise summary of signature validation. Of course this topic may need to be discussed in much more detail.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP So now, to come to the point, what are the issues with the relation between validation and trust in the PDF signatures and Adobe readers41? To summarize, the most important ones are the following: The trust list is a proprietary trust list42. As a result it contains trust anchors that are not suitable for this context. And vice versa, a trust anchor that is officially trusted by the EU member states bodies and appears on EU trusted lists may just as well be untrusted in Adobes proprietary trust list. This is a formula for misleading validity43 results. The trust mechanism does not automatically distinguish trust anchors that are non-qualified form trust anchors that belong to a qualified trust service provider. For example, an end user may see an indication that the signature is valid and trusted, while the signature is actually not a qualified electronic signature. Also this can give rise to misleading validity results. The trust mechanism does not automatically distinguish between the types of trust service provider. For example, a certificate that may be trusted as a signing certificate should not automatically44 be trusted as a timestamps certificate. One more distinction that should be made here too is that between qualified and non-qualified. Also this can give rise to misleading validity results. There is no suitable mechanism for verifying historic trust anchors. For example, a timestamp certificates issuer is not included in the trust list anymore but it may have been at the time it was created. The opposite can also happen. Thus the trust validation becomes unreliable.

The above examples illustrate a more fundamental problem. Probably because this context is only a niche market for Adobe, the validation-trust mechanisms are not fine-grained and sophisticated enough for this context. In fact it can even be questioned (but that is only a personal reflection of course) whether they have been sufficiently understood.

41

We base ourselves on version XI, but some of the issues are systemic. In fairness, it needs to be added that seemingly objective criteria are at its basis in addition to commercial interests. However, in this context the question is whether the European judiciary recognizes the trust as qualified. It should also be noted that serious incidents have proven thos e criteria to be ineffective. 43 In the European technical specifications and the used terminology a valid result also requires trust. 44 In fact it rarely is. Many natural persons or legal persons may possess a qualified certificate for electronic signatures or electronic seals. But few legal persons will be entitled to seal a (qualified) electronic timestamp.
42

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Validation ambiguity
The result of having on the one hand many free configuration settings while on the other hand there is a lack of (central) control over the signature validation policy that should apply in the given context, and the proliferation of many different PDF signature handlers, with different origins, versions, plug-ins, etc. results into what is called validation ambiguity. It means that the validation of one particular signature may return different results depending on what signature handler you use, with configuration it has, and when you execute the validation. For example: Signature handler 1 says your signature is valid, signature 2 pronounces it as invalid Signature handler 1 gives the result as invalid 2 years later The security setting for signature 2 is altered (on purpose, accidentally or maliciously) and now the result is valid

Riddle: what is the true status of the signature? Answer: it depends! Now, the central question should be how a judge should at a given time verify the validity of this signature. PDF signatures and their handlers do not deal effectively with validation ambiguity. In case of disputes in court, this could lead to nasty surprises. But you have been warned45.

45

Again I want to point out that it may be for your particular use cases or scenario that the risk and possible impact of this is negligible. Then you may ignore this warning and several other warnings. Still, you should then ask the question whether you need to use any electronic signature at all and for what purpose if you do.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Liability challenges
In the above points it has been shown that there are many reasons why a signature validation in PDF should not be generally trusted by an end-user in this context. However, it can be assured that due to their ignorance and possibly also due to the fact that misleading information about this subject is widespread, most users will trust the validity of a signature validation in PDF anyway regardless of the use case. That may even apply to many businesses and public institutions. The question is then: if the user has what later proves to be unwarranted trust in the signature validation result from a commonly available Adobe reader or other PDF handler, and this results into damages at certain time, then which party if any is liable for the damage? There are different ways to answer this question. To give some possible answers, it seems to be that: If one considers the situation as being merely a relationship between a customer and a software vendor, it is probably so that the license agreement includes disclaimers that when push comes to shove the vendor cannot be liable for such eventualities. To consider a somewhat comparable situation, no software vendors, not even those in the security domain, guarantee the error-free and vulnerability-free operation of their software. But in this case, the question is: What is the value of signature validation software if there are no such warranties and corresponding liabilities? It could also be the case that the relationship is one between a customer and a service provider. In this case, the service provider could formulate liabilities in a service agreement. It is up to the customer to then decide whether the offered guarantees and the defined liabilities are sufficient. The service provider could also be an official trust service provider, as according to the EU regulation. In that case liabilities are a mandatory part of the service agreement. In case the trust service provider is a qualified trust service provider this should yield an even higher degree of trust the customer can have in the signatures.

Given that in this context electronic signatures can be of vital importance and the effective use of these signatures in court whenever needed is directly linked to the bottom line, liability issues should not be taken lightly in this domain. Because if you dont need to rely on the legal effect of these signatures in this context, then why do you need them in the first place?

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

Evolutionary improvements
Obviously, many of the disadvantages and issue that have been identified in this paper though probably not all can be mitigated by means of improvements in the PDF (PAdES) signature standard, practice, software46 and its use. It can be expected that some improvement will already be scheduled at the time of writing. However, given the fact that PDF signature use in this context is probably seen as a niche market47, and due to the fact that the main market lies outside48 of the EU, it can also be expected that some of the deficiencies will remain for quite some time to come. Since in this context the signatures that you receive today will probably need to be valid up till quite some time in the future, this evolution if it happens at all may be too late for you. Though it is difficult to predict, the electronic signature legal philosophy and paradigm in the EU may also change, perhaps even resulting in a lower standard of proof. In that case several of the issues may become irrelevant at least for some time. This is because cybercrime, cyber-terrorism and cyber-warfare will most likely also become more sophisticated and the public and its interests will have to be protected by better regulations and more stringent demands when it comes to trust in the electronic world.

46

For example, the PDF reader may be seen as a client which transmits the signature for validation to a trust service provider. 47 And most likely that is currently true from a general and global business perspective. 48 A good indication of this was Adobes acquisition of Echosign a technology based on a paradigm with a very different origin than the European paradigm of (qualified) electronic signatures.

Signatures in the electronic world - part 3: 'When to avoid using PDF signatures' by Leslie Goodman, CISSP

About the author

The author of this paper and the series it is part of is Leslie Glenn Goodman. Leslie is a Certified Information Systems Security Professional (CISSP) with decades of experience in Information Security and PKI. Leslies interest and further studies brought him in a unique position to approach the subject of electronic signatures from a holistic perspective. This includes a risk management approach, a legal approach, a technological approach and a business-oriented approach. For several years, Leslie has also been active as Senior Product Manager at Certipost, then a Certification Service Provider and Certification Authority. The subjects that he writes about have thus been a part not only of his domain of expertise but have also been tested by his practical experiences.