[Pki-devel] Announcing the release of Dogtag 10

The Dogtag team is proud to announce the release of Dogtag v10.0.0. This release is being bundled with the GA release of Fedora 18, and marks the culmination of over a year of development by the Dogtag team. == Build Versions == pki-core-10.0.0-2.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.0-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Upgrade Notes == It is possible to upgrade from a Dogtag 9 instance by first upgrading your server to Fedora 18 and then updating the Dogtag software. Existing Dogtag instances will continue to work correctly using existing instances, with the Java-based instances running on Tomcat 6. However, because the new functionality and interfaces depend on instance configuration, these will not be available to existing Dogtag 9-style instances. To take advantage of these new features, new Dogtag 10 instances should be created. Documentation will soon be provided on how to migrate a Dogtag 9 - style instance to a new Dogtag 10 instance. == Highlights since Dogtag v. 9 == Infrastructure and Development Changes: * The Dogtag code base was moved to git from svn. * Java development is now done under Eclipse. * Dogtag 10 uses its own public-facing TRAC project management system. * Improvements were made to CMake modules for Java development. * Java development uses OpenJDK 7. * Python development uses Python 2.7 and Jython 2.2. * Dogtag 10 Java-based instances run on Tomcat 7. * Dogtag 10 RA and TPS instances run on Apache 2.4. Refactoring and Cleanup: * Code has been reformatted to uniform formatting and coding standards. * Based on feedback provided by Eclipse and Coverity, the following types of cleanup occurred: ** Removal of dead code and unnecessary code blocks. ** Removal of generic containers and implementation of type safety. ** Removal/ replacement of deprecated code, with the addition of JUnit tests to confirm correctness. ** Address various memory leaks and corruption issues, coding style issues etc. * The Dogtag code pre-dates many of the modern Java utilities to do encoding, HTTP and XML parsing etc. As a result, custom code was written to do these functions. This code has been replaced with standard code, and a whole package (osutil) was eliminated. REST Interface: To allow easier and more intuitive interaction with the Dogtag servers, a new REST interface has been added. This interface is based on RESTEasy framework, a fully certified implementation of the JAX-RS specification. Clients interact with this framework using intuitive REST URLs, and using standard XML or JSON inputs. Included is a Java client proxy framework which can be used by client applications to build HTTP requests on the Dogtag servers, simply by invoking methods on the client objects. This client framework is used in the new command line interface "pki" as described below. The plan is to continue over time to extend the REST interface to cover all of the essential Dogtag functionality. In this release, the following functionality has been implemented: * With a CA: ** Create, review and approve certificate requests. ** List, view, revoke, hold and release certificates. ** Get installation token from security domain ** Add/remove KRA connector configuration ** Retrieve and list certificate profiles * With KRA: ** Retrieve transport certificate ** List/ archive and recover symmetric keys * With all Java systems: ** Add/Remove/Modify/View users, groups and group members ** Start system installation service Third-party Components: * Dogtag 10 includes JQuery and the Jquery.i18n.properties plug-in. CLI: * A new intuitive command line interface has been created, based on the RESTEasy client framework. This allows administrators and agents to perform all of the operations exposed by the REST interface from the command line, or from scripts. Storage of symmetric keys in the DRM: * The DRM provides secure encrypted storage for asymmetric keys. The KRA has been extended to provide a mechanism to securely archive and recover symmetric keys. This would be useful for storing disk encryption keys for instance. SELinux changes: * In Dogtag 9, we maintained a custom SELinux policy to provide mandatory access controls for interactions with the Dogtag server. In Dogtag 10, this policy has been cleaned up, simplified and integrated into the system base policy. As a result, the pki-selinux package has been retired. ECC: * In earlier releases, Dogtag only supported ECC certificate issuance when the CA was connected to an ECC-capable external crypto token. In Dogtag 10, all CS servers (CA, OCSP, DRM, TKS, TPS) can now be issued ECC certificates and run in such environment that: ** CS servers can communicate securely with ECC SSL certificates. ** Administrators and agents can access their administration ports via SSL using ECC certificates ** ECC encryption certificates can now have their private keys archived (and recovered) by the DRM. For this feature, we used an ECC-capable HSM in our development and QE environment on the client side for development and testing. Certicom software tokens could not be used because of an issue with malformed private keys. ** The TMS testing client tool, tpsclient, can now be used to test token-based enrollment and key archival in the TMS environment (the actual smart card support will follow in a later release) New Installer: * New installer tools (pkispawn, pkidestroy) has been written in Python to create Dogtag Java-based instances (CA, KRA, OCSP, TKS). Over time, this installer will be extended to handle the remaining Apache-based instances (TPS and RA), and pkicreate/pkiremove/pkisilent will be retired and removed. * pkispawn performs the same operations that pkicreate and the pkisilent used to do, meaning that a Dogtag Java-based instance can be installed and configured in a single non-interactive step. With the right options, though, it is still possible to configure an instance by going through the web-based installation UI panels. New Directory Layout/ Architecture/ Standard Ports * It is now possible (though not required) to install multiple Java subsystems (CA, KRA, TKS, OCSP) within a single tomcat instance. This is useful for small deployments where, for example, you might want leverage the capabilities of a CA and KRA on a single server. In keeping with this change, the directory structure of a Dogtag instance has changed. * By default, Dogtag will install on the default tomcat ports (8443 and 8080). There will no longer be any separation of EE, admin and agent interfaces on different ports. Package Restructuring: * The Dogtag RPM packages have been restructured to reduce the number of packages and more accurately separate client and server components. The current packages are: ** pki-base: code common to clients and server ** pki-tools: Java and native tools used by client and server. ** pki-server: code used by Java servers, only on the server. ** pki-ca, pki-kra, pki-ocsp, pki-tks, pki-ra, pki-tps: subsystem specific code ** pki-javadoc: consolidation of the pki-common-javadoc, pki-java-tools-javadoc, and pki-util-javadoc packages ** pki-symkey: provides native symmetric key operations ** pki-console: administrative tool for CA, KRA, OCSP, and TKS * The UI packages have been rearranged and consolidated to make customizing an instance's user interfaces more straightforward, and to ensure a more consistent look and feel across subsystems. All of the subsystem-specific UI packages have been eliminated, and there is now a single UI package (dogtag-pki-server-theme) which contains all the CSS style sheets, image files and properties files for all subsystems. A customer wanting to customize the UI could simply replace the components in this package. Additionally, the pki-console requires its own UI package, dogtag-pki-console-theme. * A meta-package (dogtag-pki) has been created to conveniently install all existing Dogtag 10 PKI packages.