I'm looking for a good way to publish data along with a digital signature (and ideally a timestamp) which is as easy as possible to verify.

For example, imagine an election administrator who wants to publish election data which is to be audited (totals by candidate by precinct). We ideally don't want to require the public to have to acquire much if any special or proprietary software. Signatures which adhere to an open standard, can be validated on PC, Mac, Linux, and can be generated by open source software are preferred.

The data has to remain machine-readable, so a pdf isn't suitable, so if pdf is used, the data would be in attachments to the pdf.

E.g. if we generate XML Signatures (e.g. for IEEE 1622-2011 Election Markup Language (EML) files for elections), is there standard functionality in any common browsers or operating systems to validate the signatures? Is the user interface clear enough to make it clear to the user when the data looks good, when it is suspicious, and how to deal with common issues?

Other alternatives (and concerns):

  • Publish SHA-256 hash in the newspaper (How to describe verification steps to the user?)
  • Use a jar (signed zip) and jarsigner (is there a nice GUI for verifying jar signatures? X.509 PATH validation?)
  • Use OpenOffice (A hassle to install)
  • CMS or S-MIME (How can we publish an S-MIME message with attachments - public IMAP?)
  • Use gpg (but admins need to get in the PGP web of trust, and users need to learn to understand it)
  • Use s-http (a pity http://tools.ietf.org/html/rfc2660 never took off....)
  • Use Excel (are there free clients that can check the signature? Open source software to generate it via a script?)
  • "Just serve from a secure web site" (doesn't deal with a variety of attacks)
  • 1
    Some background on the requirements for transparency around election auditing are at Principles and Best Practices for Post-Election Audits: electionaudits.org/principles – nealmcb Dec 21 '10 at 4:42

One option would be to digitally sign a message with the XML attachment with S/MIME. Use an online page on which users can enter their email address to which a copy will be sent.

Another option would be to use a signed PDF. The PDF standard allows PDF documents to be digitally signed and supports attached documents. The XML can be attached to the PDF as an attachment. The complete PDF including the attachments will be signed.

If you want to make it easier for end-users to check the signature, you should make sure that you use a universally trusted x.509 certificate or, use your own certificate and publish the thumbprint of the certificate somewhere.

Martijn Brinkers

  • Fascinating! I've now successfully used pdftk to attach a file to a pdf. PDFs can cause confusion though now that many browsers render it internally. Do you know how the various user interfaces out there deal with saving attachments, validating signatures, etc? – nealmcb Dec 21 '10 at 22:16
  • I have only tested Acrobat for signature checking so I'm not sure how well that's supported by other PDF readers. Attachments however is supported by a lot of PDF readers (Acrobat, Foxit, Poppler etc.) – Martijn Brinkers Dec 22 '10 at 7:07

Clients? That rather misses the point. It's really about file formats and protocols.

x509 is a cornerstone of encryption implementations. Although its just a starting point for implementing software on, it should probably be your starting point for looking for software.

About 10 years ago, I needed to implement a PKI for my then employers. The route I took was to set up a root Certification Authority using openSSL. At that time x509 verification was available for email required plugins for MSOutlook Express and Eudora (but not for the Bat!). IIRC, these are now built-in as standard. Wincrypt (file encryption) was available as a free download and Stunnel had just been ported to MSWindows.

Certainly 10 years is a long time in encryption circles - but the nice thing about x509 is it accomodates different algorithms / key sizes. It also builds on the same basis as LDAP.

More recently there are have been many more tools implemented using SSL type encryption - e.g. Gnu Anubis (OK, it doesn't actually add the sigs - but provides hooks for calling openssl), smart cards

  • I'm all about standard formats. But without a usable client and a good way to deliver the files, the best format in the world won't help. E.g. if there was a convenient way to put an S/MIME message on the web (in a public IMAP folder??) and explain how people can validate them, that would be fine. – nealmcb Dec 21 '10 at 19:29
  • "if there was a convenient way to put an S/MIME message on the web (in a public IMAP folder??)" - that's an oxymoron. There's nothing to stop you serving up an an email message over HTTP[s] (or going down the IMAP route - but I wouldn't recommend it) - as long as you configure the right mime-type. But there are standards for encrypting files - see www.wincrypt.de and tldp.org/HOWTO/SSL-Certificates-HOWTO – symcbean Dec 22 '10 at 9:43
  • silly me: "web" != "Internet" :/ I meant "put an S/MIME message on the Internet (in a public IMAP folder)". This is supported by some servers (e.g. softalkltd.com/products/workgroupmail/shared_folders.asp). The question is how cumbersome and confusing it would be for users, and again that would depend partly on how the various client UIs would present things, and how it compares to the other options, many of which are also in a pretty sorry state. – nealmcb Dec 24 '10 at 6:41
  • Wincrypt seems dead. Anubis is an SMTP message submission daemon - seems like nothing to do with signing files. OpenSSL is an impressive developer toolkit but hardly something I'd ask the public to use. I've been signing stuff with public keys since 1993, and x509 would be fine for the certificates, but I still come back to the question of easy-to-use client support on multiple platforms for the lay public. Much as I'd love good XML Signature verification clients since we have an XML election standard, that seems problematic, so signed PDF attachments are looking promising.... – nealmcb Dec 24 '10 at 7:17

Signatures which adhere to an open standard, can be validated on [...] Mac [...]

On the Mac, there's a Certificate, Key and Trust service which is built in all over the place. That means that you could send them S/MIME data and they'd be able to inspect the certificate and its trust path in the mail client. On the other hand, the UI just looks like a little tick or cross in a bar above the message. That's also the problem with using TLS - it works, but it works silently, and in some situations it fails silently too. Everything in between needs special knowledge to comprehend.

There is a third-party plugin for GPG in Apple Mail, but as you observed in your question registration and subsequent correct use of OpenPGP is hard.

  • 1
    Yeah - this is a tall order, I'm afraid. So, given a signed file on the web in your choice of format (example.com/signed.xxx), how would a Mac user validate the signature? I don't want to have to deliver the file via email. – nealmcb Dec 21 '10 at 19:23

If the example is a common use case (election official posting) then you might want to consider an official web page that provides server side cryptographic hash validation and the option to let citizens validate offline for themselves. The election office would post the results on a page that provides the result message, a hash of said message, and a function that confirms the hash is valid for the message on the server side (button action or automatic check with on page result). This scheme would address the trust chain by resolution of the site to a legitimate government agency URL. The attack surface would be the server side artifacts of message and hash and DNS. Considering the use case in the example is about publication and not securing original documentation this might suffice as the main point would be to avoid typos being reproduced in further dissemination (newspapers etc).

  • 1
    As I said, the advice to "Just serve from a secure web site" doesn't deal with a variety of attacks. Web servers and web clients are among the most easy to attack targets around. Most users don't understand how hard it is to distinguish a real site from a fake one. And I don't see how asking a site to prove something that it is saying itself adds anything to the real assurance level, especially when only a hash is involved. Defining "a legitimate government agency URL" is also highly problematic: there are many forms, and people don't understand URLs, and subdomains are poorly controlled. – nealmcb Nov 10 '13 at 3:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.