CA stuff

Three almost unrelated things, except that they relate to the CA(s), somewhat technical stuff, so bear with me:

• If you have renewed your certificate recently and found that it didn't work with VOMS, this is due to a misdesigned "feature" of VOMRS that it insists on registering not just the user name but also the issuer name as part of the account. In the Real World(tm), we can keep the issuer (ie CA) name the same all the time but this does not work with grid middleware, so we have to change issuer name whenever we roll over. The "feature" adds no extra security for grid CAs because the user name will always be unique. There is a workaround that tells the server to ignore the feature, which we thought everyone had been using for years - but this, as Steve Traylen points out, will still cause problems if your certificate expires before you can resign the AUP (surely a rare case?!) - but should otherwise work fine. The best option otherwise seems to be to get your VOMS admin (not VO admin!) to duplicate the account entries, one with each issuer name, the old and the new one. CERN (Steve) has done this with theirs, and we are checking the other ones to see if they have failed to enable skipcacheck.  I am both amazed and sorry that we have not discovered (and resolved) this sooner... but Steve is a Wizard(tm) and will fix it...  Incidentally, it is not just us, other CAs roll over too - however, many have chosen to extend the lifetime of the existing certificate instead of renaming it - this will then not cause problems with the VOMRS accounts, but it causes problems with server/client synchronisation for HTTPS instead - if the server and client (browser) are not updated in sync (and they never are), some browsers will print obscure error messages and fail to connect (as we know from past experience).
• Oh, and another good thing is that the IGTF rules have changed - we can now make the end entity issuing CAs have longer lifetime, so we no longer have to roll over every four years.  Hooray!
• On the subject of IGTF 1.43 release which came out recently. We're rebuilding the NGS-specific release except we are going back (or forward?) to individual RPMs instead of a single one for the lot - this means we need a couple of dependency RPMs but we should then be able to not mess with the IGTF stuff much and sites can in principle fine tune what they install. We'll have to think about the dependencies carefully.
• Related to this (so, er, not entirely unrelated), there is this problem with the IGTF root signing policy file. We're trialing the Least Elegant Workaround(tm) this time, having discussed it at some length, by testing a self-signed version of the SLCS toplevel. This makes it independent of the root in the technical sense of building a verification path and checking signing policy files, so would slot in next to an unmodified IGTF release directly - but the downside is that we now have another self signed certificate that we'd need to establish trust in, and the fact that the policy of the SLCS branch (ie the SARoNGS CA, the CEDA CA, etc.) were supposed to be covered by the root CP. Depending on how good this looks (we're testing it from today), this may appear in 1.43.
• Oh yes, and I know I need to get TACAR corrected and updated. This is not trivial (requires writing forms and pgp signatures) so is awaiting a slot where I have some time...

That was three things, for suitably large values of three. If you have any questions, do get in touch...