Mike,
> The value in 6 regardless of what it is is the wrong value for
> revocation. revocationPublicationWaitTime is basically
> EarliestDateAttackFails + queryInterval + slop. Revocations take
> place immediately. You can delay them only as long as you have old
> valid signed RRSets.
So in short, the advice in 5011 section 6.6 step 3:
3. After 30 days, stop publishing the old, revoked keys and remove
any corresponding DS records in the parent.
Has nothing to do with a needed wait time (because keys are revoked
immediately) but rather the above 30 days is really just a suggested
time for operational practice?
In 2.4.2 you have:
The remove hold-down time is 30 days. This parameter is solely a key
management database bookeeping parameter. Failure to remove
information about the state of defunct keys from the database will
not adversely impact the security of this protocol, but may end up
with a database cluttered with obsolete key information.
Which seems to back this up (though I'm not convinced that there is no
security ramifications of having old trust anchors around; else why
delete them?)
So in the 5011-security-considerations draft, I agree with your point
that the right amount of time to wait should be changed to replayTime +
queryInterval + slop. Thanks for pointing that out. (though it's worth
noting that replayTime + queryInterval can be longer than 30 days).
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
