Section 2.1.2: It's still not clear exactly how the <secDNS:infData> element's sDate, eDate and vInterval should be used: in particular, none of these seem to specify a desired RRSIG lifetime. Perhaps sDate and eDate are intended to do that, though it's likely that a DNSKEY will be in use for far longer than the requested signing interval -- perhaps another field <maxRRSIGlifetime> is needed? This way a client could say: don't publish this DS until time X, use an RRSIG lifetime no more than 3 days, resigning the DSset every day, and quit publishing this DS after 30 days.
I'm going to take a stab at this from this comment. (The section is 3.1.2.)
I'm cartooning this, refer to the draft for the full story:
Inside a dsData element: req/opt set by
keytag required innate (client)
alg required innate (client)
digestType required innate (client)
digest required innate (client)
sDate required client wish, overruled by server
eDate required client wish, overruled by server
vInterval optional client wish, overruled by server
ttl optional client wish, overruled by server
keyData (4 subel'ts) optional innate, may be ignored by serverI suggest making the sDate and eDate optional. The only indisputable elements are the keytag, alg, digestType and digest, there's no alternative to the client sending this.
All of the optional elements would then be subject to the statusData element in 3.2.1., answering Marco's comment.
The default value for sDate would be "now." The default date for eDate would be the expiration time on record for the domain. (For domains that don't expire, then the eDate is "forever.")
The expiration time on a domain is not the end of the domain's time, the domain may be later renewed - I think it's *arguably* reasonable to not change the eDate when this happens. Hopefully at renewal the DS records are included in the invoice. Like I say - arguable.
A registry may decide that it won't hold future records - like I would question the sensibility of storing keys that won't come of age until after the expiration time of the domain.
I think: sDate might be "now" <= sDate <= expiration time, default to now. eDate might be "now" <= sDate < eDate <= expiration time, default to expire
How does this relate to the RRSIG(DS) validity span? It brackets it. I.e., no RRSIG(DS) should be temporally valid prior to sDate. No RRSIG(DS) should be temporally valid after eDate. But there can be an RRSIG(DS) that becomes temporally valid a day after sDate and becomes temporally invalid a day before eDate ("a day" for instance).
(Scott - this is my interpretation. Correct me if I am wrong.)
And then for vInterval, well, I am a bit fuzzy on this one to tell the truth. The client may want a new RRSIG(DS) done daily, but I can't quite fine a good reason why. Hmmph. I mean, if the client wants to remove the key in question, it can just remove it from the DNS at its end and the DS becomes a dangling reference, harmless for the most part, unless the reason for pulling the key was exposure. (In that case, the client ought to urgently get the DS pulled too.)
Speaking of urgent, the elements of statusData would now be
sDate
eDate
vInterval
ttl
keyData
urgentAnd the allowed (by not always sensible) response would be "accepted", "ignored", and "missing."
But this doesn't really do [se]Date any good. The dates are in the registry, not in the DNS. Right? Would then be in the WhoIs/IRIS? (Do we need to extend IRIS for DNSSEC data? Note to check on that.)
Comments? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
