[Pki-devel] Announcing the release of Dogtag 10

[Ade Lee]

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.