>> In my mind this is good enough reason to outlaw keytag collisions - >> without them it would be _much_ easier to implement reasonable limits >> without risk of breaking legitimate clients. > > That would make key tags meaningful. ;--)
That may be an inevitable consequence. To my mind, the problem pointed to by "this is good enough reason" is worth avoiding. > The question is how, in a multi-signer friendly way. If I were to be slightly flippant, I'd say "that's a stupid (er... "complicated") feature anyway, so the burden of ensuring this constraint is followed should fall on the provider of the feature". It might not be "friendly"... Now, I realize this might be a desireable feature (e.g. when transitioning from one signing provider to another), but if I understand correctly, there's several ways to do it. One is to line up the signers "behind each other", so that the second one signs an already-signed-by-the-first-signer zone, and in that case it should not be rocket science to eek out the key tags from the DNSKEY records from the already-signed zone, and ensure non- collision for the key tags when you generate new keys to sign the zone, or make sure to generate new keys if those you already have on hand have a collision with any of the "older" DNSKEYs. Or have I totally misunderstood, and your statement about required time of enforcement is a universal property of all multi-signer scenarios? Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
