shared KSK for static zone and dynamic subzone?

[/dev/rob0]

On Tue, Apr 26, 2011 at 10:15:18AM +0100, Phil Mayers wrote:
> On 04/26/2011 02:13 AM, /dev/rob0 wrote:
> > Is there any
> >reason why I can't use the parent zone's KSK for the dynamic
> >zone? Better yet, is there a reason why I shouldn't?
> 
> Better yet, why *would* you? Keys aren't exactly expensive to 
> generate.

Again, the $SUBJECT problem is resolved, but I have come upon a 
possible reason to reuse a key.

I'm setting up a private namespace (RFC 1918 networks and imaginary 
domain names) named+dhcpd system with three static zones, a dynamic 
forward zone, and two dynamic reverse zones. Six total.

I want all these zones to be signed. Why? No good reason, just a
learning exercise, actually. "Because I can."

Obviously I can't get into the root with DS records. I'm going to 
have an "island of security."

Two or three other sites are running named and connected via VPN. 
These sites need to be able to validate my signatures.

With one KSK and one ZSK per zone, we're looking at *12* keys to go 
in the connected sites' trusted-keys. Errr, no, I guess I only need 
the KSKs, but still, that's 6. I'd prefer that it be fewer than that. 
One sounds simpler, in fact.

While writing this, a compromise came to me. :) I can run forward 
zones as children of a single TLD, and use 168.192.in-addr.arpa. as 
parent for all my reverse zones. :)

So that's what I'm going to do. Two more zones, four more keys, but 
only two in trusted-keys. Tolerable.

> Anyway, the answer is "not really". The keys that bind generates
> include the zone name, and you can't easily use a key whose name
> != zone, and certainly not whose name is in a different zone.
> 
> You're just complicating your life to no benefit. Use a different 
> key for the child.

I'm a bit late to the DNSSEC party, what with the signed root being 
in place already, but ISTM that these trusted-keys could be a major 
management problem. Am I wrong? Is it still a problem?
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header