Are you still using DBsign 3.0?!
Find out why you should upgrade to DBsign 4.0!
We offer FREE trial licenses for serious inquiries! This is, by far, the best way to determine if DBsign is right for you.
Download our single page product brochures:
The DBsign® Universal Web Signer (UWS) is our new client-side signing solution that is based on cross-platform technology. The UWS has many important features:
Both the DBsign® UWS client and the DBsign® Server have increased multi-platform support.
The DBsign® UWS supports most 32 bit and 64 bit desktop platforms including
The DBsign® Server supports 32 or 64 bit versions of
In DBsign® 4.0, both the DBsign® UWS client and the DBsign® Server benefit from a redesigned, multi-platform, high-performance cryptographic subsystem. Although the new cryptographic subsystem has features similar to the DBsign® 3.0, the new system is even more efficient and much more flexible. The new DBsign® 4.0 cryptographic subsystem
DBsign® 4.0 has undergone rigorous testing and evaluation by independent third parties.
NIAP Common Criteria Validation. The Common Criteria is an internationally recognized set of security evaluation criteria that was developed by the National Security Agency (NSA). It replaces the older Trusted Computing Security Evaluation Criteria (TCSEC, aka, the “Rainbow Series”, or “Orange Book”). DoD directive 8500.1 mandates that all security products used in DoD be validated under the Common Criteria. DBsign® was the first and is still the only digital signature product to be NIAP Common Criteria Validated. DBsign® 4.0 is also the first and currently the only digital signature product to be validated against DoD's Protection Profile for Public Key Enabled Applications which outlines the security requirements for applications which use PKI technologies.
DoD Joint Interoperability Test Command PKE Interoperability Certification. DBsign® has been certified through JITC PKE interoperability validation multiple times, each time passing with zero defects. DoD JITC PKE certification ensures that DBsign® is fully interoperable with DoD's Public Key Infrastructure. A major component of JITC PKE testing is the NIST Public Key Infrastructure Test Suite (PKITS), which ensures that DBsign® correctly performs certificate path validation according to the relevant security standards.
The DBsign® Server 4.0 is able to achieve higher performance under heavy load environments due to greater multi-threaded concurrency and a more efficient caching architecture. These performance improvements are largely derived from the new cryptographic subsystem. A maximum of 200 concurrent requests per CPU core is suggested.
DBsign®'s Certificate Status Caching (CSC) is another performance enhancement which can greatly improve performance of heavily loaded systems, especially those which rely on OCSP and CRL-DP for revocation status checking. For example, application owners may decide that a certificate's revocation status does not need to be checked more often than, say, every 20 minutes. When DBsign®'s CSC is enabled, the last revocation status is cached and a maximum revocation check frequency is enforced which ensures that an individual certificate's revocation status is not checked too frequently. This eliminates unnecessary and costly network round trips to OCSP responders and CRL-DP sources and, in some circumstances, can greatly improve application performance. If the DBsign® CSC is disabled (the default), DBsign® checks the revocation of all certificates each time they are used in a security operation.
Application Session Tokens (AST) allow host applications increased document level security by giving the host application the ability to allow only specific users to digitally sign specific documents during a specific time period. Essentially, the AST feature allows the DBsign® Server to be “linked” to the application's login session in a application server independent manner.
DBsign® 4.0 handles CRL retrieval much differently than DBsign® 3.0. In DBsign® 3.0, DBsign® would automatically retrieve the CRL from an LDAP directory when the CRL reached its nextUpdate date. However, many DBsign® customers require a more frequent CRL update period to achieve their revocation information “freshness” policies. This fact, in combination with customer changes in CRL access methods (e.g. HTTP instead of LDAP) mandated a change in DBsign®'s CRL retrieval mechanisms. In order to meet customer requirements, DBsign® 4.0 no longer automatically retrieves CRLs but includes the CRL Updater Utility program that allows the host application to “push” CRLs to DBsign®. The CRL Updater is designed to be used by application batch mode scripts that run at a certain frequency. The CRL Updater is configured by a standard DBsign® configuration file that can be edited by DBsign® 4.0's new graphical configuration file editor.
DBsign® 4.0 uses a new XML based configuration file format. The format is easily edited with a text editor, however, DBsign® 4.0 also includes a graphical editor that greatly simplifies configuring the DBsign® Server, Admin Tools, and the CRL Updater.
DBsign® 4.0 has some new parameters which allow applications finer grained control over which users can digitally sign data. In DBsign® 3.0, control over who could sign data was limited to the Trusted Certificates list and user-to-certificate mapping with the User Manager administration tool. DBsign® 4.0 retains these features but adds a new mechanism called Certificate DN Patterns. Certificate DN Patterns enforce a policy based on information contained in the subject and issuer distinguished name (DN) fields in the user's certificate. Patterns (i.e., “regular expressions”) can be specified that either accept or reject the subject DN or issuer DN fields of users' certificates. For example, only users from the Engineering department can be allowed by specifying that the subject DN must include “ou=Engineering”. Or, all certificates issued by the Accounting department's CA can be excluded by rejecting all certificates that include “cn=Accounting CA”, for example. Since the Certificate DN Patterns are regular expressions, the matching rules are well defined and extremely flexible.
The DBsign® Server 4.0 is completely backward compatible with DBsign® 3.0's Web Signer control/plug-in client. This means that existing applications can upgrade to the DBsign® Server 4.0 without required changes to their application code.
DBsign® 4.0 requires an update to the database structure of the DBsign® System Tables and DBsign® Signature Tables. No changes are required to the application's tables and no documents need to be re-signed. All existing digital signatures are preserved. These changes are the result of DBsign® 4.0 storing DBsign® related dates in the GMT timezone instead of the local database timezone. Storing dates in GMT preserves the true time values if a system changes time zones.
Copyright © 2011 Gradkell Systems, Inc. ALL RIGHTS RESERVED.