Add the text file so I can link to it

1 files changed, 560 insertions, 0 deletions

diff --git a/draft-pkcs11-trust-assertions.txt b/draft-pkcs11-trust-assertions.txt
new file mode 100644
index 0000000..04fdb48
--- /dev/null
+++ b/draft-pkcs11-trust-assertions.txt
@@ -0,0 +1,560 @@
+
+
+
+Internet Engineering Task Force                           S. Walter, Ed.
+Internet-Draft                                                     GNOME
+Intended status: BCP                                      September 2010
+Expires: March 5, 2011
+
+
+              Storing Trust Assertions in PKCS#11 Modules
+                       draft-walter-pkcs11-trust
+
+Abstract
+
+   PKCS#11 is a standard that defines ways to store certificates, keys
+   and perform crypto operations.  It does not specify a way to store
+   trust assertions.
+
+   Trust assertions are used to assign an explicit level of trust to a
+   certificate.  Examples of trust assertions are certificate authority
+   root certificates, certificate revocation lists, and certificate
+   trust exceptions.
+
+   This document outlines a way to store trust assertions with PKCS#11.
+   This is not a new design, but documentation of the method already in
+   use by libraries such as NSS.
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on March 5, 2011.
+
+
+
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 1]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  PKCS#11 Primer . . . . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Trust Assertions . . . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Level of Trust . . . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  Usage or Purpose . . . . . . . . . . . . . . . . . . . . .  4
+     2.3.  Certificate Reference  . . . . . . . . . . . . . . . . . .  4
+   3.  PKCS#11 Trust Assertion Objects  . . . . . . . . . . . . . . .  4
+   4.  Operations . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.1.  Checking Trust Assertions  . . . . . . . . . . . . . . . .  7
+       4.1.1.  Checking a Root Certificate Authority  . . . . . . . .  7
+       4.1.2.  Checking a Self-Signed Certificate . . . . . . . . . .  8
+       4.1.3.  Checking an otherwise Trusted Certificate  . . . . . .  8
+     4.2.  Storing Trust Assertions . . . . . . . . . . . . . . . . .  8
+     4.3.  Reading Trust Assertions . . . . . . . . . . . . . . . . .  8
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Further Considerations . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
+   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . .  9
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   Intellectual Property and Copyright Statements . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 2]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+1.  Introduction
+
+   PKCS#11 is a useful and widely supported standard for storage and use
+   of keys and certificates.  It is often used with smart cards.
+
+1.1.  PKCS#11 Primer
+
+   Xxxx
+
+1.2.  Terminology
+
+   Xxxxx
+
+   Xxxx The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC 2119.
+
+
+2.  Trust Assertions
+
+   A trust assertion describes a level of trust in an object for a given
+   usage or purpose.  Conceptually each trust assertion is a triple
+   containing:
+
+   o  Certificate Reference
+
+   o  Usage or Purpose
+
+   o  Level of Trust
+
+   We examine each of these parts of the triple in further detail below.
+
+2.1.  Level of Trust
+
+   A trust assertion ultimately denotes a level of trust.  These are:
+
+   o  Untrusted: The certificate is explicitly untrusted.
+
+   o  Unknown: The trust is not known and should be determined
+      elsewhere.
+
+   o  Trusted: The certificate itself is explicitly trusted.
+
+   o  Trusted Delegator: The certificate is trusted as a certificate
+      authority trust root.  Trust is confers to certificates that this
+      certificate has signed, or signed certificates have signed, and so
+      on.
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 3]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+2.2.  Usage or Purpose
+
+   A trust assertion always refers to a specific purpose or usage.  A
+   certificate may be trusted for purposes like: email, code signing,
+   authenticating a server.
+
+2.3.  Certificate Reference
+
+   Each trust assertion contains a reference to a certificate.
+
+   There are two ways to refer to a certificate depending on whether
+   that certificate is self-signed (like a certificate authority) or
+   signed by another trusted certificate.
+
+   Self-signed certificates are referred to by their complete hash of
+   the DER value of the certificate.
+
+   Certificates signed by another certificate are referred to by the DER
+   value of the issuer field, and the serial number.
+
+   Referring to a self-signed certificate by its issuer and serial
+   number is meaningless.
+
+   Referring to a signed certificate by its hash, would preclude uses
+   such as certificate relocation lists, which do not contain
+   certificates or enough information to generate a hash.
+
+   Therefore different methods MUST be used to refer to self-signed and
+   issuer-signed certificates.
+
+
+3.  PKCS#11 Trust Assertion Objects
+
+   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.  Trust assertions objects are of
+   the class CKO_NETSCAPE_TRUST and have the following attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 4]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+                         Trust object attributes.
+
+   +----------------------------+-----------------+--------------------+
+   | Attribute                  | Type            | Description        |
+   +----------------------------+-----------------+--------------------+
+   | CKA_CLASS                  | CK_OBJECT_CLASS | CKO_NETSCAPE_TRUST |
+   +----------------------------+-----------------+--------------------+
+   | CKA_ISSUER                 | Byte array      | DER-encoding of    |
+   |                            |                 | the certificate    |
+   |                            |                 | issuer name        |
+   +----------------------------+-----------------+--------------------+
+   | CKA_SUBJECT                | Byte array      | DER-encoding of    |
+   |                            |                 | the certificate    |
+   |                            |                 | subject name.      |
+   |                            |                 | Optional, default  |
+   |                            |                 | empty              |
+   +----------------------------+-----------------+--------------------+
+   | CKA_SERIAL_NUMBER          | Byte array      | DER-encoding of    |
+   |                            |                 | the certificate    |
+   |                            |                 | serial number      |
+   +----------------------------+-----------------+--------------------+
+   | CKA_CERT_SHA1_HASH         | Byte array      | SHA1 hash of the   |
+   |                            |                 | the DER-encoding   |
+   |                            |                 | of certificate.    |
+   |                            |                 | Required for       |
+   |                            |                 | self-signed        |
+   |                            |                 | certificates.      |
+   +----------------------------+-----------------+--------------------+
+   | CKA_CERT_MD5_HASH          | Byte array      | MD5 hash of the    |
+   |                            |                 | the DER-encoding   |
+   |                            |                 | of certificate.    |
+   |                            |                 | Required for       |
+   |                            |                 | self-signed        |
+   |                            |                 | certificates.      |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_SERVER_AUTH      | CK_TRUST        | Level of trust for |
+   |                            |                 | server             |
+   |                            |                 | authentication     |
+   |                            |                 | extended usage.    |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_CLIENT_AUTH      | CK_TRUST        | Level of trust for |
+   |                            |                 | client             |
+   |                            |                 | authentication     |
+   |                            |                 | extended usage.    |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_CODE_SIGNING     | CK_TRUST        | Level of trust for |
+   |                            |                 | code signing       |
+   |                            |                 | extended usage.    |
+
+
+
+Walter                    Expires March 5, 2011                 [Page 5]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+   | CKA_TRUST_EMAIL_PROTECTION | CK_TRUST        | Level of trust for |
+   |                            |                 | email protection   |
+   |                            |                 | extended usage.    |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_IPSEC_END_SYSTEM | CK_TRUST        | Level of trust for |
+   |                            |                 | IPSEC end system   |
+   |                            |                 | extended usage.    |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_IPSEC_TUNNEL     | CK_TRUST        | Level of trust for |
+   |                            |                 | IPSEC tunnel       |
+   |                            |                 | extended usage.    |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_IPSEC_USER       | CK_TRUST        | Level of trust for |
+   |                            |                 | IPSEC user         |
+   |                            |                 | extended usage.    |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_TIME_STAMPING    | CK_TRUST        | Level of trust for |
+   |                            |                 | IPSEC time         |
+   |                            |                 | stamping extended  |
+   |                            |                 | usage.             |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_DIGITAL_SIGNATUR | CK_TRUST        | Level of trust for |
+   | E                          |                 | digital signature  |
+   |                            |                 | key usage.         |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_NON_REPUDIATION  | CK_TRUST        | Level of trust for |
+   |                            |                 | non-repudiation    |
+   |                            |                 | key usage.         |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_KEY_ENCIPHERMENT | CK_TRUST        | Level of trust for |
+   |                            |                 | key-encipherment   |
+   |                            |                 | key usage.         |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_DATA_ENCIPHERMEN | CK_TRUST        | Level of trust for |
+   | T                          |                 | data-encipherment  |
+   |                            |                 | key usage.         |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_KEY_AGREEMENT    | CK_TRUST        | Level of trust for |
+   |                            |                 | key-agreement key  |
+   |                            |                 | usage.             |
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_KEY_CERT_SIGN    | CK_TRUST        | Level of trust for |
+   |                            |                 | certificate        |
+   |                            |                 | signing key usage. |
+   +----------------------------+-----------------+--------------------+
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 6]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+   +----------------------------+-----------------+--------------------+
+   | CKA_TRUST_KEY_CRL_SIGN     | CK_TRUST        | Level of trust for |
+   |                            |                 | crl signing key    |
+   |                            |                 | usage.             |
+   +----------------------------+-----------------+--------------------+
+
+           Xxxx: Possible additional attributes: CKA_TRUST_TYPE
+          (CKT_CERTIFICATE_SELF_SIGNED, CKT_CERTIFICATE_SIGNED),
+                           CKA_CERT_SHA256_HASH
+
+                     Table 1: Trust Object Attributes
+
+                   CK_TRUST represenst a level of trust.
+
+   +-----------------------+-------------------------------------------+
+   | Value                 | Description                               |
+   +-----------------------+-------------------------------------------+
+   | CKT_UNTRUSTED         | Explicitly untrusted.                     |
+   | CKT_UNKNOWN           | Trust is unknown and should be determined |
+   |                       | elsewhere.                                |
+   | CKT_TRUSTED           | Explicitly trusts the certificate in the  |
+   |                       | assertion.                                |
+   | CKT_TRUSTED_DELEGATOR | Trusts the certificate as a certificate   |
+   |                       | authority.                                |
+   +-----------------------+-------------------------------------------+
+
+                         Table 2: CK_TRUST values
+
+
+4.  Operations
+
+4.1.  Checking Trust Assertions
+
+   Trust assertions are checked using a PKCS#11 C_FindObjects operation.
+
+   Because trust is involved and presence/lack of results is important,
+   this operation MUST be done with a specific set of lookup attributes.
+   The attributes used differ depending on whether the certificate is
+   self-signed or is signed by an issuer.
+
+   Checking of trust assertions is always done for a specific purpose.
+
+4.1.1.  Checking a Root Certificate Authority
+
+   A C_FindObjects operation is done using the following attributes.
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 7]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+      +--------------------+---------------------------------------+
+      | Attribute          | Value                                 |
+      +--------------------+---------------------------------------+
+      | CKA_CLASS          | CKO_NETSCAPE_TRUST                    |
+      | CKA_CERT_SHA1_HASH | 20 byte value of hash of certificate. |
+      | Purpose attribute  | CKT_TRUSTED_DELEGATOR                 |
+      +--------------------+---------------------------------------+
+
+4.1.2.  Checking a Self-Signed Certificate
+
+   A C_FindObjects operation is done using the following attributes.
+
+      +--------------------+---------------------------------------+
+      | Attribute          | Value                                 |
+      +--------------------+---------------------------------------+
+      | CKA_CLASS          | CKO_NETSCAPE_TRUST                    |
+      | CKA_CERT_SHA1_HASH | 20 byte value of hash of certificate. |
+      | Purpose attribute  | CKT_TRUSTED                           |
+      +--------------------+---------------------------------------+
+
+4.1.3.  Checking an otherwise Trusted Certificate
+
+   A C_FindObjects operation is done using the following attributes.
+
+    +-------------------+--------------------------------------------+
+    | Attribute         | Value                                      |
+    +-------------------+--------------------------------------------+
+    | CKA_CLASS         | CKO_NETSCAPE_TRUST                         |
+    | CKA_ISSUER        | DER encoding of certificate issuer.        |
+    | CKA_SERIAL_NUMBER | DER encoding of certificate serial number. |
+    | Purpose attribute | CKT_UNTRUSTED                              |
+    +-------------------+--------------------------------------------+
+
+4.2.  Storing Trust Assertions
+
+   Xxxx
+
+4.3.  Reading Trust Assertions
+
+   Xxxx
+
+
+5.  Acknowledgements
+
+   NSS: Who?
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 8]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+6.  Further Considerations
+
+   xxxx
+
+
+7.  Security Considerations
+
+   Xxxx: Use of multiple PKCS#11 modules
+
+   Not using just any module.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.
+
+8.2.  Informative References
+
+   [DOMINATION]
+              Mad Dominators, Inc., "Ultimate Plan for Taking Over the
+              World", 1984, <http://www.example.com/dominator.html>.
+
+
+Appendix A.  Additional Stuff
+
+   This becomes an Appendix.
+
+
+Author's Address
+
+   Stef Walter (editor)
+   GNOME
+
+   Phone: +1 505 926 1827
+   Email: stefw@gnome.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                 [Page 9]
+
+Internet-Draft          PKCS#11 Trust Assertions          September 2010
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2010).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+Walter                    Expires March 5, 2011                [Page 10]
+