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.

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.

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).