[dns-wg] DNSSEC Signer Replacement Project

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