In preparation for the agenda item
  Layout of the Trust Anchor Distribution in the Wake of OpenSSL1
scheduled for Tuesday during the EUGridPMA Dublin meeting, I would
like to share a bit of background with you:

After a warning by Anders Waananen (thanks!!!), we found out that
the new (currently still beta) releases of the OpenSSL 1.0 library,
used by many (grid) software packages and, e.g., apache httpd,
have CHANGED the HASH algorithm used for lookup of certificates in
the trust anchor store. The infamous "16da7552.0" files and the
like. When used with OpenSSL v1.x, the current IGTF distribution
fails miserably ...

So, OpenSSL1 uses a different hash algorithm for the trust anchors
store (for grid middleware traditionally in
"/etc/grid-security/certificates/"), which makes is incompatible with
previous releases. The apparent naming of the anchors (8 hex-digits,
followed by a DOT "." character and a sequence number) is the same, but
the algorithm used to make the hash from the subject DN of the certificate
is different: it's now based on SHA1, instead of MD5, for no sane reason
whatsoever :-(
If you just install the 'old' certificates, they will no longer be found
and authentication will fail (which happened to Anders with a Fedora beta
release).

For the discussion next week, I've tried out a couple of new distribution
formats, and the latest test version that I felt somewhat comfortable with
contains the following changes:

------------------------------------------------------------------------------
IGTF Distribution changes proposed

- In the installation bundles, tar-balls and RPMs, all CAs and files are named
  after their alias from the info file
- Symlinks are used to generate the structure for BOTH version of OpenSSL.
  This also means that it will no longer install on FAT32 file systems, or on
  any file system that does not support symlinks
  * We could make copies as well, but this is less maintainable and unclear
- Since "fetch-crl" 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. Thus, there is no symlink for the crl-url files, since
  this would lead to double or triple downloading
- Currently, the installation bundle (the "./configure && make && make
  install" tarball) will create both symlinks. We could also use the local
  OpenSSL and make on the one approriate for the systems where the install is
  run, but then (1) it cannot be used for exporting the same certificate
  directory to different systems and (2) it needs openssl installed on the
  system where the install is run.
- the pre-installed bundles have both hashes, using symlinks

And also proposed from now on:
- All RPMs are created with RPM version 4.4.x, i.e. the one from RHEL5
- The Java key store is generated by Java 1.6. This means that (finally) CAs
  with a root keysize of 4096 bits will be included in the distribution also
  in the JKS, but that the keystore may be unreadable for Java 1.4 clients
  with the default crypto provider.

A sample build is at:

https://dist.eugridpma.info/distribution/tests/PMA-PRIVATE-PREVIEW/el5rebuild-openssl1/distribution-1.33x/

------------------------------------------------------------------------------

I will talk about these changes in more detail in two weeks, but for the
time being, start thinking about this subject and the effects it may have
on other relying parties that currently take certificates  directly from
your own web sites.

How the various middlewares use the associates files (XXXXXXXX.signing_policy
and XXXXXXXX.namespaces) is unknown, but I guess they will use the
same OpenSSL routines for hashing. If any middleware has independently
re-implemented the hashing function, then you will need *both* versions
in the trust store, since the same program will use both hashes at the
same time :-(

At least fetch-crl works independently of the source file name, although
the CRL it spits out will be customised to the OpenSSL version that is used
by fetch-crl at runtime.