From 0d9953a60407ce5b457a84df7bac00ac0b72230c Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Mon, 6 Dec 2010 18:30:54 +0000 Subject: Remove old RFC draft. --- Makefile | 5 +- draft-pkcs11-trust-assertions.txt | 560 ------- draft-pkcs11-trust-assertions.xml | 415 ----- rfc2629.dtd | 311 ---- rfc2629.xslt | 3001 ------------------------------------- 5 files changed, 1 insertion(+), 4291 deletions(-) delete mode 100644 draft-pkcs11-trust-assertions.txt delete mode 100644 draft-pkcs11-trust-assertions.xml delete mode 100644 rfc2629.dtd delete mode 100644 rfc2629.xslt diff --git a/Makefile b/Makefile index ddaa252..24dfe43 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,4 @@ -all: draft-pkcs11-trust-assertions.txt html/index.html - -draft-pkcs11-trust-assertions.txt: draft-pkcs11-trust-assertions.xml - xml2rfc $< +all: html/index.html html/index.html: docbook-params.xsl trust-assertions.xml xmlto --skip-validation -o html/ -x docbook-params.xsl xhtml trust-assertions.xml diff --git a/draft-pkcs11-trust-assertions.txt b/draft-pkcs11-trust-assertions.txt deleted file mode 100644 index 04fdb48..0000000 --- a/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, . - - -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] - diff --git a/draft-pkcs11-trust-assertions.xml b/draft-pkcs11-trust-assertions.xml deleted file mode 100644 index 1cfe38a..0000000 --- a/draft-pkcs11-trust-assertions.xml +++ /dev/null @@ -1,415 +0,0 @@ - - - - - - - - - - - - - - - Storing Trust Assertions in PKCS#11 Modules - - - GNOME - -
- - - +1 505 926 1827 - stefw@gnome.org - -
- - - - - General - - Internet Engineering Task Force - - security - pkcs11 - trust - x509 - certificate - pki - - - 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. - - - - -
- PKCS#11 is a useful and widely supported standard for storage and use - of keys and certificates. It is often used with smart cards. - -
- Xxxx -
- -
- 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. -
- -
- -
- 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: - - - Certificate Reference - - Usage or Purpose - - Level of Trust - - - We examine each of these parts of the triple in further detail below. - -
- A trust assertion ultimately denotes a level of trust. These are: - - Untrusted: The certificate is explicitly untrusted. - - Unknown: The trust is not known and should be determined elsewhere. - - Trusted: The certificate itself is explicitly trusted. - - 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. - -
- -
- 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. -
- -
- 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. -
-
- -
- - 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. - - - 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. - - 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_SIGNATURE - CK_TRUST - Level of trust for 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_ENCIPHERMENT - CK_TRUST - Level of trust for 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. - - 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 - - - - 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. - -
- -
-
- 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. - -
- 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_DELEGATOR - -
- -
- 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 - -
- -
- 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 - -
- -
- -
- Xxxx -
- -
- Xxxx -
-
- -
- NSS: Who? -
- -
- xxxx -
- -
- Xxxx: Use of multiple PKCS#11 modules - Not using just any module. -
- - - - - - - - - - - - - - - - Minimal Reference - - - - - - - - - - - - - - - - Ultimate Plan for Taking Over the World - - - Mad Dominators, Inc. - - - - - - - -
- This becomes an Appendix. -
- - diff --git a/rfc2629.dtd b/rfc2629.dtd deleted file mode 100644 index 09e8ad6..0000000 --- a/rfc2629.dtd +++ /dev/null @@ -1,311 +0,0 @@ - - - - - - - - - - - - - -%rfc2629-xhtml; - - -%rfc2629-other; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/rfc2629.xslt b/rfc2629.xslt deleted file mode 100644 index 020be8d..0000000 --- a/rfc2629.xslt +++ /dev/null @@ -1,3001 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 - 2 - 3 - 4 - 5 - 99 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This stylesheet requires either an XSLT-1.0 processor with node-set() - extension function, or an XSLT-2.0 processor. Therefore, parts of the - document couldn't be displayed. - - - - - - - - - - - - - - - - - - - - - - - - - - -

Abstract

