From jim at rfc1035.com Mon Mar 3 18:10:57 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Mar 2008 17:10:57 +0000 Subject: [dnssec-key-tf] Input for Requirements Requested In-Reply-To: <20080229135636.GA489@reiftel.karrenberg.net> References: <20080229135636.GA489@reiftel.karrenberg.net> Message-ID: On 29 Feb 2008, at 13:56, Daniel Karrenberg wrote: > If you have any input on requirements, even if it is just in the form > of "this and that is very important to me", please let me have it > quickly. Just to start the ball rolling.... [1] The TAR should be technology neutral. It should not exclude or prevent different flavours of trust anchors to be published. [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 tarball of crypto gunk into stuff to plug into your name server configuration". [3] The TAR should somehow verify the keying material it's given before publishing or storing it. There should also be a secure channel for authenticating the TAR and any data it's publishing. [4] A process is needed to revoke a trust anchor and notify those who may be using the now withdrawn or invalid trust anchor. [5] Everybody should sign up to T&C's that hold everyone else harmless. [6] The TAR should be clear what support, if any, is available. [7] The TAR must make it clear what they keying material is for and its political significance: eg "we're not undermining IANA" (or perhaps not) or "we make no claims about the appropriateness of the stuff in our TAR" (national sovereignty & competition issues). [8] The TAR should treat all parties equally. Provided they demonstrate suitable levels of DNSSEC clue. [9] There should be regular reviews of the TAR's usefulness: ie clear goals for defining "success" or "failure" and some way of establishing consensus around these goals. [10] The TAR must have exit and escrow strategies From pk at DENIC.DE Mon Mar 3 18:22:27 2008 From: pk at DENIC.DE (Peter Koch) Date: Mon, 3 Mar 2008 18:22:27 +0100 Subject: [dnssec-key-tf] Input for Requirements Requested In-Reply-To: References: <20080229135636.GA489@reiftel.karrenberg.net> Message-ID: <20080303172227.GJ28133@x27.adm.denic.de> On Mon, Mar 03, 2008 at 05:10:57PM +0000, Jim Reid wrote: > Just to start the ball rolling.... exhaustive list skipped ... [11] The TAR should only publish keying material with the consent of the respective key manager. -Peter From Joao_Damas at isc.org Tue Mar 4 11:49:28 2008 From: Joao_Damas at isc.org (Joao Damas) Date: Tue, 4 Mar 2008 11:49:28 +0100 Subject: [dnssec-key-tf] Input for Requirements Requested In-Reply-To: References: <20080229135636.GA489@reiftel.karrenberg.net> Message-ID: Also, I think it would be better if only TA whose owner has agreed to inclusion in the TAR are actually included. That is, even if the TA could be verified from the data in the DNS and that made available elsewhere by the TAR owner, only if the owner agrees to its inclusion should it be included. Joao On Mar 3, 2008, at 6:10 PM, Jim Reid wrote: > On 29 Feb 2008, at 13:56, Daniel Karrenberg wrote: > >> If you have any input on requirements, even if it is just in the form >> of "this and that is very important to me", please let me have it >> quickly. > > Just to start the ball rolling.... > > [1] The TAR should be technology neutral. It should not exclude or > prevent different flavours of trust anchors to be published. > > [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 tarball of crypto gunk into stuff to plug into > your name server configuration". > > [3] The TAR should somehow verify the keying material it's given > before publishing or storing it. There should also be a secure > channel for authenticating the TAR and any data it's publishing. > > [4] A process is needed to revoke a trust anchor and notify those > who may be using the now withdrawn or invalid trust anchor. > > [5] Everybody should sign up to T&C's that hold everyone else > harmless. > > [6] The TAR should be clear what support, if any, is available. > > [7] The TAR must make it clear what they keying material is for and > its political significance: eg "we're not undermining IANA" (or > perhaps not) or "we make no claims about the appropriateness of the > stuff in our TAR" (national sovereignty & competition issues). > > [8] The TAR should treat all parties equally. Provided they > demonstrate suitable levels of DNSSEC clue. > > [9] There should be regular reviews of the TAR's usefulness: ie > clear goals for defining "success" or "failure" and some way of > establishing consensus around these goals. > > [10] The TAR must have exit and escrow strategies > From daniel.karrenberg at ripe.net Tue Mar 4 19:21:22 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 4 Mar 2008 19:21:22 +0100 Subject: [dnssec-key-tf] FYI: IANA and DNSSEC TAR Message-ID: <20080304182122.GJ687@reiftel.karrenberg.net> I am in the same room with David Conrad and cornered him about this ;-) He says there is active discussion inside ICANN to do this. I impressed on him that ICANN needs to make noise about this in order to prevent entropy by duplication of effortsby parallel and less suitable structures, e.g. us. He got that. I will continue nagging him. DAniel From pk at DENIC.DE Tue Mar 4 19:41:22 2008 From: pk at DENIC.DE (Peter Koch) Date: Tue, 4 Mar 2008 19:41:22 +0100 Subject: [dnssec-key-tf] FYI: IANA and DNSSEC TAR In-Reply-To: <20080304182122.GJ687@reiftel.karrenberg.net> References: <20080304182122.GJ687@reiftel.karrenberg.net> Message-ID: <20080304184122.GD29368@x27.adm.denic.de> Daniel, > He says there is active discussion inside ICANN to do this. I impressed on him > that ICANN needs to make noise about this in order to prevent entropy by duplication > of effortsby parallel and less suitable structures, e.g. us. that's good news on one hand, on the other the "noise" shouldn't prevent $us from trying to go ahead, IMHO. I assume all the best intentions, and at the risk of being unfair: we've also been hearing that ARPA will be signed 'real soon now' and appearingly some obstacles got in the way. This, our, effort should not be seen as a competitive endeavour but instead as an early pilot. And since we already talked about 'exit strategies' and 'stop criteria', it's nice there's one at the horizon. Still we should give it a start. -Peter From daniel.karrenberg at ripe.net Tue Mar 4 19:43:32 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 4 Mar 2008 19:43:32 +0100 Subject: [dnssec-key-tf] FYI: IANA and DNSSEC TAR In-Reply-To: <20080304184122.GD29368@x27.adm.denic.de> References: <20080304182122.GJ687@reiftel.karrenberg.net> <20080304184122.GD29368@x27.adm.denic.de> Message-ID: <20080304184331.GK687@reiftel.karrenberg.net> On 04.03 19:41, Peter Koch wrote: > Daniel, > > > He says there is active discussion inside ICANN to do this. I impressed on him > > that ICANN needs to make noise about this in order to prevent entropy by duplication > > of effortsby parallel and less suitable structures, e.g. us. > > that's good news on one hand, on the other the "noise" shouldn't prevent $us > from trying to go ahead, IMHO. I assume all the best intentions, and at the risk > of being unfair: we've also been hearing that ARPA will be signed 'real soon now' > and appearingly some obstacles got in the way. > This, our, effort should not be seen as a competitive endeavour but instead as an > early pilot. And since we already talked about 'exit strategies' and 'stop > criteria', it's nice there's one at the horizon. Still we should give it a start. Sorry, I was not clear: "noise" imho includes a time line. Daniel From daniel.karrenberg at ripe.net Sun Mar 9 21:47:27 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sun, 9 Mar 2008 21:47:27 +0100 Subject: [dnssec-key-tf] FYI: IANA and DNSSEC TAR In-Reply-To: <20080304184331.GK687@reiftel.karrenberg.net> References: <20080304182122.GJ687@reiftel.karrenberg.net> <20080304184122.GD29368@x27.adm.denic.de> <20080304184331.GK687@reiftel.karrenberg.net> Message-ID: <20080309204727.GB393@reiftel.karrenberg.net> In today's ICANN RSSAC meeting the IANA committed to publish either a plan or a list of objections/issues they have received about a TAR soon after the IETF. Now is the time to tell IANA and anyone they might listen to that this is a great idea. I'll the TF posted as this develops. Daniel