New key-signing keys (KSKs) for RIPE NCC forward and reverse zones
Dear Colleagues, On 12 March 2009, the RIPE NCC generated new key-signing keys (KSKs) for all the DNSSEC-signed zones that it operates. We have published updated trust anchor files for inclusion in validating resolvers. A list of all the zones that we sign and the trust anchor files are available at: https://www.ripe.net/projects/disi/keys/index.html The old KSKs are deprecated and will be removed from the zones on 15 June 2009. Please update your trust anchors before this date. Regards, Anand Buddhdev DNS Services Manager RIPE NCC
Moin! On 12.03.2009, at 16:09, Anand Buddhdev wrote:
On 12 March 2009, the RIPE NCC generated new key-signing keys (KSKs) for all the DNSSEC-signed zones that it operates. We have published updated trust anchor files for inclusion in validating resolvers.
A list of all the zones that we sign and the trust anchor files are available at: https://www.ripe.net/projects/disi/keys/index.html
This may be my error, but for me the pgp signature isn't correct: RitterRost:Downloads rw$ gpg -v --verify ripe-ncc-dnssec-keys- new.txt.asc ripe-ncc-dnssec-keys-new.txt gpg: armor header: Comment: For info see https://www.ripe.net/rs/pgp/ gpg: Signature made Thu Feb 5 11:57:16 2009 CET using DSA key ID 4BD4468C gpg: using classic trust model gpg: BAD signature from "RIPE NCC <ncc@ripe.net>" gpg: textmode signature, digest algorithm SHA1 RitterRost:Downloads rw$ ls -l ripe-ncc-dnssec-keys-new.txt*-rw-r--r-- @ 1 rw rw 58977 Mar 12 18:53 ripe-ncc-dnssec-keys-new.txt -rw-r--r-- 1 rw rw 206 Mar 12 18:55 ripe-ncc-dnssec-keys- new.txt.asc RitterRost:Downloads rw$ gpg --fingerprint 4BD4468C pub 1024D/ 4BD4468C 2008-12-02 [expires: 2010-02-02] Key fingerprint = 44DB B621 ABC8 9A30 A8F1 916B F7D3 6B18 4BD4 468C uid RIPE NCC <ncc@ripe.net> sub 2048g/7D91E9E5 2008-12-02 [expires: 2010-02-02] RitterRost:Downloads rw$ cat ripe-ncc-dnssec-keys-new.txt.asc -----BEGIN PGP SIGNATURE----- Comment: For info see https://www.ripe.net/rs/pgp/ iD8DBQFJisYM99NrGEvURowRAt8cAJ0fQ8p70WnKkeYmrAjLaduz2fZeMgCeMvtd 3+B7Bot3cSTImZvWsAjhi/Y= =a+JU -----END PGP SIGNATURE----- Any idea why? So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400
On Thu, Mar 12, 2009 at 07:01:15PM +0100, Ralf Weber wrote: Hello Ralf,
A list of all the zones that we sign and the trust anchor files are available at: https://www.ripe.net/projects/disi/keys/index.html
This may be my error, but for me the pgp signature isn't correct:
Apologies for this. This wasn't your error - the new signature file had been generated, but not propagated to the RIPE NCC website. I have pushed out the correct signature file now. If you fetch it again, it should verify. Regards, -- Anand Buddhdev DNS Services Manager, RIPE NCC
Moin! On 12.03.2009, at 22:28, Anand Buddhdev wrote:
A list of all the zones that we sign and the trust anchor files are available at: https://www.ripe.net/projects/disi/keys/index.html
This may be my error, but for me the pgp signature isn't correct:
Apologies for this. This wasn't your error - the new signature file had been generated, but not propagated to the RIPE NCC website. I have pushed out the correct signature file now. If you fetch it again, it should verify. Yes it does. Thanks for the prompt response.
So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400
* Anand Buddhdev wrote:
On 12 March 2009, the RIPE NCC generated new key-signing keys (KSKs) for all the DNSSEC-signed zones that it operates. We have published updated trust anchor files for inclusion in validating resolvers.
Are you going to use RFC 5011 to remove the old keys?
Lutz Donnerhacke wrote:
On 12 March 2009, the RIPE NCC generated new key-signing keys (KSKs) for all the DNSSEC-signed zones that it operates. We have published updated trust anchor files for inclusion in validating resolvers.
Are you going to use RFC 5011 to remove the old keys?
Hello Lutz, The toolset that we're using does not have support for setting the revocation bit, so we won't be setting it. Are many people actually running resolvers that understand RFC 5011? -- Anand Buddhdev DNS Services Manager, RIPE NCC
* Anand Buddhdev wrote:
The toolset that we're using does not have support for setting the revocation bit, so we won't be setting it.
Clear statement. Thank you.
Are many people actually running resolvers that understand RFC 5011?
Unbound has support for RFC5011 as well as the current developement version of bind (might be 9.7). So it's hard to say how many people are deploying this RFC. It seems to become the default algorithm for standalone resolvers.
Furthermore, there are resolver independent implementations of RFC 5011, like autotrust and trustman. - Matthijs Lutz Donnerhacke wrote:
* Anand Buddhdev wrote:
The toolset that we're using does not have support for setting the revocation bit, so we won't be setting it.
Clear statement. Thank you.
Are many people actually running resolvers that understand RFC 5011?
Unbound has support for RFC5011 as well as the current developement version of bind (might be 9.7). So it's hard to say how many people are deploying this RFC. It seems to become the default algorithm for standalone resolvers.
On Tue, 17 Mar 2009, Anand Buddhdev wrote:
The toolset that we're using does not have support for setting the revocation bit, so we won't be setting it.
Are many people actually running resolvers that understand RFC 5011?
Autotrust can update the keys and restart the resolver with the new keys primed for it. This is the setup currently in Fedora-11 Beta. Paul
participants (5)
-
Anand Buddhdev -
Lutz Donnerhacke -
Matthijs Mekking -
Paul Wouters -
Ralf Weber