Trust relationships are, admittedly, fairly tricky. Fortunately, you don't generally need to use them.
Let's pretend that our current keyset was created by an application's programmer. Graham has hard-coded his public key into the application so it will read any TrustedPickles he might later create. Let's further pretend that another programmer creates a TrustedPickle document to work with Graham's application.
If Graham has written his application in a flexible manner, it will alert users when they try to load this new document. It could then give them the option to use the document anyhow and even allow future documents signed by this new programmer.
This is all well and fine, but a stern warning will discourage wide-scale adoption of this new document. Let's say that Graham wants to accept all documents from this new programmer. He now has three options:
Obviously the first two options are less desirable.
To demonstrate how this works, we're going to need a second set of keys to represent the second programmer. In the real world, this new programmer would create his/er own keys, so Graham would never have access to his/er private key.
Now we need to do some file shuffling. Terry needs to get his public key file over to Graham so that he can create the trust relationship. Graham is providing proof that he trusts Terry, so he signs with his private key.
Note: Public key files may be freely shared. They do not contain any sensative data.
This may be confusing, but the new trust relationship that Graham just signed is written into Graham's public key file, and not Terry's. Graham could update Terry's public key file and then mail it back to him, but then Terry would have to trust that Graham has not erased any previous trust relationships out of the file (or otherwise corrupted the file). I know I wouldn't be comfortable doing that, so let's not assume that Terry is either.
Instead, let's have Graham mail his new public key file over to Terry so Terry can use it to update his own public key file. This can be done with the Merge() function.
Now that Terry has a public key file showing that Graham trusts him, let's create a new document file and have Terry sign it.
Note the extra parameter when we called the Sign() function this time. This indicates to include all upstream trust relationships in the document.
Now let's test the document against Graham's public key.
The signature class code is now TRANSFERRED. Note that although Terry actually signed the document, Graham's public key is returned by TestSignatures(). Graham is the trusted user and he vouched for Terry's opinion.