Electronic Signatures — Evidence: The evidential issues relating to electronic signatures — PART II

Computer Law & Security Report Vol. 18 no. 4 2002ISSN 0267 3649/02/$22.00 © 2002 Elsevier Science Ltd. All rights reserved

241

Electronic Signatures — Evidence

10 (a) Shifting the onus of proof - UNCITRAL

It has been suggested by McCullagh and Caelli that the techni-cal meaning of ‘non-repudiation’has the effect of either shiftingthe onus of proof from the recipient of the alleged electronicsignature, or denying the right of the user of the certifying cer-tificate to repudiate the certificate.25 Whilst it is clear that ‘non-repudiation’ has different meanings in the legal sense and thetechnical cryptographic sense, there is a further differencebetween the two,as pointed out by the same authors.That is thetechnical meaning relates to events that have taken place afterthe signature has taken place, and has no relation to the actualmechanism of the affixing of the digital certificate.26

McCullagh and Caelli argue that Article 13 of the UNCI-TRAL Model Law on Electronic Commerce puts the onus ofproof on the signatory to prove that the certifying certificateis a forgery. Article 13 reads as follows:27

Article 13.Attribution of data messages(1) A data message is that of the originator if it was sent bythe originator itself.(2) As between the originator and the addressee, a data mes-sage is deemed to be that of the originator if it was sent:(a) by a person who had the authority to act on behalf of theoriginator in respect of that data message; or (b) by an information system programmed by, or on behalfof, the originator to operate automatically.(3) As between the originator and the addressee, anaddressee is entitled to regard a data message as being that ofthe originator, and to act on that assumption, if:(a) in order to ascertain whether the data message was thatof the originator, the addressee properly applied a procedurepreviously agreed to by the originator for that purpose; or (b) the data message as received by the addressee resultedfrom the actions of a person whose relationship with theoriginator or with any agent of the originator enabled that

person to gain access to a method used by the originator toidentify data messages as its own.(4) Paragraph (3) does not apply:(a) as of the time when the addressee has both received noticefrom the originator that the data message is not that of the orig-inator,and had reasonable time to act accordingly;or (b) in a case within paragraph (3)(b), at any time when theaddressee knew or should have known, had it exercised rea-sonable care or used any agreed procedure, that the datamessage was not that of the originator.(5) Where a data message is that of the originator or is deemedto be that of the originator, or the addressee is entitled to acton that assumption, then, as between the originator and theaddressee, the addressee is entitled to regard the data messageas received as being what the originator intended to send,andto act on that assumption. The addressee is not so entitledwhen it knew or should have known, had it exercised reason-able care or used any agreed procedure, that the transmissionresulted in any error in the data message as received.(6) The addressee is entitled to regard each data messagereceived as a separate data message and to act on thatassumption, except to the extent that it duplicates anotherdata message and the addressee knew or should haveknown, had it exercised reasonable care or used any agreedprocedure, that the data message was a duplicate.

The following points are pertinent in relation to the provisions of Article 13:• The guidance note 83 indicates that Article 13 originates

in article 5 of the UNCITRAL Model Law on InternationalCredit Transfers.This defines the obligations of the sender ofa payment order.Bearing in mind such a transfer would nor-mally be subject to a contractual agreement between theparties, setting out the technical procedures agreedbetween each party (and any other parties in the chain) forsuch a transfer, it seems improbable that such a provision

ELECTRONIC SIGNATURES —EVIDENCETHE EVIDENTIAL ISSUES RELATING TO ELECTRONICSIGNATURES — PART IIStephen Mason, Barrister, Consultant

Both the Government and industry are keenly promoting the use of electronic signatures. It is assumed that thewidespread use of electronic signatures will encourage greater use of the Internet as a means to buy goodsand services.This article, in two parts, looks at the evidential issues relating to electronic signatures, and illus-trates the weakness of the infrastructure which, in turn, highlights the risks that both users and recipientsencounter when using electronic signatures.

CLSR1804.qxd 7/3/02 2:54 PM Page 241

242


should affect a public key infrastructure, which uses theopen network of the Internet.

• Guidance note 83 further states that it is not the purposeof Article 13 to assign responsibility between the parties.

• Guidance note 84 reinforces the point of Article 13(1),which is simply that the person originating the message isliable if it was sent by them.

• Earlier drafts of Article 13 included, according to guidancenote 92, an additional paragraph inferring that nationallaw would be used to determine attribution of the author-ship of the message.

Whilst the Article as presently drafted does not expresslymake this point, nevertheless it seems clear from the provi-sions of Article 13(1), that the onus of proof has indeed beenreversed. The logic can be described as follows:• If a user chooses to have a certifying certificate,it is assumed

that the user will be the only person to use it.• Where a recipient wishes to rely upon the electronic signa-

ture, provided they carry out adequate procedures to demon-strate the authenticity of the certifying certificate under Arti-cle 13(5) (i.e. undertake the verifying procedures set out for a electronic signature), the recipient is permitted to assumethe electronic signature is that of the sender. In this instance,the recipient is under a duty to carry out such procedures.

