[dnssec-key-tf] Proposed Mesage to IANA
Joao Damas
Wed Apr 16 15:38:13 CEST 2008
Yes On 16 Apr 2008, at 15:29, Daniel Karrenberg wrote: > On 16.04 14:02, Jim Reid wrote: >> On 16 Apr 2008, at 13:50, Daniel Karrenberg wrote: >> >>> Peter Koch suggests privately to keep calling it a TAR. Can easily >>> do that. >>> Opinions? >> >> Make it so. :-) > > OK. Can we send this to the DNS WG? > > > ---- > > Dear Barbara, > > thank you for your note about the proposed DS key registry for TLDs. > The RIPE DNS working group (DNS WG) welcomes this development. We > would > like to see IANA providing a TLD trust anchor repository (TAR) > 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 TAR should be technology neutral. It should not exclude or > prevent different flavors of trust anchors to be published, provided > those trust anchors conform to the relevant Internet standards. > > [2] The TAR should be OS/DNS implementation neutral. Tools and > documentation should be provided for use of the repository with common > DNS resolver and name server platforms. > > Comment: IANA should publish such documentation and tools, or > pointers to > them. Once we know details of the repository, we can help putting > together > this documentation. > > [3] The TAR should verify that the keying material it receives comes > from an authorised source, verify it is correctly formatted and verify > it is consistent 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. > > 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 a published 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 support for this repository known to anyone in the ICANN > governance structure > if it helps to push this along. > > Kind Regards > > RIPE DNS WG > Jim Reid > Chair > > ---- > > > *** iana-keyrep.txt 2008/04/16 12:34:16 1.3 > --- iana-keyrep.txt 2008/04/16 13:27:09 > *************** > *** 2,31 **** > 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. > > [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. > > Comment: Using the same channels IANA uses to receive update > requests to the > --- 2,29 ---- > Dear Barbara, > > thank you for your note about the proposed DS key registry for TLDs. > ! The RIPE DNS working group (DNS WG) welcomes this development. We > would > ! like to see IANA providing a TLD trust anchor repository (TAR) > ! 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 TAR should be technology neutral. It should not exclude or > ! prevent different flavors of trust anchors to be published, provided > ! those trust anchors conform to the relevant Internet standards. > > [2] The TAR should be OS/DNS implementation neutral. Tools and > ! documentation should be provided for use of the repository with > common > ! DNS resolver and name server platforms. > > ! Comment: IANA should publish such documentation and tools, or > pointers to > ! them. Once we know details of the repository, we can help putting > together > this documentation. > > [3] The TAR should verify that the keying material it receives comes > ! from an authorised source, verify it is correctly formatted and > verify > ! it is consistent 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. > > Comment: Using the same channels IANA uses to receive update > requests to the > *************** > *** 40,46 **** > > [5] The TAR should be clear what support, if any, is available. > > ! [6] The TAR must have exit strategy. > > Comment: The proposal includes that. > > --- 38,44 ---- > > [5] The TAR should be clear what support, if any, is available. > > ! [6] The TAR must have a published exit strategy. > > Comment: The proposal includes that. > > *************** > *** 49,55 **** > > 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. > > Kind Regards > --- 47,53 ---- > > 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 support for this repository known to anyone in the ICANN > governance structure > if it helps to push this along. > > Kind Regards