From 8c279a67d78ec3e3ae5a5896d58decfbb8a6ce02 Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Sat, 11 Dec 2010 13:09:49 +0000 Subject: Flesh out the specification, cleanup, fix typos, and clarify stuff. --- trust-assertions.xml | 526 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 319 insertions(+), 207 deletions(-) diff --git a/trust-assertions.xml b/trust-assertions.xml index 1d05972..d90b001 100644 --- a/trust-assertions.xml +++ b/trust-assertions.xml @@ -25,86 +25,102 @@ Introduction Trust assertions are represent bits of trust information used by an - application in trust decisions. For example, trust assertions can represent - certificate authority root anchors, pinned certificate exceptions, or - revocation lists. - - PKCS#11 XXXREFXXX is a useful and widely supported standard for storage and use - of keys and certificates. It is often used with smart cards. + application to make trust decisions. For example, trust assertions can + represent certificate authority anchors, pinned certificate exceptions, or + revocation lists. Trust assertions do not represent the trust decision + itself. They are merely one factor in the trust decision. However by using + trust assertions applications (and libraries) can make consistent trust + decisions and interoperate with one another. This is a building block + toward a usable crypto experience for the user of such applications. + + PKCS#11 is a useful + and widely supported standard for storage and use of keys and certificates. + It is often used with smart cards. This specification outlines how to store and lookup trust assertions via the PKCS#11 API. We detail an extension which accomplishes this. - XXX + A word on terminology. We use the word trust quite a bit + in this document. This is a highly overloaded and subjective term, and its use + in this specification is unfortunate. An unambiguous term is desirable. + The author cringes every time the word trust is used. + The author cringes a lot.
Trust Assertions - A trust assertion describes a level of trust in a certain subject for a - given purpose. Conceptually each trust assertion is a triple - containing the following: + + A trust assertion is a generic concept. Each trust assertion describes a level + of trust in a certain subject for a given purpose. Conceptually each trust + assertion is a triple containing the following: - Reference to the Subject - Purpose - Level of Trust + Reference to the subject + Purpose + Level of trust We examine each of these parts of the triple in further detail below. -
+
Level of Trust - XXX - - - Untrusted: Explicitly untrusted. Override other - trust. - Trusted: Explicitly trusted. Override other - trust - Trust Anchor: Explicitly trusted anchor which - can confer its trust (eg: via signatures) on other - subjects. - + This describes the level of trust represented by the trust assertion. + + + + Untrusted + The trust assertion marks the subject as explicitly + untrusted. This overrides other trust. + + + Trusted + The trust assertion marks the subject as explicitly + trusted. + + + Anchor + The trust assertion marks the subject as trusted to + confer its trust (eg: via signatures) on other subjects + (eg: via a certificate chain). + + + + We can call trust assertions which establish trust positive trust + assertions. In essence these trust assertions build up trust in + a subject. These have a level of trust of trusted + or anchor. Examples of this kind of trust assertion + are certificate authority trust anchors. + + Trust assertions that falsify trust can be called negative trust + assertions. These trust assertions tear down trust in a subject. They + assume the subject is already trusted, and want to revoke or falsify + that trust. These have a level of trust of untrusted. + Examples of this kind of trust assertion are certificate revocation lists. + + Negative trust assertions always override positive trust assertions.
-
+
Purpose - A trust assertion refers to a specific purpose or usage. A - certificate may be trusted for purposes like: email, code signing, - authenticating a server. + A trust assertion always refers to a specific purpose or usage. This is + the thing that the subject is trusted to do. For example a certificate + may be trusted for purposes like: email, code signing, or authenticating + a remote host. - In addition to the usage, the purpose can contain a more specific - designation, such as the hostname of a server. + In addition, the purpose can contain a peer, which further narrows what the + subject is trusted to do. It is then only trusted for for the given purpose + when the given peer is involved. For example the peer might be the host + name of a server.
-
+
Subject Reference Each trust assertion contains a reference to the subject. This is the thing that is trusted. In this specification we will deal exclusively with - certificates as the subject. However . - - There are two ways to refer to a certificate depending on whether - that certificate is being referred to as a trust root (like a certificate - authority) or referred to by another trusted certificate. - - Certificates used as trust roots are referred to by the complete DER - encoding of the certificate. - - Certificates verified by another certificate (signed as part - of a certificate chain) are referred to by the DER value of the issuer - field and the serial number. - - Referring to a trust root certificate by its issuer and serial number - is meaningless. - - Referring to a certificates signed by another certificate would preclude uses - such as certificate revocation lists. - - Therefore different methods MUST be used to refer certificates in these - different situations. + X.509 certificates as the subject of trust assertions.
@@ -115,18 +131,32 @@ specific to a certificate, they do not need to be stored on the same token as the certificate. - When represented as PKCS#11 objects, trust assertions get a bit less elegant - than the reference + purpose + trust-level described above. This is done - for practicality and minimizing the number of PKCS#11 lookups required - to do an operation. + When represented as PKCS#11 objects, trust assertions become less elegant + than the reference + purpose + trust-level triple described above. This is done + because of limitations in the PKCS#11 API and also to minimizing the number + of PKCS#11 lookups required to use trust assertions. + + There are two ways that a trust assertion refers to a certificate. Certificates + used in 'positive' trust assertions are referred to by the complete DER encoding + of the certificate. Certificates used in 'negative' trust assertions are referred + to by the DER value of the certificate's issuer field and its serial number. + + Unfortunately, we cannot have a single way to refer to certificates used + in both positive and negative trust assertions. For example, referring + to a certificate authority trust anchor by its issuer and serial number + would be meaningless. And using a full DER value to refer to negative + trust assertions would preclude uses such as certificate revocation + lists. Therefore different methods must be used to refer to certificates in + these different situations. The objects below reflect this.
Common Trust Assertion Object Attributes First we describe the attributes that all trust assertion objects have in - common. All trust assertions are of the class CKO_G_TRUST_ASSERTION. + common. All trust assertions are of the class + CKO_X_TRUST_ASSERTION. - +
General trust assertion attributes @@ -138,33 +168,38 @@ - CKA_CLASS - CK_OBJECT_CLASS - CKO_G_TRUST_ASSERTION + CKA_CLASS + CK_OBJECT_CLASS + CKO_X_TRUST_ASSERTION - CKA_G_TRUST_TYPE - CK_TRUST_TYPE + CKA_X_ASSERTION_TYPE + CK_X_ASSERTION_TYPE The type of trust assertion. This represents - the trust level. See more details below. + the level of trust. + See the various + assertion types. - CKA_G_PURPOSE - CK_UTF8_CHAR array - The string representation of the purpose, usually - an OID. + CKA_X_PURPOSE + CK_UTF8_CHAR array + The string representation of + the purpose, + usually an OID, and often one of the + predefined purposes.
- The CKA_G_PURPOSE attribute contains a string which represents the purpose - of the trust assertion. These are generally OIDs. The following predefined - values match those of the Extended Key Usage X.509 extension. Other values - may be used when interoperability of the trust assertion between multiple - applications is not desired. + The CKA_X_PURPOSE attribute contains a string which represents + the purpose of the trust assertion. These are + generally OIDs. The following predefined values match those of the + Extended Key Usage X.509 extension. + Other values may be used when interoperability of the trust assertion between multiple + applications is not required. - +
Predefined Purposes @@ -175,35 +210,35 @@ - 1.3.6.1.5.5.7.3.1 + 1.3.6.1.5.5.7.3.1 TLS Server Authentication - 1.3.6.1.5.5.7.3.2 + 1.3.6.1.5.5.7.3.2 TLS Client Authentication - 1.3.6.1.5.5.7.3.3 + 1.3.6.1.5.5.7.3.3 Code Signing - 1.3.6.1.5.5.7.3.4 + 1.3.6.1.5.5.7.3.4 Email Protection - 1.3.6.1.5.5.7.3.5 + 1.3.6.1.5.5.7.3.5 IPSec Endpoint - 1.3.6.1.5.5.7.3.6 + 1.3.6.1.5.5.7.3.6 IPSec Tunnel - 1.3.6.1.5.5.7.3.7 + 1.3.6.1.5.5.7.3.7 IPsec User - 1.3.6.1.5.5.7.3.8 + 1.3.6.1.5.5.7.3.8 Time Stamping @@ -211,9 +246,12 @@
Each different type of trust assertion is represented by a different - CK_G_TRUST_TYPE value. The following types are defined. + CK_X_ASSERTION_TYPE value. These represent the + level of trust. Each type of trust + assertion has additional attributes and is a distinctly different type + of PKCS#11 object. The following types are defined. - +
Trust assertion types @@ -224,20 +262,20 @@ - CKT_G_CERTIFICATE_UNTRUSTED - A trust assertion that represents an explicitly - untrust in a certificate. + CKT_X_ANCHORED_CERTIFICATE + A positive trust assertion that represents a trust + anchor which is used as the anchor of a certificate + chain. - CKT_G_CERTIFICATE_TRUST_EXCEPTION - A trust assertion that represents an explicitly - trust in a certificate. + CKT_X_PINNED_CERTIFICATE + A positive trust assertion that represents an + explicit trust in a certificate. - CKT_G_CERTIFICATE_TRUST_ANCHOR - A trust assertion that represents a trust anchor - which is used as the root of a certificate trust - tree. + CKT_X_UNTRUSTED_CERTIFICATE + A negative trust assertion that represents an + explicit untrust in a certificate. @@ -245,26 +283,23 @@
- Certificate Exception Trust Assertion - - A certificate exception is a trust assertion which signifies a trusted level - of trust in a certificate. The expectation is that all other trust validation - is overridden by this trust. + Anchored Certificate Assertion - The certificate is referenced by a using the entire DER encoding of the - certificate. + An anchored certificate is a trust assertion which is to be used with a + certificate authority that has signed other trusted certificates. It + is to be used as the anchor in a + certificate chain. - All certificate exceptions have a designated peer as part of their purpose. - In the case of TLS authentication purposes, this is the host name of the - peer that is being communicated with. In the case of email protection - purposes this is the email address this certificate is to be used with. + Because it is a positive trust assertion, the certificate is referenced by + using the entire DER encoding of the certificate. - In addition to the following, all the general trust assertion attributes - are present on a certificate exception object. + In addition to the following attributes, all the + general trust assertion attributes + are present on a anchored certificate trust assertion.
- Certificate Exception Attributes - + Anchored Certificate Assertion Attributes + Attribute @@ -274,17 +309,12 @@ - CKA_G_TRUST_TYPE - CK_TRUST_TYPE - CKT_G_CERTIFICATE_TRUST_EXCEPTION - - - CKA_G_PEER - CK_UTF8_CHAR array - The peer part of the purpose. + CKA_X_ASSERTION_TYPE + CK_X_ASSERTION_TYPE + CKT_X_CERTIFICATE_TRUST_ANCHOR - CKA_G_CERTIFICATE_VALUE + CKA_X_CERTIFICATE_VALUE Byte array The DER encoding of the certificate. @@ -295,23 +325,28 @@
- Certificate Anchor Trust Assertion + Pinned Certificate Assertion - A certificate anchor is a trust assertion which is to be used with a - certificate authority that is a trust root authority to verify - other certificates with. + A pinned certificate is an endpoint certificate (not an authority) which is + trusted explicitly. The expectation is that all other trust validation + is overridden by this pinned trust. - This type of object signifies a trust anchor level of trust. + Because it is a positive trust assertion, the certificate is referenced by + using the entire DER encoding of the certificate. - The certificate is referenced by a using the entire DER encoding of the - certificate. + All pinned certificate trust assertions have a designated peer with which + the pinned certificate assertion is relevant. In the case of the TLS + authentication purpose, this is the host name of the peer that is being + communicated with. In the case of the email protection purpose this is the + email address this certificate is to being used with. - In addition to the following, all the general trust assertion attributes - are present on a certificate exception object. + In addition to the following, all the + general trust assertion attributes + are present on a pinned certificate trust assertion.
- Certificate Anchor Attributes - + Pinned Certificate Assertion Attributes + Attribute @@ -321,12 +356,17 @@ - CKA_G_TRUST_TYPE - CK_TRUST_TYPE - CKT_G_CERTIFICATE_TRUST_ANCHOR + CKA_X_ASSERTION_TYPE + CK_X_ASSERTION_TYPE + CKT_X_PINNED_CERTIFICATE + + + CKA_X_PEER + CK_UTF8_CHAR array + The peer part of the purpose. - CKA_G_CERTIFICATE_VALUE + CKA_X_CERTIFICATE_VALUE Byte array The DER encoding of the certificate. @@ -337,20 +377,21 @@
- Certificate Untrusted Assertion + Untrusted Certificate Assertion An untrusted certificate is a trust assertion which signifies the explicit lack of trust in a certificate. An example of this is an item in a CRL or a certificate explicitly marked as untrusted by a user. - The certificate is referenced by a using the issuer and serial number - of the certificate in question. + Because it is a negative trust assertion, the certificate is referenced by + a using the issuer and serial number of the certificate in question. - In addition to the following, all the general trust assertion attributes - are present on a certificate exception object. + In addition to the following, all the + general trust assertion attributes + are present on a untrusted certificate assertion.
- Untrusted Certificate Attributes + Untrusted Certificate Assertion Attributes @@ -361,17 +402,17 @@ - CKA_G_TRUST_TYPE - CK_TRUST_TYPE - CKT_G_CERTIFICATE_UNTRUSTED + CKA_X_ASSERTION_TYPE + CK_X_ASSERTION_TYPE + CKT_X_UNTRUSTED_CERTIFICATE - CKA_ISSUER + CKA_ISSUER Byte array DER-encoding of the certificate issuer name - CKA_SERIAL_NUMBER + CKA_SERIAL_NUMBER Byte array DER-encoding of the certificate serial number @@ -388,42 +429,104 @@
Building a Certificate Chain - During TLS or other certificate verification operations, a certificate chain - must be built up. The certificate chain starts with a trust anchor and - each certificate in the chain is signed by the previous one. The chain ends - with the endpoint certificate for the peer. + During TLS or other certificate verification operations, a + certificate chain + must be built. The certificate chain starts with a endpoint certificate for + the peer, and usually ends with a certificate explicitly trusted in some + way, such as a certificate authority trust anchor. The certificates in the + chain are each in turn signed by the next certificate in the chain. - Conceptually building a certificate chain can be described as two operations - 1) building the chain based on trust assertions, and 2) allowing then - allowing falsification of all or part of the chain based on trust - assertions. + Conceptually building a certificate chain has two parts 1) building the chain + based on positive trust assertions, and 2) allowing then allowing falsification + of all or part of the chain based on negative trust assertions. + + Here is how this is accomplished. For interoperability it is important to perform + the following lookups using the attributes described: - Check if the endpoint certificate has a certificate exception - for the given purpose (and peer). If a certificate exception is found - then the certificate chain consists of one certificate and is considered - valid at this point. - - Complete the initial certificate chain. Often the peer does not - send a complete chain and only sends its own certificate. Build up the - chain backwards from the bottom up using the certificate issuer to to - perform PKCS#11 lookups for objects matching the CKA_ISSUER. This is - done until a self-signed certificate is reached, or a certificate is not - found. - - Look for a trust anchor for each certificate in the chain - starting from the certificate that signed the endpoint certificate. When - a trust anchor is found then the certificate chain is truncated at that - point. - - Allow falsification for each certificate in the resulting - certificate chain by checking whether each certificate has PKCS#11 - untrusted certificate trust assertion. If at any point an untrusted - trust assertion is found (eg: CRL) then the certificate chain is - considered invalid. - - Pass the resulting certificate chain to the crypto library for - further validation. + + + Check if the endpoint certificate has a pinned certificate + for the given purpose and peer. If a pinned certificate is found + then the certificate chain consists of one certificate and is + considered valid at this point. + + To check for pinned certificates, perform a + C_FindObject operation with the following + attributes: + + + CKA_CLASS: CKO_X_ASSERTION_TYPE + CKA_X_ASSERTION_TYPE: CKT_X_PINNED_CERTIFICATE + CKA_X_CERTIFICATE_VALUE: DER encoding of certificate + CKA_X_PURPOSE: purpose string + CKA_X_PEER: peer string + + + + + Use PKCS#11 to find all the certificates necessary for the + certificate chain. Often a peer will not send a complete chain + and only send its own certificate. Build up the chain using the + certificate issuer of each certificate to search for issuing + certificates. This is done until a self-signed issuing certificate + is found, or an issuing certificate is not found. + + To lookup issuing certificates, perform a + C_FindObject operation with the following + attributes: + + + CKA_CLASS: CKO_CERTIFICATE + CKA_CERTIFICATE_TYPE: CKC_X_509 + CKA_SUBJECT: Der encoding of subject of issued certificate + + + + + + Check for an anchored certificate assertion for each certificate + in the chain starting from the certificate that signed the + endpoint certificate. The endpoint certificate is not considered + for a possible anchor. When a anchor is found then the certificate + chain is truncated at that point. Certificates past the trust anchor + are ignored. + + To check for anchored certificates, perform a + C_FindObject operation with the following + attributes: + + + CKA_CLASS: CKO_X_ASSERTION_TYPE + CKA_X_ASSERTION_TYPE: CKT_X_ANCHORED_CERTIFICATE + CKA_X_CERTIFICATE_VALUE: DER encoding of certificate + CKA_X_PURPOSE: purpose string + + + + + Allow falsification for each certificate in the resulting + certificate chain by checking whether each certificate has + an untrusted certificate assertion. If at any point an untrusted + assertion is found (eg: a certificate listed on a certificate + revocation list) then the certificate chain is considered invalid. + + To check for untrusted certificates, perform a + C_FindObject operation with the following + attributes: + + + CKA_CLASS: CKO_X_ASSERTION_TYPE + CKA_X_ASSERTION_TYPE: CKT_X_UNTRUSTED_CERTIFICATE + CKA_X_CERTIFICATE_VALUE: DER encoding of certificate + CKA_X_PURPOSE: purpose string + + + + + Pass the resulting certificate chain to the crypto library for + further validation of signers, identity matching, etc. +
@@ -431,55 +534,64 @@
Justifications - Some answers to this spec was designed as it is. + Some answers to why this spec was designed as it is.
- Why use a complete DER encoding? + Why use a complete certificate DER encoding for positive trust assertions? Conceivably we could use a hash of the certificate instead of the - CKA_G_CERTIFICATE_VALUE. NSS Trust Objects XXREFXX uses hashes in this - way. - - In the current climate of hash algorithms being broken in various ways - it seems more prudent to avoid the hashing of the certificate and just - use the complete certificate DER-encoding for lookups. - + CKA_X_CERTIFICATE_VALUE. + + NSS Trust Objects use hashes in this way. + + In the current climate where many hash algorithms are broken in various ways + it seems prudent to avoid the hashing of the certificate and just use the + complete certificate DER encoding for lookups. This allows a robust standard + that is not dependent on the long term viability of a specific hash algorithm.
- Why lookup untrusted certificates by issuer + serial number? + Why refer to certificates in negative trust assertions by issuer and serial number? - Certificate revocation lists XXREFXX do not generally contain the full value - of the certificate or a hash thereof. They simply contain serial numbers, - which when combined with the issuer of the certificate revocation list, - are meant to uniquely identify a given certificate. - - In order to support CRLs exposed as untrusted assertions (one of the design - goals) we must limit ourselves to this method of identifying untrusted - certificates. + Certificate revocation lists + do not generally contain the full value of the certificate or a hash thereof. + They simply contain serial numbers, which when combined with the issuer of the + certificate revocation list, are meant to uniquely identify a given certificate. + In order to support CRLs exposed as untrusted certificate assertions (which is one + of the design goals of this specification) we must limit ourselves to this method + of referencing certificates in negative trust assertions.
Why not use NSS Trust Objects? NSS contains an implementation of storing trust information via PKCS#11. - This has not been completely documented, but an overview is available - here XXREFXX. + This has not been completely documented, but an + + overview is available. This method of storing trust information + has been in use by NSS for many years. - After careful study of NSS's method of storing trust information, and discussion - with others, the following inherent problems are apparent. + However the NSS method is starting to show its age. After study of NSS's + method of storing trust information, and discussion with others, the + following inherent problems are apparent. - - Mandates the use of SHA1 and MD5 hashes both of which are - cryptographically broken in some way XXREFXX. See above - XXLINKXX + + Mandates the use SHA1 and MD5 hashes both of which are + cryptographically broken in various way. Neither + + MD5 or + + SHA1 are currently recommended for use in specifications. Only supports a distinct set of purposes, new purposes are not supported. - Does not support a trust assertion limited to a single peer, which - precludes storage of trust assertions. - + Does not support a storage of a peer along with the purpose, which + precludes storage of pinned certificate assertions. + + Objects represent a number of trust assertions stored in a single PKCS#11 + object leading to more complex lookup and modification operations. +
-- cgit v1.2.3