• Should the sender dispute they sent the electronic messagewith the electronic signature attached, it will be for the sender to demonstrate that they did not send the message.

(b) Shifting the onus of proof - Englandand Wales - common lawOn the face of the decision of Waller J in SSttaannddaarrdd BBaannkk LLoonnddoonnLLiimmiitteedd vv BBaannkk ooff TTookkyyoo LLiimmiitteedd [1995] CLC 496; [1996] 1C.T.L.R.T-17, it appears that this presumption may have alreadybeen adopted in England and Wales. In this case, the Bank ofTokyo in Kuala Lumpur arranged for three tested telexes to besent to Standard,containing a secret code confirming and auth-enticating the authorized signatory of three letters of creditwith a total face value of US$19.8m, and confirming that theBank of Tokyo accepted all responsibilities and liabilities underthose letters of credit. Evidence was adduced to indicate thatbanks not only used this system with confidence,but used it toavoid arguments about authority. In this instance, the testedtelexes were sent fraudulently.

The main thrust of the Bank of Tokyo’s case was this:becausethey could establish that a fraudster must have been working intheir tested telex department,Standard could only rely upon theapparent authority of the tested telexes.As a result, it argued thatthere was a lower test to establish the lack of apparent authority.Waller J disagreed with this argument,because the issue was notreliance on apparent authority,as set out at 502 C:

Standard rely first on a general representation by BOT that if atelex comes by tested telex that telex will be duly authorizedby BOT (that representation on any view is authorised);second they rely on the use of the tested telex mechanismitself as representing that the telex is authorized as the previ-ous representation stated that it would be; andthirdly they rely on the statement in the telex as being theauthorized statement of BOT.

The Bank of Tokyo was found liable for negligent misrepre-sentation because the tested telexes could not have been sent

without negligence on the bank’s part.Whether Standard hada duty to inquire into the authenticity of the tested telexesdepended, in Waller J’s view at 501 H,on the circumstances ofeach and every case.

Tested telexes contain codes or tests that are secretbetween the sender and the recipient.This allows the recipi-ent to accept without question that the telex was sent by andwith the authority of the sender. The tested telexes in thisinstance were sent through other banks, because the Bank ofTokyo in Kuala Lumpur did not have a means of directlyauthenticating telexes between itself and Standard.

By sending tested telexes,banks intend the receiving bankto act on the content without further instructions.This meansthe receiving bank requires the sending bank to:• confirm the person signing the document is an autho-

rized signatory;• the signatory is authorized to sign the particular document;• provide sufficient evidence to satisfy the recipient that

the sending bank authorized the sending of the telex.Superficially, there is a similarity between the circumstancesof this case and the world of public key infrastructure, wherethe authentication process has to go through so many chan-nels. However, there is a distinction between a tested telexproduced in a bank and the public key infrastructure. Theauthority of a telex is reliant upon internal systems within thebank No third party is involved in identifying the sender ofthe telex or authenticating the codes or text sent. In addition,the tested telex is sent through other banks over secure linesof communication.

Conversely, the public key infrastructure operates overthe Internet,which was designed to be open and is, therefore,insecure The link between the identity and authentication ofa user of an electronic signature is not as cohesive as betweensuch trusted parties as banks. There are significantly morelinks, which neither party has control over, in the chainbetween the user of an electronic signature and the partyintending to rely on an electronic signature.

As a result, it can be argued that there is a distinctionbetween what can be termed a ‘secure communication sys-tem’ and an ‘open communications system’. Clearly, the bur-den of proving that an electronic signature was usedwithout authority must be borne by either the user or therelying party. In this instance,Waller J took the view that thesender was in full control of the environment in which thetested telex was sent, and decided that the burden shouldfall on the sender.

Whether it is for the user, when using an electronic signa-ture, to bear such a burden, is debatable. For instance, Smithpoints out that the type of technology used, both its purposeand methodology, may have a bearing on this issue28. Thereare several factors that must be considered before reaching aconclusion in relation to this matter.First, if it is accepted thatthe relying party is required to establish whether they couldrely on the certificate in all the circumstances, they will berequired to provide any or all of the following evidence,depending on the nature of the challenge:• the certifying certificate used to affix the electronic signa-

ture was used properly;• the certifying certificate used to affix the electronic signa-

ture to the communication had not been revoked or com-promised in some way, by providing the statement under

CLSR1804.qxd 7/3/02 2:54 PM Page 242

243


the provisions of section 7(3) to prove the integrity andreliability of the relevant certifying certificate;

• that the communication could not have come from anothersource;or

• that the communication was intended to have legal effect,because extrinsic evidence can be produced to demon-strate the intention of the sender.

Providing the replying party has carried out all the relevantchecks required,it can then be argued that it has discharged whatcan be described as a procedural and due diligence burden.29

Once the relying party has satisfied a judge that it has dis-charged the procedural and due diligence burden, the userwill need to address the issue of the security and integrity oftheir computer or system.This can be described as the bur-den of proof of security and integrity,which comprises both apersuasive burden (or burden of proof on the pleadings) andthe evidential burden of adducing evidence.

