Isode R14.4: Strong Authentication Verification Infrastructure & use in M-Vault

This one of a series of a messages describing new features in Isode R14.4, scheduled to ship in April 2009. You can see all of the messages on this blog relating to R14.4 by clicking on this link

R14.4 contains a number of related new capabilities in support of strong authentication and other uses of digital signatures. One aspect of digital signatures is the digital signing, and this is handled as a part of Isode "secure identity" infrastructure and management. This message looks at new capabilities in support of checking digital signatures. 

The mechanics of checking a digital signature is reasonably straightforward, and Isode provides flexible software library support for this. Associated with a verified digital signature will be an X.509 Certificate, which needs to be checked according to the rules of X.509 PKI. Isode's target mechanisms to achieve this are defined in RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". In order to follow these procedures, two things are needed. 

1. One or more "trust anchors" that define Certification Authorities (CAs) that are trusted. Open Internet environments will often use a large number of public CAs as trust anchors. Secure environments will typically use a single trust anchor, using cross certification to manage (on server side) what is trusted. 
2. Access to a directory service. This is needed for CRL validation and for "path discovery", which means identification of additional X.509 certificates needed to build the trust chain for the full certificate validation relative to a trust anchor. 

This information, along with additional information (e.g., whether or not to perform CRL checking) needs to be configured for any entity doing certificate validation. This is currently configured in a per-application tailor file, which is not always convenient. R14.4 extends the verification infrastructure to enable configuration options to be provided by the application doing the checking. This enables configuration information to be stored in a natural location for the application and support GUI configuration. A simple example of this can be seen in the Sodium bind profiles, that enable direct setting of options for the certificate verification. 

M-Vault handles configuration in two ways. First a PKCS#12 secure identity used by M-Vault for signing, may have a number of certificates stored in the PKCS#12 file. If any of these are self signed, M-Vault treats them as trust anchors. This reflects the common PKCS#12 approach of storing a certificate chain, ending in a trusted CA. Additional trust anchors may be configured as files on a file-store accessible by the directory server. This requirement for local access reflects the security sensitivity of this information. The location of the additional trust anchors are configured as directory attributes. The values of the certificates are made available to directory clients by use of a DSE (DSA Specific Entry) so that they appear as values associated with the root of the directory information tree. This allows remote inspection of the trust anchor values. 

Directory access and other certificate verification parameters for M-Vault are configured as attributes and can be managed using Sodium. This configuration is illustrated in the screenshot below, and display of the trust anchors is in the following screen shot.