Ed writes: > Currently there are four timing parameters: > > 1) TTL suggestion > 2) vInterval (signing frequency parameter > 3) startDate > 4) endDate > > If these dates are not honored, the current situation treats this as a > warning. > > Here is what we think it ought to become... > > 1) TTL limit > 2) Validity span limit > > Treating failure of the server to accommodate these as hard failures.
In general, I think Ed and I are now on the same page. I concur that a validity spam limit (which I called maxRRSIG lifetime) is needed, and I like the idea of a hard failure, for the reasons Ed described. I'm not sure the hard failure is needed for TTL, but it doesn't sound harmful. Furthermore, I expect that a resigning interval (which will be shorter than the validity span) can be calculated by the parent, as I discussed in: http://darkwing.uoregon.edu/~llynch/dnsop/msg03337.html However...the current draft does include those sDate/eDate parameters for telling a parent when to to first (and last) publish a DS. From a security standpoint, they probably aren't strictly needed (it may depend on what you want the failure mode to be if the child doesn't contact its parent regularly: do you want the DS to keep getting resigned forever and always or just timeout?). I assume there was some reason for them to be in the draft, so it's probably worth explicitly asking if that functionality desired by anyone. -- Sam . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