In the event of a dispute, it follows that it is the holder ofthe certifying certificate who is in the best position to proveeither that the security in place was inadequate, whichimplies it would be possible for an unauthorized third party(internal or external) to use the certifying certificate improp-erly, or that the security in place was such that the certifyingcertificate could not be used improperly.The user will be incontrol of the following (this list is not exhaustive):• the hardware and the software of the computer or system

upon which the private key sits;• the security in place in relation to the computer or sys-

tem, the use of the system by employees and the controlof any tokens used to store the private key;

• the ability of the user to revoke their key promptly afterfinding out that their system or key was compromised.

If the user wishes to argue their security was so poor that anunauthorized third party could have gained access to thesystem to send an electronic communication with an elec-tronic signature attached without authority, the user willundoubtedly be admitting breach of contract with the ven-dor from whom they obtained the certifying certificate.Theuser may also be admitting they were negligent.

Finally, once a communication leaves the user’s comput-er or system, they relinquish control of the document. If theuser can demonstrate the effectiveness of the security andintegrity of their computer or system, the next link is thenetwork over which the communication passes. In thisinstance, evidence may be required from a number of orga-nizations in the chain (discussed in more detail below),including:• the methods of management the trusted third party uses

to control its infrastructure;• whether the link between the issuing of the certificate

and its use was to be trusted; and• the effectiveness or otherwise of any third-party supplier

whose product or service is included in the chain.If the relying party can demonstrate that they carried outdue diligence, and the user can demonstrate the securityand integrity of their computer or system, the question thenbecomes: which party to the proceedings has the persua-sive and evidential burden of demonstrating any weakness-es in the infrastructure.Whichever party bears this burden,it will be an expensive process, bearing in mind the numberof organizations that make up the chain. In a dispute, the

burden of proof will inevitably be on the party that assertsthe problem lies with third parties in the chain. It seems thatall the relying party needs to do is to demonstrate procedur-al and due diligence.Thereafter, it is for the sender either todemonstrate lack of security, or the fault occurred as theresult of failure by third parties in the chain, unlike in theburden in proving a manuscript signature. This willinevitably mean that the sender will have to make this asser-tion in the pleadings, which will determine the persuasiveburden (and invariably the evidential burden) will lie withthe sending party.30

(c) Shifting the onus of proof — Englandand Wales — Electronic CommunicationsAct 2000By section 8(1) of the Act, Parliament has given the appropriateMinister the authority to modify the provisions of:

(a) any enactment or subordinate legislation, or(b) any scheme, licence,authorization or approval issued,grant-ed or given by or under any enactment or subordinate legisla-tion in such manner as he may think fit for the purpose ofauthorizing or facilitating the use of electronic communicationsor electronic storage (instead of other forms of communicationor storage) for any purpose mentioned in subsection (2).

Whilst the power to modify legislation may be considered tobe helpful in changing the law relating to the use of electron-ic signatures,31 nevertheless, it must be pointed out that theAct allows for the burden of proof to be shifted, if so desiredby a minister.The relevant sections are section 8(4)(g), whichreads as follows:

(4) Without prejudice to the generality of subsection (1), thepower to make an order under this section shall includepower to make an order containing any of the following provisions-…(g) provision, in relation to cases in which the use of elec-tronic communications or electronic storage is so autho-rised, for the determination of any of the matters mentionedin subsection (5), or as to the manner in which they may beproved in legal proceedings;and section 8(5)(d), which reads as follows:(5) The matters referred to in subsection (4)(g) are---(d) the person by whom such a thing was done.

In combination, these sections give scope to a Minister todetermine where the burden of proof will lie in any particu-lar order issued under the Act.32

As a result, persons deciding to use electronic signatureswill need to ensure they guard the use of their certifyingcertificates very closely. In particular, they will need toensure that their computer or the system upon which theelectronic signature sits, is properly protected from therisks set out later in this article. People using electronic sig-natures will have to determine what steps are reasonable toprotect their private keys. In all probability, companies andfirms will have to consider abiding by DISC PD 5000:1999Electronic documents and e-commerce transactions aslegally admissible evidence.33 In this respect, it is only rightthat solicitors should be concerned about the proposals forconveyancing, because the risks are serious and certainlyoutweigh the benefits that some people claim.34

CLSR1804.qxd 7/3/02 2:54 PM Page 243

244


11. EVIDENTIAL WEIGHTIt will evident from the above discussion that trusted third partieswill need to guarantee that they can audit the evidential trail in rela-tion to the use and control of the certifying certificates and keynumbers they issue. In this respect, both the trusted third partiesoffering certifying certificates and individuals challenging the ad--missibility of communications associated with electronic signa-tures will need to be able to demonstrate the integrity of their res-pective systems (or lack of integrity),as the case may be.The weightto be given to evidence relating to electronic signatures is predicat-ed on the degree of control exercised over the controlled andsecure environment of all the parties in the chain. It follows that itwill be for a judge to decide what weight, if any, is to be placed onthe integrity of the infrastructure in the event of a dispute.

