Dear Colleagues, As noted during RIPE 59, the RIPE NCC is upgrading the current DNSSEC provisioning infrastructure. This project includes the replacement of current software signers with a more secure hardware solution. During this migration, an exception will be made to the double signing policy outlined in our key maintenance procedure, which is available at: https://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html In order to reduce the likelihood of validation errors as much as possible during the migration, a one-time exception will be made to the policy of double signing our Key Signing Keys (KSKs). This is because it is not possible to exchange keys between our old and new signers. To prevent signing all our zones on two signers and then merging the results, we will pre-publish the new KSK in March 2010 as a one-time exception. The DNSSEC signer migration will involve the steps detailed below. The dates align with our standard key rollover timings, as detailed on our website at: https://www.ripe.net/projects/disi//keys/ On Tuesday, 2 March 2010, our signer will switch to the currently pre-published Zone Signing Key (ZSK). This ZSK will not be rolled over again until Monday, 14 June 2010. No new trust anchors need to be configured for resolvers at this point. On Tuesday, 23 March 2010, we will pre-publish a new KSK and ZSK in our zones. The new KSK will be available in our trust anchor repository, also available at: https://www.ripe.net/projects/disi//keys/ One KSK will be in use, but both KSKs must be configured as trust anchors in DNSSEC validating resolvers. On Monday, 14 June 2010, the old KSK and ZSK will be deprecated. Only the new keys will be able to validate. One KSK will be in use. On Tuesday, 21 September 2010, we will publish a new KSK on our website and continue with our usual double signing policy. Two keys will then be in use. Given that the parent zones of the RIPE NCC's zones are likely to be signed in the near future, we will continue to follow the current key maintenance procedure and lifetimes after the migration in completed. This will allow us to make a more informed decision on the RIPE NCC's key lifetimes when the policies for our parent zones are known. Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC