On Wed, Nov 05, 2008 at 10:42:38PM +0000, Jim Reid wrote:
PS: Please try to avoid suggestions on cosmetic changes to the text unless these would improve the clarity. The WG needs to reach consensus on a statement in a day or two. So we should try to focus on what we are trying to say rather than how we are actually saying it.
<co-chair hat=on> As a matter of process, the timeline as of Dubai suggests that the final draft response shall be ready by November, 10th. I.e., the DNS WG should have reached consensus by then - or the effort is goinf to die. After that date, further edits are not expected, but the RIPE community (as represented by the ripe-list mailing list) is asked for comment, aftre which the presence or absence of consensus will have to be judged. </co-chair>
The RIPE community (or DNS WG?) thanks the NTIA for its consultation
As an editorial matter, I understand the part in brackets (same below) would come into effect if and only if the broader RIPE community does not accept the proposal _and_ the DNS WG still plans to pursue.
4. When balancing the various concerns about signing the root zone, the chosen approach must provide an appropriate level of trust and confidence by offering a maximally secure technical solution.
It is unclear to me what the implications of "maximally secure" are. Does this imply FIPS 140 level 4 HSMs and 4K key lengths? I doubt that, but I'd appreciate a clarification here to avoid ambiguity.
7. Policies and processes for signing the root zone should make it easy for TLDs to supply keys and credentials so the delegations for those TLDs can be signed.
I'd avoid the notion of delegations being signed, because that can be read in a way inconsistent with statement (1). The prime function of a DNSSEC signed root zone is a secure, centralized way of publishing TLD trust anchors: "... delegations for those TLDs can be accompanied by the TLDs' signed Trust Anchors."
8. There is no technical justification to create a new organisation to oversee the process of signing of the root.
That's probably true, but one could argue that _technically_ there's also no need for today's role split, so I doubt this adds much. If this is a comment re: any particular proposal, the text should be more explicit.
9. No data should be moved between organisations without appropriate authenticity and integrity checking.
Ack. The list doesn't say anything re: confidentiality requirements or, more precisely, moving ZSK private key material around. Shouldn't the latter be discouraged?
11. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key.
Why this if (9) was followed? Not saying (11) is bad, but it needs a bit more explanation.
12. Changes to the entities and roles in the signing process must not necessarily require a change of keys.
I see two ambiguities here: first, which I assume 'keys' means KSK here; second: what is the meaning of "must not necessarily" as opposed to "must not"? -Peter ('s own opinions)