12.THE TRUSTED THIRD PARTY

The use of a certifying certificate does not necessarily requirethe existence of a certification authority.35 Parties that wish toagree a procedure that ensures the authenticity of documentspassing between them can make their own arrangements.Theymay choose to use a private key, where each party has the samekey, and do not share it with any other entity.Alternatively, theymay rely on a dual key,comprising a private key and a public key,issued by a certification authority or trusted third party.36

When a certification authority issues a certificate, it bases theissuance of the certificate on its Certificate Practice Statement andterms of trade.A contractual relationship is formed between thecertification authority and the customer who buys the certificate.37

Whilst the certificate purports to verify the identity of an individualperson or legal entity, it is the merchant or person receiving thecertificate that relies on the content of the certificate,known as therelying party.38 The logic is as follows:39

• The individual provides the certification authority with suffi-cient evidence to demonstrate that they are who they say theyare. Depending on the level of the certificate obtained, thisinformation could be merely name,address and the number ofa driving licence. For certificates that will support high-valuetransactions, the person seeking a certificate may be requiredto provide more robust evidence, including physically appear-ing before a notary public.

• The certification authority provides the user with a certificate.• The individual is then given a keyholder’s name.• The keyholder is the person that obtained the certificate.• This all the recipient needs to know.There are a number of flaws with this logic. For instance,John Smith of York may wish to enter a contract with a companywho is not aware of his identity. The company cannot distinguish,when it looks at the certificate,how many John Smiths live in York,and whether this particular John Smith is the person identifiedwith the certificate. Unless the certificate provides the companywith a unique identifier identifying this particular John Smith(which they may or may not provide), and the company wishes toconfirm John Smith’s identity, it must consider other ways of doingso. In conclusion, a certification authority provides a very narrowpromise when issuing a certifying certificate. It does not appearthat certification authorities seek first to establish the identity of aperson and then go on to verify that identity. It is crucial to under-stand that verification is not the same as identification.40

The point is, the certification authority generally does notshare a secret with the person to whom they provide a certificate.

Many certification authorities use the information collected by acredit bureau to identify the identity of the applicant. This meansthe identification process is based on the accuracy of the data col-lected by the credit bureau and the effectiveness of the creditbureau in keeping the information up-to-date. Another issue iswhether the recipient of the electronic signature trusts the origi-nator’s certification authority.

13.THE ROLE OF THE TRUSTED THIRD PARTY

The certification authority is a trusted third party that purports toascertain the identity of a person,and certifies that the public keyof a private key pair used to create a certifying certificate actuallybelongs to a particular person or entity. The steps in the certifica-tion process will depend on what evidence the certificationauthority obtains from the person wishing to buy a certifying cer-tificate, and the value attached to the certificate.The reader willbe aware that Article 5 of the EU Directive 1999/93/ EC on aCommunity framework for electronic signatures, OJ L13 19January 2000 provides for both simple electronic signatures andcertified advanced electronic signatures. It is debatable whetherthe UK government will have to amend the Act to provide for anadvanced electronic signature,41 but the existence of an advancedelectronic signature does not affect the technical problems thatmay arise where a person does not accept they used their elec-tronic certificate to sign a communication.42

For instance, an individual could generate their own publicand private key pair, using software on their computer.43 Theindividual then provides the certification authority with evi-dence of their identity. The type of evidence and degree ofproof will depend on the nature of the type of certifying cer-tificate required. In outline, it has been suggested that a certifi-cation authority will undertake the following tasks:• reliably identify the person or entity applying for a certifying

certificate;• reliably verify their legal capacity;• confirm the attribution of a certifying certificate to an identi-

fied physical person or legal entity by means of a certifying cer-tificate;

• maintain online access to the public register;• take measures to ensure the confidentiality of the private

key is guaranteed.44

When the certification authority has verified the identity of theindividual or entity to their satisfaction,they will issue a certificate.This is a computer record that affirms the connection of a publickey to an identified person or corporate entity.The certificate canidentify the following:• the certification authority issuing the certificate;• the individual’s public key; and• other information including, but not limited to the serial num-

ber of the certificate, the user’s name, place of birth, whetherthey are a natural person, their legal domicile, virtual domicile,an expiry date for the public key and,depending on the type ofcertificate issued,the value limit and any powers of agency.45

14.THE INFRASTRUCTURE

To enable a user of a certifying certificate to trust a certificationauthority, a number of factors have to be taken into account,some of which will be determined by legislation, others whichare internal to the certificate authority.

CLSR1804.qxd 7/3/02 2:54 PM Page 244

245


(a) Internal managementThe internal management of a certification authority, whichthe individual user will not be familiar with, can affect thetrust to be placed in the certificates issued. For instance, thelevel and extent of the checks made on employees may be rel-evant together with whether the internal management of thecertificate system is properly carried out.The level and extentof any insurance cover may also have a bearing on the suit-ability of different types of certificate issued.46

