Re: rfc4310bis 03 AD Feedback

> The idea is that the child might want to have some maximum above which
> it doesn't go, so that the child can roll keys in a predictable way.
> This unfortunately ignores the effects of the RR TTL on the whole
> issue, and IMO is a foot-gun loaded for bear, because it makes it
> trivially easy to set the RRSIG short enough that an RRSIG expires
> while in cache.  Without a knob to control TTLs, I don't know why
> you'd allow this to be adjusted.

I also can't see how it relates to rollovers - as later messages point 
out, the signature lifetime in the DS RRSIG applies to _every_ DS record, 
and is not on a per-DS basis.  Hence you can't have a different life time 
on different keys as they're introduced - all you _might_ do is reduce the 
lifetime on _all_ keys.

Our initial assessment is that we can see no need to expose this parameter 
to child zones.  The signature on the DS RRset in the parent zone is 
created by the parent, and is the way that the parent guarantees to anyone 
who retrieves the DS RRs that the information is from the parent and has 
not been altered in transit.  All the child should be concerned about is 
data in the DS record; proving the authenticity of that data is the 
parent's responsibility.

Ray