- - - - - function parseXml(str) { - var doc = new ActiveXObject ("MSXML2.DOMDocument"); - doc.async = false; - if (doc.loadXML (str)) return ""; - return doc.parseError.reason + "\n" + doc.parseError.srcText + " (" + doc.parseError.line + "/" + doc.parseError.linepos + ")"; - } - - - - - - - - -
- XML PARSE ERROR: -
-
- - - - - -
- XML PARSE ERROR: -
-
- - - - 
-    
-    
-    
-    
-    
-
- - - - {.} - - - - - - -   - - - - () - - - - -   - - - - -   -
- - - - -   - - , -   - - - - - - -   - - - - - - Phone:  - - - - - - Fax:  - - - - - - EMail:  - - - - mailto: - - - - - - - - - URI:  - - - - -   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - < - - > - - - - -
- - - - -
- - - -
- - - - - -

Figure :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - -
- - -

- - - -
- - -

- - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - .iref. - - - - - -
- - -
- - - -
- - -
- - - -
- - -
- - - -
    - - -
- - - - -
    - - -
- - - -
    - - -
- - - - - -
- -
- - - -
  • - -
    • -     - - -
    - -
    -
    - - - margin-left: em - - -
    -     - - - - - - - - - - - - - - -
    - - - - - - - - -
    -
    - -
    -     - - - - - - - -

    - -     - - -

    - - -

    -     - - -

    - - -

    -     - - - - - - - - - - - - - - - - - - - -     - - - - - - - - - - - - - - - - - - - - - - - , Ed. - - - - - - - mailto: - - - - - - - - - - - - - ,  - and - - - - - - - - - - - ,  - and - - - - - - - - "" - - - "" - - - - - , - - -   - - - - - , -   - - - - . - - -
    - -     - - - - - - - - - - - - - - - - - - - . - - - - -

    - - - - - - - - References - - - -

    - - - - - - - - - - - - -
    - -     - - - - - - - - - - <xsl:value-of select="front/title" /> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -     - - -     - - - - - - - - - - - - -

    - - - -

    - -     - - - - - - - - - - - - - - - - - - - - - - - - - - h1 - h2 - h3 - - - - - - - - np - - - - - - - - - - - -       - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -     - - -

    -     - - - - - - - - - - - - - - - - - - - - - Undefined target: - Undefined target: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - <> - - </> - - - - - - - - - - - - - - - - - - - - Network Working Group - - - Internet Draft - INTERNET DRAFT - Request for Comments: - - - - - <> - - - - - Obsoletes: - - - (if approved) - - - - - - BCP: - FYI: - STD: - - - - - - - Updates: - - - (if approved) - - - - - Category: - - - - - Expires: - - - - - - - - - - - - - - - - - - , Editor - - - , - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -   -   - - - - - - - - - - - - - - - - - - - - - - July - August - September - October - November - December - January - February - March - April - May - June - WRONG SYNTAX FOR MONTH - - - - - - - 01 - 02 - 03 - 04 - 05 - 06 - 07 - 08 - 09 - 10 - 11 - 12 - WRONG SYNTAX FOR MONTH - - - - - - - - - - - -

    - - Author's Addresses -

    - - - -
    -     - - - - - - - -
    - - - - 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 IETF's procedures with respect to rights in IETF 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 . - - - 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. - - - - - The IETF takes no position regarding the validity or scope of - any intellectual property 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; neither does - it represent that it has made any effort to identify any such - rights. Information on the IETF's procedures with respect to - rights in standards-track and standards-related documentation - can be found in BCP-11. Copies of claims of rights made - available for publication 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 implementors or users of this - specification can be obtained from the IETF Secretariat. - - - The IETF invites any interested party to bring to its - attention any copyrights, patents or patent applications, or - other proprietary rights which may cover technology that may be - required to practice this standard. Please address the - information to the IETF Executive Director. - - - - The IETF has been notified of intellectual property rights - claimed in regard to some or all of the specification contained - in this document. For more information consult the online list - of claimed 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 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. - -
    -     - - - -
    - - Copyright (C) The Internet Society (). - 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. - -
    -     - -
    - - Copyright (C) The Internet Society (). All Rights Reserved. - - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -
    -     -     - -
    - - Funding for the RFC Editor function is currently provided by the - Internet Society. - -
    - -     - - - - - -a { - text-decoration: none -} -a:hover { - text-decoration: underline -} -a:active { - text-decoration: underline -} -body { - - background: url() #ffffff left top; - - color: #000000; - font-family: helvetica, arial, sans-serif; - font-size: 13px; -} -dl { - margin-left: 2em; -} -h1 { - color: #333333; - font-size: 16px; - line-height: 16px; - font-family: helvetica, arial, sans-serif; - page-break-after: avoid; -} -h1.np { - page-break-before: always; -} -h2 { - color: #000000; - font-size: 14px; - font-family: helvetica, arial, sans-serif; - page-break-after: avoid; -} -h3 { - color: #000000; - font-size: 13px; - font-family: helvetica, arial, sans-serif; - page-break-after: avoid; -} -img { - margin-left: 3em; -} -li { - margin-left: 2em; - margin-right: 2em; -} -ol { - margin-left: 2em; - margin-right: 2em; -} -p { - margin-left: 2em; - margin-right: 2em; -} -pre { - margin-left: 3em; - background-color: lightyellow; -} -table { - margin-left: 2em; -} -table.header { - width: 66%; -} -td.top { - vertical-align: top; -} -td.topnowrap { - vertical-align: top; - white-space: nowrap; -} -td.right { - text-align: right; -} -td.header-l { - width: 33%; - color: #ffffff; - background-color: #666666; - font-size: 10px; - font-family: arial, helvetica, sans-serif; - vertical-align: top -} -td.header-r { - width: 33%; - color: #ffffff; - background-color: #666666; - font-size: 10px; - font-family: arial, helvetica, sans-serif; - vertical-align: top; -} -thead { - display:table-header-group -} -.editingmark { - background-color: khaki; -} -.error { - font-size: 14pt; - background-color: red; -} -.hotText { - color:#ffffff; - font-weight: normal; - text-decoration: none; - font-family: chelvetica, arial, sans-serif; - font-size: 9px -} -.link2 { - color:#ffffff; - font-weight: bold; - text-decoration: none; - font-family: helvetica, arial, sans-serif; - font-size: 9px -} -.toowide { - color: red; - font-weight: bold; -} -.RFC { - color:#666666; - font-weight: bold; - text-decoration: none; - font-family: helvetica, arial, sans-serif; - font-size: 9px -} -.title { - color: #990000; - font-size: 22px; - line-height: 22px; - font-weight: bold; - text-align: right; - font-family: helvetica, arial, sans-serif -} -.figure { - font-weight: bold; - text-align: center; - font-size: 12px; -} -.filename { - color: #333333; - font-weight: bold; - font-size: 16px; - line-height: 24px; - font-family: helvetica, arial, sans-serif; - text-align: right; -} -.warning { - font-size: 14pt; - background-color: yellow; -} -del { - color: red; - text-decoration: line-through; -} -.del { - color: red; - text-decoration: line-through; -} -ins { - color: green; - text-decoration: underline; -} -.ins { - color: green; - text-decoration: underline; -} - -table.openissue { - background-color: khaki; - border-width: thin; - border-style: solid; - border-color: black; -} - -table.closedissue { - background-color: white; - border-width: thin; - border-style: solid; - border-color: gray; - color: gray; -} - -.closed-issue { - border: solid; - border-width: thin; - background-color: lime; - font-size: small; - font-weight: bold; -} - -.open-issue { - border: solid; - border-width: thin; - background-color: red; - font-size: small; - font-weight: bold; -} - -.editor-issue { - border: solid; - border-width: thin; - background-color: yellow; - font-size: small; - font-weight: bold; -} - -@media print { - .noprint { - display: none; - } -} - - - - - - - #.iref. -       - - - - , - - - - - - - - - - -

    - - Index -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - -
    -     - - - - - -
    -       - - - - - -
    -     - - - - - - -
    - - - - - - - - - This document is an Internet-Draft and is - in full conformance with all provisions of Section 10 of RFC2026. - - - This document is an Internet-Draft and is - in full conformance with all provisions of Section 10 of RFC2026 - except that the right to produce derivative works is not granted. - - - This document is an Internet-Draft and is - in full conformance with all provisions of Section 10 of RFC2026 - except that the right to produce derivative works is not granted. - (If this document becomes part of an IETF working group activity, - then it will be brought into full compliance with Section 10 of RFC2026.) - - - This document is an Internet-Draft and is - NOT offered in accordance with Section 10 of RFC2026, - and the author does not provide the IETF with any rights other - than to publish as an Internet-Draft. - - - - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance - with RFC 3668. - - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance - with RFC 3668. This document may not be modified, and derivative - works of it may not be created, except to publish it as an RFC and - to translate it into languages other than English, - other than to extract as-is for separate use.. - - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance - with RFC 3668. This document may not be modified, and derivative - works of it may not be created, - other than to extract as-is for separate use... - - - CONFORMANCE UNDEFINED. - - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. - Note that other groups may also distribute working documents as - Internet-Drafts. - - - 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". - - - The list of current Internet-Drafts can be accessed at - . - - - The list of Internet-Draft Shadow Directories can be accessed at - . - - - This Internet-Draft will expire in . - - - - - - This document specifies an Internet Best Current Practices for the Internet - Community, and requests discussion and suggestions for improvements. - Distribution of this memo is unlimited. - - - - - This memo defines an Experimental Protocol for the Internet community. - It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - - - - - This memo describes a historic protocol for the Internet community. - It does not specify an Internet standard of any kind. - Distribution of this memo is unlimited. - - - - - This memo provides information for the Internet community. - It does not specify an Internet standard of any kind. - Distribution of this memo is unlimited. - - - - - This document specifies an Internet standards track protocol for the Internet - community, and requests discussion and suggestions for improvements. - Please refer to the current edition of the "Internet Official Protocol - Standards" (STD 1) for the standardization state and status of this - protocol. Distribution of this memo is unlimited. - - - - UNSUPPORTED CATEGORY. - - - -
    - -
    - - Copyright (C) The Internet Society (). All Rights Reserved. - -
    - -     - - - - - - - - - -

    - Table of Contents -

    - -

    - -

    - - - - - - - - - - - - - - - - - -   - - - - - -    - - - - - - -   - - - - -
    -     -     -     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Author's Address - Author's Addresses - - - - - - - - - - - - - - - - - . - - - - - - - - References - - - - - - - - - - - - - - - - - - - - .section. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    - - Figure : - - - - - - -

    -     - - - - - - -     - - - - -
    - - - - - - - - - - - - -
    -  RFC  - -
    - -     -
    -  TOC  -
    -     -     - - - - - - [] - [] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Artwork exceeds maximum width: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -     -     -     - - - - - - -     -     - -     - - - - - - - - - - - , - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .p. - - - - - -   - - - - - - - - - closedissue - openissue - - - - - - - - - - - - - - - - - - - - - -
    - - - - closed-issue - - - editor-issue - - - open-issue - - -  i  - -   - - - - - - - - -   - (type: , status: ) -
    - - - - - - - -
    - - - - - - - Resolution:  -
    - -     - - - -

    Issues list

    - - - - - - - - - - - - -
    - -     - - - - - - - - - - - - - - - - - - - - - -

    - The following anchor names may collide with internally generated anchors because of their prefix "": - - , - -

    - - The following anchor names may collide with internally generated anchors because of their prefix "": - - , - - -     - - - - -

    - The following target names do not exist: - - , - -

    - - The following target names do not exist: - - , - - -     - - -     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - closed-issue - - - editor-issue - - - open-issue - - -  i  - - - - - - - - - -  i  - - - - - - - - - - - - - - - - - - - - - - - - - - - del - - - ins - - - - - - - del- - - - - - - . - - - - - - - - . - - - - - . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - - - text-align: ; - - -   -
    - -     - - - - - width: ; - - - - text-align: ; - text-align: left; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - , - - - - - - - - Best Current Practice - Historic - Informational - Standards Track - Experimental - (category unknown) - - - - - - - - - - - - - - - - - - - INTERNET DRAFT - RFC - - - - - - http://greenbytes.de/tech/webdav/rfc2629.xslt, - - - - - - - - - - - - - - - - - - - - - , - - - - - - - - - - en - - - - - - - - - - - - - - - - - - - - - - - Appendix - Section - - - - - - np - - - - -     -- cgit v1.2.3