Interaction between anchors, blacklist, layering

[Stef Walter]

So in the context of the Storing Trust Policy document, I've been
thinking about the layering of sources of trust storage. This is about
this section:

http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html#model-layering

The set of anchors and the blacklist should be distinct and unrelated.
These serve very different use cases, and are used by different parts of
the certificate validation process.

In particular:

 * Anchors are a white list.

 * Blacklists are ... well a black list. An override of the usual
   certificate expiration and revocation process.

 * When something is blacklisted this is due to compromise or lack of
   trust. For example an anchor shouldn't be blacklisted just because
   it's no longer an anchor.

 * If a certificate or its key is on the blacklist, then that should be
   respected regardless of it being an anchor or not. The blacklist
   is an override, and as such overrides other trust information.

 * Consumers of trust information should check whether each certificate
   in a chain is blacklisted, and not just check if anchors are black
   listed.

 * The blacklist can be used by more than certificate validation, for
   example it can hold the Debian openssh blacklisted keys.

So coming back to the issue of layering multiple "Stores" containing
anchors or blacklists (ie: section 3.5).

 * The layering of both the anchors and blacklist should be
   independent.

 * A blacklisted certificate key at in a lower priority store would
   override an anchor even if it is stored in a stored in a higher
   priority store. The two are independent.

 * Disabling or customizing a certificate anchor can be done without
   blacklisting it by adding a stapled certificate extension which
   prevents its use (such as a BasicConstraints with isCA = FALSE).

Cheers,

Stef

-- 

stef at thewalter.net
http://stef.thewalter.net