From 76e037cf7f9949e6e76621e9c3ae8c12eea9cea3 Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Sat, 23 Oct 2010 22:42:33 +0000 Subject: Add the text file so I can link to it --- draft-pkcs11-trust-assertions.txt | 560 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 560 insertions(+) create mode 100644 draft-pkcs11-trust-assertions.txt 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, . + + +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] + -- cgit v1.2.3