[Opendnssec-develop] Enforcer engine design v2 work breakdown

[Roland van Rijswijk]

Hi Yuri,

On 29 jun 2011, at 12:37, Yuri Schaeffer wrote:

> A status update:
> 
> I'm happy to tell I made some good progress with the rules. I've
> introduced a bunch of likely rollovers to my prototype which all roll as
> expected as far as I can tell. Next thing I will do is update the
> document with the changed rules and add a better explanation. Than start
> coding again. I asked Matthijs to review the output of the prototype. 
> 
> Aside the dnssec validity rules the are some policy issues coming to the
> surface the past days. 
> 
> The main problem is that policy information is not tied to a key (in my
> initial design it was but this was somehow dropped by Rene and me in the
> actual implementation as redundant). When a policy changes all existing
> keys should still propagate according to the old policy. This is fixable
> after Rene's vacation. (I will not block on this)

Do I understand correctly that this will only affect keys that are already in use?

> The other thing that *might* be a problem is that the algorithm
> implicitly assumes you'll want to have only one key of each role. It
> will not keep juggling two ZSKs if one is enough to validate. I worked
> out a rough idea for a fix with Matthijs. It requires no changes from
> Rene but it's non-trivial. Therefore I want to know whether or not we
> want to support this. Is there a usecase? There is not much
> code-dependency so changing this at a later time will not increase
> required work.

I don't really see a use case for having two ZSKs other than when you are using two algorithms to sign a zone or perhaps if you want a standby ZSK (e.g. if you keep separate key material on two physically separate HSMs with different security worlds, although this would be ultra paranoid). But perhaps I'm overlooking more valid use cases ;-)

> I did (and introduced an ordening) and dropped it again. This is now a
> policy decision, not reflected in the rules.

Can you explain why that is and what changes you made? I recall we had quite a bit of discussion about this during the last call.

>> - Figure out how the user should indicate that an insecure zone is okay
>> to have. How does this policy look like? (again, input request for all
>> of you)
> 
> Don't know yet. How about a policy with no keys?

That sounds reasonable.

Cheers,

Roland

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl