[Opendnssec-develop] interface between enforcer and signer

[John Dickinson]

On 24 Feb 2009, at 11:13, Rick van Rein wrote:

> Hello Jacob,
>
>> John, Jelte and myself now has a proposal ready for the interface
>> between the enforcer and signer.
>
> I've had a look.  Thanks for creating these docs, they look good.
>
>> http://www.opendnssec.se/wiki/Signer/Configuration
>
> Can you indicate _between_ which components these formats are sent,
> instead of just _to_ which one it is sent?
>
>> http://www.opendnssec.se/browser/docs/signconf.xml
>
> Perhaps rename <resign/> to <re-sign/> as people tend to do in
> plain English to avoid confusion?
>
> It is not clear yet what PT2H means, and how it differs from 2H.
> Similarly for P3D, P7D, P14D, PT12H, PT300S.  Do I read from the
> <signatures/> element that SOA parameters are decided upon by
> the KASP/Enforcer?

PT2H and friends are defined here http://www.w3schools.com/Schema/schema_dtypes_date.asp

The Enforcer needs to know the SOA parameters in order to correctly  
calculate key rollover. I think it is best if the signer ensures that  
the signed zone uses parameters that the Enforcer expects. Of course,  
it would be nice if there was a link between the registry system  that  
builds the un-signed zone and the KASP DB as well.
>
>
> In the <keystore/> you refer to <flags/> and <protocol/> and
> <algorithm/> values by numbers.  These clearly depend on some
> external register of definitions.  Please make clear where these
> are defined, so software builders know where to look.  It is always
> good to define what happens in case an unknown bit is encountered.
>
> There's double information in this setup:
> 1. <ksk/> versus <zsk/>
> 2. <flags/> bit 0
> What rules dictate consistency, what happens if there is a failure,
> and is it the best course of action to have such double specs?

I don't understand what you mean by double specs.
>
>
> As for the timing constants, what relationships do they have, and
> is it possible to trick the system into, say, a dropped domain if
> it gets confused with contradicting information?
I don't think so. But we do need to define what makes the parameters  
consistent and valid. This is on the Enforcer todo list.

>
>
> If I recall well (but I am not 100% sure) the <opt-out/> allowed
> for partial opt-outs in the zone list.  I am not convinced this

Partial opt outs are bad and would make dynamic updates impossible.  
Lets just not go there.

>
> would be practically usable to have part of a zone opted in and
> part of it opted out.  If it could be useful, this interface
> description should _consider_ taking it into account.  (This is
> a weak point, just trying to provoke thought.)  For subdomains
> an opt-out may be really useful, say for dyn.harderwijk.edu
> which would hold the DHCP-assigned IPs within this University.
>
>> http://www.opendnssec.se/browser/docs/zonelist.xml
>
> I would not be surprised if we'll need <timestamp/> for more than
> one thing; perhaps adding a parameter could help.  Just a thought.
> It would certainly give a somewhat stronger suggestion as to its
> semantics.

The timestamp allows the signer to know if it needs to re-read the  
signer config for that zone. So the signer can scan the minimal zone  
list and only read the policy in the signer config when necessary.  
Hopefully this will scale better than having all zones in one big xml  
doc.

>
>
>> also a draft of the KASP XML format in:
>>
>> http://www.opendnssec.se/browser/docs/kasp.xml
>
> Similar remarks to the ones above:
> - time prefixed P and PT
> - <ksk/> and <zsk/>
> - <alogrihtm/> should be linked to its spot of definition
> - <opt-out/> maybe over partial domains?
>
> Additionally,
>
> <overlap/> -> what does that mean?

This is being written up - see http://www.opendnssec.se/browser/docs/draft-opendnssec-terms.pdf
>
>
> <length/> -> perhaps rename it to <bits/> or <bitlength/>

length is the term used in RFC5155
>
>
> <rfc5011/> -> I think it is generally good to distinguish between
> 	generating and accepting this standard, as it is somewhat
> 	controversial material and may be replaced with an alternative
> 	some day.  But the only utility of RFC 5011 in this spec would
> 	be generating, right?

I don't remember anything about 5011 off the top of my head, I keep  
reading it and always forget it totally - My understanding is that  
this is more a flag that will be used in a future version of  
OpenDNSSEC - possibly with additional parameters defined.
>
>
> I hope these remarks / questions are helpful.


Yes, thanks
John
---
John Dickinson
http://www.jadickinson.co.uk