Lawyers, Engineers and Technology: A Case Study

Lawyers and engineers see the world differently. It is as if they speak different languages, and difficulties of mutual understanding arise. The problem is not so much that they use different words to describe the same thing but rather that they may use the same words to describe different things. It may be more helpful to think of lawyers and engineers as having different belief systems: the motivation for understanding the world and what makes it tick differ. One belief system is not more accurate or ‘true’ than the other, but they can have different practical consequences.

 So long as their professional language describes phenomena that are of concern in one world and not the other, the differences have little impact. Understanding the law of thermodynamics will call on engineering expertise that lawyers will not – as lawyers – assert. Understanding the law of joint and several liability will not engage engineers as such. 

However, difficulties may arise when one is using vocabulary that overlaps between the disciplines. Some ‘overlapping’ terms present less risk of confusion than others. An engineer speaking of ‘stress’ in analyzing why a bridge may collapse is not likely to think of its impact in the same way that a lawyer would in submitting that ‘stress’ influences the culpability of his or her client. 

When law intersects with technology, the area of overlap expands, and so does the risk of misunderstanding or misuse. Engineers design devices or processes and describe them in engineering terms; lawyers may need to describe the same processes and devices in legal terms. This intersection has long existed in areas such as patent law, where the technical functioning of an invention must be fitted into legal concepts that permit it to gain statutory protection. Now that most of the our society is touched with technology to some degree, lawyers need to weigh its legal effect to do their job.

The law has never left determining the legal effect of technology to technologists. Expert witnesses may be called to ensure that decision-makers have an accurate understanding of relevant technology. It is well established, however, that the experts are not permitted to give opinions on the legal effect of the technology they describe. This rule arises not from the desire of the judicial system to preserve a monopoly, but from the incompatibility of the analytic frameworks in which the experts and the lawyers operate. Legal effects never depend entirely on physical phenomena. Legal rules and human interactions play a role too, and these are not questions of engineering. As Justice Holmes said, the life of the law is not logic but experience.

Just as lawyers need to be sure they understand how technology works before venturing to opine on its legal effect, so too do engineers need to be cautious before attributing legal effect to their technologies. Today’s case in point: a United Nations draft technical standard on ‘signed digital evidence’: United Nations Economic Commission for Europe’s Centre for Trade Facilitation and Electronic Business (UNE/CEFACT) Recommendation No. 37, “Signed Digital Evidence Interoperability Recommendation” , ECE/TRADE/C/CEFACT/2010/14. It is intended to solve (at least part of) the problem that digital signature verification systems often cannot read each others’ certificates because they are not interoperable.

It is clear from this document that ‘evidence’ is one of those overlapping terms to be handled with care.

This document has been submitted to UNE/CEFACT by the Architecture, Engineering and Construction Working Group, all engineers. A slide deck done in September 2010 says that Rec.37 is not a technical standard or a way of recognizing e-signatures across international borders. Nevertheless the Recommendation talks as if it has an impact on the rules of evidence, and to that extent it is seriously defective. 

The Executive Summary likewise disclaims any intention to deal with legal aspects of electronic signatures, which are dealt with internationally by other documents, such as those published by UNCITRAL – the Model Laws on Electronic Commerce and Signatures, and the like. Nevertheless the ‘Scope’ section of the text says that the standard will ‘simplify and facilitate the exchange and verification of electronic documents with probative value.’ (para 2.1(4)) The ‘Audience’ is described as individuals and organizations concerned with, among other things, ‘[e]nsuring the interoperability, reversibility and validity of signed digital evidence.’ (para 2.3) Probative value and validity are legal terms, particularly when associated with ‘evidence’. (I have no idea what ‘reversibility’ may mean in this context.) An operating manual intending to promote those goals must be based on an understanding of their legal meaning.

More important, Rec 37 is not about ‘evidence’ in a legal sense. As noted, the language of the document talks about facilitating the use of e-documents ‘with legal or probative value.’ Complying with the Recommendation, however, will not add any legal or probative value to an electronic signature, or to the signed document, created in compliance with it. At best it will make such a signature easier to verify by someone else’s computer. That is a technical but not a legal advantage.

The engineer authors appear to believe that an electronic document must be signed in order to be admitted as evidence. The Executive Summary leads off, ‘A digital document, unlike a paper document, has little evidence value until it is reinforced by a mechanism, such as an electronic signature, which guarantees its integrity and authenticity.’ In much of the world this is not true. While some support for integrity and authenticity may be required, that support does not need to be a ‘mechanism’. It may simply be oral evidence, or contextual argument. Further, no ‘guarantee’ is needed. Authentication on the balance of probabilities, in all the circumstances, will suffice.

