From 0968f903fe66f9bb8957b8d01e35f3743c74404b Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Tue, 4 Nov 2014 11:31:31 +0100 Subject: Brought old blog over --- content/technical/about-trust-assertions.md | 130 ++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 content/technical/about-trust-assertions.md (limited to 'content/technical/about-trust-assertions.md') diff --git a/content/technical/about-trust-assertions.md b/content/technical/about-trust-assertions.md new file mode 100644 index 0000000..41e2428 --- /dev/null +++ b/content/technical/about-trust-assertions.md @@ -0,0 +1,130 @@ +Title: About Trust Assertions +Date: 2010-10-13 +Tags: technical, security, gnome +Slug: 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. + +

+ + [specification I'm working on]: http://thewalter.net/git/cgit.cgi/pkcs11-trust-assertions/tree/draft-pkcs11-trust-assertions.xml + [implemented in Mozilla's NSS]: http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/util/pkcs11n.h + [trust-store branch of gnome-keyring]: http://git.gnome.org/browse/gnome-keyring/tree/?h=trust-store + [Cosimo]: http://blogs.gnome.org/cosimoc/ -- cgit v1.2.3