Wednesday, October 13, 2010

About Trust Assertions

I've been working on some specifications for storage of 'trust'. This a sufficiently vague and abstract concept to require a hoity toity name: Trust Assertions

Trust assertions are used to assign an explicit level of trust to a public key or certificate. I'll just refer to certificates below because that's the easiest to grasp, but the concept is sufficiently abstract to allow trust assertions for other types of keys.

Examples of trust assertions include:
  • Certificate Authority root certificates
  • Certificate Revocation Lists
  • Certificates you decide to trust manually (for your favorite self signed certificate)
  • Certificates marked bad explicitly
Trust assertions are not about the process of deciding whether you'll eventually trust a certificate. Ultimately an application needs to determine trust a certificate for a given connection, email or instant message. It does this by checking if it's valid, who it's signed by, and an obscene amount of other rules. It usually does this with the help of a crypto library.

Only the application has all the information necessary to make a trust decision. A simple example of this is how web browsers check that the common name (ie: CN) of the certificate matches the domain name of the https:// website you've browsed to.

Trust assertions are about storing basic facts that applications use in their trust decision process.
The Concept 
A trust assertion describes a level of trust in a certificate for a given usage or purpose.  Conceptually each trust assertion is a triple containing:
  • Certificate Reference
  • Usage (aka purpose)
  • Level of Trust
We examine each of these parts of the triple in further detail below.

The Level of Trust

A trust assertion ultimately denotes a level of trust. These are:
  • Untrusted: The certificate is explicitly untrusted.
  • Unknown: The trust is not known and should be determined elsewhere.
  • Trusted: The certificate itself is explicitly trusted.
  • Trusted Delegator: The certificate is trusted as a certificate authority trust root.  Trust is conferred to certificates that this certificate has signed, or that signed certificates have signed, and so on.
The Usage

A trust assertion always refers to a specific purpose or usage.  A certificate may be trusted for purposes like: email, code signing, authenticating a server.

It turns out that carte blanche trust not a super useful concept. You (should) always trust someone for some purpose. You trust your bank with your money, not your children; you trust your school with your children, and so on.

The Certificate Reference

And finally we have the certificate that the trust assertion refers to.

Pretty boring stuff actually. But it does get exciting. By comoditizing trust storage, we can use these well defined concepts for new methods of trust decision making.

The way certificate authorities work in your web browser scares a lot of people. By changing to a more general trust storage model, we have the possibilities for applications to try out new trust paradigms. One example is the have-I-seen-this-key-at-this-site-before trust model, used by OpenSSH. But I'm certain that more methods will emerge as more energy is brought to bear on the problem.

Okay enough hand waving, and back to earth.

The specification I'm working on defines how to store trust assertions as PKCS#11 objects. This isn't a new concept, and has been implemented in Mozilla's NSS for a long time. However as far as I can tell it hasn't yet been documented.

After some prodding (thanks Nikos) I figured I'd do some work to document it properly.

GNOME Keyring is completing its implementation of trust assertions. For a long time now, we've had simple read-only trust assertions that exposed everything in /etc/ssl/certs as a trusted delegator (ie: a certificate authority).

But now we're working on rounding out the support on the trust-store branch of gnome-keyring.

Cosimo is working on XTLS to encrypt jabber chats in empathy, and so the trust-store work will help store certificate exceptions in gnome-keyring.


  1. I worry about your Trusted Delagator description: I'd hope that the resulting path walk considered the trust assertions of the Delagator when assigning delegated trust.

    So, if Alice asserts that Bob is a Trusted Delagator, and Bob asserts that Chris is Trusted (but not a Delegator), and Chris asserts that David is Trusted, I'd hope that Alice would find that David's certificate status was Unknown, rather than Trusted, so that Alice could investigate other paths (and maybe discover that both Elaine and Francis (who Alice has Trusted but not marked as Trusted Delagators) have marked David's certificate as Untrusted, perhaps indicating why Bob does not delegate trust to Chris).

    If it is the case that Trusted Delagator implies "Trust is conferred to certificates that this certificate has signed, or that signed certificates have signed, and so on" without reference to the level of trust the Trusted Delagator (or any other component of the dependent chain) has indicated, the system becomes easily gameable (for example fun, find two robotic autocertification signatories that are current members of the GPG WoT "Strong Set").

    If the implementation cannot know the level of trust between two external parties (for instance, in an environment where the only means to indicate trust or lack thereof is the binary presence/absence of certificate signatures, perhaps it would be appropriate to avoid unlimited recursion from Trusted Delagators, but rather only trust those specifically trusted by the Trusted Delagator: in cases where a certificate cannot be determined to be Trusted (either directly, or directly from a Trusted Delagator), the user can be presented with the trust paths, and make appropriate determinations.

  2. Good points to keep in mind.

    But as noted, trust decisions are actually calculated by other algorithms, not by these assertions which provide some of the facts to base those decisions on.

    As you can probably see for the "Trusted Delegator" I struggled to find a good succinct description. So I resort to describing part of a trust decision algorithm. That's wrong, and outside the scope of trust assertions.

    I'll need to think about a better way to express that so there's less confusion.

  3. Question: why is "trusted delegator" an attribute of "level of trust" instead of an attribute of "usage"?

    If I go to a public notary at Kinko's, I trust it for nothing other than a delegation function.

    In particular, I want my level of trust function to return either "trusted", "not trusted", or "not defined", alone. I'd rather not complicate its value.

    On the recursion problem, consider it from a practical perspective. Suppose A is a CA, and signs off on B, who is also a CA and signs off on C. How does the level of trust associated with A impact C? Somehow, either by contract or reputation, A is asserting that all of the people it vouches for (B) will also perform a sufficient vetting process on the people for which it signs (C). That is, that A has contracted with B a relationship that says that B will do certain things.

    Recursiveness is important, of course; you want to know that the whole trust chain will be valid, starting at the know anchor and flying through intermediaries. So if we have a usage that says "this cert is useful to verify contractual relationships with signees to also enforce the vetting process" we can pick up what we want -- perhaps even more clearly, since the signee is put on clear notice that we expect their diligence -- and still have a simple assertion model.

  4. Interesting point.

    The reason that delegator is modeled as a trust level is that we want to model a delegator who is only trusted for a given purpose.

    For example we may trust a CA to vouch for certificates to be used for accessing websites. But we don't trust the same CA to sign certificates that are used with digitally signed software.