> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Andrews wrote:
> > It's not a issue. You remove the DS's which have that
> > algorithm then once they have expired from caches you can
> > remove the DNSKEY.
>
> That could still leave the zone itself in an inconsistent state... I'm
> not talking about the DS<->child apex case, but the apex<->zone data case.
If there is a DS with algorithm A then you have to have the
entire zone signed with that algorithm. Once the DS has gone
then that requirement no longer exists.
> The DNSKEY that is removed or added doesn't have to be one that is
> pointed to by a DS. Merely being present in the apex implies that there
> should be signatures of that algorithm in the zone.
No. The DS / published trust anchor indicates support for
the algorithm. Just having a DNSKEY at the apex does not
indicate support for a algorithm.
Mark
> If you don't add/remove all keys at the same time, the first or last
> DNSKEY couldn't even be a KSK; since those keys aren't used to sign the
> zone data, having a KSK as the only key of a certain algorithm number
> would always violate section 2.2.
>
> Unless of course I am misreading that MUST there :)
>
> Jelte
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAki/444ACgkQ4nZCKsdOncVoEACg2XThBDfSoUosRQBUTDcL2jYg
> bKkAoKNU4hLa/s5/xPlGVQp6XKXV7Uyv
> =TLej
> -----END PGP SIGNATURE-----
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
