Task:

In this task, you will concentrate on the digital signatures and certificate chain. Try posting messages signed with your private key and ask your colleagues to verify whether your signature on the message is valid. The message should not be encrypted; that is, the format is a clear message, with a signature on the message.

Your task is detailed in the 'Sample Template for document submission' at the end of this Assignment. However, generally speaking your task is to compare what happens in the following situations: 1.Get signature by A and check whether A's signature on one message is valid. 2.Let B sign A's key, and you sign B's key.

Then check whether A's signature on one message is valid. As you know, various PGP tools may implement the same service differently. The technical details in the following example were written for PGP 7.x; however, the basic theory is the same for all versions of PGP. If you are using GnuPG or another OpenPGP installation, the interface may look different, but the basic process should be the same. Stepping through the following example in your own software may give you a deeper understanding of how the digital signature process works. PGP 7.x

Example A screenshot of a PGPKeys window showing the features described You have talked about CA (certificate authority) in several places. The PGP trust model is different from the CA trust model. When you open the PGPKeytools, you will find that for several public keys you have imported, the small ball under the 'validity' item is not highlighted (green).

This means that that these public keys are not 'valid' according to current certificate chains. The impact is that when you verify a signature using that public key, you will get a message like 'valid signature with an invalid key'.

If the ball for your own public key is not green, you may right-click your key and choose 'key properties'. Under the 'Trust Model', choose 'Implicit trust'. Then your key should be green. Now how can you make other keys valid (green)?

An obvious way is to sign that key. When you sign a key, you will see that key is highlighted. Do you have to sign all keys to make all keys valid? The answer is NO. That is, you need to find a way to make one key highlighted (green), but you have never signed that key.

If you know that a key is really from Alice, then you can certainly click the small ball corresponding to that key and sign that key, and then you can export that public key, thus making Alice's key green.

If you do not know Alice, but you know Bob in person and Bob knows Alice well, then if Bob signs Alice's key and sends Alice's signed key to you, you should trust Alice's key. This is the PGP trust model. Practice this kind of trust model this Week.

In particular, do the following exercise: You sign A's key and mark A's key as trusted (you can do this by right-clicking A's key and choose 'key properties' and then move the sliding bar to trust). A signs B's key and publishes the signed key to the Group Project forum. Check whether B's key is valid in your screen (small ball is highlighted). Post your screenshot to convince others that you have not signed B's key but that it is valid.

Also check a message signed by B to see whether it is valid. The following is a sample screenshot. Note that Yongge Wang has not signed Ali Ahmed's key but that it is a valid key.

Also note that Yongge Wang trusts Craig's key at the 50% level. References: Brunschwig, P. (2013) Enigmail [Online]. Available from: https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/, (Accessed: 20 October 2014). The GnuPG Project (2014) The GNU privacy guard [Online]. Available from: https://www.gnupg.org (Accessed: 20 October 2014). Network Working Group (2007) Proposed Standard RFC 4880: OpenPGP Message Format [Online]. Available from: http://www.ietf.org/rfc/rfc4880.txt (Accessed 10 December 2014). OpenPGP Alliance (n.d.) OpenPGP alliance members [Online]. Available from: http://openpgp.org/members/ (Accessed 10 December 2014). Symantec (2014) Symantec Encryption Family [Online]. Available from: http://www.symantec.com/encryption/ (Accessed 10 December 2014).