[Opendnssec-develop] Importing shared keys

[Sion Lloyd]

> > Right. I would certainly only link it to that one zone initially. However
> > if you are sharing all other keys why not this one? Currently it would
> > go into the pool of unused keys for other zones on the policy, is this
> > bad?
> 
> Not necessarily, I guess it will just sit in that pool and not be used.

Why shouldn't the key be used?

> > I'm not sure that we want/need a policy rollover where the policies are
> > identical apart from the shared-keys parameter. I would need to be
> > persuaded on this one.
> 
> Ah, my bad, I'm thinking in solutions. The use case is simple: I would
> like to be able to move a zone from a one-key-per-zone situation to a
> shared-key situation. How that is solved doesn't really matter (but a
> policy rollover is one option, another is to change an existing policy).
> The rationale for this is simple: we cannot have shared keys in our set
> up as it is because of the limitations in OpenDNSSEC 1.1.x; in the
> future, however, when OpenDNSSEC does support this, we want to be able
> to migrate from a one-key-per-zone situation to a one-key-per-customer
> (shared) situation.

Okay. I think that I misunderstood "rollover" in this... Do you mean that we 
immediately retire the current set of keys, or just that all new keys will 
come from the new policy?

I have a story set up for this:
http://www.pivotaltracker.com/story/show/1086197

Moving from unshared to shared is okay I think, anything else is a bit more 
tricky; but let's not worry about that right now.

> > Yes, thank you. It also makes me think of something else. Currently you
> > can import any key onto a zone, _even_ if it does not comply with the
> > current policy... This will no doubt confuse the auditor, so should we
> > stop it from importing, warn or something else?
> 
> Ah. My personal opinion is that this is a "deny and give an error unless
> user specifies --force" situation ;-)

Sounds good to me.

Sion