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. XXX

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: Reference to the Subject Purpose Level of Trust We examine each of these parts of the triple in further detail below.

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.

A trust assertion refers to a specific purpose or usage. A certificate may be trusted for purposes like: email, code signing, authenticating a server. In addition to the usage, the purpose can contain a more specific designation, such as the hostname of a server.

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.

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. 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.

First we describe the attributes that all trust assertion objects have in common. All trust assertions are of the class CKO_G_TRUST_ASSERTION. Attribute Data Type Description CKA_CLASS CK_OBJECT_CLASS CKO_G_TRUST_ASSERTION CKA_G_TRUST_TYPE CK_TRUST_TYPE The type of trust assertion. This represents the trust level. See more details below. CKA_G_PURPOSE CK_UTF8_CHAR array The string representation of the purpose, usually an OID. 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. Value Description 1.3.6.1.5.5.7.3.1 TLS Server Authentication 1.3.6.1.5.5.7.3.2 TLS Client Authentication 1.3.6.1.5.5.7.3.3 Code Signing 1.3.6.1.5.5.7.3.4 Email Protection 1.3.6.1.5.5.7.3.5 IPSec Endpoint 1.3.6.1.5.5.7.3.6 IPSec Tunnel 1.3.6.1.5.5.7.3.7 IPsec User 1.3.6.1.5.5.7.3.8 Time Stamping Each different type of trust assertion is represented by a different CK_G_TRUST_TYPE value. The following types are defined. Trust Type Description CKT_G_CERTIFICATE_UNTRUSTED A trust assertion that represents an explicitly untrust in a certificate. CKT_G_CERTIFICATE_TRUST_EXCEPTION A trust assertion that represents an explicitly 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.

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. The certificate is referenced by a using the entire DER encoding of the certificate. 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. In addition to the following, all the general trust assertion attributes are present on a certificate exception object. Attribute Data Type Description 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_G_CERTIFICATE_VALUE Byte array The DER encoding of the certificate.

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. This type of object signifies a trust anchor level of trust. The certificate is referenced by a 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. Attribute Data Type Description CKA_G_TRUST_TYPE CK_TRUST_TYPE CKT_G_CERTIFICATE_TRUST_ANCHOR CKA_G_CERTIFICATE_VALUE Byte array The DER encoding of the certificate.

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. In addition to the following, all the general trust assertion attributes are present on a certificate exception object. Attribute Data Type Description CKA_G_TRUST_TYPE CK_TRUST_TYPE CKT_G_CERTIFICATE_UNTRUSTED CKA_ISSUER Byte array DER-encoding of the certificate issuer name CKA_SERIAL_NUMBER Byte array DER-encoding of the certificate serial number

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. 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. 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.

Some answers to this spec was designed as it is.

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.

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.

NSS contains an implementation of storing trust information via PKCS#11. This has not been completely documented, but an overview is available here XXREFXX. After careful 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 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.