In order to help make a digital signature trustworthy you can ask people you know who also own gpg identities to sign yours. This in turn allows for the web of trust to be bootstrapped by people signing and verifying each others gpg identities.

In order to sign a gpg identity, one needs to :

• Import the user’s public key, (mine can grabbed from here):
  gpg --import somePubKey.asc

• Check the identities fingerprint: gpg --fingerprint PubKeyHexValue</li>

  • Given that you are convinced the key belongs to whoever you think it should, sign the key: gpg --sign-key PubKeyHexValue</li>

    • Send the signed key back to your keyserver:
      gpg --send-keys PubKeyHexValue</ul>

    I sign all of my emails using my gpg public key, it should be noted that only emails sent from my laptop can sign be signed using this identity. I should thank my former colleagues from the University of Southampton who signed by gpg identity, they have done their little bit to help bootstrap the Web of Trust.

In this post I will describe how to both sign and in turn verify the validity of a document. Below describes how one could use the open-source GnuPG implementation of the OpenPGP standard as defined by RFC4880 as a mechanism of trust. You can find out more information here at the PGP faq at pgp.net.

So, why would you ever want to sign a document using the OpenPGP standard?

One can sign a file using the OpenPGP standard before putting it in the public domain so that if and when another person/agent views the file they can check whether or not the file has been tampered with on route. This method of signing files provides the creator of a document with an ability to sign their work, which in turn allows the reader to know whether or not the file has been altered since being signed.

In essence every user has a public and a private key, and when a GnuPG user wants to sign a file they end-up creating a checksum of whole file using their keys. This checksum can then be used to verify that a document has not been tampered with, this is done by the GnuPG software comparing the checksum, the file in question, and the user’s public key.

Step 0

After creating your gpg keys you have to ensure that you have pushed your public key to one of the public keyservers, you can do this like so:

gpg --keyserver pgp.mit.edu --send-keys YOUR-EMAIL-ADDRESS

Make sure that your private key is private, and that it is not accessible by any of the other users setup on your machine. You can do this by :

chmod 600 ~/.gnupg/YOURPRIVATEKEY.asc

Make sure this is safe, for this is the only file someone needs to pretend to be you.

Signing a file using GnuPG

In this example the file which we are signing is called foaf.rdf. After setting up your gpg keys you can sign the file like so :

gpg -a --detach-sign foaf.rdf

This creates a file called foaf.rdf.asc (ASCII-armored digital signature) in the directory where the command was executed.

Checking a file against it’s ASCII-armored digital signature

If you have both the original file and the ASCII-armored digital signature of the file in the current working directory you can verify the files integrity by execting the following command :

gpg --verify

The output this last command will notify the user to whether or not the file has been altered since the last time it was signed.

FOAF files in isolation only give you information about a person, and who they know – i.e. who they claim to know in their FOAF file.

At Garlik we have implemented a reverse search facility for FOAF, whereby given an API request one can get back triples containing a list of people who claim to know the FOAF URI/IFP used to generate the API request. This list of people is taken from our knowledge base of harvested FOAF files, which currently holds around 10 millions individual FOAF files.

By including an API request to our reverse search in your FOAF file, you can have a FOAF file with both links out and links in Wow (he says)…

This API call – http://foaf.qdos.com/reverse/?path=https://mmt.me.uk/blog/foaf.rdf%23mischa – returns an RDF fragment listing foaf:People that claim to know me.

All you need to do is add one triple that requests RDF from our reverse search API to your FOAF file. The triple will look something like this:

<#me> rdfs:seeAlso <http://foaf.qdos.com/reverse/?path=http://foo.com/foaf.rdf%23me> .

You can find examples of this API call in Danbri’s, Steve Harris’s, and my FOAF files.

There is some information regarding how to use the API on the reverse search HTML page.