> I'm not sure [RRSIG lifetime] is needed as it seems a bit redundant > to me. Sam please correctly if I'm wrong.
Here's a note on the topic that I sent to Scott back in January that may explain better. In short, there is some redundancy is including BOTH a resigning interval and a maximum RRISG lifetime, but those numbers will be different. It may be possible to derive one from the other, but I'm not exactly sure what calculation should be done for that. To be very clear, I do think maximum RRSIG lifetime is a security-critical parameter and that an EPP client should be able to request it explicitly. In the below note, I suggesting calculating a maxRRSIGlifetime based on the resigning interval (vInternal) -- I think it would be better to calculate that the other way around, deriving the resigning interval from the RRSIG lifetime, assuming that any calculation is done at all. One could also use the sDate/eDate to specify the maximum RRSIG lifetime, but that would mean far more frequent EPP updates (essentially saying "yes, it's okay for you to keep publishing this DS record for me", and saying it on a very regular basis). I think Scott said this was not the meaning he intended. -- Sam ---------- Forwarded message ---------- Date: Tue, 25 Jan 2005 19:43:31 -0500 (EST) From: Samuel Weiler <[EMAIL PROTECTED]> To: Scott Hollenbeck <[EMAIL PROTECTED]> Subject: RE: [dnsop] EPP-DNSSEC Document Updates [dropped the list, because I'm not being coherent today. Hopefully you can make more sense out of this than I can.] > > 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 don't have a strong feeling wither way about the maxRRSIGlifetime thought > above, but you have the intent correct. s/eDate describe the client's > preference for the start and end dates of DS and RRSIG publication in the > parent zone; vInterval is the client's preference for the parent to > regenerate the RRSIG every "X" units. What text would make that purpose > more clear to you? We may be confusing each other here. I see three time periods of interest: -- How long a DS is _expected_ to be published. -- The start and end times on any RRSIG covering it (noting that there's a single RRSIG lifetime on the whole DSset). -- How often the DSset is resigned. One interpretation of the existing three data elements is that the parent only resigns the DS when the RRSIG (is about to) expire -- that could lead to lots of load all at once, as caches suddenly have to refetch the DS when the RRSIG expires. Maybe the guidance should be: resign at interval vInterval with lifetime = current time + vInterval + TTL. But I'm not sure of that. I should go reread Olaf's doc... I can also imagine a case where a zone wants the RRSIG(DS) to have a maximum lifetime of (for example) 3 days, so that a compromise of the corresponding private key can be recovered from, without fail, in that time, but also have the RRSIG regenerated every day, with a renewed 3-day lifetime. -- Sam . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
