GnuTLS OpenPGP key support

Currently GnuTLS has experimental support for OpenPGP keys. OpenPGP keys are similar to X.509 certificates, in the sense that hold public key parameters. However they also allow for non-hierarchical trust models. This is not like an other new feature. It is more like a policy change. Here follows a description of both models.

The X.509 trust model

Currently the X.509 protocols which are used for Certificate authentication, users have to be certified in a hierarchical way. The model can be described by Certificate Authority (CA from now on), that signs people's and object's certificates. An object might be a user, a server, of even an other CA. A user who trusts the Certificate Authority's decisions, will be able to trust an other user, by just checking if the other user's certificate is signed by the trusted CA.

See the figure1 for a graphical representation. In that figure a Central (Root) CA, certifies two subordinate CAs, which then certify Alice, Bob and a server. In that case, if Alice trusts the "Root CA" then she also trusts Bob's certificate and the server's certificate.

The only requirement in that model is that a user must somehow have the trusted CA's certificate available.

In the real world there are several Certificate Authorities, which certify people, and objects, often for money. Thus users have to decide which of the CAs to trust. One should note that the security of a model where someone trusts several CAs, is equal to the security of the least secure CA.

Unfortunately the trusted CAs decision is barely done by users, in practice. This decision of trusted CAs is done mostly by application programmers and administrators. A good example of this is the included CA certificates in popular web browsers.

The Openpgp trust model

The OpenPGP key authentication relies on a distributed trust model, called the "web of trust". The "web of trust" uses a decentralized system of trusted introducers, which are the same as a CA. OpenPGP allows anyone to sign anyone's else public key. When Alice signs Bob's key, she is introducing Bob's key to anyone who trusts Alice. If someone trusts Alice to introduce keys, then Alice is a trusted introducer in the mind of that observer.

See the figure2 which shows graphically the above case. The normal arrows indicate the sign operation, while the dot arrows indicate trust. Thus since Dave trusts Alice to be an introducer, and Alice signed Bob's key, Dave also trusts Bob's key to be the real one.

There are some key points that are important in that model. In the example Alice has to sign Bob's key, only if she is sure that the key belongs to Bob. Otherwise she may also make Dave falsely believe that this is Bob's key. Dave has also the responsibility to know who to trust. This model is similar to real life relations.

Just see how Charlie behaves in the previous example. Although he has signed Bob's key - because he knows, somehow, that it belongs to Bob - he does not trust Bob to be an introducer. Charlie decided to trust only Kevin, for some reason. A reason could be that Bob is lazy enough, and signs other people's keys without being sure that they belong to the actual owner.

Note that Certificate Authorities may exist in the OpenPGP model, although they are not required.


In TLS and SSL traditionally the X.509 trust model is used. As shown above this model has several restrictions comparing to the openpgp trust model. Especially in distributed environments where the concept of authorities is not clear, the use of the Openpgp trust model has obvious advantages.

We believe that users should have the freedom to choose the trust model that suits best their needs, thus in GnuTLS we have implemented both. We have also proposed modifications to the TLS protocol for OpenPGP keys to the IETF TLS working group.

Return to GnuTLS' home page.