summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStef Walter <stef@thewalter.net>2010-12-12 14:54:26 +0000
committerStef Walter <stefw@collabora.co.uk>2013-01-02 09:04:08 +0100
commite69041035c1df1eb3f1286217dbacf018bd4fd6a (patch)
tree5660ce95f959374561450657773b921470a53f32
parenteb8968574777979d53c8b9a8b2f021cb054e0b4d (diff)
Add justification about PKCS#11 URIs
-rw-r--r--specs/trust-assertions.xml15
1 files changed, 15 insertions, 0 deletions
diff --git a/specs/trust-assertions.xml b/specs/trust-assertions.xml
index 6a7e4a6..b8cba93 100644
--- a/specs/trust-assertions.xml
+++ b/specs/trust-assertions.xml
@@ -593,6 +593,21 @@
object leading to more complex lookup and modification operations.</para></listitem>
</itemizedlist>
</section>
+
+ <section>
+ <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>
</article>