(b) Public degree of trustFactors that will affect the degree of trust in a certificationauthority that should be public knowledge, include the level ofcertificate issued and the limitation of liability for that particu-lar certificate.The verification process is an important functionthat should be undertaken in public.The certification authorityshould be in a position to verify the integrity of the public keyand validate the encoding techniques.Further, it should be pos-sible for a person who wishes to rely on a public key issued bya certification authority to check that the certificate is valid byway of the certification-revocation lists. Whether a certificatehas been revoked is an important part of the trust placed in acertification authority.

It should be noted that the United Kingdom governmenthas provided relevant legislative provisions relating to certifi-cation authorities in the Act. The government intend that avoluntary scheme be introduced to regulate the industry,called the tScheme.47

(c) Revocation of certificateSome certification authorities support certification revoca-tion lists.This allows a person or business to check the revo-cation list to determine whether a certificate has beenrevoked or has expired.There may be many reasons for revok-ing a certificate, including:• the private keys corresponding to the certificate have

been lost or compromised;• the certificate holder asks for the certificate to be

revoked;• the certification authority may revoke a certificate where

the holder breaches a term of the agreement;or• if the certificate was issued in error.Where such a list exists, an important question is whether thecertification authority keeps this list up-to-date and whether,therefore, it can be relied upon to provide a definitive answerthat can be trusted. If a certification authority does not have arevocation list, the person seeking to determine whether torely on a certificate needs to know how they can establishwhether a key has been revoked or compromized.

(d) Expiry of keysCertification authorities provide for the expiry of keys. Onetechnical question relates to how the life of the key is compu-ted. Ellison and Schneier contend that the key has a “theft life-time” as a function of the vulnerability of the sub-system thatstores the key. Other factors that also should be taken intoaccount include the threat of physical and network exposureto attacks and how attractive the key is to an attacker.48

(e) Root hierarchyOne of the models used to establish the validity of a certifi-cation authority is to have a hierarchy of authorities, eachauthority certifying the technologies and practices of thesubordinate authorities. Thus, there could be a top-levelauthority, followed by one or more subordinate authorities,each verifying the certificates of the authority below it inthe hierarchy.49

15. FAILURE OF SECURITY

The extent of the security measures in place,either on the com-puter, or the system upon which the certifying certificate islocated,is an important factor in evaluating the possibility that asystem can be compromised. Clearly, there is a balance to bestruck between the cost of a certificate and the liability accept-ed by the issuing authority,although this matter is not discussedin this paper.Below are some of the potential areas for concern:

(a) Hacking into the system that supportsthe certifying certificateA hacker can obtain access to the user’s system and use theprivate key of the user. If a hacker is successful, the user mayeither not have taken sufficient steps to ensure they had ade-quate security in place to prevent such an attack, or they mayhave failed properly to implement the security measures thatwere in place to prevent such an attack. Examples of simplesecurity measures that can be easily attacked include the useof a password to enter the computer (the password may beeasy to guess) or, if the key number is stored on a smart card,how resistant the card is to attack.50

(b) Side-channel attacksA hacker can,by carefully measuring the amount of time it takesthe system to perform the operations of a private key,obtain thefixed Diffie-Hellman exponents, factor RSA keys and break othercryptographic systems. Such an attack is possible because othervariables relating to the performance of the hardware and soft-ware can be monitored by the hacker to exploit measurementsin timing to find the entire key. Such an attack is computational-ly inexpensive against a vulnerable system.51 A hacker can alsoexploit the variation in voltage consumed in order to deriveinformation about the private key number.52 For instance, somecomputational processes run so slowly that it is possible to seethe mathematical functions performed by the software. Smartcards are also vulnerable to this type of attack. The card isplugged into a reader or encoder and the information containedon the memory is protected by secondary protection.Where thereader or encoder is powered by a battery that is running low inpower, it is possible to obtain access to the memory by by-pass-ing the security mechanism on the card.

(c) Breaking into the user’s computer:forgery and identity theftA hacker can break into a user’s computer and take over thesystem. By undertaking this activity, the hacker can use theprivate key of the holder. This is an example of forgery oridentity theft: a legitimate certifying certificate is used that

CLSR1804.qxd 7/3/02 2:54 PM Page 245

246


purports to come from the user, but which is actually notauthorized by the legitimate user.53

(d) Misuse of computer powerIt is also possible for a computer to be controlled to a degreethat the holder is, unwittingly, contributing computer poweras part of a collective effort to crack keys.

(e) The fraudulent substitution of a publickey for that of a genuine userThis is where an impostor substitutes their own public keyfor that of the genuine user.There is no attempt to recreatethe certifying certificate of the genuine user.The attacker cansign a document with a false public key that identifies thegenuine user incorrectly.54

(f) Theft of keysEmployees or directors may use their position of power andinfluence in collusion with others to steal keys or encryptionsecrets.

16. FAILURE OF THE VERIFICATION SYSTEM

(a) Subverting the ‘root’ key

Certification authorities use root public keys. Thus, if anattacker can add their own public key to the root key list, theattacker can issue its own certificates.These certificates willbe treated exactly like legitimate certificates.

(b) Obtaining access to the certificationauthorities private keyWhere an attacker discovers the certification authorities pri-vate key, they can produce an unlimited number of ostensiblyvalid, but forged certificates.