The authors go on at length about how to verify a signature by automated means. They favour a single e-signature technique – digital signatures (those generated by dual-key cryptography) supported by certificates in a public key infrastructure (PKI) – over many alternatives, despite that the international legal framework for signatures is resolutely technology neutral. They even claim (in the Preface) that there is an ‘urgent need for improved interoperability of digital evidence verification’. No such urgency is demonstrated in the document. 

Rec 37 deals with only one problem: what should one understand from a digital certificate? It goes into much detail about the kinds of things that can be signed, the kind of relationship between the signature and the content, the role and placement of ‘co-signers’ or ‘counter-signatures,’ a term that seems to mean what we would traditionally call certificates. The document recognizes that these details aim to support assertions of the identity or role of the signer. It says nothing, however, about what kind of support might be acceptable in evidence, much less why the support described in the Recommendation should be credible.

Rec 37 is intended to integrate with various other digital signature standards, of which many are listed in footnotes 4 through 12 and in the ‘definitions’ section, though only a few turn up in the lengthy annexes that set out the functional implementation rules, the technical implementation guidelines, and the cryptographic algorithms to support the Recommendation. Almost all of them are European standards intended to implement the EU E-Signature Directive. Now that the EU is reviewing the E-Signature Directive, it may not be the best time to be making recommendations about how to implement it. It is even arguable that the E-Signature Directive has failed, and that the newer EU Directive on e-Invoicing is a kind of admission of this failure.

Moreover, the requirements of both those Directives are a matter for the EU only. They simply do not apply to many other legal systems in the world, or even similar systems not governed by EU Directives. For example, the common law world does not require invoices be signed. It satisfies the policy of the signature requirement by other means. The European engineers responsible for Rec 37 do not appreciate this variety of legal regimes in what is proposed as a United Nations, i.e. global, recommendation. 

For that matter, the other digital signature standards mentioned have been found wanting in their application to the law of evidence. In particular, they have not been able to answer the following questions, on which Rec 37 is completely silent:

• What standards apply to the certification (or counter-signature) so that the certifier/counter-signer asserts with confidence the (a) identity, and (b) authority of the signer? What are the qualifications of a certifier/counter-signer? (It is not clear if the perennial difficult question of the liability of the certifier is relevant to what is attempted here. Probably not, except to the extent that potential liability may compel adherence to high standards.)
• What makes a court or a party to a legal dispute believe the assertions in paragraph 4.2 about the intention of the signer? Among the ‘functional features’ of ‘the proposed signed digital evidence profile’ are ‘a signature policy which describes the precise role and commitments that the signatory intends to assume with respect to the signed data’, and the ‘type of commitment associated with the signature: explicitly indicates to a verifier that by signing the data, it illustrates a specific type of commitment on behalf of the signatory.’ In addition, the ‘profile’ will specify ‘the role(s) or position(s) claimed by the signatory when signing the data.’ The presence of electronic codes making such assertions does not make them more credible in the face of a denial by the purported signer. Are we back to the notorious and notoriously failed ‘non-repudiation bit’ that made earlier PKI systems the laughing-stock of lawyers in many countries?
• Do the authors of Rec 37 believe that a technical code can itself bind the parties to a signed document? As a matter of law, the form of a signature or even the fact of a signature does not say anything about the function of a signature. The function of a signature can be detected only by the full context of the signature, including at times outside evidence (just as one may need outside evidence to link a scrawl of ink on paper with an individual whose signature it is). The function of a signature cannot be resolved by technical analysis. Having a technical assertion of function may be helpful, or it may produce more questions to be disputed in court, but it is badly misleading to claim that it is ‘probative’.
• What rules apply to the use and operation of signing devices by signers? How are those rules enforced, and compliance with them proved?

In short, Rec 37 adds only a small piece of useful information to the e-signature universe. It may be useful to standardize the form of assertions made by the class of e-signatures known as digital signatures (notably those supported by PKI), so that different systems of verification can automatically recognize assertions made by different systems of creation of signatures. But there is no justification for moving from that function to suggesting that complying with the Recommendation makes an e-document of legal value or more probative than it was before, even if combined with existing standards on digital signatures.

 The engineers needed to talk to some lawyers.