Dear CAs, Relying Parties, Users, and all others interested,
In this announcement of the IGTF:
1. Updated IGTF distribution version 1.33 available
2. Distribution format changes in the wake of OpenSSL version 1 - IMPORTANT NOTICE - BACKGROUND - COLLATERAL CHANGES
========================================================================= 1. Updated IGTF distribution version 1.33 available =========================================================================
A new distribution of Accredited Authorities by the EUGridPMA, based on the IGTF Common Source, is now available. It includes the newly accredited Authorities by all IGTF Members and retires expiring CA certificates. This is version 1.33, release 1, and it is now available for download from the Repository (and mirrors) at
https://dist.eugridpma.info/distribution/igtf/current/ (traditional format)
https://dist.eugridpma.info/distribution/igtf/1.33-new/ (new format)
Changes from 1.32 to 1.33 ------------------------- (15 February 2010)
* Added accredited MICS TCS eScience Personal CA and hierarchy (EU) * Updated AustrianGrid root cert with extended life time (AT) * Updated PolishGrid CA with new contact and extended root CA life time (PL) * Removed expired CNRS-Grid-FR CA (has been superseded by CNRS2-Grid-FR) (FR) * Removed obsolete CNRS, CNRS-Projets CA (superceded by CNRS2 hierarchy) (FR) * Corrected namespaces file for BEGrid2008 (BE) * Added comment line to REUNA CA signing_policy file (CL) * Added new classic CESNET hierarchy "CESNET-CA-Root" and "CESNET-CA-3" (CZ) * Updated (re-rooted) selected UNaccredited CAs in the "worthless" area
If you part of a coordinated-deployment project (such as OSG, EGEE, LCG, DEISA, NAREGI or others) you may want to await your project announcement before installing this release. The download repository is also mirrored by the APGridPMA at https://www.apgridpma.org/distribution/igtf/current
Next Release ------------ The next release of the distribution is expected in April 2010.
========================================================================= 2. Distribution format changes in the wake of OpenSSL version 1 =========================================================================
IMPORTANT NOTICE ----------------
This 1.33 distribution comes in two (2) formats. The primary format for this 1.33 release is the 'current' one, which has no changes. A 'new' format, available for your evaluation as of this release at: https://dist.eugridpma.info/distribution/igtf/1.33-new/ supports also OpenSSL v1 and is designed to be backwards compatible with the current distribution format.
*** YOU ARE INVITED TO EVALUATE THIS NEW DISTRIBUTION FORMAT NOW ***
In a subsequent release (1.34 or 1.35), the 'default' distribution will change to the new format and the current format will be depricated and only available via a special URL. The default download location https://dist.eugridpma.org/distribution/igtf/current/ will then point to the new-format distribution.
Releases after 1.35 (Autumn 2010) may withdraw this then-depricated format and from then on only the 'new' format will be distributed.
BACKGROUND ---------- It has come to the attention of the IGTF that the developers of the OpenSSL software (www.openssl.org) are about to release a new version of their software (version 1.0) which is fundamentally incompatible with both any pre-existing versions of their own software, as well as bring incompatibility with many other software products that use a directory-based trust anchor store (such as Apache's mod_ssl, the gLite Trust Manager, gridSite or VOMS).
A directory-based trust anchor store ("/etc/grid-security/certificates/") contains a set of files, each of which holds a single, PEM encoded, certificate that you trust. These files are named "XXXXXXXX.i", where the X'es are hexadecimal digits and "i" a number, usually "0". For example:
/etc/grid-security/certificates/16da7552.0 /etc/grid-security/certificates/16da7552.crl_url /etc/grid-security/certificates/16da7552.info /etc/grid-security/certificates/16da7552.namespaces /etc/grid-security/certificates/16da7552.r0 /etc/grid-security/certificates/16da7552.signing_policy
In this case, the "16da7552" is a hash ('digest') of the subject name of the CA in question, namely "C=NL, O=NIKHEF, CN=NIKHEF medium-security certification auth". Files with related meta-data, such as the URL where a CRL can be obtained, or the allowed name spaces in to which this CA is accredited in the IGTF, are named after the hash of the CA subject name.
Although, on first glance, the trust anchor directory in an OpenSSL v1.0 installation looks the same, the mechanism to compute these hashes has changed. So, what appears to be a 'normal' trust anchor directory no longer works when OpenSSL1 is used. However, all other current software (Apache mod_ssl, the gLite Trust Manager, etc.) will continue to work without problems. Not having the 'new' hashes installed will not lead to security risks, but it will prevent successful authentication and thus lead to unavailability.
The IGTF regrets this unwarranted change made by the OpenSSL developers, but cannot shield its relying parties and end-users from this change. Since the IGTF distributes the trust anchors of accredited authorities also in a way that used to work with OpenSSL, we feel that it is in the community's interest to keep supporting OpenSSL also for version 1, whilst ensuring that other softwares continue to work as before.
Since we anticipate that relying parties will at some point install OpenSSL version 1, and will do so whilst at the same time running other software on the same system or using the same trust anchor directory (e.g. over a distributed or shared file system), we have designed a new distribution format that will support both the conventional hash method as well as the new OpenSSL1 mode.
The new format is based on the following structure:
- In the installation bundles, tar-balls and RPMs, all CAs and files are named after their alias from the info file
- Symbolic links are used to generate the structure for BOTH the current hash mode (OpenSSL 0.x and all other software) AS WELL AS for OpenSSL 1.0 This means that it will no longer install on FAT32 file systems, or on any file system that does not support symbolic links
- Since the "fetch-crl" utility, distributed by the IGTF to facilitate periodic downloads of CRLs for each CA, will use the file name of the crl_url file, and the local version of OpenSSL to generate the hash itself, it can handle symbolic names for the crl-url file.
The name of the CRL downloaded will be derived from the version of OpenSSL used. To generate CRLs for both hashes, run this utility twice, but using a different version of OpenSSL; or make symbolic links for the 'other' hash 'XXXXXXXX.r0' file.
You can select the version of OpenSSL used by the fetch-crl utility by setting the "FETCH_CRL_OPENSSL" variable in the environment or in the fetch-crl configuration file (/etc/fetch-crl.conf or /etc/sysconfig/fetch-crl)
- The installation bundle (used for "./configure && make && make install") will create both symlinks in its installation directory (specified with --prefix=)
- The pre-installed bundles for each of the accreditation classes have both hashes installed, using symbolic links. These pre-installation bundles can thus be used only on file systems that support symbolic links, or where the un-packing utility transparently translated symbolic links to hard copies
When deployed, a new-format IGTF trust anchor distribution will look like:
.../16da7552.0 -> NIKHEF.pem .../16da7552.info -> NIKHEF.info .../16da7552.namespaces -> NIKHEF.namespaces .../16da7552.signing_policy -> NIKHEF.signing_policy .../dfb080e4.0 -> NIKHEF.pem .../dfb080e4.info -> NIKHEF.info .../dfb080e4.namespaces -> NIKHEF.namespaces .../dfb080e4.signing_policy -> NIKHEF.signing_policy .../NIKHEF.crl_url .../NIKHEF.info .../NIKHEF.namespaces .../NIKHEF.pem .../NIKHEF.signing_policy
Please note that - some software may now import the same CA /twice/, potentially doubling memory usage. Although this is not expected to cause problems, you are invited to verify that this new format accommodates your requirements. - the crl_url file is not duplicated, since fetch-crl will find this file based on its extension (not name), and the CRL file is written with the hash computed with the OpenSSL version used by fetch-crl at run time.
COLLATERAL CHANGES ------------------ At the same time, the IGTF for the 'new' distribution will update its build architecture and incorporate the following changes:
- the RPMs built by the IGTF, although based on the same SPEC files, will be constructed using RPM version 4.4.2.3 (this version is shipped, for example, with CentOS 5, RedHat Enterprise Linux 5 and like systems)
- the Java Key Stores are built now with Java 6 (jdk-1.6.0), and from now on will also contain certificates with key lengths larger than 2048 bits
========================================================================= REPEATED NOTICES =========================================================================
This newsletter carries IGTF information intended for relying parties. For more information about this newsletter and how to subscribe, refer to the EUGridPMA web site at https://www.eugridpma.org/
+-----------------------------------------------------------------------+ | For information on the IGTF Distribution, how to use it and what is | | contains, please read the information at | | https://dist.eugridpma.info/distribution/igtf/README.txt | | | | This file containes important information for new users and should be | | read before installing this Distribution. | +-----------------------------------------------------------------------+
If you have suggestions or improvements for the distribution format, to have it better suit your needs, please contact the EUGridPMA PMA at info@eugridpma.org or your Regional Policy Management Authority. See the IGTF web site (www.igtf.net) for further information.