What is Trust?

The word Trust has its root in the Proto-Indo-European deru meaning Tree or Firm, something you can depend on, rely on or have confidence in. The words True and Truth also come from this root. In English, Trust is derived from the middle English Truste, which is probably a derivation of the old Norse Traust which means Confidence.

In order to establish the level of Trust you would place in a person or organization, you need them to prove their identity and to provide evidence in the form of words and deeds. On the Internet, Identity is usually provided in the form of a Digital Certificate bound to a person or organization. However, evidence can only be gathered by direct interaction, and, or, testimonials provided by other people that you already trust (in effect your Web of Trust). Trust is established when you verify the available evidence, or to quote Helen Nissenbaum:

"...evidence that others merit trust is their past behaviour. If they have behaved well in the past, protected our interests, have not cheated or betrayed us, and in general have acted in a trustworthy manner, they are likely to elicit trust in the future."

(Reference: H. Nissenbaum, Will Security Enhance Trust Online, or Supplant It?. In P. Kramer and K. Cook (eds.) Trust and Distrust Within Organizations: Emerging Perspectives, Enduring Questions., Russell Sage Publications, 2004)

For a real-world example of establishing trust consider the formation of the American Office of Strategic Services (the fore-runner of the CIA) by William Joseph Donovan. Donovan used his extensive network of business and professional contacts built up over many years, in other words people he knew could be trusted, to help create and run the OSS. In turn, these people used their trusted contacts.

Digital certificates, Identity and Trust for AllIncontext
So as a step towards establishing trust in the AllIncontext Limited identity, all Allincontext X509 Digital Certificates (including those used for digitally signing software) are chained up to the Root certificate of the AllIncontext Certificate Authority. The Root certificate is bound by a Subject Alternative Name entry to the AllIncontext Certificate of Incorporation web page which shows a watermarked image of the real certificate of incorporation issued to a UK Limited Company by Companies House. This web page name is the Object Identifier (OID) which is deemed to be unique to AllIncontext Limited (it cannot be used by any other organization or person). The Subject Alternative Name is defined in the Internet Engineering Task Force RFC3280 as a means of binding an additional identity of an organization or a person to the digital certificate. Note that both the Root and Intermediate Certificate Authorities use the same "Subject Alternative Name" binding and that the Intermediate Certificate Authority CANNOT be used to create any subordinate Certificate Authority, ONLY certificates for use by End entities, for example a secure Email certificate for a person with a valid Email address.

For AllIncontext CodeSigning (as an example) this gives the following chain:



Note 1: Where the certificate is issued by the AllIncontext CodeSigning Organizational Unit (or OU, see RFC2253). Other "OU"'s in other AllIncontext Intermediate CA certificates are used for different purposes, for example the issuing of certificates for use with secure Email.

So, in this example, if you need to check the validity of software, you can follow the above chain from the software back up to the UK regulator for UK Companies and check if the evidence provided by the data associated with the chain is valid.

Web sites, Risk and further evaluating Trust
If you navigate to an arbitrary web site you are taking a risk that the action of navigation will not result in any harm to your PC. If the home page displays without a problem and your browser does not indicate that the page is a security risk, you will consider giving the site a small amount of trust. What you now need is a clear statement by the web site about what you can expect from that site (and the people who control it), in effect a:



This is neccesary for establishing trust but it is not sufficient, because you still need to interact with the site in order to evaluate the evidence you accumulate as you navigate the site. Obviously a site that provides only information is likely to have a lower threshold to your trusting the site than one on which you might make a transaction involving the transfer of money from your bank account to the site's bank account.


What is a Digital Certificate?
Each Certificate has a public and a private part. Only the public part is distributed for use by people other than the owner of the complete Certificate. Each part contains a key which can be used to encrypt, decrypt and sign data. You need to use the public part to encrypt data to send to the owner who will use the private part to decrypt that data. If the owner wants to send you un-encrypted data but wants you to be able to verify that the data has not been changed in transit, the owner signs the data with the private part. You can then check the signature by using the public part of the Certificate. The problem with a stand alone Certificate is that you have no independent check on the Identity of the Certificate owner. The way that this is resolved is to ensure that Digital Certificate U is the end point in a chain which can be represented as follows:


where:
Although the word Trust is used when referring to Digital Certificates, the only thing they can actually be used for is to establish Identity (just like a Driving Licence or Passport). A certificate chain can be as short as U -----> R and longer than the example given above. Since R can sign one or more Certificates I, and I can sign one or more Certificates U, you can see that in an ideal world there would be a very large number of U, fewer I and fewest R Certificates. As the Electronic Frontier Foundation has shown, this is not the case and there are some 650 or more I's and R's. Ross Anderson's rule would imply that this number of Authorities cannot be secure (because so large a number of organizations, each with many people with access to data, which needs to be secured, gives rise to greater probability for a breach. That is why William Joseph Donovan above used his contacts).

So, if you can establish the Identities of a few R Certificates, you can establish the Identity of a very large number of U Certificates so long as the Certificate chain between any U and R is valid. There are two ways you can establish the Identities of any R Certificate:

1. Examine each R yourself and any evidence available for it.
2. Accept some third party evaluation of the Identity of each R.

When a web Browser wants to establish secure communications with a web Server (for online shopping for example) it gets the U Certificate from the Server and then proceeds to verify the chain. So how does the Browser establish the Identity of R? It looks for R in your PC Trusted Root Certification Authorities Certificate store (if it is Internet Explorer) or in its own Certificate Storev (for example Mozilla Firefox. So now you might have two such Certificate Stores). The word Trusted should only be taken to mean that Trust is implied because you have no direct evidence that any arbitrary R can be trusted. Obviously, if you had to look at the evidence for each U when using a web Browser you would likely find the experience tedious, so that is why the PC Trusted Certificate Stores exist.

The question now is: "Who decided that these certificates should be included in the store?". Well, it was an ad-hoc decision by Microsoft and a few suppliers of certificates. Indeed, if you look at the digital certificate of one or more of the signed DLL files on your Windows PC in the Windows folder you are likely to find that they have been signed by a Microsoft Root Certificate Authority on behalf of the Microsoft team that produced the code. No independent third party is involved.

Certificates used in other scenarios?
These can be used, for example, to establish identity for Email messages and program code, and to encrypt and decrypt data. You should adopt a policy of checking the U Certificate and any related evidence before you decide to trust U. As noted above, there are many U Certificates and fewest R Certificates, so even if you have to install a Certificate chain, you will only need to do it infrequently for any domain which is assigned to R. Certificates I and R also tend to be longer lived than U, so installing I and R will result in the Identity of any U being established by default.

Note: Many free Email Certificates U are signed by a I which has been issued to B - Persona Not Validated. This is because any establishment of the Identity of U was done automatically by I. In other words, if the Email address of U is from a registered domain (and can be queried by Whois), I assumes that the address must be valid, but can say nothing about the person wanting Certificate U. So, unless you know the person with the Email address, all you can establish is that any signed Email is from that address and hasn't changed in transit. It does not provide evidence to Trust in the contents of the Email.