summaryrefslogtreecommitdiff
path: root/draft-pkcs11-trust-assertions.txt
diff options
context:
space:
mode:
Diffstat (limited to 'draft-pkcs11-trust-assertions.txt')
-rw-r--r--draft-pkcs11-trust-assertions.txt560
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]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 11:37:50 +0000