it might be useful to review/consider how the IETF NOMCOM does or did its selections. At one point, they used, as a salt, stock values as published on a particular date and time. the USG does the same type of thing with the CBD. <http://www.gpo.gov/help/about_commerce_business_daily.htm> … If I had anything to say about it, I’d prefer the KSK publication process include publication in one or more archival systems. But that is outside the IETF purview. I’d let this draft be published as a description of the in-baliwick, in-band, how we use the DNS protocol to publish trust anchors as used by the IANA, once upon a time. And be done with this for now.
manning bmann...@karoshi.com PO Box 6151 Playa del Rey, CA 90296 310.322.8102 On 5October2015Monday, at 14:16, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On 5 Oct 2015, at 17:00, Joe Abley wrote: > >> On 5 Oct 2015, at 16:43, Paul Hoffman wrote: >> >>> On 5 Oct 2015, at 16:12, Joe Abley wrote: >>> >>>> Hi Paul, >>>> >>>> On 5 Oct 2015, at 15:35, Paul Hoffman wrote: >>>> >>>>> A document called "DNSSEC Trust Anchor Publication for the Root Zone" >>>>> that says nothing about the most common KSK publication practice, that >>>>> is, by resolver software developers, is woefully incomplete. >>>> >>>> I am confused by that. The KSK maintainer publishes trust anchors for the >>>> root zone. Software developers produce code that consumes those trust >>>> anchors. Perhaps we are missing a shared understanding of the word >>>> "publish" here, but I don't see what common KSK publication practice >>>> you're referring to. >>> >>> Hrm. I'm pretty sure that most people would agree that software is >>> published, and that config comes with that published software. The KSK is >>> often part of that config. >> >> Ah, that helps explain the disconnect. >> >>> Of course "the KSK maintainer publishes trust anchors for the root zone". >>> So do other organizations. It seems like many people who say they want this >>> document published want this document to be how ICANN/IANA publishes the >>> trust anchors. >> >> That understanding of "publish" had never occurred to me, to be honest. >> >> If someone cuts an article out of the Toronto Star and sticks it on a >> message board for other people to see, is it reasonable to say that that >> person published the article? Or did the Toronto Star publish it? > > Including config in published software is publishing. Sticking something on a > message board is barely so, if at all. > >> >>> [...] >>> >>> Maybe you are thinking that only ICANN can publish the trust anchor? If so, >>> I would certainly disagree. Anyone can publish it, and that's a feature. >> >> That does indeed seem to be a disagreement. >> >> To state the context I had been working from (hence the confusion): >> >> - the KSK maintainer publishes a set of trust anchors >> - other people might well re-package them for one reason or another > > Got it. Yep, we disagree. > >> - in general, anybody who is hard-coding trust anchors in their published >> software is doing it wrong > > Bashing the dead horse so that it doesn't kill any more kittens: if this is > about "how ICANN does X", it really doesn't matter what you or I think about > who is doing stuff wrong, even when we agree. > >> >>>> I fully agree that the document should use actual URLs for the current >>>> KSK. As far as I can see, all the URLs mentioned in the document are URLs >>>> that work today, and have been stable since 2010. I don't see any >>>> speculation about other URLs. >>> >>>> >>>> Can you explain more fully what problem you see? >>> >>> The URL for retrieving the CSR is <http://data.iana.org/root-anchors/ >>> key-label.csr>, with "key-label" replaced by the key label of the >>> corresponding KSK. >>> >>> The URL for retrieving a signed X.509 certificate is <http:// >>> data.iana.org/root-anchors/key-label.crt>, with "key-label" again >>> replaced as described above. >>> >>> Those are templates, not URLs. ICANN does not publish anything at >>> http://data.iana.org/root-anchors/key-label.csr (unless you consider giving >>> a 404 to be publishing...). >> >> OK, I agree they are templates. >> >> I disagree that it makes sense to publish URLs that refer to just the key >> label used by the currently active KSK. That would make this document >> inaccurate as soon as a KSK roll occurred, despite the fact that it aims to >> document the way that the current and future successor trust anchors are >> published. > > It sounds like you don't want to limit the document to what many people have > asked, namely to document ICANN's current methods for publishing the KSK. > That's a fine desire, but it is quite sloppy to conflate the two. > >> The "key-label" token is intended to be taken from the root-anchors.xml >> file, which is cited with a stable URL. > > The term "key-label" does not appear in Section 2.1, so there is not even a > description of how to fill in the template. > >> You might argue that this is messy, and I might agree. But I would suggest >> that it's the only reasonable way to describe the current trust anchor >> publication mechanism used by ICANN. >>> If this document is going to be published by anyone, it should state >>> exactly how ICANN publishes things, not how it might it different future >>> circumstances. >> >> Fully agree, with the opposite conclusion. >> >>>>> It should not talk about the publication of possible future KSKs because >>>>> that is not what ICANN is doing now. >>>> >>>> I don't understand that, either. The scheme developed at ICANN in >>>> 2009/2010 was designed to facilitate publication of multiple trust >>>> anchors, specifically to allow future KSK rolls. You're saying we >>>> shouldn't document that because a KSK roll hasn't happened, yet? >>> >>> There is a difference between "how ICANN publishes the KSK" and "how ICANN >>> might publish the KSK". Please pick the one you want so that the WG can >>> decide if that's what they want you to publish. Mixing those two ideas up >>> will not help anyone who is reading the published document. >> >> ICANN might well choose different formats, URL schemes, whatever in the >> future. >> >> The current format, URL scheme, whatever is as is written in the document. >> >> The trust anchor publication strategy was designed to handle successor keys, >> and this document aims to describe that strategy. > > ...and is thus speculative. If the WG wants to publish a speculative > document, that's fine, but that's not what people have said so far, and not > how the document describes itself. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