(c) Certification authority erroneously issuing certificates to somebody claimingto be other than they areFor the public key infrastructure to be trusted, a certificationauthority must ensure that the architecture and systems that sup-port and issue certificates cannot be abused by somebodyobtaining a certificate in the name of another person or entity.Unfortunately for VeriSign, a company that issues certifying cer-tificates, this actually occurred in January 2001.VeriSign issuedtwo Class 3 code-signing certificates incorrectly to a person false-ly claiming to represent Microsoft.The certificates were issued to‘Microsoft Corporation’. During a routine audit in mid-March,the error was discovered and VeriSign notified Microsoft of theerror, posted a public notice and revoked the certificates on itscertificate-revocation list.55

This matter did not end with the posting of the publicnotice on the certificate-revocation list, however, as pointedout by Gregory L Guerin.56 The person wishing to obtain

access to the certificate-revocation list must have the cor-rect uniform resource locator (URL).The URL is the addressfrom which the certificate-revocation list can be down-loaded.There are two technical issues that affect the abilityto download a suitably recent certificate-revocation list:• how the certification authority tells you where to obtain

the relevant certificate revocation list; and• whether your computer carries out the functions you

require.Guerin points out that there are many different ways toobtain a certificate-revocation list, and because there is nostandard within the industry, no one method is mandatory.57

Regardless of the method used, the key evidential issues foranybody relying on a certifying certificate are as follows:• The certificate-revocation list should be digitally signed

by the certificate authority using its root certificate to pre-vent a certificate-revocation list from being forged.

• The certificate-revocation list is dated by the certificationauthority, which means that every certificate-revocationlist expires.

• Every certificate-revocation list has a higher sequencethan the one issued previously, to prevent forgery.

• The person wishing to check a particular certifying cer-tificate must know where to find a suitably recent certifi-cate-revocation list.

• The certificate-revocation list must actually be obtained.• The contents of the certificate-revocation list must be

authenticated.• The person relying on a certifying certificate must actual-

ly use the certificate-revocation list.In the VeriSign case, the certificate-revocation list was availablefrom a URL that was well known to developers of securityproducts,and the certificate-revocation list can be downloadedwith any browser. In this instance, as Guerin points out,VeriSign put the responsibility on the developer of the soft-ware either to ensure the software could retrieve the certifi-cate-revocation list, or provide a means to the user of thesoftware to install the VeriSign certificate-revocation list after ithad been manually downloaded by the user of the computer.58

According to Guerin,Microsoft designed the software to takea user to the address where the certificate-revocation list existed,only if the address was provided by VeriSign with the certifyingcertificate.Apparently,VeriSign does not issue Class 3 code-sign-ing certificates with an address for the certificate-revocation list.This appears to mean that the user of the relevant Microsoft soft-ware cannot retrieve the certificate -evocation list of a given cer-tifying certificate issued by VeriSign.At the time of this incident,Guerin reached the conclusion that Microsoft did not have soft-ware that had a working revocation infrastructure.59

If it is the case that a vendor of software such as Microsoft didnot have a working revocation infrastructure in place in the past,then it could be argued that past certifying certificates can hard-ly be said to be reliable. As a result, the evidential weight to begiven to a certifying certificate must be considered against thesepractical problems,otherwise,the evidence may be so poor as tomake the concept of a certifying certificate irrelevant.

17.THIRD-PARTY SUPPLIERS IN THE CHAIN

As the example above illustrates, there may be a number ofweaknesses in the security chain that will affect the reliability of

CLSR1804.qxd 7/3/02 2:54 PM Page 246

247


the certifying certificate, including the hardware, software,Internet connectivity and time-stamping functions - all of whichare not within the control of the user or of trusted third parties.In addition, the concept of authentication vendors, or cybernotaries,all adds to the complexity of the infrastructure.60

18.TECHNICAL ISSUES

The technical issues relating to certifying certificates are com-plex. The Internet Law and Policy Forum have identified anumber of problems that will affect cross-border use of certi-fying certificates.They include the lack of detailed technicalstandards, whether certification authorities should be accred-ited, certified or registered, the legal effects of such certifi-cates, whether to have supervisory bodies and whether thestandards adopted by various countries are international innature. The conclusion is that the various initiatives imple-mented to date will not allow certifying certificate technolo-gies to be standardized.61 The reader will readily note that theevidential weight to be attached to an electronic signature willbe affected by these issues.

19. CONCLUDING REMARKS

Over the past few years, politicians have rushed into passinglaws that attempt to place electronic signatures on par withmanuscript signatures. In putting legislation on to the statutebook, individual states have:• failed to agree an international meaning of what is meant

by an ‘electronic signature’;• taken different views in relation to the types of electronic

signature to be made available (ordinary signatures andqualified signatures);

• ignored the issues relating to compatibility of softwareand hardware; and

• failed to agree whether trusted third parties should belicensed or unlicensed, public or private.62

