diff options
Diffstat (limited to 'trust-assertions.xml')
| -rw-r--r-- | trust-assertions.xml | 30 |
1 files changed, 15 insertions, 15 deletions
diff --git a/trust-assertions.xml b/trust-assertions.xml index c12dd99..2535fb9 100644 --- a/trust-assertions.xml +++ b/trust-assertions.xml @@ -21,7 +21,7 @@ </authorgroup> </articleinfo> - <section> + <section id="introduction"> <title>Introduction</title> <para>Trust assertions are represent bits of trust information used by an @@ -52,7 +52,7 @@ for these other subjects.</para> </section> - <section> + <section id="trust-assertions"> <title>Trust Assertions</title> <para>A trust assertion is a generic concept. Each trust assertion describes a level @@ -129,7 +129,7 @@ </section> </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 @@ -154,7 +154,7 @@ lists. Therefore different methods must be used to refer to certificates in these different situations. The objects below reflect this.</para> - <section> + <section id="common-attributes"> <title>Common Trust Assertion Object Attributes</title> <para>First we describe the attributes that all trust assertion objects have in @@ -287,7 +287,7 @@ </table> </section> - <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 @@ -329,7 +329,7 @@ </section> - <section> + <section id="pinned-attributes"> <title>Pinned Certificate Assertion</title> <para>A pinned certificate is an endpoint certificate (not an authority) which is @@ -381,7 +381,7 @@ </section> - <section> + <section id="distrusted-attributes"> <title>Distrusted Certificate Assertion</title> <para>An distrusted certificate is a trust assertion which signifies the explicit @@ -428,10 +428,10 @@ </section> </section> - <section> + <section id="operations"> <title>Operations</title> - <section> + <section id="operation-build-chain"> <title>Building a Certificate Chain</title> <para>During TLS or other certificate verification operations, a @@ -536,12 +536,12 @@ </section> </section> - <section> + <section id="justifications"> <title>Justifications</title> <para>Some answers to why this spec was designed as it is.</para> - <section> + <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>. @@ -554,7 +554,7 @@ that is not dependent on the long term viability of a specific hash algorithm.</para> </section> - <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> @@ -567,7 +567,7 @@ of referencing certificates in negative trust assertions.</para> </section> - <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. @@ -599,7 +599,7 @@ </itemizedlist> </section> - <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> @@ -613,7 +613,7 @@ hash thereof.</para> </section> - <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>. |