[ksk-change] Capabilities of validating systems we need to consider

Joe Abley jabley at hopcount.ca
Sun Sep 21 15:37:15 UTC 2014


Hi Paul,

Veering off at a slight tangent for the purpose of agenda-building:

On 21 Sep 2014, at 11:27, Paul Hoffman <paul.hoffman at vpnc.org> wrote:

> Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
> 
> 1) Able to automatically pull and correctly use a new KSK

1.3) Able to retrieve a new KSK public key in-band through the DNS and verify its authenticity using an existing trust anchor and DNSSEC (e.g. RFC 5011)

1.6) Able to retrieve a new KSK public key out-of-band through other methods and verify its authenticity before using it (e.g. using draft-jabley-dnsop-validator-bootstrap

1.6.5) is the approach in draft-jabley-dnsop-validator-bootstrap a reasonable one?

1.6.7) do we need to consider other approaches to trust anchor publication by IANA?

> 2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
> 
> 3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
> 
> Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
> 
> We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about.


Joe


More information about the ksk-rollover mailing list