The Electronic Communications Act 2000 provides for thestatutory basis of the admissibility of electronic signatures.Theadmissibility of the public key as a component of an electronicsignature may appear to be straightforward. However, in theevent of a dispute where one party relies on the electronic sig-nature of another and the owning party denies affixing theirelectronic signature to the communication in question (whichalso implies they deny they sent the content of the communica-tion as well), then it will be for a judge to examine the evidenceto determine whether it can be shown that the electronic signa-ture in question was actually used by the owning party.

In such circumstances, the question of what, if any, legal pre-sumptions operate, will need to be addressed in relation to the

technical issues set out above.Contrary to the presumption thatmachines (i.e.the computer or system upon which the electron-ic signature sits) may be presumed to be in working order,63 it issuggested that there can be no single presumption, because anelectronic signature is not reliant upon a single machine.Variousfactors must be taken into account,such as:• the nature of the hardware and the software of the actual

computer or system upon which the private key sat;• the security in place on that computer or system;• the methods of management used by the trusted third

party and the holder of the electronic signature; and• whether the link between the issuing of the certificate

and its use was to be trusted.Other issues will need to be canvassed, including the effec-tiveness of any third-party supplier whose product or serviceis included in the chain. Further issues have also been identi-fied by the American Bar Association:64

• whether the holder of the certifying certificate carriedout their contractual duty of care to avoid the private keybeing compromised;

• whether the replying party could rely on the certificate inall the circumstances;

• if the holder of the certifying certificate revoked their keypromptly upon finding out their system or key was com-promised;

• which of the two innocent parties (relying party and hold-er) was in the better position to protect themselves fromdamage at the hands of an impostor.

Whether electronic signatures will ever be used widely is amatter that only the passing of time will determine. Themain issue surrounding electronic signatures relates to theease by which a signature can be misused. This articleseeks to show that there are many ways in which the useof an electronic signature can be challenged, although it isdoubtful that there will be large numbers of disputes thatfocus on the sole issue of whether an electronic communi-cation was signed by an unauthorized electronic signature.

SStteepphheenn MMaassoonn,, Report Correspondent, Barrister, Consultant© Stephen Mason, 2002

This paper was written to accompany a lecture given to a joint meeting of the Society for Advanced Legal Studies and British Computer Society Internet Specialist Group on 15 November 2001 in Senate Room, Senate House, Universityof London, chaired by David Spinks, Director InformationAssurance, EDS.

Stephen Mason is a barrister and Chairman of ParioCommunications Limited.He specializes in e-risks,e-business,data protection and interception of [email protected]

FOOTNOTES25 McCullagh and Caelli, 4.26 McCullagh and Caelli, 6.27 Available from <http://www.uncitral.org/english/texts/elect-com/ml-ecomm.htm>.28 Smith, 10 – 081.29Articles 6(1) and (2) of the EU Directive 1999/93/EC on a Community

framework for electronic signatures OJ No L13,19 January 2000 provide that where a Certification Authority (CA) issues a qualified certificate orguarantees such a certificate, the CA will be liable to the relying partyunless the CA prove they did not act negligently.30 Steffen Hindelang, discusses what, if any, contractual obligationsmay arise between the CA and the relying party in “No Remedy for

CLSR1804.qxd 7/3/02 2:54 PM Page 247

248


Disappointed Trust - The Liability Regime for CertificationAuthorities Towards Third Parties Outwith the EC Directive inEngland and Germany Compared”, The Journal of Information,Law and Technology (JILT), http://elj.warwick.ac.uk/jilt/02-1/hin-delang.html.31 See Law Commission, “Electronic Commerce: Formal Require-ments in Commercial Transactions”,December 2001, for a discussionon the issues relating to the formal requirements relating to com-mercial matters in England and Wales in respect of manuscript signa-tures (the text of this paper is available from <http://www.lawcom.gov.uk>).32 Bohm, et al. pointed this out at page 27 in October 2000, beforethe Bill was enacted.33 See also the comments of Graham J H Smith, “Non-ContractualLiability”, Chapter 11, Encyclopedia of Information TechnologyLaw, release 25, 7.218.34 Raymond Perry, “The perils of non-repudiation”, Law SocietyGazette, 11 October 2001,98/39,45 and “Digital signatures - securityissues and real-world conveyancing”,New Law Journal,Volume 151,Number 6993, July 20, 2001, 1100 - 1101. See Tim Travers “Digitalcertificates will pass the test”, Law Society Gazette, 20 September2001, 98/36, 45 for a contrary view.35 See Carl M Ellison, “Establishing Identity Without CertificationAuthorities”available at <http://www.clark.net/pub/cme/usenix.html >for a discussion on the meaning of identity,viewed on 9 July 1999.36 This paper does not provide an analysis of cryptography, thetypes of systems that are available (such as asymmetric and sym-metric key pairs), and how a public key infrastructure works.The reader is referred to Mason, together with the various expla-nations offered in some of the references quoted in the presentarticle.37 Apparently the scheme adopted by Identrus provides a contractu-al framework that binds both the user and the recipient. See<http://www.identrus.com>.38 See Thomas J Smedinghoff, “Certification Authority LiabilityAnalysis”,American Bankers Association, 1998 for a discussion of theissues relating to the liability of certification authorities, available at<http://www.abecom.com/news_pab.htm>.39 Ellison and Schneier, 2; “PKI Assessment Guidelines”, C.4.2“Attribution presumptions in digital signature statutes”.40 Jan Grijpink and Corien Prins,“Digital anonymity on the internet”,The Computer Law and Security Report, November/December2001,Volume 17, Issue 6, 379 - 389, 381(a).41 See discussion by Bohm et al, 24 - 26. Note the ElectronicSignature Regulations 2002 (SI 2002 No 318) came into force on 8March 2002. This statutory instrument provides for the supervisionof certification service providers, and appears to incorporate bothsimple and certified advanced electronic signatures into the regula-tory framework.42 Directive 1999/93 came into force on 19 January 2000 and shouldhave been implemented by Member States by 19 July 2001. The text ofthe Directive is available at <http://europa.eu.int/eur-lex/en/lif/dat/1999/en_399L0093.html>.43 Two identity-based encryption (IBE) schemes were advanced in2001. One by Professors Dan Boneh of Stanford University andMatt Franklin of UC Davis uses elliptic curves with proof of securi-ty (see <http://www.crypto.stanford.edu/ibe> viewed on 21January 2002).This was presented at Crypto 2001. In May of 2001,Clifford Cocks of GCHQ also proposed an IBE scheme dependingon elementary number theory, which is also security proof. This

