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 via software run locally on public data.

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?

Alternatives (and concerns):

  • RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) - what cross-platform clients are friendly?
  • OriginStamp, backed by Bitcoin blockchain (charge for rapid turnaround)
  • Signed PDF overview with attached data files: can the timestamps be verified and trusted? Can users be tricked via bogus certificates into
  • Publish link to data and hash of it via various timestamped social networks: Keybase (backed by good crypto specs), Twitter (popular), ...
  • XML Signatures
  • 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 https://www.rfc-editor.org/rfc/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)

Update, 2019:

  • Updated list of options with some newer ones, and clarified my goal (in the age of the cloud) of an approach that can be verified via locally-run software. We're learning more and more that web servers are vulnerable to attack, and there are advantages to distributing signed data.
  • Note that EML and even XML are losing favor these days

4 Answers 4


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, 2010 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, 2010 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

  • 1
    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, 2010 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, 2010 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, 2010 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, 2010 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, 2010 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, 2013 at 3:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .