1.0 - Subordinate trust point deletion - Add holddown: "If all of the keys that were originally used to validate this key are revoked prior to the timer expiring, the resolver stops the acceptance process and resets the timer". - Produce warning if really old keys are encountered. - "It would be nice if the trust anchor files only will be overwrited if there was actually a change in that file". - New option: query-rate (2 is twice as fast, 3 is thrice as fast, ...) - Wildcard trust-anchor-files. - system() or exec()? - drop permissions when deamonizing minor: - Do sscanf in options.c - Option to transition a trust anchor to revoked, regardless of its current state. - Check autoscan other ideas: - Fetching trust anchors test ideas: - test signal resolver - add a test for multiple file storage - add a cutest.tpkg - talk to unsigned zone - what to do with unknown algorithm - test count local trust keys - malformed DNSKEY/DS records - nxdomain - bad input - corner cases - zsk rollover - test on solaris questions / findings: ietf75: - Raises issues for trust history. - Can autotrust run independent from the resolver? Sometimes, the algorithm depends on DNS packets seen by the resolver. ietf74: - RFC 5011 is intended for domains at the top of islands only. A configured trust anchor that is below the top that is compromised may lead to an additional attacking window. - RFC 5011 assumes that no "holidays" are taken. That is, if for some reason the algorithm is not working for a period, it might have missed a KSK rollover. In that case, autotrust may let the corresponding resolver servfail the zone. - RFC 5011 states that we must take the RRSIG expiration time into account when determining the next refresh. What if there are multiple RRSIGs and their exception times vary? ietf73: - RFC 5011 updates RFC 4034. - should a revoked-oblivious resolver treat a DNSKEY with its REVOKED bit on different than a DNSKEY with the REVOKED bit off? - draft-dnsop-4641bis: key rollover sections should include key revocation. - what's the threshold proposal? ietf72: - if you revoke a key, the calculated key tag will become different - if you lose your private key, you are not able to revoke the key anymore * lost key * compromised key * both countermeausure: have a good store policy for your private keys, this is not in scope of the document. - what to do if you see a revoked key that has not state valid or missing * set to REVOKED or ignore it, implementors choice. - compare rdata is different (because of the REVBIT) * to define: what attributes must be the same to define equality between DNSKEYs. - revoked key does not have to be in a validated set (eg selfsigned)
