diff options
Diffstat (limited to 'specs/draft-pkcs11-trust-assertions.txt')
| -rw-r--r-- | specs/draft-pkcs11-trust-assertions.txt | 560 |
1 files changed, 0 insertions, 560 deletions
diff --git a/specs/draft-pkcs11-trust-assertions.txt b/specs/draft-pkcs11-trust-assertions.txt deleted file mode 100644 index 04fdb48..0000000 --- a/specs/draft-pkcs11-trust-assertions.txt +++ /dev/null @@ -1,560 +0,0 @@ - - - -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] - |