diff options
35 files changed, 3 insertions, 3196 deletions
diff --git a/Makefile b/Makefile deleted file mode 100644 index eae9880..0000000 --- a/Makefile +++ /dev/null @@ -1,20 +0,0 @@ - -all: specs html - -clean: - rm -rf html/* - -specs: - make -C specs all - -html: - SRCDIR="." python jinja2-build.py - -upload: all - rsync -Hvax --exclude doc --exclude releases \ - html/./* anarchy.freedesktop.org:/srv/p11-glue.freedesktop.org/www/./ - rsync -Hvax \ - specs/storing-trust/./* \ - anarchy.freedesktop.org:/srv/p11-glue.freedesktop.org/www/doc/storing-trust-policy/./ - -.PHONY: html specs @@ -0,0 +1,3 @@ +MOVED: The files previously here have moved: + +https://github.com/p11-glue/p11-glue diff --git a/jinja2-build.py b/jinja2-build.py deleted file mode 100644 index 3e11d42..0000000 --- a/jinja2-build.py +++ /dev/null @@ -1,64 +0,0 @@ -#!/usr/bin/env python - -import fnmatch -import jinja2 -import os -import shutil -import sys - -SRCDIR = os.path.abspath(os.environ.get("SRCDIR", ".")) -INDIR = os.path.join(SRCDIR, "website") -BUILDDIR = os.path.abspath(os.environ.get("BUILDDIR", SRCDIR)) -OUTDIR = os.path.join(BUILDDIR, "html") - -jinja_env = None - -def main(args): - global jinja_env - - loader = jinja2.FileSystemLoader(INDIR) - jinja_env = jinja2.Environment(loader=loader, autoescape=True, - undefined=jinja2.StrictUndefined) - - os.chdir(INDIR) - os.path.walk(".", process_file, None) - print >> sys.stderr, "Results: file://%s/index.html" % OUTDIR - -def process_file(unused, dirname, names): - - directory = os.path.normpath(os.path.join(OUTDIR, dirname)) - if not os.path.exists(directory): - os.mkdir(directory) - - args = { } - - for name in names: - path = os.path.join(dirname, name) - if os.path.isdir(path): - continue - - elif fnmatch.fnmatch(path, "*.tmpl"): - print >> sys.stderr, name - output = os.path.join(OUTDIR, path[0:-5]) - template = jinja_env.get_template(path) - data = unicode(template.render(**args)).encode("utf-8") - if os.path.exists(output): - os.unlink(output) - with open(output, 'w') as f: - f.write(data) - os.chmod(output, 0444) - - elif fnmatch.fnmatch(path, "*.incl"): - continue - - else: - output = os.path.join(OUTDIR, path) - if os.path.exists(output): - os.unlink(output) - shutil.copy(path, output) - os.chmod(output, 0444) - - -# For running as a standalone server -if __name__ == "__main__": - sys.exit(main(sys.argv)) diff --git a/specs/.gitignore b/specs/.gitignore deleted file mode 100644 index 67bc862..0000000 --- a/specs/.gitignore +++ /dev/null @@ -1,5 +0,0 @@ -junk -*.tmp -*.pdf -*.html -Makefile.local diff --git a/specs/Makefile b/specs/Makefile deleted file mode 100644 index 0599622..0000000 --- a/specs/Makefile +++ /dev/null @@ -1,26 +0,0 @@ -NULL = - -STORING_TRUST_FILES = \ - storing-trust-c.xml \ - storing-trust-dbus.xml \ - storing-trust-json.xml \ - storing-trust-model.xml \ - storing-trust-existing.xml \ - storing-trust-pkcs11.xml \ - storing-trust-policy.xml \ - storing-trust-retrofit.xml \ - $(NULL) - -STORING_TRUST_DIR = storing-trust - -all: $(STORING_TRUST_DIR)/index.html - -clean: - rm -rf $(STORING_TRUST_DIR) - -$(STORING_TRUST_DIR)/index.html: docbook-params.xsl Makefile $(STORING_TRUST_FILES) - mkdir -vp $(STORING_TRUST_DIR)/ - rm -vf $(STORING_TRUST_DIR)/* - xmlto -vv -m docbook-params.xsl -o $(STORING_TRUST_DIR) html storing-trust-policy.xml - --include Makefile.local diff --git a/specs/docbook-params.xsl b/specs/docbook-params.xsl deleted file mode 100644 index 7690bc2..0000000 --- a/specs/docbook-params.xsl +++ /dev/null @@ -1,39 +0,0 @@ -<?xml version="1.0"?> -<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> - -<!-- - Parameters for DocBook transformation. - - Copyright (C) 2009 Michael Leupold <lemma@confuego.org> - - This library is free software; you can redistribute it and/or - modify it under the terms of the GNU Lesser General Public - License as published by the Free Software Foundation; either - version 2.1 of the License, or (at your option) any later version. - - This library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with this library; if not, write to the Free Software - Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ---> - - <xsl:param name="generate.toc"> - book toc - part nop - chapter toc - article toc - </xsl:param> - - <xsl:param name="html.stylesheet">style.css</xsl:param> - <xsl:param name="refentry.generate.name">0</xsl:param> - <xsl:param name="refentry.generate.title">1</xsl:param> - <xsl:param name="section.autolabel">1</xsl:param> - <xsl:param name="chunk.section.depth" select="0"></xsl:param> - <xsl:param name="tox.max.depth" select="0"></xsl:param> - <xsl:param name="toc.section.depth" select="1"></xsl:param> - <xsl:param name="use.id.as.filename" select="1"></xsl:param> -</xsl:stylesheet> diff --git a/specs/pkcs11-trust-assertions.h b/specs/pkcs11-trust-assertions.h deleted file mode 100644 index decfd32..0000000 --- a/specs/pkcs11-trust-assertions.h +++ /dev/null @@ -1,56 +0,0 @@ -/* - * pkcs11x.h - * Copyright 2010 Collabora, Ltd - * - * This file is free software; as a special exception the author gives - * unlimited permission to copy and/or distribute it, with or without - * modifications, as long as this notice is preserved. - * - * This file is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY, to the extent permitted by law; without even - * the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR - * PURPOSE. - */ - -/* - * The latest version of this file is at: - * - * git://thewalter.net/git/pkcs11-trust-assertions - * - * or viewable on the web at: - * - * http://thewalter.net/git/cgit.cgi/pkcs11-trust-assertions/tree/pkcs11-trust-assertions.h - * - */ - -#ifndef PKCS11_TRUST_ASSERTIONS_H -#define PKCS11_TRUST_ASSERTIONS_H - -#include "pkcs11.h" - -#define CKA_XDG (CKA_VENDOR_DEFINED | 0x58444700UL /* XDG0 */ ) -#define CKO_XDG (CKA_VENDOR_DEFINED | 0x58444700UL /* XDG0 */ ) - -/* ------------------------------------------------------------------- - * TRUST ASSERTIONS - */ - -#define CKO_X_TRUST_ASSERTION (CKO_XDG + 100) - -#define CKA_X_ASSERTION_TYPE (CKA_XDG + 1) - -#define CKA_X_CERTIFICATE_VALUE (CKA_XDG + 2) - -#define CKA_X_PURPOSE (CKA_XDG + 3) - -#define CKA_X_PEER (CKA_XDG + 4) - -typedef CK_ULONG CK_X_ASSERTION_TYPE; - -#define CKT_X_UNTRUSTED_CERTIFICATE 1UL - -#define CKT_X_PINNED_CERTIFICATE 2UL - -#define CKT_X_ANCHORED_CERTIFICATE 3UL - -#endif /* PKCS11_TRUST_ASSERTIONS_H */ diff --git a/specs/storing-trust-c.xml b/specs/storing-trust-c.xml deleted file mode 100644 index eb6e106..0000000 --- a/specs/storing-trust-c.xml +++ /dev/null @@ -1,22 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article id="storing-trust-c"> - <title>Representation: C API</title> - - <para>Although the <link linkend="storing-trust-pkcs11">PKCS#11 representation</link> - is callable from C, there is likely a need for a simpler C API and ABI to - access the trust information.</para> - - <note> - <title>Work item</title> - <para>At the present time no C caller for - such an API exists. Most crypto libraries already use PKCS#11 to access - keys and certificates, and thus they are not the consumer for this C API. - It is also undesirable to design an API in a vacuum. Therefore if you are - such an interested caller, please contact - <ulink url="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</ulink> - for discussion.</para> - </note> - -</article> diff --git a/specs/storing-trust-dbus.xml b/specs/storing-trust-dbus.xml deleted file mode 100644 index 60018db..0000000 --- a/specs/storing-trust-dbus.xml +++ /dev/null @@ -1,22 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article id="storing-trust-dbus"> - <title>Representation: DBus API</title> - - <para>On the Linux desktop various apps would like to do lookups or modifications - of anchor data via DBus. This also facilitates concepts such as - privilege escalation (polkit prompting) to modify the system - wide trust stores.</para> - - <note> - <title>Work item</title> - <para>We need to look at the interested DBus - callers and discuss the desired form. It is undesirable to design an - API in a vacuum. Therefore if you are such an interested caller, - please contact - <ulink url="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</ulink> - for discussion.</para> - </note> - -</article> diff --git a/specs/storing-trust-existing.xml b/specs/storing-trust-existing.xml deleted file mode 100644 index 9629bea..0000000 --- a/specs/storing-trust-existing.xml +++ /dev/null @@ -1,289 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article id="storing-trust-existing"> - <title>Existing Trust Storage Implementations</title> - - <para>Obviously if a comprehensive, future-proof and realistic standard - representation of out-of-band trust policy exists, we should not define a - new representation for Linux. Instead we should gather around it. So let's - examine the various representations in use, and why they are insufficient - to provide such a comprehensive standard.</para> - - <sect1 id="nss-trust-objects"> - <title>NSS Trust Objects</title> - - <para>Internally NSS represents out-of-band trust policy using PKCS#11 - trust objects. These are not well documented - <footnote><para>Although one can see them in the NSS source code - <ulink url="http://mxr.mozilla.org/seamonkey/source//security/nss/lib/ckfw/builtins/certdata.txt?raw=1">certdata.txt</ulink> file in all their glory.</para></footnote> - so an attempt will be made to describe them here.</para> - - <para>Each NSS trust object contains the following attributes - <footnote><para>In addition to standard PKCS#11 object attributes</para></footnote> - used to find the the trust object that applies to a given X.509 - certificate:</para> - - <variablelist> - <varlistentry> - <term><literal>CKA_CLASS</literal></term> - <listitem><para><literal>CKO_NSS_TRUST</literal></para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_CERT_SHA1_HASH</literal></term> - <listitem><para>A SHA1 hash of the DER encoded X.509 - certificate to which this trust object's policy - applies.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_CERT_MD5_HASH</literal></term> - <listitem><para>An MD5 hash of the DER encoded X.509 - certificate to which this trust object's policy - applies.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_ISSUER</literal></term> - <listitem><para>The DER encoding of the issuer of the - X.509 certificate to which trust object's policy - applies.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_SUBJECT</literal></term> - <listitem><para>The DER encoding of the subject of the - X.509 certificate to which trust object's policy - applies.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_SERIAL_NUMBER</literal></term> - <listitem><para>The DER encoding of the serial number of the - X.509 certificate to which trust object's policy - applies.</para></listitem> - </varlistentry> - </variablelist> - - <para>The NSS trust object then contains the following usage attributes. - Together these roughly represent the KeyUsage and ExtendedKeyUsage - certificate extensions, as out-of-band trust policy. The names should be - self explanatory for readers familiar with those certifiacte - extensions.</para> - - <itemizedlist> - <listitem><para><literal>CKA_TRUST_DIGITAL_SIGNATURE</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_NON_REPUDIATION</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_KEY_ENCIPHERMENT</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_DATA_ENCIPHERMENT</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_KEY_AGREEMENT</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_KEY_CERT_SIGN</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_CRL_SIGN</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_SERVER_AUTH</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_CLIENT_AUTH</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_CODE_SIGNING</literal></para></listitem> - <listitem><para><literal>CKA_TRUST_EMAIL_PROTECTION</literal></para></listitem> - </itemizedlist> - - <para>The above usage attributes each can contain a trust setting, one of the - following:</para> - - <variablelist> - <varlistentry> - <term><literal>CKT_NSS_TRUSTED</literal></term> - <listitem><para>The certificate is trusted for this - usage.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKT_NSS_TRUSTED_DELEGATOR</literal></term> - <listitem> - <para>The certificate is trusted anchor as a certificate - authority for the usages.</para> - <para>In NSS the trusted anchor does not have to be - self-signed. You can explicitly trust an intermediate - certificate as if it were a trusted anchor.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><literal>CKT_NSS_NOT_TRUSTED</literal></term> - <listitem><para>This certificate is explicitly not trusted: neither - for the given usage, nor as a delegator of the given - usage.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKT_NSS_MUST_VERIFY_TRUST</literal></term> - <listitem> - <para>The certificate is not a trusted anchor (even - if a later trust record in another PKCS #11 module says - this cert should be trusted). If the marked certificate is - self-signed, then this is semantically equivalent to - <literal>CKT_NSS_NOT_TRUSTED</literal>, except NSS will return - a different error code (<emphasis>unknown CA</emphasis> for - <literal>CKT_NSS_MUST_VERIFY_TRUST</literal> - versus <emphasis>untrusted CA</emphasis> for - <literal>CKT_NSS_NOT_TRUSTED</literal>).</para> - </listitem> - </varlistentry> - <varlistentry> - <term><literal>CKT_NSS_TRUST_UNKNOWN</literal></term> - <listitem><para>This record does not explictily provide trust one - way or the other. If there is another trust record for this - cert in another PKCS #11 module, use it.</para></listitem> - </varlistentry> - </variablelist> - - <sect2 id="nss-trust-problems"> - <title>Deficiencies</title> - <para>NSS trust objects have been around for nearly two decades. They may - have been sufficient in the past but are showing their age.</para> - - <para>These trust objects do not seem to be designed as a comprehensive - representation of out-of-band trust policy. They are insufficient - in the following ways:</para> - - <itemizedlist> - <listitem><para>Makes use SHA1 and MD5 hashes both of which are - aging cryptographically.</para></listitem> - <listitem><para>Trust objects only support trust policy related to - the KeyUsage, ExtendedKeyUsage and parts of the BasicConstraints - certificate extensions.</para></listitem> - <listitem><para>Even though the ExtendedKeyUsage certificate extension - can support arbitrary usages, the set of usages represented by - these trust objects is limited to those defined above. Trust - policy for additional usages is awkward to add.</para></listitem> - <listitem><para>Blacklisting is done by marking a certificate as untrusted - for specific usages. This works in practice but does not correctly - model the reality of having a certificate blacklisted completely - and for any usage.</para></listitem> - <listitem><para>Trust objects are a PKCS#11 specific. While PKCS#11 is one - acceptable object model for representing out-of-band trust policy, - for a standard representation it cannot be the only one.</para></listitem> - </itemizedlist> - </sect2> - </sect1> - - <sect1 id="openssl-trusted"> - <title>OpenSSL Trusted Certificates</title> - <para>OpenSSL contains a representation of out-of-band trust policy in its - <literal>TRUSTED CERTIFICATE</literal> PEM blocks aka. CertAux. - Files containing this information can be manipulated using - its <command>openssl x509</command> tool.</para> - - <para>It appears that this format is undocumented, so an attempt will be made - to document it here.</para> - - <para>PEM files contain a header and footer containing the words - <literal>TRUSTED CERTIFICATE</literal>. Contained in the PEM - data are two DER sequences. The first is an X.509 certificate, - and the latter is a structure known internally as <literal>X509_CERT_AUX</literal>.</para> - - <para>The <literal>X509_CERT_AUX</literal> DER sequence may be defined as follows: -<programlisting> -CertAux ::= SEQUENCE { - trust SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, - reject [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, - alias UTF8String OPTIONAL, - keyid OCTET STRING OPTIONAL, - other [1] SEQUENCE OF AlgorithmIdentifier OPTIONAL -} -</programlisting> - </para> - - <para>The <literal>trust</literal> and <literal>reject</literal> fields - contain sequences of ExtendedKeyUsage object identifiers to - trust the certificate to be used for, or to reject usage of the - certificate for.</para> - - <para>Together <literal>trust</literal> and <literal>reject</literal> - fields represent out-of-band trust policy representing the - ExtendedKeyUsage certificate extension. The other fields are - not related to trust policy.</para> - - <sect2 id="openssl-trusted-problems"> - <title>Deficiencies</title> - - <para>This representation seems to be designed to solve a specific use - case, and not designed as a comprehensive way to represent - out-of-band trust policy. It is insufficient in the following - ways:</para> - - <itemizedlist> - <listitem><para>This format only supports trust policy related to - the ExtendedKeyUsage certificate extension.</para></listitem> - <listitem><para>Blacklisting is done by rejecting a certificate for - specific usages. This works in practice but does not correctly - model the reality of having a certificate blacklisted completely - and for any usage.</para></listitem> - <listitem><para>This format has OpenSSL implementation specific traits. - The PEM contents are the concatenation of two DER structures, - and though trivially parseable with the OpenSSL DER parser, it - is awkward to parse especially when using other and/or strict - DER parsers.</para></listitem> - </itemizedlist> - </sect2> - </sect1> - - - <sect1 id="trust-assertions"> - <title>Trust Assertions</title> - - <para>Trust Assertions are the author's previous attempt to solve the problem of sharing - trust policy information. Details about this are available online - <footnote><para><ulink url="http://p11-glue.freedesktop.org/doc/pkcs11-trust-assertions/">Storing Trust Assertions in PKCS#11 Modules</ulink></para></footnote>.</para> - - <sect2 id="trust-assertion-problems"> - <title>Deficiencies</title> - - <para>Although claiming to solve the problem of out-of-band trust policy - in a general way, closer inspection and application to the - real world exposed the following problems:</para> - - <itemizedlist> - <listitem><para>This concept only supports trust policy related to - the ExtendedKeyUsage certificate extension.</para></listitem> - <listitem><para>Blacklisting is done by rejecting a certificate for - specific usages. This works in practice but does not correctly - model the reality of having a certificate blacklisted completely - and for any usage.</para></listitem> - <listitem><para>Although they claim to be general trust assertions were - thought out as a PKCS#11 specific concept. While PKCS#11 is one - acceptable object model for representing out-of-band trust policy, - for a standard representation it cannot be the only one.</para></listitem> - </itemizedlist> - - <para>In addition claims of extensibility and generality proved hard - to implement in the real world, and trust assertions ended up - as a far more constrained concept that initially envisioned.</para> - </sect2> - </sect1> - - <sect1 id="ca-bundles"> - <title>Certificate Authority Bundles</title> - - <para>A bundle is either a file or directory containing one or more X.509 - certificate authorities. These have been used to represent the possible - anchors on a system. These are widely used today.</para> - - <para>They are usually stored in the OpenSSL PEM format, but may also be - seen in the Java Keystore format, and others.</para> - - <sect2 id="ca-bundle-problems"> - <title>Deficiencies</title> - - <para>Although widely used today certificate authority bundles have - the following deficiencies as a standard representation of - trust policy:</para> - - <itemizedlist> - <listitem><para>There is no standard way to represent out-of-band - trust policy in addition to the policy contained in the - certificate extensions. In theory one could create different - bundles for certificate authorities trusted for different - usages and circumstances, but this quickly gets out of - hand.</para></listitem> - <listitem><para>There is no concept of blacklisting in a such a bundle - bundle. One can remove a certificate from the bundle, but if - that certificate is used in the middle of a certificate chain - rather than as an anchor, the certificate validation will - not respect such a removal.</para></listitem> - </itemizedlist> - </sect2> - </sect1> - -</article> diff --git a/specs/storing-trust-json.xml b/specs/storing-trust-json.xml deleted file mode 100644 index 272b363..0000000 --- a/specs/storing-trust-json.xml +++ /dev/null @@ -1,21 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article id="storing-trust-json"> - <title>Representation: JSON</title> - - <para>Since various browsers already represent trust information as JSON data - there is likely a need to have a standard JSON form for the the models - described in these documents.</para> - - <note> - <title>Work Item</title> - <para>We need to look at the interested JSON - callers and discuss the desired form. It is undesirable to design an - API in a vacuum. Therefore if you are such an interested caller, - please contact - <ulink url="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</ulink> - for discussion.</para> - </note> - -</article> diff --git a/specs/storing-trust-model.xml b/specs/storing-trust-model.xml deleted file mode 100644 index 7f1c721..0000000 --- a/specs/storing-trust-model.xml +++ /dev/null @@ -1,491 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article id="storing-trust-model"> -<title>Model: Anchors and Blacklists</title> - -<sect1 id="introduction"> - <title>Introduction</title> - - <para>Various crypto libraries have various ways to represent and store information - about which Certificate Authorities are to be used as trust anchors. They also - have different ways to represent certificates that are blacklisted.</para> - - <para>This has led to a poor experience and a lack of coherency on Linux when it - comes to validating certificates.</para> - - <para>In this document we examine a general purpose method for storing anchor - certificates, and representing policy about them. We also look at blacklists - and their peculiarities. We see how we can represent these in a - coherent and future-proof manner. In addition to being extensible, the proposed concept - is relatively easy to implement and retrofit into existing code.</para> - - <para>By using consistent anchors and other trust information, crypto libraries - can make consistent decisions about X.509 certificates.</para> - - <sect2> - <title>Scope</title> - - <para>We are dealing here with the anchors and other trust policy - information used by a key or certificate validation algorithm. The algorithm - itself lives inside of a crypto library implementation. This trust policy - information can be viewed as input to the certificate validation algorithms. - We are not dealing with the validation algorithms themselves. These are - dealt in sufficient detail in the relevant RFCs - <footnote><para>Certificate verification is dealt with in detail - in <ulink url="http://www.ietf.org/rfc/rfc5280.txt">RFC 5280</ulink>. - </para></footnote>. - While in theory it could be nice to have all implementations share common - code for verification of certificates, imagining such an effort is outside - the scope of this document. This document does not conflict with such a - theoretical effort.</para> - - <para>This document attempts to represent basic local trust policy information for X.509 - certificate validation. It does not attempt to tackle the theoretical - problem of representing all possible forms of digital trust. There are - many possible flags, profiles and inputs to certificate validation which are - not represented. Instead this is a common base of information to share, which - augmented by other application specific information.</para> - - <para>This document currently limits itself to treatment of anchors and blacklisted - certificates. Later companion documents will deal with pinned keys and shared - state/storage needed by alternative trust validation implementations.</para> - </sect2> -</sect1> - -<sect1 id="concepts"> - <title>Concepts</title> - <para>Since the words used with these topics are often heavily overloaded and - some concepts are discussed here.</para> - - <para>A word on terminology. The word <emphasis>trust</emphasis> is used quite a bit - in this document. This is a highly overloaded and subjective term, and its use - in this specification is unfortunate. An unambiguous term is desirable. - The author cringes every time the word <emphasis>trust</emphasis> is used. - The author cringed a lot while writing this document.</para> - -<sect2 id="concept-anchors"> - <title>About Anchors</title> - - <para>X.509 is structured around the concept of having a chain of certificates, each - of which is signed and therefore trusted by the previous certificate in the - chain: a certificate authority. These chains are built by crypto libraries - when validating certificates. They are built in various ways, several of - which are outlined in RFC 5280.</para> - - <para>At one end of a certificate chain is the <emphasis>end entity</emphasis> - certificate, which is the certificate that is being validated. At the other - end the certificate chain is anchored by a trust anchor. This is a public - key that is explicitly trusted by the local system, either by default or - by a deliberate configuration choice. Usually this public key is represented - as a certificate. The anchor is usually, but not always, a root self-signed - certificate authority.</para> - - <para>Anchors can have <emphasis>trust policy</emphasis> - <footnote><para>Note we use the term <emphasis>policy</emphasis> here rather - broadly, and is not limited to the PolicyConstraints certificate - extension. Rather it includes such concepts as ExtendedKeyUsage, - NameConstraints, PolicyConstraints, and so on.</para></footnote> - attached to them which define the situations - they can be used as anchors. This policy takes on many forms. A given - anchor might be only be relevant when verifying an end entity certificate - used for email. Another anchor might be relevant only for an end entity - certificate that has a Common Name under a certain domain. There are many - such policies and combinations of them.</para> - - <para>When the anchor public key is represented by a certificate, this trust policy - is often included in the certificate itself. This is done by use of X.509 - certificate extensions. The email anchor above would have an ExtendedKeyUsage - <footnote><para>See RFC 5280 section 4.2.1.12</para></footnote> - certificate extension included in it. The second anchor above would have a - NameConstraints - <footnote><para>See RFC 5280 section 4.2.1.10</para></footnote> - certificate extension included in it.</para> - - <para>But it very often occurs that the trust policy included with the anchor - is not present or is not enough. System builders, administrators, and others wish to - override or adjust the trust policy for a given certificate authority - especially when used as an anchor. This overridden out-of-band trust policy - is not included in the anchor itself.</para> - - <para>On Linux there has been no standard way to represent this additional trust - policy. Various crypto libraries have various of representing this out-of-band - trust policy, <link linkend="storing-trust-existing">as examined elsewhere</link>. - This document wishes to define such a standard.</para> -</sect2> - -<sect2 id="concept-attached"> - <title>About Attached Extensions</title> - - <para>X.509 certificate extensions usually define the ways that a certificate - can be used to represent trust policy. Usually these - certificate extensions are internal to the certificate, and are signed - by the issuer of the certificate.</para> - - <para>By associating additional certificate extensions to a public key or - X.509 certificate we can represent out-of-band trust policy, as defined - by a system builder, administrator or user.</para> - - <para>We will refer to these additional extensions as <emphasis>Attached - Extensions</emphasis>.</para> - - <para>When both standard X.509 certificate extensions and attached extensions are - present, the attached extension is to be used instead of the certificate - extension with the same OID in the certificate itself. In this way attached - certificate extensions override policy defined in the certificate, if any.</para> - - <para>This has the implication that if only one portion of a certificate extension - needs to be adjusted by a attached certificate extension, that entire - extension will be overridden for that certificate. This is intentional. Each extension - that contains trust policy should be treated as a whole unit of trust - policy. This includes changing the critical field of an extension. - This is part of the whole.</para> - - <para>For each certificate, there may not be more than one attached certificate extension of a given - identifier or type. There is no way to automatically merge certificate - extensions. It may be possible for applications which store attached - certificate extensions (such as a management interface) to merge certain - extensions in some way. However that is out of the scope of this - document.</para> - - <para>Attached certificate extensions are associated with the subject public key info - of the anchor or certificate.</para> -</sect2> - -<sect2 id="concept-blacklist"> - <title>About Blacklisting and Revocation</title> - - <para>A blacklisted key or certificate is one that should be rejected outright - when it is encountered in a validation algorithm.</para> - - <para>As designed, when an X.509 certificate is compromised, either through malice - or accident, it is supposed to be revoked. Verification algorithms check against - lists of revoked certificates published by certificate authorities in - standard ways.</para> - - <para>When an anchor certificate is revoked, or revocation needs to take place - independent of the certificate authority, such a certificate is added to - a blacklist. This is a separate mechanism from the certificate revocation - lists outlined in X.509.</para> - - <para>Blacklists are distributed by system builders or administrators. They are - used as a supplement to retrieved revocation lists, and dynamic protocols - such as OCSP and OCSP Stapling.</para> - - <para>On Linux there has been no standard way to represent blacklists. Various - crypto libraries have various means of representing them, and - <link linkend="storing-trust-existing">we examine them elsewhere</link>. - This document wishes to define a such a standard.</para> -</sect2> - -</sect1> - -<sect1 id="model"> - <title>Model</title> - - <para>Over the years there have been many ways that anchors and - blacklists have been represented. It is clear that none of the - <link linkend="storing-trust-existing">examined representations</link> - serve to comprehensively model the necessary trust information.</para> - - <para>Here we discuss a stored model which can be used to store, - lookup, and share (between implementations) anchors and blacklists. - The model is generic in nature and defines the characteristics - that actual APIs and formats should have.</para> - - <para>Actual APIs for accessing this model are defined in companion - documents.</para> - -<sect2 id="model-store"> - <title>The Store</title> - - <para>In its general form the store has the following characteristics. It is - a subset of the behavior and characteritsics used by many other - object stores or relational models.</para> - - <variablelist> - <varlistentry> - <term>Sets</term> - <listitem><para>The store contains various data <emphasis>sets</emphasis> - used for various various purposes.</para></listitem> - </varlistentry> - <varlistentry> - <term>Items</term> - <listitem><para>Each set contains multiple items.</para></listitem> - </varlistentry> - <varlistentry> - <term>Fields</term> - <listitem><para>Each item has fields. Fields have an identifier, - and contain byte data as their value.</para></listitem> - </varlistentry> - <varlistentry> - <term>Lookup fields</term> - <listitem><para>Certain fields are used to lookup items in a - set. These lookup fields are not necessarily unique among - all items in a set. Multiple items may match a given lookup - field value.</para></listitem> - </varlistentry> - <varlistentry> - <term>Optional fields</term> - <listitem><para>Certain fields are optional, and may be missing - from an item.</para></listitem> - </varlistentry> - <varlistentry> - <term>Lookup operation</term> - <listitem> - <para>A lookup operation takes as input: the set, the lookup - fields/values, and the identifiers of the fields to return.</para> - <para>The returned values and fields are returned for all - items matching the lookup fields.</para> - <para>No particular order is defined for the returned items.</para> - <para>It is possible to do a lookup without specifying any - fields to return, merely to check if matching items are in the set.</para> - <para>It is not an error for a lookup operation to return no items.</para> - </listitem> - </varlistentry> - <varlistentry> - <term>Remove operation</term> - <listitem> - <para>A remove operation takes as input: the set, and the lookup - fields/values.</para> - <para>All items matching the input are removed from the set.</para> - <para>The remove operation is not supported by read-only sets.</para> - <para>It is not an error for a remove operation to remove no items.</para> - </listitem> - </varlistentry> - <varlistentry> - <term>Store operation</term> - <listitem> - <para>A store operation takes as input: the set, and the - fields/values to store.</para> - <para>If an item matching all the fields/values already exists - in the set, then the item is not added, although this is not an - error.</para> - <para>The store operation is not supported by read-only sets.</para> - </listitem> - </varlistentry> - </variablelist> - - <para>Implementations of the store may have additional capabilities, but must implement - the above characteristics and behavior.</para> -</sect2> - -<sect2 id="model-anchors"> - <title>Set: Anchors</title> - - <para>This is a known set containing anchors to be used in certificate - chain validation. The presence of a public key in this data set makes - it an anchor.</para> - - <para>Items in the set of anchors contain the following fields:</para> - - <variablelist> - <varlistentry> - <term>Public Key Info: <emphasis>required, lookup</emphasis></term> - <listitem><para>The public key of the anchor. A DER encoded - SubjectPublicKeyInfo sequence as defined in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term>Subject: <emphasis>optional, lookup</emphasis></term> - <listitem><para>The subject DN of the anchor. A DER encoded - Name sequence defined in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term>Certificate: <emphasis>optional</emphasis></term> - <listitem><para>A certificate associated with the anchor. The - DER encoded Certificate sequence defined in X.509.</para></listitem> - </varlistentry> - </variablelist> - - <para>Given the above fields and their flags, this set has the following - characteristics:</para> - - <itemizedlist> - <listitem><para>Anchors are defined as a public key.</para></listitem> - <listitem><para>Some, but not all anchors have an associated certificate.</para></listitem> - <listitem><para>Some, but not all anchors have an associated subject.</para></listitem> - <listitem><para>A single anchor public key can be stored multiple times - with different subjects and certificates.</para></listitem> - </itemizedlist> - - <para>Implementation notes:</para> - - <itemizedlist> - <listitem><para>To determine whether a given public key is an anchor - callers should perform a lookup operation on this set using the - public key info as the lookup field.</para></listitem> - <listitem><para>To determine whether a given certificate is an anchor - callers should extract the subjectPublicKeyInfo field of that - certificate. Then perform a lookup operation on this set using - the public key info as the lookup field.</para></listitem> - <listitem><para>If a caller is building a certificate chain, and wishes - to find a possible anchor: Perform a lookup operation on this set - using the issuer field of the last certificate in - the chain as the subject lookup field.</para></listitem> - <listitem><para>Callers looking up anchors in the store which are - unable to handle anchors that are not certificates, should - ignore anchors that do not contain certificates. If multiple - results are returned for a lookup, such callers should prefer - the result which contains a certificate field.</para></listitem> - <listitem><para>Anchors without a subject field are not able to be - used when building a certificate chain.</para></listitem> - <listitem><para>To change whether a public key or certificate is an anchor - or not, it is added or removed from the list of anchors.</para></listitem> - <listitem><para>Callers storing anchors in the store, should be aware - that certificate and subject fields are desired by many callers, - and should store those fields with the anchor if possible.</para></listitem> - <listitem><para>In order to be a certificate authority anchor (that is an - anchor in a certificate chain with a length longer than one) - the BasicConstraints extension must be present with a isCa - field set to TRUE. This extension can be present either in - the certificate or attached to it.</para></listitem> - </itemizedlist> -</sect2> - -<sect2 id="model-blacklist"> - <title>Set: Blacklist</title> - - <para>This is a known set containing public keys that should never be - treated as valid. Items in the blacklist set contain the following fields:</para> - - <variablelist> - <varlistentry> - <term>Public Key Info: <emphasis>optional, lookup</emphasis></term> - <listitem><para>The public key that is blacklisted. A DER encoded - SubjectPublicKeyInfo sequence as defined in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term>Issuer: <emphasis>optional, lookup</emphasis></term> - <listitem><para>The issuer DN of the authority that issued or - previously validated the key or a certificate cotnaining the key. - A DER encoded Name sequence defined in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term>Serial Number: <emphasis>optional, lookup</emphasis></term> - <listitem><para>The serial number given by the authority issued or - previously validated the key or a certificate containing the key. - The DER encoded CertificateSerialNumber field defined in X.509.</para></listitem> - </varlistentry> - </variablelist> - - <para>Given the above fields and their flags, this set has the following - characteristics:</para> - - <itemizedlist> - <listitem><para>Keys may be black listed by their public key.</para></listitem> - <listitem><para>Certificates may be black listed by issuer and serial number.</para></listitem> - <listitem><para>A single public key may be blacklisted with different issuer - and serial number fields.</para></listitem> - </itemizedlist> - - <para>Implementation notes:</para> - - <itemizedlist> - <listitem><para>To determine whether a given public key is black listed - callers should perform a lookup operation on this set using the - public key info as the lookup field.</para></listitem> - <listitem><para>Callers which are validating certificate chains should, - for all non-root certificates in the chain, perform a lookup - on this set using the issuer and serialNumber as lookup - fields.</para></listitem> - <listitem><para>Callers storing blacklists in the store, should store - as much information as is available. If a certificate is available - then store all three of the public key info, issuer, and serial number - fields. If only issuer and serial number information is available - (such as would come from a CRL list) then store those.</para></listitem> - <listitem><para>Additionally it is possible to blacklist a certificate by - constraining its trust policy with certificate extensions like - ExtendedKeyUsage so that it will not validate for any purpose - or use case. This is not the recommended approach. Implementors - should instead place the certificates on an explicit - blacklist.</para></listitem> - </itemizedlist> -</sect2> - -<sect2 id="model-attached"> - <title>Set: Attached Extensions</title> - - <para>This is a known set of certificate extensions that should be applied - to a public key, which define or adjust trust policy for it. Items in the - attached extensions set contain the following fields:</para> - - <variablelist> - <varlistentry> - <term>Public Key Info: <emphasis>required, lookup</emphasis></term> - <listitem><para>The public key with which the extension is to - be used. A DER encoded SubjectPublicKeyInfo sequence as defined - in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term>Extension: <emphasis>required</emphasis></term> - <listitem><para>The extension to define for the public key. - A DER encoded Extension sequence defined in X.509.</para></listitem> - </varlistentry> - </variablelist> - - <para>Given the above fields and their flags, this set has the following - characteristics:</para> - - <itemizedlist> - <listitem><para>Attached extensions are associated with a public key.</para></listitem> - <listitem><para>Multiple attached extensions may be present for a given public key.</para></listitem> - </itemizedlist> - - <para>Implementation notes:</para> - - <itemizedlist> - <listitem><para>To lookup all attached extensions for a given certificate - or public key, callers should perform a lookup operation on this - set using the public key info as the lookup field.</para></listitem> - <listitem><para>Callers which are validating certificate chains should, - retrieve all attached extensions for each certificate in the chain - and use those attached extensions as if they had been present in - the respective certificate. If an attached extension has the same - extnID value as one present in the certificate, the attached - certificate extension should be used instead.</para></listitem> - <listitem><para>Callers storing attached extensions in the store, should never - store duplicate extensions in the set that contain the same extnID - value, just as you would not place multiple extensions in a certificate - with the same extnID.</para></listitem> - <listitem><para>To change whether a certificate is an authority or not, an - attached BasicConstraints extension is added with the relevant - isCa and pathlen fields.</para></listitem> - <listitem><para>An ExtendedKeyUsage or KeyUsage attached extension may - be added to a certificate when the system builder or administrator - wishes to define or override which purposes a certificate can be - used for (eg: server authentication, email, etc.)</para></listitem> - <listitem><para>In combination with having a certificate an anchor, these - attached extensions may be used to constrain for what purposes - anchors can be used.</para></listitem> - <listitem><para>A NameConstraints attached certificate extension may be - added to a certificate when the system builder or administrator - wishes to define which end entity names can be signed by a - given certificate.</para></listitem> - </itemizedlist> -</sect2> - -<sect2 id="model-layering"> - <title>Store Layering</title> - - <para>Implementations may have multiple stores, each containing the above sets. - For example one store may be a read-only system store, and another store may - be one editable by the user. Implementations should have a defined order of - lookup priority for these multiple stores.</para> - - <para>Callers performing a lookup operation should perform the lookup against - each store in turn, using the defined order. Once the lookup operation returns - results against a store, it should not continue to on to lower priority stores. - In this way items in higher priority stores override information in lower - priority stores.</para> - - <para>If a public key or certificate is both in the set of anchors and the - blacklist set, then the caller should treat it as black listed. This means that both - the anchors and blacklist sets in a given store should be consulted when - validating certificates or keys. However again, as noted above, once a store - returns results for a key, stores with a lower priority should not be consulted - for trust information about that key.</para> -</sect2> - -</sect1> - -</article> diff --git a/specs/storing-trust-pkcs11.xml b/specs/storing-trust-pkcs11.xml deleted file mode 100644 index a41a31b..0000000 --- a/specs/storing-trust-pkcs11.xml +++ /dev/null @@ -1,285 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article id="storing-trust-pkcs11"> - <title>Representation: PKCS#11</title> - - <para><ulink url="http://www.cryptsoft.com/pkcs11doc/">PKCS#11</ulink> is a useful - and widely supported standard for storage and use of keys and certificates. - It is often used with smart cards.</para> - - <para>Here we outline how to use PKCS#11 as a store for trust policy, containing sets - for anchors, blacklist, and attached extensions.</para> - -<simplesect id="pkcs11-store"> - <title>Store representation</title> - - <para>We define a trust store using the stardard PKCS#11 object model, with a few - new attributes.</para> - - <variablelist> - <varlistentry> - <term>Store</term> - <listitem><para>Each PKCS#11 token is a store.</para></listitem> - </varlistentry> - <varlistentry> - <term>Sets</term> - <listitem><para>Sets are implemented by using certain PKCS#11 attributes to - differentiate between items in various sets.</para></listitem> - </varlistentry> - <varlistentry> - <term>Items</term> - <listitem><para>Items in the sets are represented by PKCS#11 objects.</para></listitem> - </varlistentry> - <varlistentry> - <term>Fields</term> - <listitem> - <para>Fields are implemented as various PKCS#11 <literal>CK_ATTRIBUTE</literal> - attributes, and the field identifiers are the <literal>CK_ATTRIBUTE_TYPE</literal> type - of the attribute.</para> - <para>Some fields are standard PKCS#11 attributes, and others are - implemented by defining a few extension vendor attributes in the PKCS#11 - defined fashion. To make it clear which attributes are defined here - and which are standard, all new attributes and values are - prefixed by the letters <literal>_X_</literal>. Once standardized - they would lose this tag.</para> - </listitem> - </varlistentry> - <varlistentry> - <term>Lookup fields</term> - <listitem> - <para>In PKCS#11 any field can be used as a lookup field. For speedy - lookups it is recommended that implementations internally index the - attributes that will be used to lookup trust policy.</para> - </listitem> - </varlistentry> - <varlistentry> - <term>Optional fields</term> - <listitem> - <para>Optional fields are implemented as an empty zero-length - <literal>CK</literal> value when the field is not present.</para> - </listitem> - </varlistentry> - <varlistentry> - <term>Lookup operation</term> - <listitem> - <para>A lookup operation is implemented using the - <literal>C_FindObjectsInit()</literal> <literal>C_FindObjects()</literal> - PKCS#11 functions.</para> - <para>The set to lookup is specified by passing certain set specific - attributes, defined below, as part of the <literal>C_FindObjectsInit()</literal> - find template.</para> - <para>The fields to lookup are also passed as part of the - <literal>C_FindObjectsInit()</literal> find template.</para> - <para>If there are fields for which values need to be retrieved, the - <literal>C_GetAttributeValue()</literal> function should be used to retrieve - them on each of the objects matched by <literal>C_FindObjects()</literal>.</para> - </listitem> - </varlistentry> - <varlistentry> - <term>Remove operation</term> - <listitem> - <para>A remove operation is implemented using the - <literal>C_FindObjectsInit()</literal> <literal>C_FindObjects()</literal> - PKCS#11 functions, in the same way as a in the lookup operation described - above.</para> - <para>The <literal>C_DestroyObject()</literal> function should be used to - remove the objects matched by the <literal>C_FindObjects()</literal> - function.</para> - <para>Another concurrent operation may have also removed an item. Do not - propogate <literal>CKR_OBJECT_HANDLE_INVALID</literal> return codes from - the <literal>C_DestroyObject()</literal> function.</para> - <para>Callers may consult the standard PKCS#11 <literal>CK_TOKEN_INFO</literal> - <literal>CKF_TOKEN_WRITE_PROTECTED</literal> flag, and object - <literal>CKA_MODIFIABLE</literal> attribute to determine whether items - may be removed.</para> - </listitem> - </varlistentry> - <varlistentry> - <term>Store operation</term> - <listitem> - <para>A store operation is implemented using the <literal>C_CreateObject()</literal> - PKCS#11 function.</para> - <para>The set to store the item in is specified by passing certain - set specific attributes, defined below, as part of the - <literal>C_CreteObject()</literal> attribute template.</para> - <para>The fields to store are also passed as part of the - <literal>C_CreateObject()</literal> attribute template.</para> - <para>Implementors of the <literal>C_CreateObject()</literal> function should - check for another item that matches the relevant fields for the set in question. - If one exists the existing handle should be returned, rather than storing a - duplicate object.</para> - <para>Callers may consult the standard PKCS#11 <literal>CK_TOKEN_INFO</literal> - <literal>CKF_TOKEN_WRITE_PROTECTED</literal> flag to determine whether items - may be stored.</para> - </listitem> - </varlistentry> - </variablelist> - -</simplesect> - -<simplesect id="pkcs11-anchors"> - <title>Set: Anchors</title> - - <para>The standard <literal>CKA_TRUSTED</literal> boolean attribute is used - to define a certificate or public key as an anchor.</para> - - <para>The following attribute is set on items that are part of the - set of anchors:</para> - - <variablelist> - <varlistentry> - <term><literal>CKA_TRUSTED</literal></term> - <listitem><para>Value: <literal>CK_TRUE</literal></para></listitem> - </varlistentry> - </variablelist> - - <para>Items in the set of anchors contain the following fields:</para> - - <variablelist> - <varlistentry> - <term><literal>CKA_PUBLIC_KEY_INFO</literal></term> - <listitem><para>The public key of the anchor, always present. A DER encoded - SubjectPublicKeyInfo sequence as defined in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_SUBJECT</literal></term> - <listitem><para>The subject DN of the anchor. Contents as defined in - PKCS#11: a DER encoded Name sequence defined in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_CLASS</literal></term> - <listitem><para>Set to <literal>CKO_CERTIFICATE</literal> when the - stored item is a certificate, and <literal>CKO_PUBLIC_KEY</literal> - when it doesn't.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_VALUE</literal></term> - <listitem><para>When the stored item is a certificate - (it has a <literal>CKA_CLASS</literal> of <literal>CKO_CERTIFICATE</literal>, - see above) this attribute stores the DER encoded Certificate - sequence defined in X.509.</para></listitem> - </varlistentry> - </variablelist> - - <para>Other standard PKCS#11 fields should be present on the objects as per - the <literal>CKA_CLASS</literal> attribute.</para> - - <para>Note that the presence of a BasicConstraints extension marks it as a - certificate authority anchor, capable of anchoring a certificate chain, - and not just itself.</para> -</simplesect> - -<simplesect id="pkcs11-blacklist"> - <title>Set: Blacklist</title> - - <para>We define a new boolean attribute CKA_X_DISTRUSTED to indicate - blacklist status.</para> - - <para>The following attribute is set on items that are part of the - blacklist set:</para> - - <variablelist> - <varlistentry> - <term><literal>CKA_X_DISTRUSTED</literal></term> - <listitem><para>Value: <literal>CK_TRUE</literal></para></listitem> - </varlistentry> - </variablelist> - - <para>Items in the blacklist set contain the following fields:</para> - - <variablelist> - <varlistentry> - <term><literal>CKA_PUBLIC_KEY_INFO</literal></term> - <listitem><para>The public key of the anchor. A DER encoded - SubjectPublicKeyInfo sequence as defined in X.509. When this - value is not present, set to a zero length value.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_ISSUER</literal></term> - <listitem><para>The DN of the issuer. Contents as defined in - PKCS#11: a DER encoded Name sequence defined in X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_SERIAL_NUMBER</literal></term> - <listitem><para>The serial number assigned by the issuer. Contents - as defined in PKCS#11: a DER encoded Name sequence defined in - X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_CLASS</literal></term> - <listitem><para>Set to <literal>CKO_CERTIFICATE</literal> when the - <literal>CKA_ISSUER</literal> and <literal>CKA_SERIAL</literal> are\ - present. Otherwise may be set to either <literal>CKO_PUBLIC_KEY</literal> - or <literal>CKO_CERTIFICATE</literal> as appropriate.</para></listitem> - </varlistentry> - </variablelist> - - <para>Other standard PKCS#11 fields should be present on the objects as per - the <literal>CKA_CLASS</literal> attribute.</para> -</simplesect> - -<simplesect> - <title>Set: Attached Extensions</title> - - <para>A new object class is defined of type <literal>CKO_X_CERTIFICATE_EXTENSION</literal>. Each - object of this class represents one attached certificate extension. It - contains the following (standard and newly defined) attributes (in addition - to the standard data storage attributes):</para> - - <para>The following attribute is set on items that are part of the - set of attached extensions:</para> - - <variablelist> - <varlistentry> - <term><literal>CKA_CLASS</literal></term> - <listitem><para>Value: <literal>CKO_X_CERTIFICATE_EXTENSION</literal></para></listitem> - </varlistentry> - </variablelist> - - <para>Items in the set of attached extensions set contain the following fields:</para> - - <variablelist> - <varlistentry> - <term><literal>CKA_PUBLIC_KEY_INFO</literal></term> - <listitem><para>The public key associated with the attached - extension. A DER encoded SubjectPublicKeyInfo sequence as defined in - X.509.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_VALUE</literal></term> - <listitem><para>The DER encoded value of the Extension sequence as - defined in X.509. Note that this is the entire Extension - sequence and not just the extnValue field.</para></listitem> - </varlistentry> - <varlistentry> - <term><literal>CKA_OBJECT_ID</literal></term> - <listitem><para>The DER-encoded OID of the attached certificate - extension. This is the exact contents of the extnID field in the - Extension sequence.</para></listitem> - </varlistentry> - </variablelist> - - <para>In addition the PKCS#11 <emphasis>Common Storage Object Attributes</emphasis> may - be present, as well as the <literal>CKA_ID</literal> attribute.</para> - -</simplesect> - -<simplesect id="pkcs11-constants"> - <title>Constants</title> - - <para>The following constants are defined:</para> - -<programlisting> -<![CDATA[ -#define CKO_X_CERTIFICATE_EXTENSION 0xd84447c8UL -#define CKA_X_DISTRUSTED 0xd8444764UL - -/* The following definition comes from PKCS#11 2.40 -#define CKA_PUBLIC_KEY_INFO 0x00000129UL -]]> -</programlisting> - -</simplesect> - -</article> diff --git a/specs/storing-trust-policy.xml b/specs/storing-trust-policy.xml deleted file mode 100644 index 82252cb..0000000 --- a/specs/storing-trust-policy.xml +++ /dev/null @@ -1,68 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<book> - <title>Storing Trust Policy</title> - - <bookinfo> - <releaseinfo>Revision: Take two</releaseinfo> - <date>June 2013</date> - <authorgroup> - <author> - <firstname>Stef</firstname> - <surname>Walter</surname> - <affiliation> - <orgname>Red Hat Inc.</orgname> - <address> - <email>stefw@redhat.com</email> - </address> - </affiliation> - </author> - <author> - <othername>... with a lot of insight from others</othername> - </author> - </authorgroup> - </bookinfo> - - <preface id="status"> - <title>Status of this document</title> - - <para>This document is in a state of construction. I applaud those who wish to join - in and participate. Many things like footnotes, clarifications are missing. - There is some editorializing that should not be in the final. - Comments, including nit picking, are welcome.</para> - - <para>The - <ulink url="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</ulink> - mailing list is the preferred venue for discussion.</para> - </preface> - - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" - href="storing-trust-model.xml"/> - - <part> - <title>Concrete Representations</title> - - <partintro> - <para>In order to make sense of the following concrete representations - it's helpful to be familiar with the - <link linkend="storing-trust-model">abstract model</link> being implicitly - referenced here.</para> - </partintro> - - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" - href="storing-trust-pkcs11.xml"/> - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" - href="storing-trust-c.xml"/> - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" - href="storing-trust-json.xml"/> - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" - href="storing-trust-dbus.xml"/> - </part> - - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" - href="storing-trust-retrofit.xml"/> - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" - href="storing-trust-existing.xml"/> - -</book> diff --git a/specs/storing-trust-retrofit.xml b/specs/storing-trust-retrofit.xml deleted file mode 100644 index 1dea929..0000000 --- a/specs/storing-trust-retrofit.xml +++ /dev/null @@ -1,56 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article id="storing-trust-retrofit"> - <title>Retrofiting Existing Implementations</title> - - <para>In an ideal world all implementations would move to this shared - model of trust policy as soon as possible. However in the real - world these things take time. Here we discuss various strategies - for retrofitting existing implementations to be able to consume - this stored data.</para> - - <para>While such retrofits result in ignoring certain trust policy by - a given implementation, there are concrete benefits of sharing - even just some of the trust information. Such an interim retrofit - produces coherent results for many current real world use cases. - It is thus better than having all the crypto library implementations - use their own source for trust policy.</para> - - <para>Such a retrofit should be an interim measure.</para> - -<sect1 id="retrofit-anchors"> - <title>Retrofit: Bundle of anchors</title> - - <para>If a crypto library expects an input of a set of anchor certificate authorities - and nothing more, then it is possible to lookup all acceptable anchors from - the store. Anchors that no not match the necessary trust policy would be - filtered out before handing them over to the validation algorithms.</para> -</sect1> - -<sect1 id="retrofit-callback"> - <title>Retrofit: Extra validation</title> - - <para>If a crypto library allows access to the certificate chain before, during (via a - callback) or after validation, then it is possible to check each certificate\ - in the chain against the blacklist.</para> -</sect1> - -<sect1 id="retrofit-nss-trust"> - <title>Retrofit: NSS trust objects</title> - - <para>It is possible to model NSS PKCS#11 trust objects on top of an underlying storage - based on attached certificate extensions. This will only enforce the KeyUsage - and ExtendedKeyUsage extensions. Blacklists are modeled by marking all usages - as untrusted.</para> -</sect1> - -<sect1 id="rerofit-openssl-x509-store"> - <title>Retrofit: OpenSSL X509_STORE</title> - <para>It is possible to model an OpenSSL X509_STORE implementation on top of an - underlying storage based on attached certificate extensions. This will only - enforce the ExtendedKeyUsage extensions. Blacklists are enforced by rejecting all - usages.</para> -</sect1> - -</article> diff --git a/specs/trust-assertions.xml b/specs/trust-assertions.xml deleted file mode 100644 index 73fa840..0000000 --- a/specs/trust-assertions.xml +++ /dev/null @@ -1,644 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -]> -<article> - -<!-- RETIRED: SEE DETAILS BELOW --> - - <title>Storing Trust Assertions in PKCS#11 Modules</title> - - <articleinfo> - <releaseinfo>This document has been retired.</releaseinfo> - <date>December 2010</date> - <authorgroup> - <author> - <firstname>Stef</firstname> - <surname>Walter</surname> - <affiliation> - <orgname>Collabora Ltd</orgname> - <address> - <email>stefw@collabora.co.uk</email> - </address> - </affiliation> - </author> - </authorgroup> - </articleinfo> - - <section id="status"> - <title>Status of This Document</title> - - <para>This document has been retired. Although the concepts herein worked, - they were not compelling enough to be used as a common means of - sharing trust information. In particular this document shared - deficiencies with prior solutions it was meant to replace.</para> - - <para>Further work on this topic continues under the - <ulink url="http://p11-glue.freedesktop.org/doc/sharing-trust-policy/">Sharing Trust Policy</ulink> specification, including the concept of - Attached Certificate Extensions.</para> - </section> - - <section id="introduction"> - <title>Introduction</title> - - <para>Trust assertions are represent bits of trust information used by an - application to make trust decisions. For example, trust assertions can - represent certificate authority anchors, pinned certificate exceptions, or - revocation lists. Trust assertions do not represent the trust decision - itself. They are merely one factor in the trust decision. However by using - trust assertions applications (and libraries) can make consistent trust - decisions and interoperate with one another. This is a building block - toward a usable crypto experience for the user of such applications.</para> - - <para><ulink url="http://www.cryptsoft.com/pkcs11doc/">PKCS#11</ulink> is a useful - and widely supported standard for storage and use of keys and certificates. - It is often used with smart cards.</para> - - <para>This specification outlines how to store and lookup trust assertions via the - PKCS#11 API. We detail an extension which accomplishes this.</para> - - <para>A word on terminology. We use the word <emphasis>trust</emphasis> quite a bit - in this document. This is a highly overloaded and subjective term, and its use - in this specification is unfortunate. An unambiguous term is desirable. - The author cringes every time the word <emphasis>trust</emphasis> is used. - The author cringes a lot.</para> - - <para>In this specification we deal only with trust assertions related to certificates. - In theory, trust assertions can relate to secret keys, and other subjects - as well. Future versions of this specification may specify trust assertions - for these other subjects.</para> - </section> - - <section id="trust-assertions"> - <title>Trust Assertions</title> - - <para>A trust assertion is a generic concept. Each trust assertion describes a level - of trust in a certain subject for a given purpose. Conceptually each trust - assertion is a triple containing the following:</para> - - <itemizedlist> - <listitem><para><link linkend='trust-subject'>Reference to the subject</link></para></listitem> - <listitem><para><link linkend='trust-purpose'>Purpose</link></para></listitem> - <listitem><para><link linkend='trust-level'>Level of trust</link></para></listitem> - </itemizedlist> - - <para>We examine each of these parts of the triple in further detail below.</para> - - <section id='trust-level'> - <title>Level of Trust</title> - - <para>This describes the level of trust represented by the trust assertion.</para> - - <variablelist> - <varlistentry> - <term>Distrusted</term> - <listitem><para>The trust assertion marks the subject as explicitly - distrusted. This overrides other trust.</para></listitem> - </varlistentry> - <varlistentry> - <term>Trusted</term> - <listitem><para>The trust assertion marks the subject as explicitly - trusted.</para></listitem> - </varlistentry> - <varlistentry> - <term>Anchor</term> - <listitem><para>The trust assertion marks the subject as trusted to - confer its trust (eg: via signatures) on other subjects - (eg: via a certificate chain).</para></listitem> - </varlistentry> - </variablelist> - - <para>We can call trust assertions which establish trust <emphasis>positive trust - assertions</emphasis>. In essence these trust assertions build up trust in - a subject. These have a level of trust of <emphasis>trusted</emphasis> - or <emphasis>anchor</emphasis>. Examples of this kind of trust assertion - are certificate authority trust anchors.</para> - - <para>Trust assertions that falsify trust can be called <emphasis>negative trust - assertions</emphasis>. These trust assertions tear down trust in a subject. They - assume the subject is already trusted, and want to revoke or falsify - that trust. These have a level of trust of <emphasis>distrusted</emphasis>. - Examples of this kind of trust assertion are certificate revocation lists.</para> - - <para>Negative trust assertions always override positive trust assertions.</para> - </section> - - <section id='trust-purpose'> - <title>Purpose</title> - - <para>A trust assertion always refers to a specific purpose or usage. This is - the thing that the subject is trusted to do. For example a certificate - may be trusted for purposes like: email, code signing, or authenticating - a remote host.</para> - - <para>In addition, the purpose can contain a peer, which further narrows what the - subject is trusted to do. It is then only trusted for for the given purpose - when the given peer is involved. For example the peer might be the host - name of a server.</para> - </section> - - - <section id='trust-subject'> - <title>Subject Reference</title> - <para>Each trust assertion contains a reference to the subject. This is the thing - that is trusted. In this specification we will deal exclusively with - X.509 certificates as the subject of trust assertions.</para> - </section> - </section> - - <section id="pkcs11-objects"> - <title>PKCS#11 Trust Assertion Objects</title> - - <para>Trust assertions are stored as objects on a PKCS#11 token. Although these are - specific to a certificate, they do not need to be stored on the same token as - the certificate.</para> - - <para>When represented as PKCS#11 objects, trust assertions become less elegant - than the reference + purpose + trust-level triple described above. This is done - because of limitations in the PKCS#11 API and also to minimizing the number - of PKCS#11 lookups required to use trust assertions.</para> - - <para>There are two ways that a trust assertion refers to a certificate. Certificates - used in 'positive' trust assertions are referred to by the complete DER encoding - of the certificate. Certificates used in 'negative' trust assertions are referred - to by the DER value of the certificate's issuer field and its serial number.</para> - - <para>Unfortunately, we cannot have a single way to refer to certificates used - in both positive and negative trust assertions. For example, referring - to a certificate authority trust anchor by its issuer and serial number - would be meaningless. And using a full DER value to refer to negative - trust assertions would preclude uses such as certificate revocation - lists. Therefore different methods must be used to refer to certificates in - these different situations. The objects below reflect this.</para> - - <section id="common-attributes"> - <title>Common Trust Assertion Object Attributes</title> - - <para>First we describe the attributes that all trust assertion objects have in - common. All trust assertions are of the class - <literal>CKO_X_TRUST_ASSERTION</literal>.</para> - - <para>In addition to the following trust assertion attributes, all the stardard - PKCS#11 storage object attributes of <literal>CKA_TOKEN</literal>, - <literal>CKA_PRIVATE</literal>, <literal>CKA_MODIFIABLE</literal> and - <literal>CKA_LABEL</literal> may be present.</para> - - <table id='assertion-attributes'> - <title>General trust assertion attributes</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Data Type</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry><literal>CKA_CLASS</literal></entry> - <entry><literal>CK_OBJECT_CLASS</literal></entry> - <entry><literal>CKO_X_TRUST_ASSERTION</literal></entry> - </row> - <row> - <entry><literal>CKA_X_ASSERTION_TYPE</literal></entry> - <entry><literal>CK_X_ASSERTION_TYPE</literal></entry> - <entry>The type of trust assertion. This represents - the <link linkend='trust-level'>level of trust</link>. - See the various - <link linkend='assertion-types'>assertion types</link>.</entry> - </row> - <row> - <entry><literal>CKA_X_PURPOSE</literal></entry> - <entry><literal>CK_UTF8_CHAR</literal> array</entry> - <entry>The string representation of - <link linkend='trust-purpose'>the purpose</link>, - usually an OID, and often one of the - <link linkend='defined-purposes'>predefined purposes</link>.</entry> - </row> - </tbody> - </tgroup> - </table> - - <para>The <literal>CKA_X_PURPOSE</literal> attribute contains a string which represents - the <link linkend='trust-purpose'>purpose of the trust assertion</link>. These are - generally OIDs. The following predefined values match those of the - <ulink url='http://www.ietf.org/rfc/rfc5280.txt'>Extended Key Usage X.509 extension</ulink>. - Other values may be used when interoperability of the trust assertion between multiple - applications is not required.</para> - - <para>Applications should ignore trust assertions whose <literal>CKA_X_PURPOSE</literal> attribute - they do not understand. They should not treat them as negative assertions.</para> - - <table id='defined-purposes'> - <title>Predefined Purposes</title> - <tgroup cols="2"> - <thead> - <row> - <entry>Value</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry><literal>1.3.6.1.5.5.7.3.1</literal></entry> - <entry>TLS Server Authentication</entry> - </row> - <row> - <entry><literal>1.3.6.1.5.5.7.3.2</literal></entry> - <entry>TLS Client Authentication</entry> - </row> - <row> - <entry><literal>1.3.6.1.5.5.7.3.3</literal></entry> - <entry>Code Signing</entry> - </row> - <row> - <entry><literal>1.3.6.1.5.5.7.3.4</literal></entry> - <entry>Email Protection</entry> - </row> - <row> - <entry><literal>1.3.6.1.5.5.7.3.8</literal></entry> - <entry>Time Stamping</entry> - </row> - </tbody> - </tgroup> - </table> - - <para>Each different type of trust assertion is represented by a different - <literal>CK_X_ASSERTION_TYPE</literal> value. These represent the - <link linkend='trust-level'>level of trust</link>. Each type of trust - assertion has additional attributes and is a distinctly different type - of PKCS#11 object. The following types are defined.</para> - - <table id='assertion-types'> - <title>Trust assertion types</title> - <tgroup cols="2"> - <thead> - <row> - <entry>Trust Type</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry><literal>CKT_X_ANCHORED_CERTIFICATE</literal></entry> - <entry>A positive trust assertion that represents a trust - anchor which is used as the anchor of a certificate - chain.</entry> - </row> - <row> - <entry><literal>CKT_X_PINNED_CERTIFICATE</literal></entry> - <entry>A positive trust assertion that represents an - explicit trust in a certificate.</entry> - </row> - <row> - <entry><literal>CKT_X_DISTRUSTED_CERTIFICATE</literal></entry> - <entry>A negative trust assertion that represents an - explicit distrust in a certificate.</entry> - </row> - </tbody> - </tgroup> - </table> - </section> - - <section id="anchored-attributes"> - <title>Anchored Certificate Assertion</title> - - <para>An anchored certificate is a trust assertion which is to be used with a - certificate authority that has signed other trusted certificates. It - is to be used as the anchor in a - <ulink url='http://www.ietf.org/rfc/rfc5280.txt'>certificate chain</ulink>.</para> - - <para>Because it is a positive trust assertion, the certificate is referenced by - using the entire DER encoding of the certificate.</para> - - <para>In addition to the following attributes, all the - <link linkend='assertion-attributes'>general trust assertion attributes</link> - are present on a anchored certificate trust assertion.</para> - - <table> - <title>Anchored Certificate Assertion Attributes</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Data Type</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry><literal>CKA_X_ASSERTION_TYPE</literal></entry> - <entry><literal>CK_X_ASSERTION_TYPE</literal></entry> - <entry><literal>CKT_X_CERTIFICATE_TRUST_ANCHOR</literal></entry> - </row> - <row> - <entry><literal>CKA_X_CERTIFICATE_VALUE</literal></entry> - <entry>Byte array</entry> - <entry>The DER encoding of the certificate.</entry> - </row> - </tbody> - </tgroup> - </table> - - </section> - - <section id="pinned-attributes"> - <title>Pinned Certificate Assertion</title> - - <para>A pinned certificate is an endpoint certificate (not an authority) which is - trusted explicitly. The expectation is that all other trust validation - is overridden by this pinned trust.</para> - - <para>Because it is a positive trust assertion, the certificate is referenced by - using the entire DER encoding of the certificate.</para> - - <para>All pinned certificate trust assertions have a designated peer with which - the pinned certificate assertion is relevant. In the case of the TLS - authentication purpose, this is the host name of the peer that is being - communicated with. In the case of the email protection purpose this is the - email address this certificate is to being used with.</para> - - <para>In addition to the following, all the - <link linkend='assertion-attributes'>general trust assertion attributes</link> - are present on a pinned certificate trust assertion.</para> - - <table> - <title>Pinned Certificate Assertion Attributes</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Data Type</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry><literal>CKA_X_ASSERTION_TYPE</literal></entry> - <entry><literal>CK_X_ASSERTION_TYPE</literal></entry> - <entry><literal>CKT_X_PINNED_CERTIFICATE</literal></entry> - </row> - <row> - <entry><literal>CKA_X_PEER</literal></entry> - <entry><literal>CK_UTF8_CHAR</literal> array</entry> - <entry>The peer part of the purpose.</entry> - </row> - <row> - <entry><literal>CKA_X_CERTIFICATE_VALUE</literal></entry> - <entry>Byte array</entry> - <entry>The DER encoding of the certificate.</entry> - </row> - </tbody> - </tgroup> - </table> - - </section> - - <section id="distrusted-attributes"> - <title>Distrusted Certificate Assertion</title> - - <para>An distrusted certificate is a trust assertion which signifies the explicit - lack of trust in a certificate. An example of this is an item in a CRL - or a certificate explicitly marked as distrusted by a user.</para> - - <para>Because it is a negative trust assertion, the certificate is referenced by - a using the issuer and serial number of the certificate in question.</para> - - <para>In addition to the following, all the - <link linkend='assertion-attributes'>general trust assertion attributes</link> - are present on a distrusted certificate assertion.</para> - - <table> - <title>Distrusted Certificate Assertion Attributes</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Data Type</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry><literal>CKA_X_ASSERTION_TYPE</literal></entry> - <entry><literal>CK_X_ASSERTION_TYPE</literal></entry> - <entry><literal>CKT_X_DISTRUSTED_CERTIFICATE</literal></entry> - </row> - <row> - <entry><literal>CKA_ISSUER</literal></entry> - <entry>Byte array</entry> - <entry>DER-encoding of the certificate issuer name</entry> - </row> - <row> - <entry><literal>CKA_SERIAL_NUMBER</literal></entry> - <entry>Byte array</entry> - <entry>DER-encoding of the certificate serial number</entry> - </row> - </tbody> - </tgroup> - </table> - - </section> - </section> - - <section id="operations"> - <title>Operations</title> - - <section id="operation-build-chain"> - <title>Building a Certificate Chain</title> - - <para>During TLS or other certificate verification operations, a - <ulink url='http://www.ietf.org/rfc/rfc5280.txt'>certificate chain</ulink> - must be built. The certificate chain starts with a endpoint certificate for - the peer, and usually ends with a certificate explicitly trusted in some - way, such as a certificate authority trust anchor. The certificates in the - chain are each in turn signed by the next certificate in the chain.</para> - - <para>Conceptually building a certificate chain has two parts 1) building the chain - based on positive trust assertions, and 2) allowing then allowing falsification - of all or part of the chain based on negative trust assertions.</para> - - <para>Here is how this is accomplished. For interoperability it is important to perform - the following lookups using the attributes described:</para> - - <orderedlist> - <listitem> - - <para>Check if the endpoint certificate has a pinned certificate - for the given purpose and peer. If a pinned certificate is found - then the certificate chain consists of one certificate and is - considered valid at this point.</para> - - <para>To check for pinned certificates, perform a - <literal>C_FindObject</literal> operation with the following - attributes:</para> - - <programlisting> - CKA_CLASS: CKO_X_ASSERTION_TYPE - CKA_X_ASSERTION_TYPE: CKT_X_PINNED_CERTIFICATE - CKA_X_CERTIFICATE_VALUE: <emphasis>DER encoding of certificate</emphasis> - CKA_X_PURPOSE: <emphasis>purpose string</emphasis> - CKA_X_PEER: <emphasis>peer string</emphasis> - </programlisting> - </listitem> - - <listitem> - <para>Use PKCS#11 to find all the certificates necessary for the - certificate chain. Often a peer will not send a complete chain - and only send its own certificate. Build up the chain using the - certificate issuer of each certificate to search for issuing - certificates. This is done until a self-signed issuing certificate - is found, or an issuing certificate is not found.</para> - - <para>To lookup issuing certificates, perform a - <literal>C_FindObject</literal> operation with the following - attributes:</para> - - <programlisting> - CKA_CLASS: CKO_CERTIFICATE - CKA_CERTIFICATE_TYPE: CKC_X_509 - CKA_SUBJECT: <emphasis>Der encoding of subject of issued certificate</emphasis> - </programlisting> - - </listitem> - - <listitem> - <para>Check for an anchored certificate assertion for each certificate - in the chain starting from the certificate that signed the - endpoint certificate. The endpoint certificate is not considered - for a possible anchor. When a anchor is found then the certificate - chain is truncated at that point. Certificates past the trust anchor - are ignored.</para> - - <para>To check for anchored certificates, perform a - <literal>C_FindObject</literal> operation with the following - attributes:</para> - - <programlisting> - CKA_CLASS: CKO_X_ASSERTION_TYPE - CKA_X_ASSERTION_TYPE: CKT_X_ANCHORED_CERTIFICATE - CKA_X_CERTIFICATE_VALUE: <emphasis>DER encoding of certificate</emphasis> - CKA_X_PURPOSE: <emphasis>purpose string</emphasis> - </programlisting> - </listitem> - - <listitem> - <para>Allow falsification for each certificate in the resulting - certificate chain by checking whether each certificate has - an distrusted certificate assertion. If at any point an distrusted - assertion is found (eg: a certificate listed on a certificate - revocation list) then the certificate chain is considered invalid.</para> - - <para>To check for distrusted certificates, perform a - <literal>C_FindObject</literal> operation with the following - attributes:</para> - - <programlisting> - CKA_CLASS: CKO_X_ASSERTION_TYPE - CKA_X_ASSERTION_TYPE: CKT_X_DISTRUSTED_CERTIFICATE - CKA_X_CERTIFICATE_VALUE: <emphasis>DER encoding of certificate</emphasis> - CKA_X_PURPOSE: <emphasis>purpose string</emphasis> - </programlisting> - </listitem> - - <listitem> - <para>Pass the resulting certificate chain to the crypto library for - further validation of signers, identity matching, etc.</para> - </listitem> - </orderedlist> - </section> - </section> - - <section id="justifications"> - <title>Justifications</title> - - <para>Some answers to why this spec was designed as it is.</para> - - <section id="justification-why-no-hash"> - <title>Why use a complete certificate DER encoding for positive trust assertions?</title> - <para>Conceivably we could use a hash of the certificate instead of the - <literal>CKA_X_CERTIFICATE_VALUE</literal>. - <ulink url='https://developer.mozilla.org/en/NSS/PKCS_%2311_Netscape_Trust'> - NSS Trust Objects</ulink> use hashes in this way.</para> - - <para>In the current climate where many hash algorithms are broken in various ways - it seems prudent to avoid the hashing of the certificate and just use the - complete certificate DER encoding for lookups. This allows a robust standard - that is not dependent on the long term viability of a specific hash algorithm.</para> - </section> - - <section id="justification-why-issuer-serial"> - <title>Why refer to certificates in negative trust assertions by issuer and serial number?</title> - - <para><ulink url='http://www.ietf.org/rfc/rfc5280.txt'>Certificate revocation lists</ulink> - do not generally contain the full value of the certificate or a hash thereof. - They simply contain serial numbers, which when combined with the issuer of the - certificate revocation list, are meant to uniquely identify a given certificate.</para> - - <para>In order to support CRLs exposed as distrusted certificate assertions (which is one - of the design goals of this specification) we must limit ourselves to this method - of referencing certificates in negative trust assertions.</para> - </section> - - <section id="justification-why-not-nss"> - <title>Why not use NSS Trust Objects?</title> - - <para>NSS contains an implementation of storing trust information via PKCS#11. - This has not been completely documented, but an - <ulink url='https://developer.mozilla.org/en/NSS/PKCS_%2311_Netscape_Trust'> - overview is available</ulink>. This method of storing trust information - has been in use by NSS for many years.</para> - - <para>However the NSS method is starting to show its age. After study of NSS's - method of storing trust information, and discussion with others, the - following inherent problems are apparent.</para> - - <itemizedlist> - <listitem><para>Mandates the use SHA1 and MD5 hashes both of which are - cryptographically broken in various way. Neither - <ulink url='http://tools.ietf.org/html/draft-turner-md5-seccon-update-07'> - MD5</ulink> or - <ulink url='https://tools.ietf.org/html/draft-turner-sha0-sha1-seccon-00'> - SHA1</ulink> are currently recommended for use in specifications.</para></listitem> - - <listitem><para>Only supports a distinct set of purposes, new purposes are - not supported.</para></listitem> - - <listitem><para>Does not support a storage of a peer along with the purpose, which - precludes storage of pinned certificate assertions.</para></listitem> - - <listitem><para>Objects represent a number of trust assertions stored in a single PKCS#11 - object leading to more complex lookup and modification operations.</para></listitem> - </itemizedlist> - </section> - - <section id="justification-why-not-uris"> - <title>Why not use PKCS#11 URIs?</title> - - <para>The <ulink url='http://tools.ietf.org/html/draft-pechanec-pkcs11uri-03'>PKCS#11 URI Scheme</ulink> - is a useful draft standard which can be used to identify objects stored on a PKCS#11 - token. It has been suggested that a list of PKCS#11 URIs could be used to identify - which certificates are useful as certificate anchors.</para> - - <para>As outlined above, positive trust assertions build up trust. Certificates used in positive - trust assertions must be identified by the certificate value or a hash thereof. PKCS#11 - URIs do not have the ability to uniquely identify a certificate by its DER encoding or a - hash thereof.</para> - </section> - - <section id="justification-why-cka-trusted"> - <title>How is this related to CKA_TRUSTED?</title> - - <para>Later versions of the PKCS#11 spec contain an attribute called <literal>CKA_TRUSTED</literal>. - This attribute can be set on public keys, secret keys, and certificates by an application - as a flag indicating trust in some form. <literal>CKA_TRUSTED</literal> can be used as a - crude form of marking which certificates can be used as a certificate authority trust - anchor.</para> - - <para>We see this specification as complementary to <literal>CKA_TRUSTED</literal>. This specification - defines a fine grained method for representing all sorts of positive and negative trust - assertions, and not just anchored certificates.</para> - </section> - - </section> - -</article> diff --git a/website/base.incl b/website/base.incl deleted file mode 100644 index 5589163..0000000 --- a/website/base.incl +++ /dev/null @@ -1,53 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<!--
-Design by Free CSS Templates
-http://www.freecsstemplates.org
-Released for free under a Creative Commons Attribution 2.5 License
--->
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-<meta http-equiv="content-type" content="text/html; charset=utf-8" />
-<link href="style.css" rel="stylesheet" type="text/css" media="screen" /><title>{% block title %}{% endblock %}</title>
-</head>
-<body>
-<div id="header-wrapper">
- <div id="header">
- <div id="menu">
- <ul>
- <li><a href="http://www.freedesktop.org/" class="first">FreeDesktop.org</a></li>
- <li><a href="http://lists.freedesktop.org/mailman/listinfo/p11-glue">Mailing List</a></li>
- <li><a href="/">About</a></li>
- </ul>
- </div>
- </div>
-</div>
-<!-- end #header -->
-<!-- end #header-wrapper -->
-<div id="logo">
- <h1><a href="/">p11-glue</a></h1>
- <p><em>using PKCS#11 to unite crypto libraries</em></p>
-</div>
-<hr />
-<!-- end #logo -->
-<div id="page"><div id="page-bgtop">
-
- <div id="sidebar">
- {% block sidebar %}
- {% endblock %}
- </div>
-
- <div id="content">
- {% block content %}
- {% endblock %}
- </div>
-
-</div>
-
- <!-- end #page -->
- <div id="footer">
- <p>Design by <a href="http://www.freecsstemplates.org/">Free CSS Templates</a>.</p>
- </div>
- <!-- end #footer -->
-</div>
-</body>
-</html>
diff --git a/website/images/img01.jpg b/website/images/img01.jpg Binary files differdeleted file mode 100644 index 3623bce..0000000 --- a/website/images/img01.jpg +++ /dev/null diff --git a/website/images/img02.jpg b/website/images/img02.jpg Binary files differdeleted file mode 100644 index 556de14..0000000 --- a/website/images/img02.jpg +++ /dev/null diff --git a/website/images/img03.jpg b/website/images/img03.jpg Binary files differdeleted file mode 100644 index 00b57e2..0000000 --- a/website/images/img03.jpg +++ /dev/null diff --git a/website/images/img04.jpg b/website/images/img04.jpg Binary files differdeleted file mode 100644 index aea0719..0000000 --- a/website/images/img04.jpg +++ /dev/null diff --git a/website/images/img05.jpg b/website/images/img05.jpg Binary files differdeleted file mode 100644 index 00ecb2a..0000000 --- a/website/images/img05.jpg +++ /dev/null diff --git a/website/images/img06.jpg b/website/images/img06.jpg Binary files differdeleted file mode 100644 index d2d8c02..0000000 --- a/website/images/img06.jpg +++ /dev/null diff --git a/website/images/p11-glue.jpg b/website/images/p11-glue.jpg Binary files differdeleted file mode 100644 index 6f31e03..0000000 --- a/website/images/p11-glue.jpg +++ /dev/null diff --git a/website/index.html.tmpl b/website/index.html.tmpl deleted file mode 100644 index aa097f8..0000000 --- a/website/index.html.tmpl +++ /dev/null @@ -1,80 +0,0 @@ -{% extends "base.incl" %}
-
-{% block title %}p11 glue{% endblock %}
-
-{% block sidebar %}
-<ul>
- <li>
- <h2><a href="p11-kit.html">Project: p11-kit</a></h2>
- <p><a href="p11-kit.html">p11-kit</a> provides a way to load and
- enumerate PKCS#11 modules. Implements a standard discoverable
- configuration for installed PKCS#11 modules.</p>
- </li>
- <li>
- <h2><a href="sharing-trust-policy.html">Spec: Sharing Trust Policy</a></h2>
- <p>Sharing <a href="sharing-trust-policy.html">trust policy</a>
- allows multiple crypto libraries to make coherent decsions.
- Attached certificate extensions are a part of this.</p>
- </li>
- <li>
- <h2><a href="pkcs11-uris.html">Spec: PKCS#11 URIs</a></h2>
- <p><a href="pkcs11-uris.html">PKCS#11 URIs</a> are a way to
- identify a certain crypto object that resides in a PKCS#11
- module.</p>
- </li>
- <li>
- <h2><a href="trust-module.html">Project: Trust Module</a></h2>
- <p>The <a href="trust-module.html">PKCS#11 Trust Module</a>
- provides access to system certificates and trust policy.</p>
- </li>
- <li>
- <h2><a href="revocation-cache.html">Project: Revocation Cache</a></h2>
- <p><a href="revocation-cache.html">PKCS#11 Revocation Cache</a>
- provides a common cache of OSCP responses and CRLs and a daemon to update them.</p>
- </li>
-</ul>
-{% endblock %}
-
-{% block content %}
-<h1>Introduction</h1>
-<p>This is an effort to use and promote <a href="http://www.rsa.com/rsalabs/node.asp?id=2133">PKCS#11</a>
-as glue between crypto libraries and security applications on the open source
-desktop.</p>
-
-<p><img src="images/p11-glue.jpg"></p>
-
-<p>On the desktop today we have a variety of technically excelent crypto
-libraries (such as NSS, GnuTLS, OpenSSL etc.) The diversity allows each to
-excel and progress in its area of focus. Applications choose to use different
-crypto libraries for all sorts of good reasons.</p>
-
-<p>Users suffer because the desktop lacks a consistent way to use certificates
-or keys with all the various applications. For example different applications
-look for their trust anchor certificates in different places, and configuring
-each application with a client certificate is a laborious task.</p>
-
-<p>Developers suffer because when an application needs to use security
-(like TLS), the application needs to provide support for all sorts of
-security configuration, cetrificate/key file locations, security exceptions,
-smart cards, and so on. And so progress suffers because there's no foundation
-for consistent place to store security stuff on the desktop.</p>
-
-<p><a href="http://www.rsa.com/rsalabs/node.asp?id=2133">PKCS#11 is a standard</a>
-for accessing crypto objects like keys and certificates and performing cryptographic
-operations on them. It's often used together with smart cards.</p>
-
-<p>By using PKCS#11 to provide a plugable way for crypto libraries and other
-software to access keys, certificate, and things like trust anchors, we can
-solve the above problems.</p>
-
-<p>We can use PKCS#11 to make apps more secure (through the support use of
-smart cards), more usable (through common storage), and easier to develop
-(through standard ways to store and access crypto objects).</p>
-
-<ul>
- <li><a href="http://www.rsa.com/rsalabs/node.asp?id=2133">The PKCS#11 Specification</a></li>
- <li><a href="pkcs11-support.html">Application and Library support for PKCS#11</a></li>
-</ul>
-
-<br class="clear">
-{% endblock %}
diff --git a/website/license.txt b/website/license.txt deleted file mode 100644 index 8cb70da..0000000 --- a/website/license.txt +++ /dev/null @@ -1,63 +0,0 @@ -Creative Commons Attribution 3.0 Unported
-=========================================
- -License
- -THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
- -BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.
- -1. Definitions
- - 1. "Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.
- 2. "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.
- 3. "Distribute" means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.
- 4. "Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.
- 5. "Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.
- 6. "Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.
- 7. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.
- 8. "Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.
- 9. "Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.
- -2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.
- -3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:
- - 1. to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;
- 2. to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";
- 3. to Distribute and Publicly Perform the Work including as incorporated in Collections; and,
- 4. to Distribute and Publicly Perform Adaptations.
- 5.
- - For the avoidance of doubt:
- 1. Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;
- 2. Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,
- 3. Voluntary License Schemes. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.
- -The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.
- -4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:
- - 1. You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.
- 2. If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.
- 3. Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.
- -5. Representations, Warranties and Disclaimer
- -UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.
- -6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
- -7. Termination
- - 1. This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.
- 2. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.
- -8. Miscellaneous
- - 1. Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.
- 2. Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.
- 3. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.
- 4. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.
- 5. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.
- 6. The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.
diff --git a/website/p11-kit.html.tmpl b/website/p11-kit.html.tmpl deleted file mode 100644 index a92fe24..0000000 --- a/website/p11-kit.html.tmpl +++ /dev/null @@ -1,59 +0,0 @@ -{% extends "base.incl" %}
-
-{% block title %}p11-kit{% endblock %}
-
-{% block content %}
-<h1>Project: p11-kit</h1>
-
-<p>Provides a way to load and enumerate PKCS#11 modules. Provides a standard
-configuration setup for installing PKCS#11 modules in such a way that they're
-discoverable.</p>
-
-<p>Also solves problems with coordinating the use of PKCS#11 by different
-components or libraries living in the same process.</p>
-
-<h2>Implementations and Integration</h2>
-
-<ul>
- <li>Drop in compatible with any application or library that can use
- PKCS#11 modules. Some additional benefits are gained from
- integrating directly.</li>
- <li><a href="http://library.gnome.org/devel/glib/">Glib Library</a>
- <a href="xxx">GTlsDatabase PKCS#11 database</a>: Will use p11-kit to load PKCS#11 modules, and
- load configuration (In progress).</li>
- <li><a href="http://library.gnome.org/devel/gck/unstable/">Gck Library</a>: Use p11-kit to load
- and enumerate PKCS#11 modules. Use p11-kit to parse PKCS#11 URIs (In progress).</li>
- <li><a href="http://library.gnome.org/devel/gcr/unstable/">Gcr Library</a>: Use p11-kit to load
- configuration for looking up and storing trust assertions (In progress).</li>
-</ul>
-
-<h2>Documentation</h2>
-
-<ul>
- <li><a href="http://p11-glue.freedesktop.org/doc/p11-kit/">All Documentation</a></li>
- <li><a href="http://p11-glue.freedesktop.org/doc/p11-kit/reference.html">API Reference</a></li>
-</ul>
-
-<h2>Source Code</h2>
-
-<p>The source code releases are available for download here:<br>
-<a href="http://p11-glue.freedesktop.org/releases/">http://p11-glue.freedesktop.org/releases/</a></p>
-
-<p>The source code is available via git, or <a href="http://cgit.freedesktop.org/p11-glue/p11-kit/">browseable online</a>.</p>
-
-<pre>
-$ git clone git://anongit.freedesktop.org/p11-glue/p11-kit
-</pre>
-
-<h2>Contributing</h2>
-
-<ul>
- <li>Mailing list:
- <a href="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</a></li>
- <li>Bugs:
- <a href="https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue">bugs.freedesktop.org</a></li>
- <li>Guide to - <a href="http://p11-glue.freedesktop.org/doc/p11-kit/devel.html">building, contributor and packaging</a>.</li> -</ul>
-
-{% endblock %}
diff --git a/website/pkcs11-support.html.tmpl b/website/pkcs11-support.html.tmpl deleted file mode 100644 index f7296fa..0000000 --- a/website/pkcs11-support.html.tmpl +++ /dev/null @@ -1,52 +0,0 @@ -{% extends "base.incl" %}
-
-{% block title %}PKCS#11 Support{% endblock %}
-
-{% block content %}
-<h1>PKCS#11 Support</h1>
-
-<p>This project is all about using providing the glue so that different crypto
-libraries and apps can provide consistent experience for users and developers.
-This is possible because PKCS#11 is supported by so many applications.</p>
-
-<p>The support for PKCS#11 is not obviously not consistent across the board,
-but that will improve as PKCS#11 becomes more used.</p>
-
-<p>Here is an incomplete list (a-z):</p>
-
-<h2>Libraries</h2>
-
-<ul>
- <li><a href="http://live.gnome.org/GnomeKeyring">Gnome Keyring</a></li>
- <li><a href="http://www.gnu.org/software/gnutls/">GnuTLS</a></li>
- <li><a href="http://download.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html">Java</a></li>
- <li><a href="http://www.mozilla.org/projects/security/pki/nss/">Mozilla NSS</a></li>
- <li><a href="http://opensc-project.org/">OpenSC</a></li>
- <li><a href="http://www.opensc-project.org/pam_pkcs11/">PAM</a></li>
- <li><a href="http://delta.affinix.com/qca/">QCA</a></li>
- <li><a href="http://download.oracle.com/docs/cd/E19120-01/open.solaris/819-2145/6n4f2qhp3/index.html">Solaris</a></li>
-</ul>
-
-<h2>Applications</h2>
-
-<ul>
- <li><a href="http://live.gnome.org/Empathy">Empathy</a></li>
- <li><a href="http://projects.gnome.org/evolution/">Evolution</a></li>
- <li><a href="http://www.mozilla.com/en-US/firefox/new/">Firefox</a></li>
- <li><a href="http://www.google.com/chrome">Google Chrome</a></li>
- <li><a href="http://www.openssh.com/">OpenSSH</a></li>
- <li><a href="http://openvpn.net/">OpenVPN</a></li>
- <li><a href="http://subversion.tigris.org/">Subversion</a></li>
- <li><a href="http://www.strongswan.org/">Strong Swan</a></li>
- <li><a href="http://www.mozillamessaging.com/en-US/thunderbird/">Thunderbird</a></li>
- <li><a href="http://www.truecrypt.org/">Truecrypt</a></li>
-</ul>
-
-<h2>Patched or in Progress</h2>
-
-<ul>
- <li><a href="http://library.gnome.org/devel/glib/">Glib</a></li>
- <li><a href="http://www.opensc-project.org/engine_pkcs11/">OpenSSL</a></li>
-</ul>
-
-{% endblock %}
diff --git a/website/pkcs11-uris.html.tmpl b/website/pkcs11-uris.html.tmpl deleted file mode 100644 index 2077bb5..0000000 --- a/website/pkcs11-uris.html.tmpl +++ /dev/null @@ -1,42 +0,0 @@ -{% extends "base.incl" %}
-
-{% block title %}PKCS#11 URIs{% endblock %}
-
-{% block content %}
-<h1>Spec: PKCS#11 URIs</h1>
-
-<p>PKCS#11 URIs are a way to identify a certain
-crypto object that resides in a PKCS#11 module. These URIs can be used in
-configuration files, or when one application needs to refer another to a
-cryptographic object, like a key or a certificate.</p>
-
-<p>A PKCS#11 URI looks like:</p>
-
-<pre>
-pkcs11:token=The%20Software%20PKCS#11%20softtoken;object=my-certificate;
- objecttype=cert;id=%69%95%3e%5c%f4%bd%ec%91
-</pre>
-
-<h2>Implementations and Integration</h2>
-
-<ul>
- <li><a href="http://www.gnu.org/software/gnutls/">GnuTLS</a>:
- <a href="http://www.gnu.org/software/gnutls/manual/gnutls.html#PKCS-_002311-tokens">Used to lookup</a>
- certificate and key objects.
- <li><a href="http://people.collabora.co.uk/~stefw/gck-docs/">Gck library</a>: API for
- <a href="http://people.collabora.co.uk/~stefw/gck-docs/gck-PKCS11-URIs.html">parsing and building</a>
- PKCS#11 URIs</li>
- <li><a href="p11-kit.html">p11-kit</a>: Used in configuration. Also has
- <a href="http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-URIs.html">an API</a> for
- parsing and building PKCS#11 URIs</li>
-</ul>
-
-<h2>Specification</h2>
-
-<ul>
- <li>An IETF RFC Draft: <a href="http://tools.ietf.org/html/draft-pechanec-pkcs11uri-03">draft-pechanec-pkcs11uri</a></li>
- <li>Discussion: <a href="https://www.ietf.org/mailman/listinfo/saag">saag@ietf.org</a></li>
- <li>Authors: J. Pechanec, D. Moffat</li>
-</ul>
-
-{% endblock %}
diff --git a/website/revocation-cache.html.tmpl b/website/revocation-cache.html.tmpl deleted file mode 100644 index 6fcd78a..0000000 --- a/website/revocation-cache.html.tmpl +++ /dev/null @@ -1,38 +0,0 @@ -{% extends "base.incl" %} - -{% block title %}Common Revocation Lists{% endblock %} - -{% block content %} -<h1>Project: Common Revocation Lists</h1> - -<p>This is a cache of OSCP responses (via a proxy) and CRLs (via a PKCS#11 -module) so applications and crypto libraries can share their queries and -responses as desired.</p> - -<p>Rather than each application or library downloading and caching their own -copy of the CRLs, this module and accompanying daemon, keeps track of and -updates CRLs. Applications then access this information in a consistent -manner.</p> - -<h2>Documentation</h2> - -<p>Still in proposal/conceptual stages.</p> - -<h2>Source Repository</h2> - -<p>No source available yet.</p> - -<h2>Implementations and Integration</h2> - -<p>Still being planned.</p> - -<h2>Contributing</h2> - -<ul> - <li>Mailing list: - <a href="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</a></li> - <li>Bugs: - <a href="https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue">bugs.freedesktop.org</a></li> -</ul> - -{% endblock %} diff --git a/website/sharing-trust-policy.html.tmpl b/website/sharing-trust-policy.html.tmpl deleted file mode 100644 index aa6a6c7..0000000 --- a/website/sharing-trust-policy.html.tmpl +++ /dev/null @@ -1,32 +0,0 @@ -{% extends "base.incl" %} - -{% block title %}p11-kit{% endblock %} - -{% block content %} -<h1>Spec: Sharing Trust Policy</h1> - -<p>Various crypto libraries have various ways to represent and store information -about which Certificate Authorities are to be used as trust anchors. They also -have different ways to represent certificates that are blacklisted.</p> - -<p>This has led to a poor experience and a lack of coherency on Linux when it -comes to validating certificates.</p> - -<p>This is an effort to define a standard way to represent trust policy, anchor -certificates and black lists. These should be represented in a coherent and -future-proof manner. The outlined solution, in addition to be an extensible concept, -is relatively easy to implement and retrofit into existing code.</p> - -<p><a href="/doc/storing-trust-policy/">The specification document</a> is in a -state of early construction.</p> - -<h2>Contributing</h2> - -<ul> - <li>Mailing list: - <a href="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</a></li> - <li>Bugs: - <a href="https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue">bugs.freedesktop.org</a></li> -</ul> - -{% endblock %} diff --git a/website/style.css b/website/style.css deleted file mode 100644 index 8995b6b..0000000 --- a/website/style.css +++ /dev/null @@ -1,484 +0,0 @@ - -/* -Design by Free CSS Templates -http://www.freecsstemplates.org -Released for free under a Creative Commons Attribution 2.5 License -*/ - -body { - margin: 0px; - padding: 0; - background: #F3F2ED url(images/img04.jpg) repeat-x left top; - font-family: Verdana, Arial, 'Bitstream Vera Sans', Helvetica, sans-serif; - font-size: 13px; - color: #464646; -} - -h1, h2, h3 { - margin: 0; - font-weight: normal; -} - -h1 { font-size: 20px; } - -h2 { font-size: 18px; } - -h3 { } - -p, ul, ol { - margin-top: 0; - line-height: 200%; -} - -ul, ol { } - -blockquote { } - -a { color: #D99821; } - -a:hover { text-decoration: none; } - -a img { - border: none; -} - -img.left { - float: left; - margin: 7px 30px 0 0; -} - -img.right { - float: right; - margin: 7px 0 0 30px; -} - -img.center { - margin-left: auto; - margin-right: auto; -} - -hr { display: none; } - -.list1 { -} - -.list1 li { - float: left; - line-height: normal; -} - -.list1 li img { - margin: 0 30px 30px 0; -} - -.list1 li.alt img { - margin-right: 0; -} - -#wrapper { -} - -/* Header */ - -#header-wrapper { - height: 60px; - background: #131313; -} - -#header { - width: 790px; - margin: 0 auto; -} - -/* Menu */ - -#menu { - float: left; - width: 400px; -} - -#menu ul { - margin: 0; - padding: 8px 0px 0px 0px; - list-style: none; - line-height: normal; -} - -#menu li { - background: url(images/img01.jpg) no-repeat left 10px; - display: block; - float: left; -} - -#menu a { - display: block; - float: left; - height: 32px; - padding: 14px 20px 0px 20px; - letter-spacing: -1px; - text-decoration: none; - text-align: center; - text-transform: lowercase; - font-family: Verdana, Arial, 'Bitstream Vera Sans', Helvetica, sans-serif; - font-size: 12px; - font-weight: normal; - color: #FFFFFF; -} - -#menu a:hover { - text-decoration: none; -} - -#menu .current_page_item a { -} - -#menu .first { -} -/* Search */ - -#search { - float: right; - padding: 10px 10px 0px 0px; -} - -#search form { - float: right; - margin: 0; - padding: 4px 0px 0 0; -} - -#search fieldset { - margin: 0; - padding: 0; - border: none; -} - -#search input { - float: left; - font: 12px Georgia, "Times New Roman", Times, serif; -} - -#search-text { - width: 213px; - height: 28px; - padding: 6px 0 0 7px; - border: none; - background: url(images/img02.jpg) no-repeat left top; - color: #000000; -} - -#search-submit { - width: 82px; - height: 28px; - margin-left: 10px; - padding: 0px 5px; - background: url(images/img03.jpg) no-repeat left top; - border: none; - text-indent: -9999px; - color: #FFFFFF; -} - -/* Page */ - -#page { - width: 850px; - margin: 0px auto; - margin: 0 auto; - background: #FFFFFF url(images/img06.jpg) repeat-y left 20px; -} - -#page-bgtop { - width: 770px; - margin: 0px auto; - padding: 25px 40px; - background: url(images/img05.jpg) no-repeat left top; -} - - -/** LOGO */ - -#logo { - width: 790px; - height: 97px; - margin: 0 auto; - padding-top: 20px; - padding-left: 20px; -} - -#logo h1, #logo p { - margin: 0px; - line-height: normal; - text-transform: lowercase; - font-weight: normal; - color: #FFFFFF; -} - -#logo p { - margin-top: -4px; - text-transform: lowercase; - font-family: Georgia, "Times New Roman", Times, serif; - font-size: 13px; - color: #FFFFFF; -} - -#logo h1 { - font-family: Georgia, "Times New Roman", Times, serif; - font-size: 48px; -} - -#logo a { - text-decoration: none; - color: #FFFFFF; -} - -#banner { - padding-bottom: 20px; -} - -/* Content */ - -#content { - width: 510px; -} - -#content h1 { - margin-top: 0; - margin-bottom: 5pt; -} - -#content h2 { - padding-top: 10pt; - margin-bottom: 5pt; -} - -/* Post */ - -.post { - margin-bottom: 45px; - padding-bottom: 30px; - border-bottom: 1px solid #E0E0E0; -} - -.post .title { - height: 44px; -} - -.post .title a { - text-decoration: none; - text-transform: capitalize; - font-size: 30px; - color: #2E2E2E; -} - -.post .date { - display: inline-block; - background: #454545; - margin: 0px; - padding: 0px 10px; - color: #FFFFFF; -} - -.post .meta { - margin-left: 2px; - padding: 4px 30px 2px 0px; - font-family: Verdana, Arial, 'Bitstream Vera Sans', Helvetica, sans-serif; - font-weight: normal; - font-size: 10px; - color: #66665E; -} - -.post .meta span { - margin: 0px; -} - -.post .meta a { - padding: 6px 10px 5px 10px; - background: #454545; - text-decoration: none; - color: #FFFFFF; -} - -.post .entry { - padding: 10px 0px 20px 0px; -} - -.post .links { - height: 18px; - margin: 0px 0px 4px 0px; - padding: 6px 10px 5px 10px; - background: #454545; - text-decoration: none; - font-family: Verdana, Arial, 'Bitstream Vera Sans', Helvetica, sans-serif; - font-size: 11px; - text-decoration: none; - font-weight: bold; - color: #FFFFFF; -} - -.post .comments { - display: block; - width: 120px; - height: 18px; - margin: 0px; - padding: 3px 0px 0px 40px; - background: #90BF35; - border: 1px solid #5F817E; - text-decoration: none; - font-family: Verdana, Arial, 'Bitstream Vera Sans', Helvetica, sans-serif; - font-size: 11px; - text-decoration: none; - font-weight: bold; - color: #FFFFFF; -} - -/* Sidebar */ - -#sidebar { - float: right; - width: 250px; - font-family: Verdana, Arial, 'Bitstream Vera Sans', Helvetica, sans-serif; - font-size: 12px; - padding-left: 20px; -} - -#sidebar ul { - margin: 0; - padding: 0; - list-style: none; - line-height: normal; -} - -#sidebar li { - margin-bottom: 10px; - padding: 0 0 5px 0px; -} - -#sidebar li ul { - margin: 0px 0px; - border-left: 5px solid #E0E0E0; -} - -#sidebar li li { - margin: 0px 0px 0px 20px; - padding: 10px 0px 10px 0px; - border-bottom: 1px solid #E0E0E0; -} - -#sidebar li li a { - font-weight: normal; -} - -#sidebar li li a:hover { - color: #666666; -} - -#sidebar p { - margin: 0; - padding: 0px 0px 0px 19px; -} - -#sidebar h2 { - height: 30px; - margin: 0 0 5px 0px; - padding: 6px 0 2px 0px; - text-transform: capitalize; - font-size: 18px; - font-weight: normal; - color: #2E2E2E; -} - - -#sidebar p { - line-height: 200%; -} - -#sidebar h2 a { - text-align: left; - text-decoration: none; - color: #875a00; -} - -/* Calendar */ - -#calendar { -} - -#calendar caption { - padding-bottom: 5px; - font-weight: bold; -} - -#calendar table { - width: 100%; - border-collapse: collapse; - border-bottom: 1px solid #24130F; - border-left: 1px solid #24130F; - border-right: 1px solid #24130F; -} - -#calendar thead th { - padding: 5px 0; - text-align: center; - border-top: 1px solid #24130F; - border-left: 1px solid #24130F; - background: #24130F; -} - -#calendar tbody td { - padding: 5px 0; - text-align: center; - border-top: 1px solid #24130F; - border-left: 1px solid #24130F; - border-bottom: 1px solid #24130F; -} - -#calendar tfoot td { - padding: 5px; - border-left: 1px solid #24130F; - border-bottom: 1px solid #24130F; -} - -#calendar tfoot #next { - border-top: 1px solid #24130F; - text-align: right; -} - -#calendar tfoot #prev { - border-top: 1px solid #24130F; -} - -#calendar .pad { - border-bottom: 1px solid #24130F; -} - -#calendar #today { - background: #24130F; -} - -/* Footer */ - -#footer { - width: 770px; - height: 100px; - margin: 0 auto; - padding: 0; - border-top: 1px solid #E0E0E0; -} - -#footer-bgcontent { -} - -#footer p { - margin: 0; - padding: 30px 0px 0px 0px; - text-align: center; - line-height: normal; - font-size: 12px; -} - -#footer a { -} - -br.clear { - clear: both; -} diff --git a/website/system-module.html.tmpl b/website/system-module.html.tmpl deleted file mode 100644 index a3683ca..0000000 --- a/website/system-module.html.tmpl +++ /dev/null @@ -1,10 +0,0 @@ -{% extends "base.incl" %} - -{% block title %}System Storage Module{% endblock %} - -{% block content %} -<h1>Project: System Storage Module</h1> - -<p>This has been renamed the <a href="trust-module.html">Trust Storage Module</a>.</p> - -{% endblock %} diff --git a/website/trust-assertions.html.tmpl b/website/trust-assertions.html.tmpl deleted file mode 100644 index ff98687..0000000 --- a/website/trust-assertions.html.tmpl +++ /dev/null @@ -1,76 +0,0 @@ -{% extends "base.incl" %} - -{% block title %}p11-kit{% endblock %} - -{% block content %} -<h1>Spec: Trust Assertions</h1> - -<p><b>Note:</b> Trust assertions were a conceptual way to share trust -information. They have been withdrawn as a solution worth gathering around. -The current discussion is directed towards -<a href="/doc/storing-trust-policy/">Storing Trust Policy</a>.</p> - -<h3>The following remains here for historical reference.</h3> - -<p>A trust assertion represents a single piece of information about the user's -or system's trust preferences. These can be used to make consistent trust -decisions.<p> - -<p><a href="/doc/pkcs11-trust-assertions">There's a specification</a> for how -trust assertions work, and how they can be stored within PKCS#11.</p> - -<p>NSS uses similar method of storing trust information, called -<a href="https://developer.mozilla.org/en/NSS/PKCS_%2311_Netscape_Trust">Trust Objects</a>, -which were studied as part of this research. But they had too many drawbacks to -make them the candidate for adoption as a 'glue' mechanism.</p> - -<p>However implementors of trust assertions can easily support NSS-style trust -objects at the same time. Gnome Keyring for example does this.</p> - -<h2>Documentation</h2> - -<ul> - <li>Specification draft: <a href="/doc/pkcs11-trust-assertions">pkcs11-trust-assertions</a></li> - <li>Header: <a href="/doc/pkcs11-trust-assertions/pkcs11-trust-assertions.h">pkcs11-trust-assertions.h</a></li> - <li>Talk by Stef Walter: <a href="#">Video</a> | - <a href="https://www.opensc-project.org/opensc/attachment/wiki/FOSDEM2011/trust-assertion-notes.ps">Slides</a></li> -</ul> - -<h2>Source Repository</h2> - -<p>The source code is available via git.</p> - -<pre> -$ git clone git://anongit.freedesktop.org/p11-glue/pkcs11-trust-assertions -</pre> - -<h2>Implementations and Integration</h2> - -<ul> - <li><a href="http://live.gnome.org/GnomeKeyring">Gnome Keyring's</a> - <a href="http://git.gnome.org/browse/gnome-keyring/tree/pkcs11/xdg-store">xdg-store module</a>: - Storage trust assertions via PKCS#11.</li> - <li><a href="http://library.gnome.org/devel/gcr/unstable/">Gcr library</a> - <a href="http://library.gnome.org/devel/gcr/unstable/gcr-Trust-Storage-and-Lookups.html">trust lookup/store functions</a>: - Helper functions for storing and looking up trust assertions via PKCS#11.</li> - <li><a href="http://library.gnome.org/devel/glib/">Glib Library</a> - <a href="http://git.gnome.org/browse/glib/log/?h=tls-database">GTlsDatabase PKCS#11 database</a>: - Will use trust assertions to lookup root anchor certificates, and pinned certificates (In progress).</li> - <li><a href="http://live.gnome.org/Empathy">Empathy</a>: - Uses trust assertions to lookup trust anchor certificates, and store pinned certificates.</li> - <li><a href="revocation-cache.html">CRL PKCS#11 Module</a>: (Planned) - </li> - <li><a href="system module.html">System Certificates Module</a>: (Planned) - </li> -</ul> - -<h2>Contributing</h2> - -<ul> - <li>Mailing list: - <a href="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</a></li> - <li>Bugs: - <a href="https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue">bugs.freedesktop.org</a></li> -</ul> - -{% endblock %} diff --git a/website/trust-module.html.tmpl b/website/trust-module.html.tmpl deleted file mode 100644 index 570ea84..0000000 --- a/website/trust-module.html.tmpl +++ /dev/null @@ -1,99 +0,0 @@ -{% extends "base.incl" %} - -{% block title %}Trust Storage Module{% endblock %} - -{% block content %} -<h1>Project: Trust Storage Module</h1> - -<p>This is a PKCS#11 module that exposes read-only storage of system -certificates and trust policy. It loads the certificates and trust -storage from a directory of files.</p> - -<p>Crypto libraries are able to use this as a shared source of certificate -authority anchors, black lists, and other locally stored system trust policy.</p> - -<p>There is work going on to define a comprehensive representation of -this <a href="sharing-trust-policy.html">shared trust policy</a>. Once such a -solution matures we hope to implement it in this PKCS#11 trust storage module.</p> - -<p>Also included is a tool called <tt>p11-kit extract-trust</tt> that can be used -to extract certificates anchors with trust information in various formats for -crypto libraries not (or not yet) able to read from this PKCS#11 trust module -directly.</p> - -<p>A goal is to have minimal dependencies, and be crypto library agnostic so this -can be used by any library or app. Accesses information owned by root and configured -by a system administrator or distro creator. These PKCS#11 objects are read-only -and so don't need to go through a coordinating daemon. Thus we can implement an -efficient, reliable lookup for these system certs and other objects, with less -moving parts.</p> - -<h2>Source Repository</h2> - -<p>Code has been merged into the main p11-kit repository, and is found in -the <tt>trust/</tt> subdirectory. The extract code is found in the <tt>tools</tt> -subdirectory:</p> - -<pre> -$ git clone git://anongit.freedesktop.org/p11-glue/p11-kit -$ cd p11-kit -$ cd trust/ -</pre> - -<h2>Status</h2> - -<p>An implementation of the module is available, and you can try it out. A dependency -on libtasn1-devel is required to build the PKCS#11 trust module. The extract -tool is also implemented.</p> - -<pre> -$ sh autogen.sh --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib64 --enable-debug \ - --with-system-anchors=/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/anchors -$ make -$ sudo make install -$ sudo mv -v /usr/lib64/libnssckbi.so /opt/libnssckbi.so.orig-nss -$ sudo ln -sv pkcs11/p11-kit-trust.so /usr/lib64/libnssckbi.so -</pre> - -<p>Now place some certificates in the <tt>--with-system-anchors</tt> location(s). -Right now, as input, you can use DER, PEM or OpenSSL style 'trusted -certificates'.</p> - -<p>For example you can tweak some trust policy bits like so:</p> - -<pre> -$ openssl x509 -addtrust serverAuth -addreject clientAuth \ - -in /path/to/my-ca.pem -out /etc/pki/tls/certs/anchors/my-ca.pem -</pre> - -<p>Now you can run apps like Firefox and see the certificates appear in the -Certificate manager and are trusted as appropriate. You can use a command like -this to see some debug output:</p> - -<pre> -$ P11_KIT_DEBUG=all firefox -</pre> - -<p>Run the extraction tool, and/or customize it:</p> - -<pre> -$ p11-kit extract-trust -</pre> - -<h2>Documentation</h2> - -<ul> - <li><a href="http://p11-glue.freedesktop.org/doc/p11-kit/trust.html">Trust policy module documentation</a></li> - <li><a href="http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit.html">Extract tool documentation</a></li> -</ul> - -<h2>Contributing</h2> - -<ul> - <li>Mailing list: - <a href="http://lists.freedesktop.org/mailman/listinfo/p11-glue">p11-glue@lists.freedesktop.org</a></li> - <li>Bugs: - <a href="https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue">bugs.freedesktop.org</a></li> -</ul> - -{% endblock %} |
