Automated Updates of DNS Security (DNSSEC) Trust Anchors
RFC 5011
Yes
(Mark Townsley)
(Sam Hartman)
No Objection
Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert
No Objection
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2007-05-22)
Unknown
In his SecDir Review, Stefan Santesson said: > > This document introduce a rule set for revocation of a DNS key > where revocation of that key requires use of the corresponding > private key. This raises a question how you revoke a key that > may be compromised but where the private key has been lost. Is > there a non-recoverable security risk involved if a vital key > can't be revoked due to such situation? > The security considerations ought to discuss this point. It already says that a non-compromised key is needed to recover. However it does not say anything about the situation where a hardware module fails that contains the private key. It is not compromised, but no one can make use of it. (I'm ignoring backup of keys for simplicity. I think the author will still understand the point.)
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2007-05-17)
Unknown
Should we include an RFC Editor Note to update section 3 based on the assignment of a bit in the DNSKEY flags field? The current text of section 3 begins "Bit n of the DNSKEY Flags field", and there is no inline note to the RFC editor to update the text... In section 2.3, I don't think you need "MAX" in the definition of queryInterval. Similarly, I believe there are issues with the definition of retryTime in the following paragraph. I think both should specify a range, but MAX gives us a scalar right?