On Sun, Oct 03, 2010 at 01:18:01PM -0400, Joe Abley wrote: > > I'm not entirely sure the answer shouldn't be "because we manage the > keys, and we say so" actually.
I think I've made this argument before, but the above seems to me to be one of two possibly relevant perspectives in respect of keys (either in this DNSSEC context or more generally, but I'm concentrating on the DNSSEC context just now). On the one hand, we can understand keys as expressing a certain trustworthiness-assurance on the part of the key publisher. We can understand the publication of the key as an assertion on the part of the publisher that data signed with that key is trustworthy. I call this view publisher-centric. If we understand keys according to this scheme, then it is entirely reasonable for a key publisher to say, "Once I have pulled a key, don't use it, ever." On the other hand, we can understand keys as a feature a publisher offers users in order that those users may make intelligent choices about trust. In this view, we can understand the publication of a key as part of that support offered to users who want to validate data. Those users are then in a position to make evaluations of data they receive. I call this the user-interpretive view. Under this view, it is not reasonable for a key publisher to try to prescribe how the key is to be used once it is published. This approach, however, comes with the risk to the user that the user will not know of a key compromise. The problem in this case is that the use-value to the user, which lies in increased confidence in the value of the signed data, is misplaced. Instead, the publisher's role is reduced to warning users (by policies) what uses the publisher is willing to support, and what uses are unsupported. It seems to me that both perspectives are useful and valuable, but they're different ways of looking at the issue and they have different implications. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
