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?
[...]
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
- in general, anybody who is hard-coding trust anchors in their
published software is doing it wrong
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.
The "key-label" token is intended to be taken from the root-anchors.xml
file, which is cited with a stable URL.
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.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
