Dear CAs, Relying Parties, Users, and all others interested,
In this announcement of the IGTF:
1. Updated IGTF distribution version 1.34 available
2. Distribution format changes in the wake of OpenSSL version 1
(repeated annoucement)
=========================================================================
1. Updated IGTF distribution version 1.34 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.34, 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.34-new/
(new format)
Changes from 1.32 to 1.33
-------------------------
(18 February 2010)
* Corrected malformed EACL syntax in signing_policy for CESNET-Root-CA (CZ)
Since this is a quick-fix for the 1.33 distribution, you are reminded
of these changes in 1.33 in case one migrates from a previous version 1.33:
* 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.34 distribution comes in two (2) formats. The primary format
for this 1.34 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.34-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.35 or 1.36), 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.36 (Autumn 2010) may withdraw this then-depricated
format and from then on only the 'new' format will be distributed.
For more information, please refer to the February 15th newsletter:
https://www.eugridpma.org/newsletter/eugridpma-newsletter-20100215.txt
=========================================================================
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(a)eugridpma.org> or your Regional Policy Management Authority. See
the IGTF web site (www.igtf.net) for further information.
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(a)eugridpma.org> or your Regional Policy Management Authority. See
the IGTF web site (www.igtf.net) for further information.