[dnssec-key-tf] Proposed Mesage to IANA

On 16 Apr 2008, at 13:51, Daniel Karrenberg wrote:
>
> New text.
>
> I dropped the escrow bit, because further cogitation makes it seem
> a very bottomless pit to me in the IANA context. I hope y'all can  
> agree.
> diff follows below:
>
>
> ------
>
> Dear Barbara,
>
> thank you for your note about the proposed DS key registry for TLDs.
> The RIPE DNS working group (DNS WG) force welcomes this
> development. We would like to see IANA providing such a registry as
> soon as possible. As you know we have developed a set of requirements
> for such a repository. As these may be useful for you when  
> implementing
> the service, we offer them here:
>
>
> [1] The registry should be technology neutral. It should not exclude  
> or
> prevent different flavours of trust anchors to be published, provided
> provided those trust anchors conform to the relevant standards.
>

s/provided provided/provided/

> [2] The TAR should be OS/DNS implementation neutral. Tools and
> documentation should be provided for the common platforms: "here's how
> to transform this crypto gunk into stuff to plug into your
> resolver/server configuration".
>
> Comment: IANA should publish such docmentation and tools, or  
> pointers to
> them. Once we know details of repository, we can help putting together
> this documentation.
>
> [3] The TAR should verify that the keying material it receives comes
> from authorised source, verify it is correctly formatted and verify
> it is consisten with what is published in the TLD zone before  
> publishing it.
> There should also be a secure channel  for authenticating the TAR  
> and any
> data it is publishing.
>

what does correctly formatted mean?
s/consiten/consistent/
I am struggling with what would constitute a secure channel here?  
Would it be a phone call, a fax, something over the Internet? Can we  
just say the verification should be through an IANA trusted channel  
not including any DNS data? I think most important part here is that  
key is not slurped from the zone itself, but that it arrives at IANA  
by another means (and can later be checked against the DNS entries)

> Comment: Using the same channels IANA uses to receive update  
> requests to the
> root zone from TLDs is fine. We do not mean special new channels.
> https delivery and possibly checksums are sufficient for publication.
>
> [4] A process is needed to revoke a trust anchor and notify those who
> may be using the now withdrawn or invalid trust anchor.
>
> Comment: An opt-in mailing list for operational news should be  
> sufficient
> to satisfy this.
>
> [5] The TAR should be clear what support, if any, is available.
>
> [6] The TAR must have exit strategy.
>
> Comment: The proposal includes that.
>
> [7] The TAR should only publish keying material with the consent of
>     the respective key manager.
>
> Please let us know any the details of the repository as well as the  
> time-line
> for implementation as soon as they become available. Please feel  
> free to make
> our supoort for this repository known to anyone in the ICANN  
> govenance structure
> if it helps to push this along.

OK, with text, minding the comments/typos

Joao