scheme was discussed by Professor Fred Piper in his article “HolyGrail or Red Herring”, Infosecuritymanagement, November 2001,34 (<http://www.infosecuritymanagement.com>).44 See ISTEV Final Report, Chapter 2(2) and the Electronic SignatureRegulations 2002 (SI 2002 No 318), which came into force on 8March 2002.45 Issues relating to the protection of personal data in accordancewith the Data Protection Act 1998 are relevant, as set out inRegulation 5 to the Electronic Signature Regulations 2002 (SI 2002No 318), which came into force on 8 March 2002.46 See D.5 of “PKI Assessment Guidelines”for an in-depth discussion.47 At <http://www.tscheme.org>.48 Ellison and Schneier, 6.49 See the ISTEV Final Report, chapter 2(1) for examples in Europe;also the thesis by Marc Branchaud “A Survey of Public-KeyInfrastructures”, March 1997 available at <http://home.xcert.com/~marcnarc/PKI/thesis> viewed on 20 July 2001.50 Ellison and Schneier suggest most smart cards are very weak, 2.51 Paul C. Kocher, “Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems”, <http://www.cryptogra-phy.com/timingattack.html>, viewed on 3 October 2001.52 Fred Piper and Matt Robshaw, “Cryptography - A Snapshot OfWhere We Stand”, Information Security Bulletin, June 2001, 22;John Kelsey, Bruce Schneier, David Wagner and Chris Hall “SideChannel Cryptanalysis of Product Ciphers”, Journal of ComputerSecurity, Volume 8, Number 2 - 3, 2000, pp 141 - 158 available at<http:// www.counterpane.com/side_channel.html>.53 One example of a virus and what it can do to a system is discussed byRaymond Perry,“The BadTrans Virus and E-conveyancing”, Computersand Law,December 2001/January 2002,Volume 12,Issue 5,8 - 9.54 Piper and Robshaw, 21.55 Gregory L Guerin,“Microsoft,VeriSign, and Certification Revocation”,at <http://amug.org/~glguerin/opinion/revocation.html> viewed on 17May 2001. Guerin provides hyperlinks to all the relevant web sites con-taining correspondence relating to this incident.56 Guerin, 4.57 Guerin, 5.58 Guerin, 6.59 Guerin, 8 - 11.60 Theodore Sedgwick Brassi,“The cybernotary: public key registra-tion and certification and authentication of international legal transactions”, available from <http://www.abanet.org/scripts/ PrintView.asp> viewed on 20 July 2001.61 See “An Analysis of International Electronic and Digital SignatureImplementation Initiatives”, A Study Prepared for the Internet Lawand Policy Forum, September 2000, 1- 2, <http://www.ilpf.org/groups/analysis_IEDSII.htm> viewed on 3 October 2001.62 Mason for references; the possibility of misusing an electronicsignature is evident to many, and the paper by the National NotaryAssociation, “A Position On Digital Signature Laws And Notari-zation”, offers a possible explanation on page 5: “One possibleanswer [why legislators voted to forsake public protections] wasgiven by a Midwestern state lawmaker who said that he and fellowlawmakers were afraid not to pass digital technology legislationthat many of them did not fully understand, lest they put theirstate at a competitive disadvantage and be personally accused ofstanding in the way of progress.”63 Colin Tapper, “Evidence”, Chapter 11, Encyclopedia ofInformation Technology Law, release 27, 11.404.64 PKI Assessment Guidelines, C.4.4, 52.

CLSR1804.qxd 7/3/02 2:54 PM Page 248

Documents

Electronic Signatures — Evidence: The evidential issues relating to electronic signatures — PART II