From rickard.bondesson at iis.se Tue Mar 3 11:15:57 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 3 Mar 2009 12:15:57 +0100 Subject: [Opendnssec-develop] Call for meeting topics, 9th March Message-ID: <69830D4127201D4EBD146B904119971896C515@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I have added a draft on the agenda on the wiki: http://www.opendnssec.se/wiki/Meetings/Agenda/2009-03-09 Any additional topics you want to discuss? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSa0RbeCjgaNTdVjaAQg1PAf/T1rh6dO4MUHKNoxIfQLzw8Qxynk+h/T6 sZ97/HA2TkhSYyFuAs9KMpmA6WzYkZLyzSYpeT/7k7K64UtNBS1cv+UEKlvYg7fp heUUlhFBU5li9bMwEfbboaa0nfaWWJtmJfN35hnH4kc0nakrtmOBcCpYe419we+W xr+frm9Ci6hkGe19bigkhCBYHaBtG4CG4XSdsTQzVWJ6UVwSM1HyN2s/mgMh0gUG WNizfx+OKrcaHYD8j3v7niDJhQ2X5JmVVu89bpOwS2nvRmyeHKi9Y3EjuXXTqXaX lgQCZhPimvPqJXLt4HzRh8mdM/CT/GVqJBr7fXJaC6X24Ti3s7URVg== =gP2L -----END PGP SIGNATURE----- From jakob at kirei.se Thu Mar 5 13:22:17 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 5 Mar 2009 14:22:17 +0100 Subject: [Opendnssec-develop] KSK vs ZSK Message-ID: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> hi, john, jelte and I just had an interesting discussion on jabber. a KSK is a key that signs all DNSKEY RRset. we all agree on that. but does a ZSK sign all RRSETs or all non-DNSKEY RRsets? if so, a key can be both a KSK and a ZSK. so, dear list, please advice! jakob From matthijs at NLnetLabs.nl Thu Mar 5 13:35:04 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 05 Mar 2009 14:35:04 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> Message-ID: <49AFD508.9070608@nlnetlabs.nl> I think general discussion Jakob Schlyter wrote: > hi, >=20 > john, jelte and I just had an interesting discussion on jabber. >=20 > a KSK is a key that signs all DNSKEY RRset. we all agree on that. > but does a ZSK sign all RRSETs or all non-DNSKEY RRsets? if so, a key > can be both a KSK and a ZSK. >=20 >=20 > so, dear list, please advice! >=20 > jakob >=20 > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From rick at openfortress.nl Thu Mar 5 13:35:33 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 5 Mar 2009 13:35:33 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> Message-ID: <20090305133533.GA16240@phantom.vanrein.org> Hi, Nice one. The path down ( DS / KSK / ZSK / RR ) is always traversed in the same direction, so if you use both KSK and ZSK in a zone, without a need to step back or sideways from ZSK to a(nother) ZSK or KSK. > a KSK is a key that signs all DNSKEY RRset. we all agree on that. > but does a ZSK sign all RRSETs or all non-DNSKEY RRsets? I cannot think of situations where ZSK-signed DNSKEYs pose a problem; and I cannot think of situations where ZSK-signed DNSKEYs are of any use. No signing DNSKEYs with the ZSK would save wire bits, and that weak reason is all I can think of. > if so, a key > can be both a KSK and a ZSK. Haha! The idea of the distinction in names is to show their different functions. If there's no difference you shouldn't use those names! -Rick From matthijs at NLnetLabs.nl Thu Mar 5 13:38:33 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 05 Mar 2009 14:38:33 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> Message-ID: <49AFD5D9.1010204@nlnetlabs.nl> Don't know what happened there. Here is the original message: The discussion continued at our office. RFC 4641 says the ZSK should sign all the RRsets. For the sake of OpenDNSSEC, perhaps we should add an attribute to keys called 'sign-what' or something, that can have the following values: - sign nothing - sign all - sign all but keyset - sign only keyset. Makes sense? Matthijs Jakob Schlyter wrote: > hi, > > john, jelte and I just had an interesting discussion on jabber. > > a KSK is a key that signs all DNSKEY RRset. we all agree on that. > but does a ZSK sign all RRSETs or all non-DNSKEY RRsets? if so, a key > can be both a KSK and a ZSK. > > > so, dear list, please advice! > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From jelte at NLnetLabs.nl Thu Mar 5 13:40:52 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Thu, 05 Mar 2009 14:40:52 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <20090305133533.GA16240@phantom.vanrein.org> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <20090305133533.GA16240@phantom.vanrein.org> Message-ID: <49AFD664.1080605@NLnetLabs.nl> Rick van Rein wrote: > Hi, > >> if so, a key >> can be both a KSK and a ZSK. > > Haha! The idea of the distinction in names is to show their different > functions. If there's no difference you shouldn't use those names! > actually, in this case, the terms KSK and ZSK would change from being key types to being separate key properties, which can both be either true or false for any given key. technically this would be an implementation detail with about the same features as the list of attributes matthijs just mailed (btw, 4641bis will contain something along the lines of 'ZSKs sign all zone data, except perhaps the DNSKEY rrset) Jelte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From roy at nominet.org.uk Thu Mar 5 13:41:30 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 5 Mar 2009 14:41:30 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> Message-ID: Jakob Schlyter wrote on 03/05/2009 02:22:17 PM: > hi, > > john, jelte and I just had an interesting discussion on jabber. > > a KSK is a key that signs all DNSKEY RRset. we all agree on that. > but does a ZSK sign all RRSETs or all non-DNSKEY RRsets? if so, a key > can be both a KSK and a ZSK. > > so, dear list, please advice! Technically (protocol wise) it doesn't matter as long as every authoritative RRset is signed by at least one key of each key algorithm of keys present in the apex. The difference in KSK and ZSK (the SEP bit) is solely cosmetic and must completely ignored by validators. So, you could have K1, K2 and K3. where K1 signs the keyset, K2 signs all the NSEC(3) records, and K3 signs the rest of the data. This could also be done by one single key. Note that, as long as the algorithm is the same for the KSK and the ZSK, signatures made by the ZSK over the DNSKEY RRset are redundant. This would be a very small optimization, and probably not worth the effort. The 'term' KSK and ZSK is coined for operators. I have no idea where it originated. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Thu Mar 5 13:48:38 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 5 Mar 2009 13:48:38 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <49AFD5D9.1010204@nlnetlabs.nl> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: <20090305134838.GD16240@phantom.vanrein.org> Hello, > For the sake of OpenDNSSEC, perhaps we should add an attribute to keys > called 'sign-what' or something, that can have the following values: > > - sign nothing > - sign all > - sign all but keyset > - sign only keyset. > > Makes sense? I wonder if this isn't cluttering the user interface with details that are of no significant consequence. The choice is non-deterministic, as far as I can tell. That means you are free to choose what you prefer, and the accepting side ought to be liberal in what it accepts. Keep in mind that OpenDNSSEC is supposed to be "plug and play", so it makes no sense to me to add GUI frills for unimportant choices that need a lot of explanation! Cheerio, -Rickio From jakob at kirei.se Thu Mar 5 13:54:40 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 5 Mar 2009 14:54:40 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <20090305134838.GD16240@phantom.vanrein.org> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> <20090305134838.GD16240@phantom.vanrein.org> Message-ID: <028BFC9A-352D-4FF5-B093-B13FD11BDF12@kirei.se> this not about GUI, just internal API semantics... -- Sent from my iPhone, hence this mail might be briefer than normal. On 5 mar 2009, at 14.48, Rick van Rein wrote: > Hello, > >> For the sake of OpenDNSSEC, perhaps we should add an attribute to >> keys >> called 'sign-what' or something, that can have the following values: >> >> - sign nothing >> - sign all >> - sign all but keyset >> - sign only keyset. >> >> Makes sense? > > I wonder if this isn't cluttering the user interface with details that > are of no significant consequence. The choice is non-deterministic, > as far as I can tell. That means you are free to choose what you > prefer, and the accepting side ought to be liberal in what it accepts. > > Keep in mind that OpenDNSSEC is supposed to be "plug and play", so it > makes no sense to me to add GUI frills for unimportant choices that > need a lot of explanation! > > > Cheerio, > -Rickio > From roy at nominet.org.uk Thu Mar 5 13:54:57 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 5 Mar 2009 14:54:57 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <49AFD5D9.1010204@nlnetlabs.nl> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: Matthijs Mekking wrote on 03/05/2009 02:38:33 PM: > The discussion continued at our office. > RFC 4641 says the ZSK should sign all the RRsets. > For the sake of OpenDNSSEC, perhaps we should add an attribute to keys > called 'sign-what' or something, that can have the following values: Okay, lets ignore the terminology SEP/KSK/ZSK for now. > - sign nothing > - sign all > - sign all but keyset > - sign only keyset. > > Makes sense? Yes it does. We need to have a set of keys, that when combined, signs everything in the zone (the keys need to complement each other), and also note that overlap is not an issue. I can think of a variety of 'ranges' for a key: DNSSEC signing, three bits: sign keyset: 001 sign data: 010 sign NSEC/3: 100 So, a key with range 7 would sign everything (similarly like a ZSK), and a key with range 1 would be a KSK. All the keys that are currently in use, must have a combined range of "7" I can also see seperate DNSKEY uses, for instance signatures over SSHFP's or over CERT records, which would automatically get a range of 0, and an associated range. Just a thought, Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at jadickinson.co.uk Thu Mar 5 16:41:13 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 5 Mar 2009 16:41:13 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: On 5 Mar 2009, at 13:54, Roy Arends wrote: > Matthijs Mekking wrote on 03/05/2009 02:38:33 PM: > > > The discussion continued at our office. > > RFC 4641 says the ZSK should sign all the RRsets. > > For the sake of OpenDNSSEC, perhaps we should add an attribute to > keys > > called 'sign-what' or something, that can have the following values: > > Okay, lets ignore the terminology SEP/KSK/ZSK for now. > > > - sign nothing > > - sign all > > - sign all but keyset > > - sign only keyset. > > > > Makes sense? > > Yes it does. We need to have a set of keys, that when combined, > signs everything in the zone (the keys need to complement each > other), and also note that overlap is not an issue. > > I can think of a variety of 'ranges' for a key: > > DNSSEC signing, three bits: > > sign keyset: 001 > sign data: 010 > sign NSEC/3: 100 > > So, a key with range 7 would sign everything (similarly like a ZSK), > and a key with range 1 would be a KSK. > > All the keys that are currently in use, must have a combined range > of "7" > > I can also see seperate DNSKEY uses, for instance signatures over > SSHFP's or over CERT records, which would automatically get a range > of 0, and an associated range. > Do we really need all this complexity? What is wrong with KSK = SEP = Sign only DNSKEY RRSet. ZSK = !SEP = Sign all RRSets. This might be boring but it causes no surprises and is as people expect when they read the Pro DNS and BIND book or the dnssec-keygen/ signzone man pages. One of the aims of OpenDNSSEC is to make DNSSEC simple. John --- John Dickinson http://www.jadickinson.co.uk From roy at nominet.org.uk Thu Mar 5 17:00:51 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 5 Mar 2009 18:00:51 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: John Dickinson wrote on 03/05/2009 05:41:13 PM: > On 5 Mar 2009, at 13:54, Roy Arends wrote: > > > Matthijs Mekking wrote on 03/05/2009 02:38:33 PM: > > > > > The discussion continued at our office. > > > RFC 4641 says the ZSK should sign all the RRsets. > > > For the sake of OpenDNSSEC, perhaps we should add an attribute to > > keys > > > called 'sign-what' or something, that can have the following values: > > > > Okay, lets ignore the terminology SEP/KSK/ZSK for now. > > > > > - sign nothing > > > - sign all > > > - sign all but keyset > > > - sign only keyset. > > > > > > Makes sense? > > > > Yes it does. We need to have a set of keys, that when combined, > > signs everything in the zone (the keys need to complement each > > other), and also note that overlap is not an issue. > > > > I can think of a variety of 'ranges' for a key: > > > > DNSSEC signing, three bits: > > > > sign keyset: 001 > > sign data: 010 > > sign NSEC/3: 100 > > > > So, a key with range 7 would sign everything (similarly like a ZSK), > > and a key with range 1 would be a KSK. > > > > All the keys that are currently in use, must have a combined range > > of "7" > > > > I can also see seperate DNSKEY uses, for instance signatures over > > SSHFP's or over CERT records, which would automatically get a range > > of 0, and an associated range. > > > > Do we really need all this complexity? What is wrong with > > KSK = SEP = Sign only DNSKEY RRSet. > ZSK = !SEP = Sign all RRSets. > > This might be boring but it causes no surprises and is as people > expect when they read the Pro DNS and BIND book or the dnssec-keygen/ > signzone man pages. One of the aims of OpenDNSSEC is to make DNSSEC > simple. There is nothing wrong with the assumption that KSK=SEP=Sign DNSKEY, and ZSK=!SEP=Sign All. That can be taken care of in the presentation layer, right? The gui, the default settings, etc. However, with an increasing flexible and dynamic name-service environment, while we might see new applicability of DNSSEC to specific needs, why not provision for that. Is it really so much more? Is it really so complex? Mind you, we're not actually presenting this flexibility and complexity to the end user, but we could take it into account now. To converge, why not have the KSK functionality have a value of "1" and the ZSK functionality a value of "7". Leave the rest undefined, ffu, or what not. Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Mar 5 19:56:02 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 5 Mar 2009 20:56:02 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: On 5 mar 2009, at 14.54, Roy Arends wrote: > DNSSEC signing, three bits: > > sign keyset: 001 > sign data: 010 > sign NSEC/3: 100 > > So, a key with range 7 would sign everything (similarly like a ZSK), > and a key with range 1 would be a KSK. we need no bits, this is just in the instructions for the signer - we could do something like: ... keys denial data would be equal to keys would be equal to keysdenialdata jakob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: not available URL: From olaf at NLnetLabs.nl Thu Mar 5 20:17:20 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 5 Mar 2009 21:17:20 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: On 5 mrt 2009, at 20:56, Jakob Schlyter wrote: > On 5 mar 2009, at 14.54, Roy Arends wrote: > >> DNSSEC signing, three bits: >> >> sign keyset: 001 >> sign data: 010 >> sign NSEC/3: 100 >> >> So, a key with range 7 would sign everything (similarly like a >> ZSK), and a key with range 1 would be a KSK. > > we need no bits, this is just in the instructions for the signer - > we could do something like: > > > ... > keys > denial > data > > > > would be equal to keys > would be equal to keysdenial sign>data I could imagine all sorts of extensions such as: dynamic Extensions... that reminds me that I once tried to extend an XML schema that I used in a configuration and was happy I had a version attribute defined so that my parser knew that the schema had changed. Has versioning of the XML been considered, or is there some standard way of doing extensions? I must admit I have only practical knowledge of XML and schemas. --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part URL: From jakob at kirei.se Thu Mar 5 21:06:10 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 5 Mar 2009 22:06:10 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: <028F915D-0B0D-400F-8987-579BAF13CB91@kirei.se> On 5 mar 2009, at 21.17, Olaf Kolkman wrote: > Extensions... that reminds me that I once tried to extend an XML > schema that I used in a configuration and was happy I had a version > attribute defined so that my parser knew that the schema had changed. yes, we should version the schema once finalised. jakob From olaf at NLnetLabs.nl Fri Mar 6 06:00:26 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 6 Mar 2009 07:00:26 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> Message-ID: <74C6D952-75F5-4562-8E33-10F9B3B2F77C@NLnetLabs.nl> On 5 mrt 2009, at 21:17, Olaf Kolkman wrote: >> >> >> ... >> keys >> denial >> data >> >> I am not a very experienced XML designer but it occurs to me that you would like to design the XML in such a way that most of the checking can be done through validating of the schema. I never quite understood when to shoot for an attribute or an element but my laymen understanding is that when a property is not just "free form" and you want to control the properties that are submitted through your XML based protocol or configuration, an attribute makes a bit more sense e.g.: --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part URL: From jakob at kirei.se Fri Mar 6 06:51:41 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 6 Mar 2009 07:51:41 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <74C6D952-75F5-4562-8E33-10F9B3B2F77C@NLnetLabs.nl> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> <74C6D952-75F5-4562-8E33-10F9B3B2F77C@NLnetLabs.nl> Message-ID: <65FB148A-70A7-4E9B-B509-B38402C5BF48@kirei.se> On 6 mar 2009, at 07.00, Olaf Kolkman wrote: > I am not a very experienced XML designer but it occurs to me that > you would like to design the XML in such a way that most of the > checking can be done through validating of the schema. I never quite > understood when to shoot for an attribute or an element but my > laymen understanding is that when a property is not just "free form" > and you want to control the properties that are submitted through > your XML based protocol or configuration, an attribute makes a bit > more sense e.g.: > not quite - look at kasp.rnc for a good example: element serial { "counter" | "unixtime" | "datecounter" }? which is a RelaxNG compact definition of a element that can contain specific test. in the old days of DTD your clain was more true though. element vs attribute is still an interesting discussion, but far more complex than data type. jakob From jakob at kirei.se Fri Mar 6 08:16:15 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 6 Mar 2009 09:16:15 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> Message-ID: <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> after a short dicsussion with Roy, here is a more specific proposal: for each key we can specify two things - if it should be included in the signed zone file or not, and what RRset to sign. - for publication we use . - for signing we use zero or more XXX, where XXX is an RRTYPE or OTHERS. if RRTYPE is ANY, we sign all RRsets with that key. if RRTYPE is a specific type(s), we sign only those types. classic typical KSK: DNSKEY new style typical ZSK: ANY key for delegation only: DS BUT, we might want to be able to sign everything not explicitly selected, so a classic ZSK would then be: ANY DNSKEY (since DNSKEY was explicitly selected by the KSK, and we want the ZSK to sign ANY RRset including DNSKEY). complex? yes, but understandable. useful? I believe so. jakob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: not available URL: From olaf at NLnetLabs.nl Fri Mar 6 08:16:39 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 6 Mar 2009 09:16:39 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <65FB148A-70A7-4E9B-B509-B38402C5BF48@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> <74C6D952-75F5-4562-8E33-10F9B3B2F77C@NLnetLabs.nl> <65FB148A-70A7-4E9B-B509-B38402C5BF48@kirei.se> Message-ID: On 6 mrt 2009, at 07:51, Jakob Schlyter wrote: > > which is a RelaxNG compact definition of a element that can > contain specific test. in the old days of DTD your clain was more > true though. > Aha.. as said.. my XML experience is rusty... > element vs attribute is still an interesting discussion, but far > more complex than data type. I'd appreciate an (off-list) pointer to such comprehensive discussion. I am sure they exist. --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 235 bytes Desc: This is a digitally signed message part URL: From roy at nominet.org.uk Fri Mar 6 08:39:39 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 6 Mar 2009 09:39:39 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> Message-ID: Jakob Schlyter wrote on 03/06/2009 09:16:15 AM: > after a short dicsussion with Roy, here is a more specific proposal: To be clear: We did not discuss the publish part (but nolo contendere on that) > for each key we can specify two things - if it should be included in > the signed zone file or not, and what RRset to sign. > > - for publication we use . We did indeed discuss: > - for signing we use zero or more XXX, where XXX is an > RRTYPE or OTHERS. > > if RRTYPE is ANY, we sign all RRsets with that key. > if RRTYPE is a specific type(s), we sign only those types. > > classic typical KSK: DNSKEY > new style typical ZSK: ANY > key for delegation only: DS > > BUT, we might want to be able to sign everything not explicitly > selected, so a classic ZSK would then be: > > ANY > DNSKEY > > (since DNSKEY was explicitly selected by the KSK, and we want the ZSK > to sign ANY RRset including DNSKEY). so: ANY DNSKEY leads to that KEY-1 will NOT sign DNSKEYs. (this is exactly what I want) ofcourse, if you want the vanilla behaviour, you'd need to specify ANY DNSKEY DNSKEY This way, you can even specify keys for denial by adding a key with NSEC and NSEC3 This is the granularity I was looking for! Thanks, Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Fri Mar 6 08:40:37 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 6 Mar 2009 09:40:37 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> Message-ID: <110F053F-EFA0-4C90-A03B-C8920AA9AB9F@kirei.se> On 6 mar 2009, at 09.39, Roy Arends wrote: > This is the granularity I was looking for! I agree! jakob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: not available URL: From rick at openfortress.nl Fri Mar 6 08:52:55 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 6 Mar 2009 08:52:55 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> Message-ID: <20090306085255.GB29351@phantom.vanrein.org> Hi, > > > ANY > > > > DNSKEY > So, ANY means "sign anything by DNSKEY"? That sounds like a recipe for confusion. A more orthogonal alternative, with less opportunities for confusion, could be: ANY DNSKEY DNSKEY or even ANYDNSKEY DNSKEY Cheers, -Rick From rick at openfortress.nl Fri Mar 6 08:53:58 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 6 Mar 2009 08:53:58 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <20090306085255.GB29351@phantom.vanrein.org> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> Message-ID: <20090306085358.GC29351@phantom.vanrein.org> Sorry, > So, ANY means "sign anything by DNSKEY"? anything _but_ DNSKEY -> that looks like an opportunity for confusion. -Rick From roy at nominet.org.uk Fri Mar 6 09:03:29 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 6 Mar 2009 10:03:29 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <20090306085255.GB29351@phantom.vanrein.org> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 03/06/2009 09:52:55 AM: > Hi, > > > > > > > ANY > > > > > > > > DNSKEY > > > > So, ANY means "sign anything by DNSKEY"? That sounds like > a recipe for confusion. A more orthogonal alternative, with less > opportunities for confusion, could be: > > > > ANY > DNSKEY > > > > DNSKEY > > > or even > > > > ANYDNSKEY > > > > DNSKEY > Rick, that does not look less complex to me. The rule in our scheme is basically that you explicitly assign keys to types they need to sign. Anything not explicity assigned falls in the category 'ANY'. kind of like the 'default:' part of the switch/case statement. Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Fri Mar 6 09:05:25 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 6 Mar 2009 10:05:25 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> Message-ID: Roy Arends/Nominet wrote on 03/06/2009 10:03:29 AM: > The rule in our scheme is basically that you explicitly assign keys > to types they need to sign. Anything not explicity assigned falls in > the category 'ANY'. > > kind of like the 'default:' part of the switch/case statement. Come to think of it, should we use 'default' instead of 'ANY' ? Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Fri Mar 6 09:07:53 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 06 Mar 2009 10:07:53 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> Message-ID: <49B0E7E9.4000506@nlnetlabs.nl> so a typical ZSK would become ANY DNSKEY NSEC3 ... ? In that case, I would prefer an additional sign value: ALL. Matthijs Roy Arends wrote: > Rick van Rein wrote on 03/06/2009 09:52:55 AM: > >> Hi, >> >> > >> > >> > ANY >> > >> > >> > >> > DNSKEY >> > >> >> So, ANY means "sign anything by DNSKEY"? That sounds like >> a recipe for confusion. A more orthogonal alternative, with less >> opportunities for confusion, could be: >> >> >> >> ANY >> DNSKEY >> >> >> >> DNSKEY >> >> >> or even >> >> >> >> ANYDNSKEY >> >> >> >> DNSKEY >> > > Rick, that does not look less complex to me. > > The rule in our scheme is basically that you explicitly assign keys to > types they need to sign. Anything not explicity assigned falls in the > category 'ANY'. > > kind of like the 'default:' part of the switch/case statement. > > Regards, > > Roy Arends > Sr. Researcher > Nominet UK > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From rick at openfortress.nl Fri Mar 6 09:15:52 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 6 Mar 2009 09:15:52 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> Message-ID: <20090306091552.GA32394@phantom.vanrein.org> Hi, > Rick, that does not look less complex to me. It isn't. All I propose is to put the knowledge into the XML structure, where I think it should go once you accept XML. If we need to interpret names like "ANY" we're bypassing XML as a modelling language. Orthogonality is a tool to get the structure clearer, not simpler. If there are exceptions, I'd rather see them out in the open instead of concealing them in a "you know what I mean" term. That is why I think that a non-lingual interpretetation of a word like "ANY", "DEFAULT" or "ALL" can cause confision. I'm not surprised that we're now discussing these terms -- it is a sign that they are open for interpretation, and thus, of misinterpretation. Hope this helps, -Rick From jakob at kirei.se Fri Mar 6 09:23:59 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 6 Mar 2009 10:23:59 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> Message-ID: <9E1F4C59-97F8-4C7E-938F-523C7DFC4895@kirei.se> On 6 mar 2009, at 10.05, Roy Arends wrote: > Come to think of it, should we use 'default' instead of 'ANY' ? until someone defines the RRTYPE default. ANY is reserved already. j -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: not available URL: From roy at nominet.org.uk Fri Mar 6 09:38:50 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 6 Mar 2009 10:38:50 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <20090306091552.GA32394@phantom.vanrein.org> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> <20090306091552.GA32394@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 03/06/2009 10:15:52 AM: > Hi, > > > Rick, that does not look less complex to me. > > It isn't. All I propose is to put the knowledge into the XML structure, > where I think it should go once you accept XML. If we need to interpret > names like "ANY" we're bypassing XML as a modelling language. > > Orthogonality is a tool to get the structure clearer, not simpler. > > If there are exceptions, I'd rather see them out in the open instead > of concealing them in a "you know what I mean" term. That is why I > think that a non-lingual interpretetation of a word like "ANY", "DEFAULT" > or "ALL" can cause confision. I'm not surprised that we're now discussing > these terms -- it is a sign that they are open for interpretation, and > thus, of misinterpretation. Rick, this is not really about terminology. We should pick the least confusing term, whatever that may be. You're approaching this from a completely different angle. (no value statement, just an observation). Yours is: explicitly state what a key can be used for, and can not be used for. This is needed when there are overlapping realms, like ALL. Ours is: explicitly state what a key can be used for. The rest defaults to 'ANY' or 'default' or whatever term we coin for it. Note that this is not about orthogonality, but design principle. Like I said, the analogy here is the switch/case statement. Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at jadickinson.co.uk Fri Mar 6 09:39:38 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Fri, 6 Mar 2009 09:39:38 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> Message-ID: <491DF870-0B7E-4A8F-9518-0BAF6332440D@jadickinson.co.uk> On 6 Mar 2009, at 08:39, Roy Arends wrote: > Jakob Schlyter wrote on 03/06/2009 09:16:15 AM: > > > after a short dicsussion with Roy, here is a more specific proposal: > > To be clear: We did not discuss the publish part (but nolo > contendere on that) > > > for each key we can specify two things - if it should be included in > > the signed zone file or not, and what RRset to sign. > > > > - for publication we use . > > We did indeed discuss: > > > - for signing we use zero or more XXX, where XXX is an > > RRTYPE or OTHERS. > > > > if RRTYPE is ANY, we sign all RRsets with that key. > > if RRTYPE is a specific type(s), we sign only those types. > > > > classic typical KSK: DNSKEY > > new style typical ZSK: ANY > > key for delegation only: DS > > > > BUT, we might want to be able to sign everything not explicitly > > selected, so a classic ZSK would then be: > > > > ANY > > DNSKEY > > > > (since DNSKEY was explicitly selected by the KSK, and we want the > ZSK > > to sign ANY RRset including DNSKEY). > > so: > > > > ANY > > > > DNSKEY > > > leads to that KEY-1 will NOT sign DNSKEYs. (this is exactly what I > want) > > ofcourse, if you want the vanilla behaviour, you'd need to specify > > > > ANY > DNSKEY > > > > DNSKEY > > We also need to specify how key rollover will occur. Will the key be treated according to the KSK or ZSK logic as specified in the draft (pre-publish or double key?)? How about this: KSK DEFAULT ZSK DEFAULT ZSK DS If = DEFAULT then KSKs sign the DNSKEY RRSet and ZSKs sign everything including the DNSKEY RRSet. If != DEFAULT the the key only signs the specified types of RRSet. If = KSK then == DEFAULT John --- John Dickinson http://www.jadickinson.co.uk From jakob at kirei.se Fri Mar 6 09:47:45 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 6 Mar 2009 10:47:45 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <491DF870-0B7E-4A8F-9518-0BAF6332440D@jadickinson.co.uk> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <491DF870-0B7E-4A8F-9518-0BAF6332440D@jadickinson.co.uk> Message-ID: <3F00FBAC-BE48-47A9-AC76-12E490B3A48E@kirei.se> On 6 mar 2009, at 10.39, John Dickinson wrote: > We also need to specify how key rollover will occur. Will the key be > treated according to the KSK or ZSK logic as specified in the draft > (pre-publish or double key?)? but the rollover logic is up to KASP, no? it does not have to be communicated to the signer. it just signs. jakob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: not available URL: From jad at jadickinson.co.uk Fri Mar 6 09:48:48 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Fri, 6 Mar 2009 09:48:48 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <491DF870-0B7E-4A8F-9518-0BAF6332440D@jadickinson.co.uk> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <491DF870-0B7E-4A8F-9518-0BAF6332440D@jadickinson.co.uk> Message-ID: On 6 Mar 2009, at 09:39, John Dickinson wrote: > We also need to specify how key rollover will occur. Will the key be > treated according to the KSK or ZSK logic as specified in the draft > (pre-publish or double key?)? How about this: > > > > KSK > DEFAULT > > > > ZSK > DEFAULT > > > > ZSK > DS > > > If = DEFAULT then KSKs sign the DNSKEY RRSet and ZSKs sign > everything including the DNSKEY RRSet. > > If != DEFAULT the the key only signs the specified types of > RRSet. > > If = KSK then == DEFAULT Even better lets no re-introduce KSK/ZSK terms and lets get rid of default how about doublekey DNSKEY prepublish ALL prepublish DS So in this example, KEY-1 is effectively a KSK in the typical sense, KEY-2 is a typical ZSK and KEY-3 is one of our special ones. --- John Dickinson http://www.jadickinson.co.uk From roy at nominet.org.uk Fri Mar 6 09:55:20 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 6 Mar 2009 10:55:20 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> <20090306091552.GA32394@phantom.vanrein.org> Message-ID: Roy Arends wrote on 03/06/2009 10:38:50 AM: > Rick van Rein wrote on 03/06/2009 10:15:52 AM: > > > Hi, > > > > > Rick, that does not look less complex to me. > > > > It isn't. All I propose is to put the knowledge into the XML structure, > > where I think it should go once you accept XML. If we need to interpret > > names like "ANY" we're bypassing XML as a modelling language. > > > > Orthogonality is a tool to get the structure clearer, not simpler. > > > > If there are exceptions, I'd rather see them out in the open instead > > of concealing them in a "you know what I mean" term. That is why I > > think that a non-lingual interpretetation of a word like "ANY", "DEFAULT" > > or "ALL" can cause confision. I'm not surprised that we're now discussing > > these terms -- it is a sign that they are open for interpretation, and > > thus, of misinterpretation. > > Rick, this is not really about terminology. We should pick the least > confusing term, whatever that may be. > > You're approaching this from a completely different angle. (no value > statement, just an observation). > > Yours is: explicitly state what a key can be used for, and can not > be used for. This is needed when there are overlapping realms, like ALL. > > Ours is: explicitly state what a key can be used for. The rest > defaults to 'ANY' or 'default' or whatever term we coin for it. > > Note that this is not about orthogonality, but design principle. > Like I said, the analogy here is the switch/case statement. Rick, let me try to be more clear before things spiral in an undesired direction: I am not against orthogonality. not at all. My point is that we could have a value that we assign to a key to signify that it needs to be used when there are no other keys available. Assume that key gets the value XXX. Your point is, to satisfy orthogonality, is that XXX signs everything. If types need to be excluded, exclude it explicitly. I'm fine with that. My intention was to make the exclusion implicit (hence I was looking to avoid the term ALL, and used ANY or DEFAULT). You seem opposed to that. hope this helps Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Fri Mar 6 13:25:23 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 6 Mar 2009 14:25:23 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <467FEAFF-FCF7-4DBD-A121-458A139819D3@kirei.se> <20090306085255.GB29351@phantom.vanrein.org> <20090306091552.GA32394@phantom.vanrein.org> Message-ID: <33BBC798-FBAF-4245-BCE6-24A08EB0ABB4@kirei.se> ok, here's another try after some more real-time jabber discussions with roy and john: DNSKEY DNSKEY rules: the default for sign is the full set, except if you explicitly include stuff - then you start with an empty set of RRtypes. jakob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: not available URL: From jakob at kirei.se Fri Mar 6 13:30:59 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 6 Mar 2009 14:30:59 +0100 Subject: [Opendnssec-develop] FYI: persistent jabber room available Message-ID: <70BBEEB1-C405-4163-ADA9-8EE475AAFB48@kirei.se> I've created a persistent jabber room at xmpp:opendnssec at conference.kirei.se for hallway discussions. most people are on the access list, if you are not - please ask someone to invite you while in session or ask me to add. jakob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: not available URL: From rick at openfortress.nl Mon Mar 9 08:13:03 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 9 Mar 2009 08:13:03 +0000 Subject: [Opendnssec-develop] Welcome page Message-ID: <20090309081303.GA13001@phantom.vanrein.org> Hello Rickard and others, As promised, I've reordered the information on the OpenDNSSEC home page to make it a bit more inviting. If you care to comment on it, you can glance at it here: http://openfortress.nl/tmp/opendnssec/welcome/ There is an image left to be drawn, and it totally lacks layout. I could load it into TRAC. But before I do that, comments are welcome. Cheers, -Rick From rickard.bondesson at iis.se Mon Mar 9 08:49:39 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 9 Mar 2009 09:49:39 +0100 Subject: [Opendnssec-develop] Meeting 20090309 Message-ID: <69830D4127201D4EBD146B904119971896C772@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi The agenda with phone numbers are available on the wiki: http://www.opendnssec.se/wiki/Meetings/Agenda/2009-03-09 Time: 14:00-15:00 CET // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbTYI+CjgaNTdVjaAQglmQgAieCtKD77mxg+SuvPVSAp/gDm7/WnadVu LKW60Qnc2u2vax7FvmAY1tGE0mKbvay4NZWI5OF3RQ7u8R10k+JNRzscpbSRBXwA 8BQw1NWJymXq2lQ1zLL+neDM8zVwDzHUeLsrryNcm65KA7/TAviuwI8yyodDryV2 LrsoMAlimOZtNyCflbjHX68U5cmXNy+0Ma6hMJz72gIKYFRP9nycV6orM3fTjHnt AISaEvPhV9Pv2XXl2KHF5vazXyJp7nscxMJqZZkAfOCJ2fuBIP2PsKhiHu/3D6mH PfsD055UCwfAIIdyQy990/gQKLbDX1XzwS/BrhcX/feK5aDz8+t6Sw== =77UZ -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Mon Mar 9 14:46:06 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 9 Mar 2009 15:46:06 +0100 Subject: [Opendnssec-develop] OpenDNSSEC meeting during IETF74 Message-ID: <69830D4127201D4EBD146B904119971896C7D2@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Pick the timeslots where you are available for a meeting with the OpenDNSSEC project group. There will be six of us attending IETF74 in San Francisco. The aim is to discuss the finalization of phase 1. (Local time) http://www.doodle.com/s65v4dx2id2iafwb // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbUrruCjgaNTdVjaAQicCAf+P7xM0+pO5OGczSCXN00GHjEQfdEVaww5 3DevT+SLxT9r3Zc118SsmHmSnhwPyysqkh1D1KuXLOzX9VRKy4UrJFGfBkIzNAJM GgXcOLGUl5LcDQiFyUpXXnvkiz86FcnjQGavhX9m5aIdRPlqiNCvD3yf/oQU+Cn0 eCveoVEyRfK0eYg5N77Xzwfn3nKdlDEoWLwYxZXfm3BHYMaOi31KU7OCON7u1TFK bCZzWV+Gw30g/HTgYKFGsuZ3VE57T/18Lf3QVCwQ7Du8NsP9ylLF/oznVpLYi4sl yv5Om35/wjLqU6lrzRZB5WuO45nRK6zfbaKS8jUAQreSmbIMPXo0Fg== =VaeT -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Tue Mar 10 12:29:05 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 10 Mar 2009 13:29:05 +0100 Subject: [Opendnssec-develop] libsofthsm 1.0.0 RC1 Message-ID: <69830D4127201D4EBD146B904119971896C859@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A tarball of libsofthsm 1.0.0 RC1 can be found at: http://www.opendnssec.se/export/269/releases/libsofthsm/libsofthsm-1.0.0-RC1.tar.gz // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbZdEeCjgaNTdVjaAQh2mwgAqhVDxXjaHWQtoOdGjrNmRigcg5Nv3esP NAU182ytqO6nsNvoimyX+U8YLWAT8tuowU2xmoQ3ApMZj0bL+4jAzSHH1UyHEzqM AugM3D7Ce2nX+yDKnO8f/epGSL8g1gSPpoIA3ff2bH796cdxCXosko+xeBLoEMBH J3AoY58TbISxMoZQKMM6w0lWQDAZFyQaE6Tis3YoU/pyAQ7TVgzPxGYhu1nLIRqU qUlqeadfDz40TluzrR0VBn7qNFfk3h2y6SeYce6d65SYAG0fo74t9Ge1cYIbuCGG isK/mSHD3sy7BPsWCzHpM9fHdQKaxO0JWKXKI5M07niNanaV3Oq1uQ== =qs7O -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Tue Mar 10 17:03:17 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 10 Mar 2009 17:03:17 +0000 Subject: [Opendnssec-develop] Minutes of teleconference, 2009-03-09 Message-ID: Now available on the wiki: http://www.opendnssec.se/wiki/Meetings/Minutes/2009-03-09 Let me know of any errors or omissions and I will correct them. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bondesson at iis.se Wed Mar 11 09:03:30 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Mar 2009 10:03:30 +0100 Subject: [Opendnssec-develop] OpenDNSSEC meeting during IETF74 In-Reply-To: <69830D4127201D4EBD146B904119971896C7D2@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971896C7D2@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971896C8CA@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Pick the timeslots where you are available for a meeting with > the OpenDNSSEC project group. There will be six of us > attending IETF74 in San Francisco. The aim is to discuss the > finalization of phase 1. > > (Local time) > > http://www.doodle.com/s65v4dx2id2iafwb Please fill in the Doodle, so we can set a meeting time. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbd+YuCjgaNTdVjaAQjYlggAmOCeaxVNC7UNwItTSH91MO1FxLrmyOKa bok8a4yemAUu2k3JGT68fSIkF+Ym0EazplH1mg8mAuZPuWRYrHhz1NZAdd6HHTrJ RlYSidHAz76r7E6QXj1+btrE1g+ItsI7uVsriZh5Yc4o2IsZHtKmxeMHVPMJTeGH aCSXqK5fxvrqTbOYrQEi1mLaEsXqjQAJLDB+TJGbD/zVMlSDk3Za1lOZVVKZ3ZD2 zJkarHoryJAJ7iHWN0Yp34xF7rIyffReTBrICX3TkbOWBDr7l88odTWIBDc/rsfb Vo7cF+t4asuBXI4simdfF0lISKT2CbvlfYN2f6eHNldizELlEQzA6w== =0vh+ -----END PGP SIGNATURE----- From jakob at kirei.se Wed Mar 11 10:33:15 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 11:33:15 +0100 Subject: [Opendnssec-develop] compact HSM needed... Message-ID: hi, I'm looking for a smartcard with integrated USB-reader (aka "token") that is: a) with a CCID-class reader (so I can use it om my mac) b) with a chip that is supported by OpenSC the Aladdin eToken seemed to fit my reqs, but the reader isn't supported. the purpose of this exercise is to be able to show a very small HSM so I can demo OpenDNSSEC at the IETF. jakob From roy at nominet.org.uk Wed Mar 11 11:48:18 2009 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 11 Mar 2009 12:48:18 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions Message-ID: While the hsm-toolkit slowly reaches adolescense, I'd like to discuss some topics on the subject: 1) The object identifier We need to identify an object. This can either be done by the LABEL or by ID. Please give guidance on which to use, and what the values for this identifiers need to be. I remember that 'hash of the key' was mentioned. Please advice which algorithm to use. I also need to know if hsm-toolkit needs to avoid identifier collisions or not. 2) additional functionality The software can list, generate and destroy RSA objects from the token. Is there interest in additional functionality, or do we want to keep it to the bare necessities (list/generate/destroy objects) 3) configurable defaults Currently, all parameters need to be specified on the command line. Some have static defaults. Do we want configurable defaults through a configuration file, or no defaults, or the current status quo? thanks, Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at jadickinson.co.uk Wed Mar 11 11:57:35 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 11:57:35 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: Message-ID: <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> On 11 Mar 2009, at 11:48, Roy Arends wrote: > While the hsm-toolkit slowly reaches adolescense, I'd like to > discuss some topics on the subject: Hi Roy, I have also been thinking about a few of these things because the Enforcer needs to do them as well and so I plan to steal code directly from yours :) I have a patch to add dynamic linking of the pkcs11. So that you specify -P /usr/local/lib/libpkcs11.so on the command line instead of at compile time. I am just cleaning it up and will submit it later today. > 1) The object identifier > > We need to identify an object. This can either be done by the LABEL > or by ID. Please give guidance on which to use, and what the values > for this identifiers need to be. I remember that 'hash of the key' > was mentioned. Please advice which algorithm to use. I also need to > know if hsm-toolkit needs to avoid identifier collisions or not. Enforcer needs this as well. I was going to ask Jakob this very question - Jakob, do you know the answer? > > 2) additional functionality > > The software can list, generate and destroy RSA objects from the > token. Is there interest in additional functionality, or do we want > to keep it to the bare necessities (list/generate/destroy objects) I expect we want more - I will have a think of ideas. > > 3) configurable defaults > > Currently, all parameters need to be specified on the command line. > Some have static defaults. Do we want configurable defaults through > a configuration file, or no defaults, or the current status quo? I like it as it is. --- John Dickinson http://www.jadickinson.co.uk From roy at nominet.org.uk Wed Mar 11 12:07:50 2009 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 11 Mar 2009 13:07:50 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> References: <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> Message-ID: John Dickinson wrote on 03/11/2009 12:57:35 PM: > On 11 Mar 2009, at 11:48, Roy Arends wrote: > > > While the hsm-toolkit slowly reaches adolescense, I'd like to > > discuss some topics on the subject: > > Hi Roy, > > I have also been thinking about a few of these things because the > Enforcer needs to do them as well and so I plan to steal code directly > from yours :) Steal right ahead :-) > I have a patch to add dynamic linking of the pkcs11. So that you > specify -P /usr/local/lib/libpkcs11.so on the command line instead of > at compile time. I am just cleaning it up and will submit it later > today. I have already added the functionality, using your patch. Thanks. Works :-). > > 1) The object identifier > > > > We need to identify an object. This can either be done by the LABEL > > or by ID. Please give guidance on which to use, and what the values > > for this identifiers need to be. I remember that 'hash of the key' > > was mentioned. Please advice which algorithm to use. I also need to > > know if hsm-toolkit needs to avoid identifier collisions or not. > > Enforcer needs this as well. I was going to ask Jakob this very > question - Jakob, do you know the answer? > > > > > 2) additional functionality > > > > The software can list, generate and destroy RSA objects from the > > token. Is there interest in additional functionality, or do we want > > to keep it to the bare necessities (list/generate/destroy objects) > > I expect we want more - I will have a think of ideas. > > > > > 3) configurable defaults > > > > Currently, all parameters need to be specified on the command line. > > Some have static defaults. Do we want configurable defaults through > > a configuration file, or no defaults, or the current status quo? > > I like it as it is. Cool. thanks for the help! Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at jadickinson.co.uk Wed Mar 11 12:14:13 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 12:14:13 +0000 Subject: [Opendnssec-develop] compact HSM needed... In-Reply-To: References: Message-ID: <65065BE3-7AB5-4C3E-B3EB-9060EED1D484@jadickinson.co.uk> I used one from here once http://store.gemalto.com/ I have some cryptoflex e-gate 32k cards that I never used and a now appear to be called TPC cards. I also have a USB key token v1 that I can not find on the site anymore. the USB token does work on the MAC with opensc/openct But it looks like there are other CCID options here... John On 11 Mar 2009, at 10:33, Jakob Schlyter wrote: > hi, > > I'm looking for a smartcard with integrated USB-reader (aka "token") > that is: > > a) with a CCID-class reader (so I can use it om my mac) > b) with a chip that is supported by OpenSC > > the Aladdin eToken seemed to fit my reqs, but the reader isn't > supported. > > > the purpose of this exercise is to be able to show a very small HSM > so I can demo OpenDNSSEC at the IETF. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- John Dickinson http://www.jadickinson.co.uk From rickard.bondesson at iis.se Wed Mar 11 12:25:51 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Mar 2009 13:25:51 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B904119971896C910@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > 1) The object identifier I remember that Jakob had the task of defining how we should internally reference the keys, which this will be a part of. My view is that ID should be used as an identifier for a key. LABEL is used as a description of the object. John talked about using C_DigestKey, but that is not applicable to asymmetric keys. So you would have to extract some key material on your own and digest that. > 2) additional functionality Can't think of anything right now. > 3) configurable defaults The defaults look good. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbetz+CjgaNTdVjaAQiReAf9FkIAssty85KiaBlZqmmad6bFUtj0kxtV 9OgGjv0/07mSzGBC/aTpTwUGlsRXWxrEfSxRhjY4EQ9PLpfRFg0IYhmZIJ5Y3NAZ zDj0vvONd55FEmMQCXJJ+kCmaYuWY8TlZ+Ly9s2fmQ3KDX8gruXGxTem+HQngDJv J27P3QKlq9Pd71rxCYmZTGks4UcAyhnK0pPvwrdBwHlBP3Ek6YBuRlexgAVcIpm9 yINTQM4knjl/eS4pkXsZnVkNJC7GUgTouBupsGYQf5iWwxsQgSz1VscwZdVd4GSj x2EVI0ZwJY3FRSWSHyzXt8RlbGKoci92IZDpyBWh/SQHJIlr+UK64w== =maeT -----END PGP SIGNATURE----- From jakob at kirei.se Wed Mar 11 12:34:17 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 13:34:17 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: Message-ID: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> On 11 mar 2009, at 12.48, Roy Arends wrote: > 1) The object identifier > > We need to identify an object. This can either be done by the LABEL > or by ID. Please give guidance on which to use, and what the values > for this identifiers need to be. I remember that 'hash of the key' > was mentioned. Please advice which algorithm to use. I also need to > know if hsm-toolkit needs to avoid identifier collisions or not. I believe we decided that the LABEL should be used and that the generator of the key assigns the label. IIRC, we said that the KASP enforcer would typically generate the key and then update the label to be the hash (SHA-1) of the public key. All others will refers to key by the label and find them by querying all configured HSM for all keys. I'll put it on my todo-list to write a short note about this on the wiki. jakob From jakob at kirei.se Wed Mar 11 12:38:14 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 13:38:14 +0100 Subject: [Opendnssec-develop] compact HSM needed... In-Reply-To: <65065BE3-7AB5-4C3E-B3EB-9060EED1D484@jadickinson.co.uk> References: <65065BE3-7AB5-4C3E-B3EB-9060EED1D484@jadickinson.co.uk> Message-ID: On 11 mar 2009, at 13.14, John Dickinson wrote: > I used one from here once > > http://store.gemalto.com/ > > I have some cryptoflex e-gate 32k cards that I never used and a now > appear to be called TPC cards. I also have a USB key token v1 that I > can not find on the site anymore. the reader part I can find now, but I cannot find any SIM-sized cryptoflex-card nomore. rick? roland? - any hints? OpenSC supports these cards: onjiea> /Library/OpenSC/bin/opensc-tool -D Configured card drivers: rutoken Rutoken driver cardos Siemens CardOS cardos Siemens CardOS flex Schlumberger Multiflex/Cryptoflex cyberflex Schlumberger Cyberflex gpk Gemplus GPK gemsafeV1 driver for the Gemplus GemSAFE V1 applet miocos MioCOS 1.1 mcrd MICARDO 2.1 asepcos Athena ASEPCOS setcos Setec cards starcos STARCOS SPK 2.3/2.4 tcos TCOS 3.0 openpgp OpenPGP card jcop JCOP cards with BlueZ PKCS#15 applet oberthur Oberthur AuthentIC.v2/CosmopolIC.v4 belpic Belpic cards atrust-acos A-Trust ACOS cards muscle Muscle Card Driver emv EMV compatible cards incrypto34 Incard Incripto34 piv PIV-II for multiple cards acos5 ACS ACOS5 card akis TUBITAK UEKAE AKIS entersafe entersafe default Default driver for unknown cards From rickard.bondesson at iis.se Wed Mar 11 12:41:06 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Mar 2009 13:41:06 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I believe we decided that the LABEL should be used and that > the generator of the key assigns the label. IIRC, we said > that the KASP enforcer would typically generate the key and > then update the label to be the hash (SHA-1) of the public key. Then we have to define how the public key should be hashed (in what order to hash the key material). Or perhaps there is a procedure defined by the community? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbexYuCjgaNTdVjaAQgEaAf/btxV8yZjMmyRN1fAtWiT0NhTgD2D2Xl/ GWMzsfF5vZ0p/FCAAGz9rSoJW/FFcALZr6cASeo+UBztpx3k9HeWlgnWStaw/87M Om+ESq3ccM5RVh+yACiwqBkyu/nr0ixHwxthlg5cHdhMenjp/QIv6tTSgakuFqzj QmwUzmV1G90ERZS27Vtz69iA+PQrqXrEzYa798vw6WrhZI/+SA7QwvaKaH+xik05 9r54ZjWpAs935wBYWun5wKjZU18YipQjdm8SXVej9Wh+G8s5cNMC4uNfE8wRAHJr mcPwKqwKVfBkg/dLgpPLRkNewNMT+h+g4mOEqrKyPOl5efS8qq9F8Q== =qA/p -----END PGP SIGNATURE----- From jakob at kirei.se Wed Mar 11 12:45:22 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 13:45:22 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> Message-ID: <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> On 11 mar 2009, at 13.41, Rickard Bondesson wrote: > Then we have to define how the public key should be hashed (in what > order to hash the key material). Or perhaps there is a procedure > defined by the community? no, we don't and that's a very nice property of this solution. the one who generates the label decides how to hash - the ones using it will just get the key from the keystore (e.g. using the in the signconf XML blob) and query the HSMs. jakob From jad at jadickinson.co.uk Wed Mar 11 14:00:52 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 14:00:52 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> Message-ID: Hi, here is a patch to hsm-toolkit to print a hash of the public key. Before I finish it and submit it - can anyone see any problems? Index: hsm-toolkit.c =================================================================== --- hsm-toolkit.c (revision 272) +++ hsm-toolkit.c (working copy) @@ -32,6 +32,7 @@ #include #include #include "cryptoki.h" +#include const CK_BBOOL ctrue = CK_TRUE; const CK_BBOOL cfalse = CK_FALSE; @@ -358,9 +359,34 @@ Add_Attr(pri_temp+cnt2++,CKA_PRIVATE, &ctrue, sizeof (ctrue)); Add_Attr(pri_temp+cnt2++,CKA_EXTRACTABLE, &ctrue, sizeof (ctrue)); CK_OBJECT_HANDLE ignore; + CK_OBJECT_HANDLE publickey; check_rv("C_GenerateKeyPair", sym->C_GenerateKeyPair(ses, &mech, pub_temp, cnt1, - pri_temp, cnt2, &ignore,&ignore)); + pri_temp, cnt2, &publickey,&ignore)); + + /* Create a hash of the public key */ + unsigned char md[SHA_DIGEST_LENGTH]; + SHA_CTX sha1ctx; + SHA1_Init(&sha1ctx); + int j; + /* Hash the modulus bits */ + SHA1_Update(&sha1ctx, &keysize, sizeof (keysize)); + /* Hash the public exponent */ + SHA1_Update(&sha1ctx, &pubex, sizeof (pubex)); + /* Get the Modulus */ + CK_ATTRIBUTE template[32]; + Add_Attr(template,CKA_MODULUS,NULL_PTR,0); + check_rv("C_GetAttributeValue",sym->C_GetAttributeValue(ses, publickey, template, 1)); + Init_Attrs(template,1); + check_rv("C_GetAttributeValue",sym->C_GetAttributeValue(ses, publickey, template, 1)); + SHA1_Update(&sha1ctx, (char*) Get_Val_string(template,CKA_MODULUS, 1), (int) Get_Val_Len(template,CKA_MODULUS,1) *8); + Flush_Attrs(template,1); + SHA1_Final(md, &sha1ctx); printf("Created RSA key pair object, labeled %s\n",label); + printf("HASH WAS: "); + for (j = 0; j < SHA_DIGEST_LENGTH; j++) { + printf("%02x", md[j]); + } + printf("\n"); } CK_SLOT_ID GetSlot() { John On 11 Mar 2009, at 12:45, Jakob Schlyter wrote: > On 11 mar 2009, at 13.41, Rickard Bondesson wrote: > >> Then we have to define how the public key should be hashed (in what >> order to hash the key material). Or perhaps there is a procedure >> defined by the community? > > no, we don't and that's a very nice property of this solution. > the one who generates the label decides how to hash - the ones using > it will just get the key from the keystore (e.g. using the > in the signconf XML blob) and query the HSMs. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- John Dickinson http://www.jadickinson.co.uk From rickard.bondesson at iis.se Wed Mar 11 14:10:33 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Mar 2009 15:10:33 +0100 Subject: [Opendnssec-develop] Newsletter #4 Message-ID: <69830D4127201D4EBD146B904119971896C933@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Here is the news from the two latest weeks: ******************************************* * The project The finalization of phase 1 has been planned, but will be discussed more during an OpenDNSSEC meeting in connection with IETF74, San Francisco. The project web page has been upgraded to collect statistics with Google Analytics (starting on 6 March) and has been updated with a more appealing front page. * Meetings We had a telephone meeting on 9 March. Minutes are published on the wiki. Next meeting is in San Francisco in connection with IETF74. The exact time will be decided via a Doodle. * KSM and KASP Enforcer The work with KSM/KASP has been delayed due to high working load in other projects. This delays the finalization of phase 1 with two weeks, in other words in the middle of April. * Signer Engine The Signe Engine and its parts are essentially finished. Only some minor questions are left to resolve, like how the recipient will be notified that the zone has been signed. * SoftHSM SoftHSM is ready to be release for version 1. Before it is released, it has to be tested by internal and external parties. The code is package, documented, and published. It is also available via this url: http://freshmeat.net/projects/softhsm/ After one day, it has resulted in the following statistics: Record hits: 343 URL hits: 116 Subscribers: 4 ********************************************* // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbfGWeCjgaNTdVjaAQjW/AgAo2he1Mww1o6FRcuhPWj62aSyA3n58BbT cZ+fR57nPGu+aCScY7YrqIRNkzD+7DfFE5YYRFIQBN/rf2ltmRDUF9Lqm4du2l9E g0P72J9/0bOe2HOnbF0yeHx/mWAxM7N73HhdkFa1ysUNnuJrELNaef5xW2P11s85 BdMn4jnnvn2ngbSlhOdigg3aoQzxigZ1CrRYh7OoHAdrfgzvgM5socFneT6xRPHQ BouAHClOeilY89tIL3vJJdrIsGkC53YqER8fjVhKnFLbgL8Txv4k4rP0UBy2YT5r W7AypBhOUlMu6JqtGO/xPp/tUGVyoJJtiD9GcfbIAnrUTCdM67eedg== =BiuU -----END PGP SIGNATURE----- From rick at openfortress.nl Wed Mar 11 13:46:19 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Mar 2009 13:46:19 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C910@EXCHANGE.office.nic.se> <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C910@EXCHANGE.office.nic.se> <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> Message-ID: <20090311134619.GA12776@phantom.vanrein.org> Hello Roy, John, Rickard, Jakob, This is a reply to all that is currently in this thread. (I sometimes wonder how people can survive without Mutt...) On Wed, Mar 11, 2009 at 12:48:18PM +0100, Roy Arends wrote: > 1) The object identifier > > We need to identify an object. This can either be done by the LABEL or by > ID. Please give guidance on which to use, and what the values for this > identifiers need to be. Quoting PKCS #11 v2.11 sections: "The CKA_LABEL attribute is intended to assist users in browsing." (10.4) "The CKA_ID field is intended to distinguish among multiple keys." (10.7) So, you should use CKA_ID to store a hash code identifier. Being not-for-humans, you could even consider to use a binary form of the hash, instead of base64 or hex. It probably makes most sense out of what is defined in PKCS #11 as a byte array. > I remember that 'hash of the key' was mentioned. > Please advice which algorithm to use. I also need to know if hsm-toolkit > needs to avoid identifier collisions or not. A concern here is whether id collisions would raise security issues. If not, you could use (a partial string of) MD4, otherwise use SHAxxx. I could imagine attacks that would lead you to finding a key of choice that happened to have the same ID as another one that was constructed to fool you, but: 1. You would probably notice ID collisions, and refuse to accept a newly created key with an existing ID; 2. Even if the above attack would succeed, the private key is still protected by a PIN. I see no other security problems, so the question about collision is not a security question, IMHO. That means that a quick/simple hash like MD4 would do; it is not secure but quicker than MD5. Of course, practical issues like availability of the hash routine could lead you to prefer MD5 over MD4. Although I see no benefit, you could even opt for using a prefix of a hash string as ID instead of the full string. > 2) additional functionality > > The software can list, generate and destroy RSA objects from the token. Is > there interest in additional functionality, or do we want to keep it to > the bare necessities (list/generate/destroy objects) No requests from me. > 3) configurable defaults > > Currently, all parameters need to be specified on the command line. Some > have static defaults. Do we want configurable defaults through a > configuration file, or no defaults, or the current status quo? Bit length of keys should be configfile defaults, not static ones. We don't want anything like "I'm stymied -- get thee a wizard". (That's a bit of TeX folklore.) On Wed, Mar 11, 2009 at 11:57:35AM +0000, John Dickinson wrote: > I have a patch to add dynamic linking of the pkcs11. So that you > specify -P /usr/local/lib/libpkcs11.so on the command line instead of > at compile time. I am just cleaning it up and will submit it later > today. Yes, this ought to work in general. PKCS #11 is often loaded dynamically, e.g. by Mozilla where you specify it in the GUI. > Enforcer needs this as well. I was going to ask Jakob this very > question - Jakob, do you know the answer? Same answer: Use CKA_ID, and you could consider binary notation. On Wed, Mar 11, 2009 at 01:25:51PM +0100, Rickard Bondesson wrote: > > My view is that ID should be used as an identifier for a key. LABEL is used as a description of the object. Your gut feeling matches the prescriptions of the specification. > John talked about using C_DigestKey, but that is not applicable to asymmetric keys. So you would have to extract some key material on your own and digest that. I've missed what this is about, but C_DigestKey is intended AFAIK to generically support algorithms like DIGEST-MD5 and CRAM-MD5, which hash some data including a hardware-encapsulated key. For asymmetric keys, this is not common, as these are not usually treated as random secrets. If your intention is to find a hash, simply extract the public key and hash it. It's probably best not to extract more, including no descriptive information such as in a certificate; that would make it possible to use the same key with different descriptive information, leading to different identities -- you probably want to detect and reject if the same key is used more than once. On Wed, Mar 11, 2009 at 01:34:17PM +0100, Jakob Schlyter wrote: > > I believe we decided that the LABEL should be used and that the > generator of the key assigns the label. Did we? Wow, we decided something in conflict with the standard. Better backtrack that decision and become decent citizens again :) If a domain is ever to be attached to a key, it could go into CKA_LABEL, but CKA_ID definately is the place for the machine's way of locating it. > IIRC, we said that the KASP > enforcer would typically generate the key and then update the label to > be the hash (SHA-1) of the public key. SHA-1 is fine, but not (much) better than MD5 or even (insecure) MD4, see above. I'm happy with either hash algorithm, provided it doesn't give a high collision probability like CRC-32 would. (Keep in mind that the number of people in a room need only be SQRT(365) to have a better-than-50% probability of a matching birthday. Similarly, having SQRT(Reach(CRC-32)) = 2^16 keys would suffice to have a hit between two. Two keys per domain, that makes only 32768 domains if you'd use CRC-32.) > All others will refers to key by the label and find them by querying > all configured HSM for all keys. As stated above, PKCS #11 disagrees with the label -> use CKA_ID instead. On Wed, Mar 11, 2009 at 01:41:06PM +0100, Rickard Bondesson wrote: > > Then we have to define how the public key should be hashed (in what order to hash the key material). Or perhaps there is a procedure defined by the community? Isn't the wire format for a public key standardised? PKCS #1 (not #11 but #1) specifies a public key syntax in appendix A. Isn't that the most suitable format to use? Note that in doing so, you want to select suitable encoding rules. I believe DER-encoding is commonly used before hashing. (Let me know if getting into ASN.1 is hard work, I may be of help. I used to read its hexdumps -- a treat compared to PGP's base64.) > >Then we have to define how the public key should be hashed (in what > >order to hash the key material). Or perhaps there is a procedure > >defined by the community? > > no, we don't and that's a very nice property of this solution. We should keep in mind that we do not want to be dependent on, say, libraries on an operating system. Those beasts update every once in a while, and I'm not certain that XML protects us against people adding pretty-print code to their libraries, forgetting that they are breaking signatures. > the one who generates the label decides how to hash - the ones using > it will just get the key from the keystore (e.g. using the > in the signconf XML blob) and query the HSMs. XML is a bad idea as a source for hashing. It would have to be turned into a canonical format, which unlike ASN.1/DER isn't its default; furthermore, there are things in XML that cannot be turned into a canonical format, for reasons that are fundamental i.e. unresolvable. Mixing XML and hashing is a recipe for problems. XML is not suitable for this, no matter what the existence of an XML Signing standard may lead you to believe. Stay well away from it! Best, -Rick From rick at openfortress.nl Wed Mar 11 14:12:50 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Mar 2009 14:12:50 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <7E3A2A7C-216A-4D59-94EF-5F123E5FA38F@kirei.se> References: <69830D4127201D4EBD146B904119971896C910@EXCHANGE.office.nic.se> <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> <20090311134619.GA12776@phantom.vanrein.org> <7E3A2A7C-216A-4D59-94EF-5F123E5FA38F@kirei.se> Message-ID: <20090311141250.GE12776@phantom.vanrein.org> Hey, > I'd use SHA1 just to avoid discussions with people regarding MDx. Sure. It's always a drag to have to explain if/why there are no security implications. Users don't like cryptographic reasoning. I'm just adding the technical issues that I can see from my background. -Rick From rick at openfortress.nl Wed Mar 11 14:19:03 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Mar 2009 14:19:03 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> Message-ID: <20090311141903.GF12776@phantom.vanrein.org> John, > + /* Hash the modulus bits */ > + SHA1_Update(&sha1ctx, &keysize, sizeof (keysize)); Not seeing the keysize in this patch, I'm assuming it is a value of platform-independent endianness? We don't want to get into trouble when moving the signing service from an i386 Mac to a PowerPC Mac, so to speak. Also, the sizeof (keysize) is the same for all platforms, I hope? Actually, this same reasoning also applies to strengthen my previous remark about hashing XML representations of keys. Lacking a canonical form for XML (even if the name is coined for something that approaches it) we cannot assume that the "canonical" form of any XML document yields the same hash. > + for (j = 0; j < SHA_DIGEST_LENGTH; j++) { > + printf("%02x", md[j]); > + } I also agree that hex is more practical for us developers, and don't mind a few bytes being wasted on it. Not even if the context in which it is stored is as scarce in memory as a token. Cheers, -Rick From rick at openfortress.nl Wed Mar 11 14:22:00 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Mar 2009 14:22:00 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> Message-ID: <20090311142200.GG12776@phantom.vanrein.org> John, Steering away from the code, I am getting more thoughts. > here is a patch to hsm-toolkit to print a hash of the public key. > Before I finish it and submit it - can anyone see any problems? You did not start by hashing the algorithm identifier, which makes more sense in the light that RSA won't be around forever. It's not a major thing though -- as CKA_ID is not a security thing. I wonder if there is a reason not simply to adhere to the ASN.1 encoding and hashing that. It may offer better integration with existing tools. -Rick From jakob at kirei.se Wed Mar 11 14:23:38 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 15:23:38 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <20090311141903.GF12776@phantom.vanrein.org> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> Message-ID: <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> On 11 mar 2009, at 15.19, Rick van Rein wrote: > Not seeing the keysize in this patch, I'm assuming it is a value > of platform-independent endianness? We don't want to get into > trouble when moving the signing service from an i386 Mac to a > PowerPC Mac, so to speak. Also, the sizeof (keysize) is the > same for all platforms, I hope? the label is only set when generating the key, if you move the key - between architecture or HSM:s - the label stays the same. perhaps we should considering setting the CKA_ID to a plain UUID instead? like D242124C-B411-4E33-BBB0-44F60C607275 - easy to generate (and no rename after generated needed) - will never collide - no crypto discussions jakob From rickard.bondesson at iis.se Wed Mar 11 14:26:05 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Mar 2009 15:26:05 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se><69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se><69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971896C93F@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > here is a patch to hsm-toolkit to print a hash of the public key. > Before I finish it and submit it - can anyone see any problems? Do we want to use OpenSSL and not the digesting function of the HSM? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbfJ/eCjgaNTdVjaAQjjIAf/QJ12udvVPM/ayRZbowAeI+CHxd+nVHbD BGzjLVTzqbi6AURn7/HD9IwGyD8PRDJIhi2nXTj0NOteSbhuH5Okv8sz2Uimahr1 IFEeNnJddz3C6HpdcW6l00EDoKRc5QPOxqiB4anXb0lyYrWH7Ul5SAbR1v0M7Fyt 5cMLKWI1iH9urKo7S/kvonF2oXA7tHZY2CJsssBp8yRsFKqjnADRJEjIHh6e+j/l GJzCcidOcV8ErP+bYWDDzoyGk0snpEprVCkwTa+EvNA9f4GHrTA8dTV/GN6UrBoz j4BZbLn8Xp5IP5MzfKbVAaC0hOnnYwLLnEpWVPBovCPxoKC/r1NNYQ== =J5Jb -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Wed Mar 11 14:34:39 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 14:34:39 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> Message-ID: <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> On 11 Mar 2009, at 14:23, Jakob Schlyter wrote: > On 11 mar 2009, at 15.19, Rick van Rein wrote: > >> Not seeing the keysize in this patch, I'm assuming it is a value >> of platform-independent endianness? We don't want to get into >> trouble when moving the signing service from an i386 Mac to a >> PowerPC Mac, so to speak. Also, the sizeof (keysize) is the >> same for all platforms, I hope? > > the label is only set when generating the key, if you move the key - > between architecture or HSM:s - the label stays the same. > > perhaps we should considering setting the CKA_ID to a plain UUID > instead? > like D242124C-B411-4E33-BBB0-44F60C607275 > > - easy to generate (and no rename after generated needed) > - will never collide > - no crypto discussion Good idea. Not having to create and rename is nice. Is there a library on several platforms to calculate this or do I have to read RFC4122? John --- John Dickinson http://www.jadickinson.co.uk From jakob at kirei.se Wed Mar 11 14:39:25 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 15:39:25 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> Message-ID: <19872975-5770-42E6-8BB4-EFA309B6A2C3@kirei.se> On 11 mar 2009, at 15.34, John Dickinson wrote: > Good idea. Not having to create and rename is nice. Is there a > library on several platforms to calculate this or do I have to read > RFC4122? yes, example code on http://en.wikipedia.org/wiki/Universally_Unique_Identifier . there are at least one good BSD-license UUID generator (http://www.ossp.org/pkg/lib/uuid/ ). jakob From rick at openfortress.nl Wed Mar 11 14:39:40 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Mar 2009 14:39:40 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> Message-ID: <20090311143940.GD12583@phantom.vanrein.org> Hello, > perhaps we should considering setting the CKA_ID to a plain UUID > instead? > like D242124C-B411-4E33-BBB0-44F60C607275 If it is to be treated as a random string I like this one better than hashing any explicit material. We won't be able to detect colliding keys though. > - easy to generate (and no rename after generated needed) Yep. > - will never collide Fingers crossed... I would always check this sort of "normally" situations. > - no crypto discussions Heheh, yeah, it'll make me more quiet for sure ;-) Cheers, -Rick From jad at jadickinson.co.uk Wed Mar 11 14:39:58 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 14:39:58 +0000 Subject: Fwd: [Opendnssec-develop] hsm-toolkit questions References: <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> Message-ID: <1BF606AF-E421-49B4-8DF8-589BE76282BE@jadickinson.co.uk> Begin forwarded message: >> >> - no crypto discussion > > Good idea. Not having to create and rename is nice. Is there a > library on several platforms to calculate this or do I have to read > RFC4122? Well it appears that there is on OS X, FreeBSD and Linux (ubuntu) - so I say yes go for UUIDs --- John Dickinson http://www.jadickinson.co.uk From jad at jadickinson.co.uk Wed Mar 11 15:03:38 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 15:03:38 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <19872975-5770-42E6-8BB4-EFA309B6A2C3@kirei.se> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> <19872975-5770-42E6-8BB4-EFA309B6A2C3@kirei.se> Message-ID: <7AE32270-2B12-4895-A529-25488C660F01@jadickinson.co.uk> On 11 Mar 2009, at 14:39, Jakob Schlyter wrote: > On 11 mar 2009, at 15.34, John Dickinson wrote: > >> Good idea. Not having to create and rename is nice. Is there a >> library on several platforms to calculate this or do I have to read >> RFC4122? > > yes, example code on http://en.wikipedia.org/wiki/Universally_Unique_Identifier > . there are at least one good BSD-license UUID generator (http://www.ossp.org/pkg/lib/uuid/ > ). > > jakob > Do we care which algorithm/version is used to generate the uuid? If it is time then it could leak some information about key generation time and mac address of the machine used. Not that this uuid will ever be made public. With at least one lib we can force a fully random uuid. John --- John Dickinson http://www.jadickinson.co.uk From jad at jadickinson.co.uk Wed Mar 11 15:59:09 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 15:59:09 +0000 Subject: [Opendnssec-develop] relationships between KASP paarameters Message-ID: <7EC06FE0-29A3-48D9-A231-53F80A79579A@jadickinson.co.uk> Sion and I are wondering if the Enforecer/libKSM should validate the policies. For example there could be a set of rules like: - TTLs must be no less than 5 min and no greater than 2 years - key lifetime must be at least n * TTLkey where n is some number like 5. - ... these are made up examples please don't worry about the exact numbers for now :) Do people think that a) the enforcer/libKSM is the place to do this b) this should be done at all c) this should be left for the GUI/CLI that populates the KASP DB? d) this should wait for v2 John --- John Dickinson http://www.jadickinson.co.uk From jakob at kirei.se Wed Mar 11 16:53:07 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 17:53:07 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C910@EXCHANGE.office.nic.se> <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> <2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk> <20090311134619.GA12776@phantom.vanrein.org> Message-ID: I've written some text about Keys within OpenDNSSEC at http://www.opendnssec.se/wiki/Signer/Keys . this pages is not yet linked to other pages and needs more work. jakob From jakob at kirei.se Wed Mar 11 16:55:18 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Mar 2009 17:55:18 +0100 Subject: [Opendnssec-develop] relationships between KASP paarameters In-Reply-To: <7EC06FE0-29A3-48D9-A231-53F80A79579A@jadickinson.co.uk> References: <7EC06FE0-29A3-48D9-A231-53F80A79579A@jadickinson.co.uk> Message-ID: <5E7BF588-9A23-45FF-9A56-7456EEEE2B9E@kirei.se> On 11 mar 2009, at 16.59, John Dickinson wrote: > Sion and I are wondering if the Enforecer/libKSM should validate the > policies. For example there could be a set of rules like: > - TTLs must be no less than 5 min and no greater than 2 years > - key lifetime must be at least n * TTLkey where n is some number > like 5. > - ... > > these are made up examples please don't worry about the exact > numbers for now :) > > Do people think that > a) the enforcer/libKSM is the place to do this > b) this should be done at all > c) this should be left for the GUI/CLI that populates the KASP DB? > d) this should wait for v2 I think we can do (d) right now and in the future decide if we do it at all. this could be done by a standalone KASP "Lint" that reads the policy XML. jakob From rick at openfortress.nl Wed Mar 11 18:15:11 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Mar 2009 18:15:11 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <7AE32270-2B12-4895-A529-25488C660F01@jadickinson.co.uk> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> <19872975-5770-42E6-8BB4-EFA309B6A2C3@kirei.se> <7AE32270-2B12-4895-A529-25488C660F01@jadickinson.co.uk> Message-ID: <20090311181511.GA15725@phantom.vanrein.org> Hi, A formal remark, and a practical one: > Do we care which algorithm/version is used to generate the uuid? The idea of a UUID is that it is globally unique, by taking into account some system-specifics, something time-specific and something random and hashing it all into a nice, fixed-size string. > If it > is time then it could leak some information about key generation time > and mac address of the machine used. Not that this uuid will ever be > made public. With at least one lib we can force a fully random uuid. There is no such thing as a random UUID; there are UUIDs (which are in part random) and, as a totally different thing, random numbers that may or may not look alike. I see no danger in "leaking" the generation time, because an HSM uses a strong source of random numbers, instead of srand(time()). Cheers -Rick From jad at jadickinson.co.uk Wed Mar 11 18:22:40 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 18:22:40 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <20090311181511.GA15725@phantom.vanrein.org> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> <19872975-5770-42E6-8BB4-EFA309B6A2C3@kirei.se> <7AE32270-2B12-4895-A529-25488C660F01@jadickinson.co.uk> <20090311181511.GA15725@phantom.vanrein.org> Message-ID: <34F8FE6C-5F55-4EDA-927E-69B665F5F5A3@jadickinson.co.uk> On 11 Mar 2009, at 18:15, Rick van Rein wrote: > > There is no such thing as a random UUID; there are UUIDs (which are in > part random) and, as a totally different thing, random numbers that > may or may not look alike. man uuid_generate " The uuid_generate_time function forces the use of the alternative algo- rithm which uses the current time and the local ethernet MAC address (if available). This algorithm used to be the default one used to gen- erate UUID, but because of the use of the ethernet MAC address, it can leak information about when and where the UUID was generated. This can cause privacy problems in some applications, so the uuid_generate func- tion only uses this algorithm if a high-quality source of randomness is not available. " --- John Dickinson http://www.jadickinson.co.uk From jad at jadickinson.co.uk Wed Mar 11 18:42:04 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Mar 2009 18:42:04 +0000 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: <34F8FE6C-5F55-4EDA-927E-69B665F5F5A3@jadickinson.co.uk> References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se> <69830D4127201D4EBD146B904119971896C915@EXCHANGE.office.nic.se> <69AF2F14-9F7D-43FD-83A2-1F5C39F9EE7E@kirei.se> <20090311141903.GF12776@phantom.vanrein.org> <2DFF8FBB-DD8E-49E8-9500-D31649F16BF0@kirei.se> <1B799ED7-3032-4BBB-8D17-F51D1534DE0F@jadickinson.co.uk> <19872975-5770-42E6-8BB4-EFA309B6A2C3@kirei.se> <7AE32270-2B12-4895-A529-25488C660F01@jadickinson.co.uk> <20090311181511.GA15725@phantom.vanrein.org> <34F8FE6C-5F55-4EDA-927E-69B665F5F5A3@jadickinson.co.uk> Message-ID: <042C25A0-77AD-4221-BF08-B7D29B6C6667@jadickinson.co.uk> On 11 Mar 2009, at 18:22, John Dickinson wrote: > > On 11 Mar 2009, at 18:15, Rick van Rein wrote: > >> >> There is no such thing as a random UUID; there are UUIDs (which are >> in >> part random) and, as a totally different thing, random numbers that >> may or may not look alike. > > man uuid_generate > > " The uuid_generate_time function forces the use of the > alternative algo- > rithm which uses the current time and the local ethernet > MAC address > (if available). This algorithm used to be the default one > used to gen- > erate UUID, but because of the use of the ethernet MAC > address, it can > leak information about when and where the UUID was generated. > This can > cause privacy problems in some applications, so the > uuid_generate func- > tion only uses this algorithm if a high-quality source of > randomness is > not available. > " Actually, let me be a bit more verbose. 1. You might want to read about the 5 versions of UUIDs mentioned in http://en.wikipedia.org/wiki/Universally_Unique_Identifier (the URL already sent by Jakob.) 2. just in case you don't have a mac or linux the whole man page: SYNOPSIS #include void uuid_generate(uuid_t out); void uuid_generate_random(uuid_t out); void uuid_generate_time(uuid_t out); DESCRIPTION The uuid_generate function creates a new universally unique identifier (UUID). The uuid will be generated based on high-quality randomness from /dev/urandom, if available. If it is not available, then uuid_generate will use an alternative algorithm which uses the current time, the local ethernet MAC address (if available), and random data generated using a pseudo-random generator. The uuid_generate_random function forces the use of the all- random UUID format, even if a high-quality random number generator (i.e., /dev/urandom) is not available, in which case a pseudo-random generator will be subsituted. Note that the use of a pseudo-random generator may compromise the uniqueness of UUID's generated in this fashion. The uuid_generate_time function forces the use of the alternative algorithm which uses the current time and the local ethernet MAC address (if available). This algorithm used to be the default one used to generate UUID, but because of the use of the ethernet MAC address, it can leak information about when and where the UUID was generated. This can cause pri- vacy problems in some applications, so the uuid_generate function only uses this algorithm if a high-quality source of randomness is not available. The UUID is 16 bytes (128 bits) long, which gives approximately 3.4x10^38 unique values (there are approximately 10^80 elemntary particles in the universe according to Carl Sagan's Cosmos). The new UUID can reasonably be considered unique among all UUIDs created on the local system, and among UUIDs created on other systems in the past and in the future. RETURN VALUE The newly created UUID is returned in the memory location pointed to by out. CONFORMING TO OSF DCE 1.1 AUTHOR Theodore Y. Ts'o AVAILABILITY http://e2fsprogs.sourceforge.net/ 3. the mac uuid code on >=10.5 appears to be that from e2fsprogs 4. I agree there is little danger of leaking information - however, it might be good practice to force the use of uuid_generate_random when using the e2fsprogs uuid lib. 5. BTW - I do know what a UUID is :) John --- John Dickinson http://www.jadickinson.co.uk From Stephen.Morris at nominet.org.uk Wed Mar 11 18:49:42 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 11 Mar 2009 18:49:42 +0000 Subject: [Opendnssec-develop] relationships between KASP parameters In-Reply-To: <5E7BF588-9A23-45FF-9A56-7456EEEE2B9E@kirei.se> Message-ID: opendnssec-develop-bounces at lists.opendnssec.org wrote on 11/03/2009 16:55:18: > On 11 mar 2009, at 16.59, John Dickinson wrote: > > > Sion and I are wondering if the Enforecer/libKSM should validate the > > policies. For example there could be a set of rules like: > > - TTLs must be no less than 5 min and no greater than 2 years > > - key lifetime must be at least n * TTLkey where n is some number > > like 5. > > - ... > > > > these are made up examples please don't worry about the exact > > numbers for now :) > > > > Do people think that > > a) the enforcer/libKSM is the place to do this > > b) this should be done at all > > c) this should be left for the GUI/CLI that populates the KASP DB? > > d) this should wait for v2 > > I think we can do (d) right now and in the future decide if we do it > at all. this could be done by a standalone KASP "Lint" that reads the > policy XML. like Jakob, I suggest (d) for now. However, I think it ought to be done at the point the policy is created, which is probably (c). The easiest way might be to put another parameters table in the database with a set of maximum/minimum/default values. Then every time a parameter is modified, it is checked against the thresholds and a warning output if they are exceeded. (Note warning - we are not stopping the user exceeding a threshold, we are just warning them that it might not be advisable to do so.) Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Thu Mar 12 07:32:51 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 12 Mar 2009 07:32:51 +0000 Subject: [Opendnssec-develop] compact HSM needed... In-Reply-To: References: Message-ID: <20090312073251.GB28438@phantom.vanrein.org> Hello Jakob, > I'm looking for a smartcard with integrated USB-reader (aka "token") > that is: > > a) with a CCID-class reader (so I can use it om my mac) > b) with a chip that is supported by OpenSC Trying to break the token market open... I've wished for that for years, but found the token market to be rather nasty in that respect. Some vendors flatly refuse to abolish their proprietary USB-cardreader protocol in favour of the CCID standard profile for them. And OpenSC has never actually worked for me. You may have a bit more luck if you allow for OpenSC + OpenCT to work. OpenCT is an open source card terminal that comes as part of OpenSC. You should be able to find advice on those on opensc.org. Since OpenDNSSEC works on top of PKCS #11 I suppose testing its code could be done on top of any compliant library, including closed ones from various vendors. I'm not sure if that is what you are after though. Since these libraries are usually of low quality, don't be surprised if problems in the implementations occur, such as functions that simply haven't been implemented. In my experience however, the developers are quite eager to get new applications on board, so they will work with app developers to get it to work. > the Aladdin eToken seemed to fit my reqs, but the reader isn't > supported. I have heard lots of complaints that Aladdin is far from pleasant to deal with, in the sense that they are far from open. > the purpose of this exercise is to be able to show a very small HSM so > I can demo OpenDNSSEC at the IETF. Wunderbar! I suppose OpenSC + CCID/OpenCT is a personal preference then. It does not seem necessary for this goal; any working closed implementation of PKCS #11 would do. As explained before, I find the idea appealing to use tokens as a low-end HSM for OpenDNSSEC, to cover limited numbers of domains. Hope this helps, Cheers, -Rick From roland.vanrijswijk at surfnet.nl Thu Mar 12 07:39:58 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 12 Mar 2009 08:39:58 +0100 Subject: [Opendnssec-develop] compact HSM needed... In-Reply-To: References: Message-ID: <49B8BC4E.4060702@surfnet.nl> Hi Jakob, Jakob Schlyter wrote: > I'm looking for a smartcard with integrated USB-reader (aka "token") > that is: > > a) with a CCID-class reader (so I can use it om my mac) > b) with a chip that is supported by OpenSC > > the Aladdin eToken seemed to fit my reqs, but the reader isn't supported. > > > the purpose of this exercise is to be able to show a very small HSM so I > can demo OpenDNSSEC at the IETF. I can supply you with a Marx Cryptoken USB key which is CCID compatible and comes with a PKCS #11 library that runs on a variety of platforms (Win32, Mac OS X, Linux distros), let me know if I should arrange this for you. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard.bondesson at iis.se Thu Mar 12 08:01:38 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 12 Mar 2009 09:01:38 +0100 Subject: [Opendnssec-develop] hsm-toolkit questions In-Reply-To: References: <6E180159-98A2-4511-93E3-B8D9B8834B2A@kirei.se><69830D4127201D4EBD146B904119971896C910@EXCHANGE.office.nic.se><2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk><2A01DCE0-3C9B-4063-B576-F0E20421397F@jadickinson.co.uk><20090311134619.GA12776@phantom.vanrein.org> Message-ID: <69830D4127201D4EBD146B904119971896C96F@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I've written some text about Keys within OpenDNSSEC at > http://www.opendnssec.se/wiki/Signer/Keys > . this pages is not yet linked to other pages and needs more work. Looking good. But we need to define how and where the components can find the configured HSM, so the user do not have to configure each component with this information. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbjBYuCjgaNTdVjaAQjaIAf8Cco5etLEmRsF3e2UUHpbelq+WuQ387aQ D2+M3DZBHJ9+mqH+IOSFo4kNFd2dYp/Mev8J4Lb6/NREYGzdriZJ2B23/rMgGC9X eRw2/LO+nm2K1mF1qFY7iQoy2jnox6scZhXjOTi9CHQCtQ4CZF2AR83N/QjyI+cz +ofdOrD68Alq68Gr9ksAZQf9A6RywPiRG156t9p2WC8QWPFrxHJlNuSBFG5Hd7O0 TF73nKx741wcbDevB0sq0x/tUSPnCtW8euKoSphpl9rak6RPLv6wU2pjWgHn7MjY LZmdXM3py4RbZgmy3Hh9Apiqsl0HwT1zziAcYopYrOuLxYuWr7dGdQ== =Vk1A -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Thu Mar 12 08:18:49 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 12 Mar 2009 09:18:49 +0100 Subject: [Opendnssec-develop] OpenDNSSEC meeting during IETF74 In-Reply-To: <69830D4127201D4EBD146B904119971896C8CA@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971896C7D2@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971896C8CA@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971896C972@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thank you everyone. The Doodle tells us that we can have a meeting on Wednesday 13:00-15:30. Stephen, let us know if Nominet have a meeting room available as mentioned during the telephone meeting. The subject will be the finalization of phase 1. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSbjFaeCjgaNTdVjaAQgezgf7BF+1+HOn1f97jSfT/mhU8wXx6RZge7Gu GkDr0OLsF9X34cV+iqHWIv8wOFu7IrcQxy9UFwP4c4IeCwhndzxK3btWCrYAM297 gww6FZ4RcEshwdsJAK4qqOsnlTBV3VGLLybktfixDNtRLJEYgfmr2G+yVizMVf1Q Cz3vRuxQllltWiyZwk16E84u6Rw4sYDXq9x25zE3GZGvKABujGGj0lTAWEIuP2nM 11rSGy/jHA2aIUrWD28/soYbFRES8oH+lulYMMl5xW748fVnhc/0fziacEMcAXMs b9yOBVxusPbpKEbfH21OWENGG370MGii39YQ9Tyd1rbW9qjy6dj8sQ== =QJ/r -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Thu Mar 12 08:27:50 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 12 Mar 2009 09:27:50 +0100 Subject: [Opendnssec-develop] Status update HSM buyer's guide Message-ID: <49B8C786.9060803@surfnet.nl> Hi all, Just to let you know: I'm still working on the HSM buyer's guide. Unfortunately I have a very busy schedule so progress is slow. I'm hoping to have something reviewable by the end of next week. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Stephen.Morris at nominet.org.uk Thu Mar 12 11:00:34 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 12 Mar 2009 11:00:34 +0000 Subject: [Opendnssec-develop] OpenDNSSEC meeting during IETF74 In-Reply-To: <69830D4127201D4EBD146B904119971896C972@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 12/03/2009 08:18:49: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Thank you everyone. > > The Doodle tells us that we can have a meeting on Wednesday 13:00-15:30. > > Stephen, let us know if Nominet have a meeting room available as > mentioned during the telephone meeting. Will do. The current state is that we have asked for a meeting room, but the IETF organisers haven't got back to us yet. I'll keep you posted. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Thu Mar 12 13:43:53 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 12 Mar 2009 14:43:53 +0100 Subject: [Opendnssec-develop] (long) My personal thoughts about identifiers, attributes and formats. Message-ID: To help the discussion surrounding the identification of objects in a pkcs11 enabled environment, I have put my thoughts here. Please skip the blurb below to the "QUESTIONS" section if you do not wish to submerge into the boring material. (1) Unique Identifiers All key-pairs should be uniquely identifiable. They need to be unique, as Jakob and John tell me, across "time and space". Though I found this argument too strong before, I have reconsidered this thought. Unique across time essentially means that key identifiers must be unique over time. This restriction is important, since a key generator might not have knowledge of prior generation of keys. Unique across space essentially means that key identifiers must be unique in the presence of multiple storage environments. This restriction is important, since a key generator might not have knowledge of all available key storage. The scenario that convinced me is that an organisation might migrate storage of keys from a special purpose HSM to a general purpose HSM. That is, an organisation might already have an HSM for SSL termination and/or acceleration, and wants to use it to store DNSSEC related objects. Though we might highly recommend a separate "security world", slot, keystore or what not, for DNSSEC, the reality is, that the general HSM has objects that should not confuse OpenDNSSEC, and OpenDNSSEC related objects should not confuse existing applications (users). Also, since key-generation and key-using events are unrelated (apart from the order ;-) ). I can generate a key on HSM x, for zone y, but when actually continuously signing records in bulk, for various zones, there might be more than one HSM present. UUID's satisfy this requirement, and I'm not unwilling to use it for this purpose, so lets have a look: (2) The source of identifier UUID's are of fixed length (128 bits), and are not extendable. I'm sure 128 bits is more than enough. Then there is the question of how to determine (or calculate) UUID's, and there is some guidance in rfc 4412 on this. There are 5 defined ways of 'sourcing' uuids. There can be more but have not been defined. There is no IANA registry for UUID versions, nor is there a designated template for defining new versions. I also like the UUID itself to be completely independent of the content of the object. This avoids that an object is generated, and then need to be re-read to determine an UUID. So, as a source for the UUID, I think that a prng would do. The obvious choice is then version 4. Version 5 doesn't add anything, as it would only hash the random number, ergo, if the random number generator is not actually random enough, than hashing it won't make it more random. This also avoid dependency on a hash algorithm and the subsequent crypto grandstanding around it. (3) Which attribute to use. We still have to determine which pkcs11 object attribute (CKA_bladibla) we will use to store the identifier. The CKA_LABEL attribute is common across all objects of the storage class. This storage class is inherited by the key class. The CKA_ID attribute belongs to the KEY object class. PKCS11 generalizes between KEY and CERTIFICATE classes. To clarify, the KEY object class refers to the CERTIFICATE class when discussing CKA_ID usage. I've quoted the specific sections below: On CKA_LABEL usage: a) 10.4 Storage objects The CKA_LABEL attribute is intended to assist users in browsing. On CKA_ID usage: b) 10.7.2 Overview (10.7 Key objects) The CKA_ID field is intended to distinguish among multiple keys. In the case of public and private keys, this field assists in handling multiple keys held by the same subject; the key identifier for a public key and its corresponding private key should be the same. The key identifier should also be the same as for the corresponding certificate, if one exists. Cryptoki does not enforce these associations, however. (See Section 10.6 for further commentary.) subsequently (since the previous quote refers to Section 10.6 for further commentary): c) 10.6.3 X.509 public key certificate objects The CKA_ID attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject (whether stored in the same token or not). (Since the keys are distinguished by subject name as well as identifier, it is possible that keys for different subjects may have the same CKA_ID value without introducing any ambiguity.) The term "browsing" (from 'assist users in browsing') is undefined, but it implies that it can be used by a user (application) to distinguish an object when more than one is present. I would recommend against using a combination of both. As for as formatting goes, CKA_LABEL is UTF-8 encoded unicode, while the CKA_ID is an array of bytes, both do not restrict usage. It seems that CKA_LABEL is persistent across all storage objects. When I look at practises in other applications, it seems that CKA_ID is used to tie key (objects) to certificate (objects). The quoted text seems to substantiate that thought. (4) Storage format. Lastly, we have to determine if we store the source of the UUID, or the UUID itself. My personal preference is to store the UUID itself. If we only store the 128 bit value, we require all encompassing software that relates the object identifier to a value to translate the identifier to UUID and back. The UUID is then solely a presentation format. After extensive sieving through the spec, I have the following questions: QUESTIONS: (1) Can I use UUID as an identification format. (2) Can I use UUID version 4 (random numbers) as the source. (3) Can I use the CKA_LABEL attribute to store the identifier. (4) Can I store the UUID string without special formatting. Thanks, Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.vanrijswijk at surfnet.nl Thu Mar 12 14:12:36 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 12 Mar 2009 15:12:36 +0100 Subject: [Opendnssec-develop] (long) My personal thoughts about identifiers, attributes and formats. In-Reply-To: References: Message-ID: <49B91854.1080804@surfnet.nl> Hi Roy, > QUESTIONS: > > (3) Can I use the CKA_LABEL attribute to store the identifier. What other objects do you think you will be storing on the HSM other than keys? If all you are using is keys, then I would suggest that you used CKA_ID for machine readable identifiers (e.g. UUIDs) and CKA_LABEL for human readable identifiers (a descriptive string "Private KSK for zone ladila.org"). > (4) Can I store the UUID string without special formatting. CKA_LABEL uses UTF8 encoding, which means that you cannot store arbitrary byte values without breaking the encoding (values above 127 (0x7F) have a special meaning); I would therefore suggest that you use a hexadecimal string representation of the UUID according to the commonly used formatting (fields separated by dashes: abcd-1234-56a... etc) Just my 2 cents. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From roy at nominet.org.uk Thu Mar 12 14:43:17 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 12 Mar 2009 15:43:17 +0100 Subject: [Opendnssec-develop] (long) My personal thoughts about identifiers, attributes and formats. In-Reply-To: <49B91854.1080804@surfnet.nl> References: <49B91854.1080804@surfnet.nl> Message-ID: Roland van Rijswijk wrote on 03/12/2009 03:12:36 PM: > Hi Roy, > > > QUESTIONS: > > > > (3) Can I use the CKA_LABEL attribute to store the identifier. > > What other objects do you think you will be storing on the HSM other > than keys? If all you are using is keys, then I would suggest that you > used CKA_ID for machine readable identifiers (e.g. UUIDs) and CKA_LABEL > for human readable identifiers (a descriptive string "Private KSK for > zone ladila.org"). It seems that CKA_ID is used to tie a key object to a certificate object. In short, you'd identify a certificate first, by using CKA_SUBJECT, and then you use CKA_ID of the certificate object find the associated key object. This is exactly why most applications use the modulus as an identifier in CKA_ID, as it is persistent among the two objects. Though in essence, you could use CKA_ID, but it seems that CKA_LABEL is the defacto method of identifying an object. I say defacto, because pkcs11 goes out of its way to have a single identifier or method to identify keys. To answer your question though, I do not foresee the OpenDNSSEC project to store anything other than keys in an HSM, though the HSM might have other users as well. > > (4) Can I store the UUID string without special formatting. > > CKA_LABEL uses UTF8 encoding, which means that you cannot store > arbitrary byte values without breaking the encoding (values above 127 > (0x7F) have a special meaning); I would therefore suggest that you use a > hexadecimal string representation of the UUID according to the commonly > used formatting (fields separated by dashes: abcd-1234-56a... etc) I meant using the UUID string (like "e62d9060-0f11-11de-8b30-0002a5d5c51b") in the CKA_LABEL, instead of using any other special formatting. Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at jadickinson.co.uk Thu Mar 12 17:00:48 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 12 Mar 2009 17:00:48 +0000 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <028F915D-0B0D-400F-8987-579BAF13CB91@kirei.se> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> <028F915D-0B0D-400F-8987-579BAF13CB91@kirei.se> Message-ID: <4B467F96-F28E-40FB-8B71-A7C68E66023D@jadickinson.co.uk> On 5 Mar 2009, at 21:06, Jakob Schlyter wrote: > On 5 mar 2009, at 21.17, Olaf Kolkman wrote: > >> Extensions... that reminds me that I once tried to extend an XML >> schema that I used in a configuration and was happy I had a version >> attribute defined so that my parser knew that the schema had changed. > > yes, we should version the schema once finalised. > I suspect (but I am no xml expert) that it would be a good idea to add a namespace to the xml Index: kasp.rnc =================================================================== --- kasp.rnc (revision 280) +++ kasp.rnc (working copy) @@ -2,6 +2,8 @@ datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" +default namespace od = "http://www.opendnssec.org/ns/kasp/1" + start = element kasp { # Parameters about the key rollover procedure itself Index: kasp.xml =================================================================== --- kasp.xml (revision 280) +++ kasp.xml (working copy) @@ -2,7 +2,7 @@ - + PT3600S We can then use namespaces to version the xml. There is a discussion here (but it is a bit old and maybe someone can point us in a more up- to-date direction) http://www.w3.org/2001/tag/doc/versioning-xml John --- John Dickinson http://www.jadickinson.co.uk From roy at nominet.org.uk Thu Mar 12 17:45:31 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 12 Mar 2009 18:45:31 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. Message-ID: I've discussed the issue with David Miller and Dr Stephen N Henson. It seems that there is indeed much confusion in the field about CKA_ID's and CKA_LABELs. As an example, there exist pkcs11 libraries that will promiscuously match CKA_ID's while the search template specifies CKA_LABEL and vice versa. On the uniqueness of identifiers they advised that we can't uniquely assign identifiers per object, since some objects need to match other objects. In our case, we need to match CKO_PRIVATE_KEY with CKO_PUBLIC_KEY. Two different, independent objects from a PKCS11 perspective, though they need to be matched. For that purpose, we need to have CKA_ID to match the two, hence they need to be equal. So the uniquely identifiable pragma holds only for CKO_PRIVATE_KEY and CKO_PUBLIC_KEY Pairs. There are some implementations that ignore CKA_ID, and some that ignore CKA_LABEL. Even to the point that the attribute is present, but can't be used for C_FindObjects. Another issue is that often CKA_LABEL needs to be non-empty, as there are some applications that use the empty CKA_LABEL to match all objects for a certain purpose. Their conclusion is to be pragmatic. Though the theory is that CKA_LABEL can well be used for searching, CKA_ID needs to be present anyway to match the private object with the public object. Hence forcing the use of CKA_LABEL is overkill. So it seems that the experts (rick, roland, david and steve) agree. I'll step off my high-horse and conform. CKA_ID it is. Next time we meet (RIPE?) , beer is on me, to compensate for the wasted time. (Rick, lets do that soon). That leaves us with the encoding. do we put a string like "254F9220-7B9C-4386-ABC2-F8230E3843B3" in the CKA_ID or do we put the 128 bit value in the CKA_ID. There is no restriction here, other than the requirement of the signer for translating the 128 bit value to UUID when we decide to store the 128-bit value. (the translation does not need to be done in the signer when we use the UUID overall). We still need the CKA_LABEL to be non-empty. I'll just put "OpenDNSSEC DNSKEY" in there, unless told otherwise. Thanks, Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Mar 12 21:07:31 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 12 Mar 2009 22:07:31 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: References: Message-ID: I recommend that we use the ASCII representation of the UUID to ease access with 3rd party tools for debugging and monitoring. -- Sent from my iPhone, hence this mail might be briefer than normal. On 12 mar 2009, at 18.45, "Roy Arends" wrote: > I've discussed the issue with David Miller and Dr Stephen N Henson. > > It seems that there is indeed much confusion in the field about > CKA_ID's and CKA_LABELs. As an example, there exist pkcs11 libraries > that will promiscuously match CKA_ID's while the search template > specifies CKA_LABEL and vice versa. On the uniqueness of identifiers > they advised that we can't uniquely assign identifiers per object, > since some objects need to match other objects. In our case, we need > to match CKO_PRIVATE_KEY with CKO_PUBLIC_KEY. Two different, > independent objects from a PKCS11 perspective, though they need to > be matched. For that purpose, we need to have CKA_ID to match the > two, hence they need to be equal. So the uniquely identifiable > pragma holds only for CKO_PRIVATE_KEY and CKO_PUBLIC_KEY Pairs. > There are some implementations that ignore CKA_ID, and some that > ignore CKA_LABEL. Even to the point that the attribute is present, > but can't be used for C_FindObjects. > > Another issue is that often CKA_LABEL needs to be non-empty, as > there are some applications that use the empty CKA_LABEL to match > all objects for a certain purpose. Their conclusion is to be > pragmatic. Though the theory is that CKA_LABEL can well be used for > searching, CKA_ID needs to be present anyway to match the private > object with the public object. Hence forcing the use of CKA_LABEL is > overkill. > > So it seems that the experts (rick, roland, david and steve) agree. > I'll step off my high-horse and conform. CKA_ID it is. Next time we > meet (RIPE?) , beer is on me, to compensate for the wasted time. > (Rick, lets do that soon). > > That leaves us with the encoding. do we put a string like > "254F9220-7B9C-4386-ABC2-F8230E3843B3" in the CKA_ID or do we put > the 128 bit value in the CKA_ID. There is no restriction here, other > than the requirement of the signer for translating the 128 bit value > to UUID when we decide to store the 128-bit value. (the translation > does not need to be done in the signer when we use the UUID overall). > > We still need the CKA_LABEL to be non-empty. I'll just put > "OpenDNSSEC DNSKEY" in there, unless told otherwise. > > Thanks, > > Regards, > > Roy Arends > Sr. Researcher > Nominet UK > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.vanrijswijk at surfnet.nl Fri Mar 13 08:34:32 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Fri, 13 Mar 2009 09:34:32 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: References: Message-ID: <49BA1A98.4080209@surfnet.nl> Excellent idea! Agreed :-) Cheers, Roland Jakob Schlyter wrote: > I recommend that we use the ASCII representation of the UUID to ease > access with 3rd party tools for debugging and monitoring. > > -- > Sent from my iPhone, hence this mail might be briefer than normal. > > On 12 mar 2009, at 18.45, "Roy Arends" > wrote: > >> I've discussed the issue with David Miller and Dr Stephen N Henson. >> >> It seems that there is indeed much confusion in the field about >> CKA_ID's and CKA_LABELs. As an example, there exist pkcs11 libraries >> that will promiscuously match CKA_ID's while the search template >> specifies CKA_LABEL and vice versa. On the uniqueness of identifiers >> they advised that we can't uniquely assign identifiers per object, >> since some objects need to match other objects. In our case, we need >> to match CKO_PRIVATE_KEY with CKO_PUBLIC_KEY. Two different, >> independent objects from a PKCS11 perspective, though they need to be >> matched. For that purpose, we need to have CKA_ID to match the two, >> hence they need to be equal. So the uniquely identifiable pragma holds >> only for CKO_PRIVATE_KEY and CKO_PUBLIC_KEY Pairs. There are some >> implementations that ignore CKA_ID, and some that ignore CKA_LABEL. >> Even to the point that the attribute is present, but can't be used for >> C_FindObjects. >> >> Another issue is that often CKA_LABEL needs to be non-empty, as there >> are some applications that use the empty CKA_LABEL to match all >> objects for a certain purpose. Their conclusion is to be pragmatic. >> Though the theory is that CKA_LABEL can well be used for searching, >> CKA_ID needs to be present anyway to match the private object with the >> public object. Hence forcing the use of CKA_LABEL is overkill. >> >> So it seems that the experts (rick, roland, david and steve) agree. >> I'll step off my high-horse and conform. CKA_ID it is. Next time we >> meet (RIPE?) , beer is on me, to compensate for the wasted time. >> (Rick, lets do that soon). >> >> That leaves us with the encoding. do we put a string like >> "254F9220-7B9C-4386-ABC2-F8230E3843B3" in the CKA_ID or do we put the >> 128 bit value in the CKA_ID. There is no restriction here, other than >> the requirement of the signer for translating the 128 bit value to >> UUID when we decide to store the 128-bit value. (the translation does >> not need to be done in the signer when we use the UUID overall). >> >> We still need the CKA_LABEL to be non-empty. I'll just put "OpenDNSSEC >> DNSKEY" in there, unless told otherwise. >> >> Thanks, >> >> Regards, >> >> Roy Arends >> Sr. Researcher >> Nominet UK >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > ------------------------------------------------------------------------ > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Sun Mar 15 10:54:12 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Sun, 15 Mar 2009 11:54:12 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: <49BA1A98.4080209@surfnet.nl> References: <49BA1A98.4080209@surfnet.nl> Message-ID: <0565D5AE-9336-4123-82E9-C8218FCF264E@kirei.se> On 13 mar 2009, at 09.34, Roland van Rijswijk wrote: > Excellent idea! Agreed :-) this way one can use simple tools as pkcs11-tool from OpenSC and poke with the keys. jakob From jakob at kirei.se Sun Mar 15 11:03:43 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Sun, 15 Mar 2009 12:03:43 +0100 Subject: [Opendnssec-develop] KSK vs ZSK In-Reply-To: <4B467F96-F28E-40FB-8B71-A7C68E66023D@jadickinson.co.uk> References: <202CCE1E-C4AC-464C-89F1-BF3CFBFED7AA@kirei.se> <49AFD5D9.1010204@nlnetlabs.nl> <028F915D-0B0D-400F-8987-579BAF13CB91@kirei.se> <4B467F96-F28E-40FB-8B71-A7C68E66023D@jadickinson.co.uk> Message-ID: <7FC724C8-D221-4A0F-B830-F8C9B6967D73@kirei.se> On 12 mar 2009, at 18.00, John Dickinson wrote: > I suspect (but I am no xml expert) that it would be a good idea to > add a namespace to the xml yes, we should do this as soon as we've frozen version 1 of the specs. jakob From jakob at kirei.se Mon Mar 16 13:41:38 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 16 Mar 2009 14:41:38 +0100 Subject: [Opendnssec-develop] HSM recommendations or not? Perhaps a short review instead Message-ID: how about recoming the HSM product list and comparision and replace them with a list of the HSM:s we have 1st hand experience with? - Sun SCA6000 - AEP? - MARX Cryptobox (soonish) a short summary of features, approx cost and pros/cons. nothing more and no complete guide. makes sense? jakob From roland.vanrijswijk at surfnet.nl Mon Mar 16 13:46:16 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 16 Mar 2009 14:46:16 +0100 Subject: [Opendnssec-develop] HSM recommendations or not? Perhaps a short review instead In-Reply-To: References: Message-ID: <49BE5828.5000503@surfnet.nl> Hi Jakob, all, Maybe a "HOWTO" form is more useful; describe how one product or other was used with OpenDNSSEC and what had to be done to get it to work with OpenDNSSEC. In this way, you don't give explicit recommendations (i.e. no endorsing of one product over another). Pro's and con's can still be part of a HOWTO B.T.W. Cheers, Roland Jakob Schlyter wrote: > how about recoming the HSM product list and comparision and replace them > with a list of the HSM:s we have 1st hand experience with? > > - Sun SCA6000 > - AEP? > - MARX Cryptobox (soonish) > > a short summary of features, approx cost and pros/cons. nothing more and > no complete guide. > > makes sense? > > > jakob > > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Tue Mar 17 09:48:58 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 17 Mar 2009 10:48:58 +0100 Subject: [Opendnssec-develop] HSM review/howto Message-ID: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> as an inventory, which of the following HSM:s do we have first hand experience of? ? Sun Crypto Accelerator 6000 ? AEP Networks Keyper ? nCipher nShield ? nCipher netHSM ? SafeNet Luna SA ? SafeNet Luna PCI ? SafeNet ProtectServer Gold ? SafeNet ProtectServer External ? IBM 4764 I've work with the SCA6000. others? j From roland.vanrijswijk at surfnet.nl Tue Mar 17 09:55:29 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 17 Mar 2009 10:55:29 +0100 Subject: [Opendnssec-develop] HSM review/howto In-Reply-To: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> References: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> Message-ID: <49BF7391.2050505@surfnet.nl> Hi Jakob, all, I've worked with the SafeNet (formerly Eracom) ProtectServer and with the nCipher nShield but that was a long time ago. I know I had some issues getting both to work but once I got them running they worked fine (I wouldn't feel comfortable writing a HOWTO about these, since it's simply too long ago that I used them). We're considering buying a SafeNet HSM to use with OpenDNSSEC within SURFnet. I've got some sales people over the first week of April. If we decide to buy a SafeNet HSM I'm sure I can let some of you guys play around with it. Cheers, Roland Jakob Schlyter wrote: > as an inventory, which of the following HSM:s do we have first hand > experience of? > > ? Sun Crypto Accelerator 6000 > ? AEP Networks Keyper > ? nCipher nShield > ? nCipher netHSM > ? SafeNet Luna SA > ? SafeNet Luna PCI > ? SafeNet ProtectServer Gold > ? SafeNet ProtectServer External > ? IBM 4764 > > I've work with the SCA6000. others? > > j > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard.bondesson at iis.se Wed Mar 18 09:58:46 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 18 Mar 2009 10:58:46 +0100 Subject: [Opendnssec-develop] Phase 1 UML diagram Message-ID: <69830D4127201D4EBD146B904119971896CB97@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I would be happy if everyone sends me a short description on how their components interact with its surrounding. I will then put this information on the wiki page. I know that we have specified this in the system design, but the real world differs from the design. E.g. how will the SECP talk to the Signer Engine or how will the administrator populate the database? http://www.opendnssec.se/wiki/Signer/Phase1/HowItWorks // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBScDF1uCjgaNTdVjaAQinqwf/Y/6oEFWHI29w/c/qEuKeGGkqv2RKgIjX BOZb2zfwNNjMScpfP6iXnriCHBehx3d8iPftjJpGQa3RyH/vlibJ9oqs9yKjwv26 CO4tHQuXm9Q1XeHj0fEr107vA9dXTRKV3p5gyYKbrw8Z4ADi9rhVWRmwDPeSZhf+ 7dSJOCNhfhG7+PLPKU4/+np15BQrKmRlpeNdcxJCOdgyyRgJv5PRTEYXjhvYtYHT iQqt3JrpQc81gfrA8mHna9KQuotgxY/UUVjWn1CsIpV6o3HBUxTbboPEN9ouMRsk txtZ1ltDv6xafSlXH1vaw2CoWAoJhilHlZhUGvXMbYLzjaeCEah9MA== =aFTl -----END PGP SIGNATURE----- From jakob at kirei.se Thu Mar 19 15:15:14 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 19 Mar 2009 16:15:14 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: <49BA1A98.4080209@surfnet.nl> References: <49BA1A98.4080209@surfnet.nl> Message-ID: <30B0168B-CBF8-4280-9710-333B7A817FE3@kirei.se> On 13 mar 2009, at 09.34, Roland van Rijswijk wrote: > Excellent idea! Agreed :-) however, it turns out the tools (like opensc's pkcs11-tool only supports hex strings), so I say: - the hex digits from the UUID, encoded as hex without separators. e.g. 8D76C0C4-9FEB-4A97-B8E9-20C7552401CE is stored as 8D76C0C49FEB4A97B8E920C7552401CE. which is also inline with what Jelte has written code for... ok? jakob From roy at nominet.org.uk Thu Mar 19 15:40:04 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 19 Mar 2009 16:40:04 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: <30B0168B-CBF8-4280-9710-333B7A817FE3@kirei.se> References: <49BA1A98.4080209@surfnet.nl> <30B0168B-CBF8-4280-9710-333B7A817FE3@kirei.se> Message-ID: Jakob Schlyter wrote on 03/19/2009 04:15:14 PM: > > Excellent idea! Agreed :-) > > however, it turns out the tools (like opensc's pkcs11-tool only > supports hex strings), so I say: > > - the hex digits from the UUID, encoded as hex without separators. > > e.g. 8D76C0C4-9FEB-4A97-B8E9-20C7552401CE is stored as > 8D76C0C49FEB4A97B8E920C7552401CE. > > > which is also inline with what Jelte has written code for... ok? Fine by me. Just to be completely clear, we store the hex representation (32 bytes), not the 16 byte value represented by that hex presentation. Regards, Roy Arends Sr. Researcher Nominet UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Morris at nominet.org.uk Thu Mar 19 17:57:05 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 19 Mar 2009 17:57:05 +0000 Subject: [Opendnssec-develop] OpenDNSSEC meeting during IETF74 In-Reply-To: Message-ID: I wrote on 12/03/2009 11:00:34: > > "Rickard Bondesson" wrote on 12/03/2009 08:18:49: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Thank you everyone. > > > > The Doodle tells us that we can have a meeting on Wednesday 13:00-15:30. > > > > Stephen, let us know if Nominet have a meeting room available as > > mentioned during the telephone meeting. > > Will do. The current state is that we have asked for a meeting > room, but the IETF organisers haven't got back to us yet. I'll keep > you posted. > > Stephen _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop A room has been booked for our meeting at the IETF on Wednesday, 13:00 - 15:30. I'll let you know the room number as soon as I find out myself. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Mar 19 21:26:17 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 19 Mar 2009 22:26:17 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: References: <49BA1A98.4080209@surfnet.nl> <30B0168B-CBF8-4280-9710-333B7A817FE3@kirei.se> Message-ID: On 19 mar 2009, at 16.40, Roy Arends wrote: > Fine by me. Just to be completely clear, we store the hex > representation (32 bytes), not the 16 byte value represented by that > hex presentation. as I understand the implementations, the hex representation shown in tools like pkcs11-tool (from OpenSC) is the hex representation of the byte values. so, 2EFAD382-4F44-475E-97CE-1CE3EB9283FE would be stored as a 16-byte array: { 2E FA D3 82 4F 44 47 5E 97 CE 1C E3 EB 92 83 FE } Roland? Rick? does this make sense? jakob From rick at openfortress.nl Fri Mar 20 07:01:17 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 20 Mar 2009 07:01:17 +0000 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: References: <49BA1A98.4080209@surfnet.nl> <30B0168B-CBF8-4280-9710-333B7A817FE3@kirei.se> Message-ID: <20090320070117.GB2120@phantom.vanrein.org> Hi all, To be honest, I'm not keen on following OpenSC as the definition of what our PKCS #11 implementation should look like. I'd rather improve on the code of that library if it fails to meet the standard. I don't hold the quality of OpenSC very highly and it could drag us down. Having said that, I don't mind storing identifiers textually, as long as we remember to handle upper/lowercase problems. Perhaps it is better to store CKA_ID in its canonical, binary form, to avoid any such problems. It is great that tools like OpenSC solve the problem of how to print binary content by showing it as hex dumps. This is probably the most sensible one can do, given that CKA_ID is just a binary byte array. If our UUID is spelled out in hexadecimal and then stored, each hex digit would be printed as a byte code, which is not the intuitive readout that we were hoping for by storing the UUID as a text string. Had we stored the UUID in CKA_LABEL, a textual representation would have been ideal; but since we are going for CKA_ID, I think it is best to stick to the binary representation. > so, 2EFAD382-4F44-475E-97CE-1CE3EB9283FE would be stored as a 16-byte > array: > { 2E FA D3 82 4F 44 47 5E 97 CE 1C E3 EB 92 83 FE } > > > Roland? Rick? does this make sense? Yes, even if it seems to conflict earlier messages. This is what I am in favour of. But not just because OpenSC told us so! Cheers, -Rick From rickard.bondesson at iis.se Fri Mar 20 07:02:41 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 20 Mar 2009 08:02:41 +0100 Subject: SV: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: References: <49BA1A98.4080209@surfnet.nl><30B0168B-CBF8-4280-9710-333B7A817FE3@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971896CC44@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > as I understand the implementations, the hex representation > shown in tools like pkcs11-tool (from OpenSC) is the hex > representation of the byte values. > > so, 2EFAD382-4F44-475E-97CE-1CE3EB9283FE would be stored as a 16-byte > array: > { 2E FA D3 82 4F 44 47 5E 97 CE 1C E3 EB 92 83 FE } If I store the same value in both CKA_LABEL and CKA_ID with pkcs11-tool, lets say 090310084749289287 Then pkcs11-tool will present this: label: 090310084749289287 ID: 303930333130303834373439323839323837 They are represented by the same bytes in the token, but presented diffrently. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBScM/keCjgaNTdVjaAQgvtwf+LqUbKIEvVTz/S7wYTBRXsh0eHmpFH9wF +Wp53/HHK6yiV2/536nj+AIdqmEu1MWrP2yn70WFT9Twr85QO+d6Y2uL/mST5lw1 DjgQpZgS0T4+I6oV8O3PknOS4JAd9pIhzwNlUGYZT6p5QzNZZeVKRUXXmE8uuW3K BY63QP2cz9q+MHjIRoENxKNBWpHSc9+DmfUdYo4RL+TfOwRTRK2LCAx1rBfDdcAp NLWsHyx325FAJ5aF789eGNEobVnWiRWEL2mdglg72uHjcrfoUANL1oC7sza47+o9 xuoHzxhu+1GJL3QiDC1wTv/rWHHYK9P4cNd9wKMvE0gRwVFRT1rDeg== =dIaF -----END PGP SIGNATURE----- From rick at openfortress.nl Fri Mar 20 07:05:06 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 20 Mar 2009 07:05:06 +0000 Subject: SV: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: <69830D4127201D4EBD146B904119971896CC44@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971896CC44@EXCHANGE.office.nic.se> Message-ID: <20090320070506.GC2120@phantom.vanrein.org> Hello Rickard/others, > If I store the same value in both CKA_LABEL and CKA_ID with pkcs11-tool, lets say 090310084749289287 > > Then pkcs11-tool will present this: > > label: 090310084749289287 > ID: 303930333130303834373439323839323837 > > They are represented by the same bytes in the token, but presented diffrently. This seems to confirm my conclusion that it is best to use the textual UUID in the CKA_LABEL and the binary UUID in the CKA_ID. Great, so we'll have the most compact storage combined with pleasant readout! -Rick From rickard.bondesson at iis.se Fri Mar 20 10:58:36 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 20 Mar 2009 11:58:36 +0100 Subject: [Opendnssec-develop] *blush* The experts agree. CKA_ID it is. In-Reply-To: <69830D4127201D4EBD146B904119971896CC44@EXCHANGE.office.nic.se> References: <49BA1A98.4080209@surfnet.nl><30B0168B-CBF8-4280-9710-333B7A817FE3@kirei.se> <69830D4127201D4EBD146B904119971896CC44@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971896CC76@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > If I store the same value in both CKA_LABEL and CKA_ID with > pkcs11-tool, lets say 090310084749289287 > > Then pkcs11-tool will present this: > > label: 090310084749289287 > ID: 303930333130303834373439323839323837 > > They are represented by the same bytes in the token, but > presented diffrently. Ohh sorry this is what I should have said: If I store the same value in both CKA_LABEL and CKA_ID in my token, lets say { 30 39 30 33 31 30 30 38 34 37 34 39 32 38 39 32 38 37 } (a byte array) Then pkcs11-tool will present this: label: 090310084749289287 ID: 303930333130303834373439323839323837 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBScN23OCjgaNTdVjaAQjIggf/dbg2mXERzLwZp38lLn3EhZbTd9qLhUQi 2s8jOZqr0mpRm3H5mVGkpE69C4NgVZaC5ocY0N8Jm5sGDrvvAoxulduIHL49kHbH WaT88inlxjLfHHZSJ9CCpCcFr2KhwjA2wqNCfq3pVcXjRytMmBkJjM8QwuEmwkZG pC31PbPxE62FTPPqlzjPgYVq/zIVGqPizzzx0NKLEpWVx9ehz6dGT/1CdierfnrB YmGXcfhmFLyoE+tvf4fM+0CvT0syM2bW5Xb6TCGOfaCbp5t019NYVsNZKjpRVBfM NlLARLHT+yl4eFj1JkAoLU2gXqcozX29EWtgYrSKOC+d5eaRG7f/kw== =MxPQ -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Fri Mar 20 11:55:18 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 20 Mar 2009 12:55:18 +0100 Subject: [Opendnssec-develop] Call for meeting topics at IETF74 Message-ID: <69830D4127201D4EBD146B904119971896CC79@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Are there any other questions besides the finalization of phase 1, that you would like to discuss? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBScOEJuCjgaNTdVjaAQju3Af/RPcDysBHk/HClGXumBVG3vLqnwxYDfoO oN9KGXj3XJJJH+oVL1FdrQnS94ad8YizHICJWYKnkmzWqHHfuZ2XfMRLlelXPT9V /x8enfOj5bvij3DB25GBorPwwuvaX6jsb71i8+GKNgvbqpHsZDVO2LLm/Joegq8S +78lUmOwRcPEhsB6I3062CECPDHFnyeYFRM4Vzibw3aKCl1dDMNDSrnssfyr2thv D3NG3ZHWjiU2xXzSDfBDFLsWSz8WFnWBuTaxBNeaIMswoqIwNP96+bjy0j/iBn4H lSmvKhgFSSjTwLWHswjJfwO35/Op7nM+KcDtofEk023l9vQ/5xow9w== =yBpL -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Fri Mar 20 16:03:24 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 20 Mar 2009 16:03:24 +0000 Subject: [Opendnssec-develop] Meeting at IETF74 In-Reply-To: <69830D4127201D4EBD146B904119971896CC79@EXCHANGE.office.nic.se> Message-ID: Just to let you know that the the meeting will be in the LOMBARD ROOM, located on the 6th floor of Tower 3 of the hotel. The room is capable of taking 12 people - although there are only six of us, we may collect a couple of interested bystanders along the way. (Certainly my colleague Ray, who sits next to Sion and myself, is interested in coming along.) See you in San Francisco. Stephen From Stephen.Morris at nominet.org.uk Fri Mar 20 16:14:33 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 20 Mar 2009 16:14:33 +0000 Subject: [Opendnssec-develop] Call for meeting topics at IETF74 In-Reply-To: <69830D4127201D4EBD146B904119971896CC79@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 20/03/2009 11:55:18: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi > > Are there any other questions besides the finalization of phase 1, > that you would like to discuss? > > // Rickard If we are this close to finishing phase 1, why not take the opportunity to start discussing phase 2? Stephen From jad at jadickinson.co.uk Mon Mar 23 10:10:12 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 23 Mar 2009 10:10:12 +0000 Subject: [Opendnssec-develop] HSM review/howto In-Reply-To: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> References: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> Message-ID: <7566EB3F-CF2C-4954-ACCC-00B3744D6506@jadickinson.co.uk> On 17 Mar 2009, at 09:48, Jakob Schlyter wrote: > as an inventory, which of the following HSM:s do we have first hand > experience of? > > ? Sun Crypto Accelerator 6000 > ? AEP Networks Keyper > ? nCipher nShield > ? nCipher netHSM > ? SafeNet Luna SA > ? SafeNet Luna PCI > ? SafeNet ProtectServer Gold > ? SafeNet ProtectServer External > ? IBM 4764 > > I've work with the SCA6000. others? SCA6000 Keyper - but I no longer have access to it nCipher netHSM - a long time ago Safenet Luna SA - a long time ago I suspect that they all work - they all provided pkcs11 after all. The big problem I found with most of them is the appalling documentation and the lack of basic utilities such as a key generator. So, I think a how-to is a very good idea. Also the buyers guide should have a section on the basic things that you might want to look for when selecting a HSM - such as - is the documentation readable - can I ring tech support and speak to someone who knows something - is there a little demo of simple stuff like how to create a RSA key and use all the other features? Or does the documentation assume that I am looking for SSL acceleration only? - can I read the docs without being a crypto expert etc... IMHO - only once these sort of basic questions have been satisfied should the actual crypto and quality of security be considered. If they can not write good documentation then how can they write crypto code? In my experience the quality of the docs, demos and utilities varies greatly between the manufacturers listed above and makes all the difference when using an HSM. John --- John Dickinson http://www.jadickinson.co.uk From rick at openfortress.nl Mon Mar 23 10:16:14 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 23 Mar 2009 10:16:14 +0000 Subject: [Opendnssec-develop] HSM review/howto In-Reply-To: <7566EB3F-CF2C-4954-ACCC-00B3744D6506@jadickinson.co.uk> References: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> <7566EB3F-CF2C-4954-ACCC-00B3744D6506@jadickinson.co.uk> Message-ID: <20090323101614.GA30464@phantom.vanrein.org> Hi, > The > big problem I found with most of them is [...] > the lack of basic utilities such as a key generator. This is probably because applications usually have their own formatting issues with the keys being used; attributes are usually set in a way that suits the app. So, applications generate their own keys. > So, I think a how-to is a very good idea. Certainly. > In my experience the quality of the docs, demos and utilities varies > greatly between the manufacturers listed above and makes all the > difference when using an HSM. Good point. Cheers, -Rick From jad at jadickinson.co.uk Mon Mar 23 11:16:56 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 23 Mar 2009 11:16:56 +0000 Subject: [Opendnssec-develop] HSM review/howto In-Reply-To: <20090323101614.GA30464@phantom.vanrein.org> References: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> <7566EB3F-CF2C-4954-ACCC-00B3744D6506@jadickinson.co.uk> <20090323101614.GA30464@phantom.vanrein.org> Message-ID: On 23 Mar 2009, at 10:16, Rick van Rein wrote: > Hi, > >> The >> big problem I found with most of them is [...] >> the lack of basic utilities such as a key generator. > > This is probably because applications usually have their own > formatting > issues with the keys being used; attributes are usually set in a way > that suits the app. So, applications generate their own keys. That is something else I hate - a key is a key it shouldn't matter what you are going to use it for. It should not be necessary for there to be a dnssec-keygen and a ssh-keygen and a genrsa and so on and so on... :) John --- John Dickinson http://www.jadickinson.co.uk From rick at openfortress.nl Mon Mar 23 11:30:41 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 23 Mar 2009 11:30:41 +0000 Subject: [Opendnssec-develop] HSM review/howto In-Reply-To: References: <7E8E99BB-CC84-4D04-9C92-486E61BC39D0@kirei.se> <7566EB3F-CF2C-4954-ACCC-00B3744D6506@jadickinson.co.uk> <20090323101614.GA30464@phantom.vanrein.org> Message-ID: <20090323113041.GB31078@phantom.vanrein.org> Hi, > That is something else I hate - a key is a key it shouldn't matter > what you are going to use it for. It should not be necessary for there > to be a dnssec-keygen and a ssh-keygen and a genrsa and so on and so > on... :) I agree with you, but only on an abstract level. But now you're not having an issue with any HSM, but with PKCS #11. Or even more accurately, with the requirements that applications tend to place on them. Since it is unwise to use the same key for multiple applications, I don't think it is such a bad idea that apps set their own attributes and requirements on keys. Key management rules are also different, depending on the application (its usage requirements and its ability to communicate new keys with peers) so generating keys is, in my humble view, perfectly located inside an application. Cheers, -Rick From jakob at kirei.se Mon Mar 23 17:54:37 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Mar 2009 10:54:37 -0700 Subject: [Opendnssec-develop] XML capitalisation Message-ID: <0D843D1C-F974-43A8-80EB-F9265F63EDC1@kirei.se> I have an issue with our XML capitalisation. to be more specific, I find reSign really ugly. at the same time, using dashes in the element names are ugly, since some parsers don't quite work with them. so I propose that we choose between: - a) sane capitalisation only to indicate spaces and other features - b) lowercase only e.g. (a) is resign, keygenInterval, ttlDS, backupDelay. remember, XML is case sensitive. any strong opionions? or I'll do (a) soonish... jakob From matthijs at NLnetLabs.nl Mon Mar 23 18:54:39 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 23 Mar 2009 11:54:39 -0700 Subject: [Opendnssec-develop] Zone moving between operators Message-ID: <49C7DAEF.6040309@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I had a talk with Antoin Verschuren and have the feeling that moving zones between operators is underspecified in the opendnssec project. The issue was raised earlier by Rick. Questions that were raised are: * What to do when a zone moves from one operator to another. * What to do when the HSM is replaced * Should we really want to use the same key for multiple zones? It could have great impact if it became compromised. And does KASP has the logic if a key for zone A needs to be rollovered, but must be kept for other zones. This is clearly v2 material, but since it was suggested that we could discuss v2 in the upcoming meeting, I think it is worth to include this topic. I have taken the liberty to invite Antoin for wednesday to discuss the issues. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBScfa7w8yVCPsQCW5AQJasAgA0XBEYAm8b/yzNkh+UcIUf1iawR1LMULH NeNXoRywHUqyVUFUEnP+7wazXtxro7BhD4JS45dKrCAeIx8EGwHhMQWQWXGLOxFi FVkhbxGtiLVKRju7KltpIio+U2DutlFcBgfPiha3zg+hcEvbyvsilGHzSOi+ch3m UPdy0DfGBOpz+CfU+ADHezGIWuJ9gp4LWXo3p/38xdAsLEKRsRYdwdGBMPUnOOeo /AFmkqSQp4v+704FeHDTVPucUYHhfPFteGGDZGplplOa3C7qcYGJoFwQ0GiAC+B8 gS1cLOULfv3dgOMYPKVaz02u9GEXODGViWnSpeigCfsWb36nnBO0Yw== =CDK4 -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Mon Mar 23 18:58:19 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Mon, 23 Mar 2009 10:58:19 -0800 Subject: [Opendnssec-develop] XML capitalisation In-Reply-To: <0D843D1C-F974-43A8-80EB-F9265F63EDC1@kirei.se> Message-ID: opendnssec-develop-bounces at lists.opendnssec.org wrote on 23/03/2009 10:54:37: > I have an issue with our XML capitalisation. to be more specific, I > find reSign really ugly. at the same time, using dashes in the element > names are ugly, since some parsers don't quite work with them. so I > propose that we choose between: > > - a) sane capitalisation only to indicate spaces and other features > - b) lowercase only > > e.g. (a) is resign, keygenInterval, ttlDS, backupDelay. > > remember, XML is case sensitive. > > > any strong opionions? or I'll do (a) soonish... > > jakob How about Upper Camel Case for element names and Lower Camel Case for attributes, as used by ebXML? (See http://www.wmusers.com/forum/showthread.php?t=8745 for a brief desription.) Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at jadickinson.co.uk Mon Mar 23 19:09:46 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 23 Mar 2009 19:09:46 +0000 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <49C7DAEF.6040309@nlnetlabs.nl> References: <49C7DAEF.6040309@nlnetlabs.nl> Message-ID: On 23 Mar 2009, at 18:54, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I had a talk with Antoin Verschuren and have the feeling that moving > zones between operators is underspecified in the opendnssec project. > The > issue was raised earlier by Rick. > > Questions that were raised are: > > * What to do when a zone moves from one operator to another. Several people have asked me this as well - Off the top of my head, I don't think we can do anything. There are too many variables. I think that unless you (as a registrant) are willing to test the interaction between operators on a regular basis you have to assume that you will go, or at least will risk going, unsigned at change over. > * What to do when the HSM is replaced Just works (I hope). You add a new HSM, update policies to start using it and new keys will be created in the new HSM. > * Should we really want to use the same key for multiple zones? It > could > have great impact if it became compromised. Yes that is a risk - if you don't want to risk it don't do it. > And does KASP has the logic > if a key for zone A needs to be rollovered, but must be kept for other > zones. No - lets not go there. :) John --- John Dickinson http://www.jadickinson.co.uk From Antoin.Verschuren at sidn.nl Mon Mar 23 20:46:24 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Mon, 23 Mar 2009 21:46:24 +0100 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: References: <49C7DAEF.6040309@nlnetlabs.nl> Message-ID: <1237841184.6637.25.camel@SIDN0022> Op maandag 23-03-2009 om 19:09 uur [tijdzone +0000], schreef John Dickinson: > On 23 Mar 2009, at 18:54, Matthijs Mekking wrote: > > > > * What to do when a zone moves from one operator to another. > > Several people have asked me this as well - Off the top of my head, I > don't think we can do anything. There are too many variables. I think > that unless you (as a registrant) are willing to test the interaction > between operators on a regular basis you have to assume that you will > go, or at least will risk going, unsigned at change over. In current economics, the answer "we can't" won't help to get DNSSEC deployed. If my choice is between not signing my zone or disappoint my clients when I'm changing infrastructure, I know I will choose to not sign. Changing infrastructure is a common thing in current business processes, and in some countries even a requirement in policy. I think we can do it. Moving a zone has 3 options: 1. Become insecure, like you say. 2. Hand over the private keys for the zone to the new operator so he can do a key rollover to use his own keys. Not a very safe proces and certainly not possible when you use certain HSM's. 3. Have the losing operator sign the new key(s) from the gaining operator during a special key rollover process. I think that it's doable. Disadvantage of the last 2 is that it needs cooperation of the losing operator. But that's politics or policy, but I think it must be possible to change infrastructure without becoming insecure for DNSSEC to become deployed. > > * What to do when the HSM is replaced > > Just works (I hope). You add a new HSM, update policies to start using > it and new keys will be created in the new HSM. Here you actually have the same issue as you have in option 3 above. You need the old HSM to sign the new keys that are generated by the new HSM if you cannot move the private keys around from HSMold to HSMnew. You cannot just start using a new keyset that was not signed by the old one because you will break the chain of trust for signatures that are still in caches. > > And does KASP has the logic > > if a key for zone A needs to be rollovered, but must be kept for other > > zones. > > No - lets not go there. :) I prefer not to go there as well, but as it is common business practice to move one zone from operator 1 to operator 2 without moving all the other zones from operator 1, the advice should be to use a key per zone, and not reuse keys. Again, without these business processes supported, DNSSEC will not be used in the current real world. -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: Dit berichtdeel is digitaal ondertekend URL: From vramiro at niclabs.cl Mon Mar 23 20:58:16 2009 From: vramiro at niclabs.cl (Victor Ramiro) Date: Mon, 23 Mar 2009 16:58:16 -0400 Subject: [Opendnssec-develop] Access to svn code Message-ID: <8BFBC70F-77DD-4540-8FFF-B9A8F149C123@niclabs.cl> Hello everyone, We are gathering information about tools and services to implement DNSSEC here in .CL TLD (Niclabs is the research lab of NIC Chile). By now, we are studding configurations setups, available tools, etc. We are really interested in participate on your project, because in our internal roadmap we are planning to do some tools, that seems to be really close to your current development. So, we would like to start trying the code, maybe as beta-testers or something like that. So, if this sounds good to you, could we have access to code/svn? Regards, -- Victor Ramiro R&D Engineer Niclabs Chile (http://www.niclabs.cl) From jakob at kirei.se Mon Mar 23 21:15:56 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Mar 2009 14:15:56 -0700 Subject: [Opendnssec-develop] Access to svn code In-Reply-To: <8BFBC70F-77DD-4540-8FFF-B9A8F149C123@niclabs.cl> References: <8BFBC70F-77DD-4540-8FFF-B9A8F149C123@niclabs.cl> Message-ID: <4B2D2C85-C460-4218-815E-1AA308DFDB4F@kirei.se> hi victor, the svn repo is accessible as http://svn.opendnssec.se/. the current code isn't that runnable just yet, but I hope soon it will be. jakob From jakob at kirei.se Mon Mar 23 21:21:35 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Mar 2009 14:21:35 -0700 Subject: [Opendnssec-develop] XML capitalisation In-Reply-To: References: Message-ID: <78B3107D-FD43-432E-AD24-4CFBF38CE810@kirei.se> On 23 mar 2009, at 11.58, Stephen.Morris at nominet.org.uk wrote: > How about Upper Camel Case for element names and Lower Camel Case > for attributes, as used by ebXML? (See > http://www.wmusers.com/forum/showthread.php?t=8745 for a brief > desription.) as long as we make up our minds, I fine with anything. others? I hope we can freeze this soonish so John and Jelte doesn't have to update their code every other week :-) jakob From jakob at kirei.se Mon Mar 23 21:24:51 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Mar 2009 14:24:51 -0700 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <49C7DAEF.6040309@nlnetlabs.nl> References: <49C7DAEF.6040309@nlnetlabs.nl> Message-ID: <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se> On 23 mar 2009, at 11.54, Matthijs Mekking wrote: > * Should we really want to use the same key for multiple zones? It > could > have great impact if it became compromised. And does KASP has the > logic > if a key for zone A needs to be rollovered, but must be kept for other > zones. could you, or someone else, describe a scenario where one key in a HSM would be compromised and while other keys in the same HSM are not? (given that we use RSA with resonable key lengths) jakob From rickard.bondesson at iis.se Mon Mar 23 21:27:17 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 23 Mar 2009 22:27:17 +0100 Subject: [Opendnssec-develop] Access to svn code In-Reply-To: <8BFBC70F-77DD-4540-8FFF-B9A8F149C123@niclabs.cl> References: <8BFBC70F-77DD-4540-8FFF-B9A8F149C123@niclabs.cl> Message-ID: <69830D4127201D4EBD146B904119971896CD35@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Victor Glad to here that you are interested in the OpenDNSSEC project. Everything we do is freely available (BSD license) in our SVN repo as Jakob answered in another mail. The plan is to have the phase 1 of the project finished in April. And phase 2 by the summer. As of now, the current code is not fully documented and not fully complete. It is always good to have more people reviewing the code and testing the program. We will keep in touch. // Rickard > Hello everyone, > > We are gathering information about tools and services to > implement DNSSEC here in .CL TLD (Niclabs is the research lab > of NIC Chile). By now, we are studding configurations setups, > available tools, etc. > > We are really interested in participate on your project, > because in our internal roadmap we are planning to do some > tools, that seems to be really close to your current > development. So, we would like to start trying the code, > maybe as beta-testers or something like that. > > So, if this sounds good to you, could we have access to code/svn? -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBScf+teCjgaNTdVjaAQj3JAgAgR04NSmNjhDJlK0ZOLFCZXZnSRDOh4wS Uu3Ib7U71dH73sVmL9vnNQwcR23QY2fH+0m9gz5H77jh5pccEgqe0wF14AINTCHr o0JR6g3dTjJYM9wI88MUvKUF7dISFzkH1vHbEdGKp51phBih1DkKeP1WnQOGMjjs deFSCBDY4m01ORe444NvdseY4vh0qGshIMr/53xsJpG+bdEHy/VQYjAll3bYWtRc B4KD5hMxrYx9iNSJifBhNIbNwTlWOoTo+nt3kw/RMVuWZjQwskvPx4JxBgIyg10p AmRgwj6BmRiEQLTELdM5psfR7OOAIOIeBavIsmOuvcehEmhlaMHi9A== =+5ny -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Mon Mar 23 23:50:20 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 23 Mar 2009 16:50:20 -0700 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se> Message-ID: <49C8203C.1090202@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That's not really the point I am trying to make. I guess what I meant was that if one key is used for many zones and it gets compromised it could have great impact in the sense that all the zones need to be rollovered, perhaps many DS records need to be replaced and many updates need to go to the secondaries. Another issue is that if zone A is transferred to another DNS party, and zone uses a key that is in use for many zones. In that case, zone A needs an immediate rollover, but the key should be kept alive because it is use for other zones. However, this is no issue if we decide one key should not span multiple zones. Matthijs Jakob Schlyter schreef: > On 23 mar 2009, at 11.54, Matthijs Mekking wrote: > >> * Should we really want to use the same key for multiple zones? It could >> have great impact if it became compromised. And does KASP has the logic >> if a key for zone A needs to be rollovered, but must be kept for other >> zones. > > could you, or someone else, describe a scenario where one key in a HSM > would be compromised and while other keys in the same HSM are not? > (given that we use RSA with resonable key lengths) > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBScggPA8yVCPsQCW5AQJsaggAwAToaht9aLYAkNY+0TeZTexZZWlyVjb3 c0nJ+NVFe2tjGG6/ZGjuQXkggQ+Jf8hIA23IVwMVTTjbYDY5q1fMVTVnWOaUJM1z oKNIb5DwaBJtvJVXgCALWTf+Ud0yOE3sTCuBq1t2r9iahdcy3RbdnWeQqlmq6uAl hEOWSVLmUBbj21FnG+CV0L8eR+TssRJkLdZmkQU+j6Dlop5OjmotTzfP/juGDlqG YvZEI5m9T7Fjg4xISZh8gOvVUZpr278+8Fd0+V0xNRvyKgDtLguJyKfPqIkJnavD ZDRruX+XTHNPSQ1kb/DzChsC0TV3XOHmrT+DFyIxSShpm3FTlNDppw== =omdY -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Tue Mar 24 10:14:31 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Tue, 24 Mar 2009 11:14:31 +0100 Subject: [Opendnssec-develop] opt-out Message-ID: <49C8B287.2000807@NLnetLabs.nl> Hi, regarding opt-out, at the moment the signer does set the opt-out bit in NSEC3 records if so specified by the xml config file, but it doesn't actually opt out anything; it still creates NSEC3 records for each name and each nonterminal in the zone. Now originally i was thinking that the user/kasp/whatever would have to provide all names that would need an NSEC3, or all names that should be ignored during the creation of the NSEC3 chain. But recently i had another idea. This may be what the authors of RFC 5155 always had in mind (Roy, is it? :) ). What I am thinking of (at least for ldns-signzone, and if so also for opendnssec), is to automatically ignore any name that only consist of an NS RRSet when creating the NSEC3 chain. Although i'm not really sure what to do with empty nonterminals yet. This would make using opt-out really easy for its intended purpose in delegation-centric zones. It would however mean that one would lose a little control over verified insecure delegations. Any thoughts? Jelte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jad at jadickinson.co.uk Tue Mar 24 10:30:29 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Tue, 24 Mar 2009 10:30:29 +0000 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <49C8203C.1090202@nlnetlabs.nl> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se> <49C8203C.1090202@nlnetlabs.nl> Message-ID: On 23 Mar 2009, at 23:50, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > That's not really the point I am trying to make. I guess what I meant > was that if one key is used for many zones and it gets compromised it > could have great impact in the sense that all the zones need to be > rollovered, perhaps many DS records need to be replaced and many > updates > need to go to the secondaries. > > Another issue is that if zone A is transferred to another DNS party, > and > zone uses a key that is in use for many zones. In that case, zone A > needs an immediate rollover, but the key should be kept alive > because it > is use for other zones. > > However, this is no issue if we decide one key should not span > multiple > zones. But it is only an option - keys may be used for either 1 zone or all zones in a policy. John From roy at nominet.org.uk Tue Mar 24 10:43:19 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Tue, 24 Mar 2009 11:43:19 +0100 Subject: [Opendnssec-develop] opt-out In-Reply-To: <49C8B287.2000807@NLnetLabs.nl> References: <49C8B287.2000807@NLnetLabs.nl> Message-ID: Jelte Jansen wrote on 03/24/2009 11:14:31 AM: > Hi, > > regarding opt-out, at the moment the signer does set the opt-out bit in > NSEC3 records if so specified by the xml config file, but it doesn't > actually opt out anything; it still creates NSEC3 records for each name > and each nonterminal in the zone. Now originally i was thinking that the > user/kasp/whatever would have to provide all names that would need an > NSEC3, or all names that should be ignored during the creation of the > NSEC3 chain. But recently i had another idea. > > This may be what the authors of RFC 5155 always had in mind (Roy, is it? > :) ). > > What I am thinking of (at least for ldns-signzone, and if so also for > opendnssec), is to automatically ignore any name that only consist of an > NS RRSet when creating the NSEC3 chain. Although i'm not really sure > what to do with empty nonterminals yet. This would make using opt-out > really easy for its intended purpose in delegation-centric zones. It > would however mean that one would lose a little control over verified > insecure delegations. > > Any thoughts? Jelte, that is _exactly_ what we had in mind. This is how my little perl signer worked, that generated the examples in the RFC: 1) make a list of all names in the zone: $names 2) make a list of all delegations in the zone: $dels 3) (OO) add empty non-terminal names in $dels to $names 4) create a list of NSEC3s as follows: - for each name in $names, exit if glue (i.e. subname of any name in $dels) (OO) exit if name exists in $dels that does not have DS record. create NSEC3 record, add to $nsec3s 5) sort $nsec3s, chain'em This is not the most elegant way, and was solely a proof of concept (and subsequently passed all the workshops). Note that only the lines marked with (OO) are special to Opt-Out=1. Hope this helps. Roy From jelte at NLnetLabs.nl Tue Mar 24 10:56:41 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Tue, 24 Mar 2009 11:56:41 +0100 Subject: [Opendnssec-develop] opt-out In-Reply-To: References: <49C8B287.2000807@NLnetLabs.nl> Message-ID: <49C8BC69.6060300@NLnetLabs.nl> roy at nominet.org.uk wrote: > Jelte Jansen wrote on 03/24/2009 11:14:31 AM: > > Jelte, that is _exactly_ what we had in mind. This is how my little perl > signer worked, that generated the examples in the RFC: > > 1) make a list of all names in the zone: $names > 2) make a list of all delegations in the zone: $dels > 3) (OO) add empty non-terminal names in $dels to $names > 4) create a list of NSEC3s as follows: > - for each name in $names, > exit if glue (i.e. subname of any name in $dels) > (OO) exit if name exists in $dels that does not have DS record. > create NSEC3 record, add to $nsec3s > 5) sort $nsec3s, chain'em > > This is not the most elegant way, and was solely a proof of concept (and > subsequently passed all the workshops). Note that only the lines marked > with (OO) are special to Opt-Out=1. > just to be sure; from this i gather that all empty nonterminals need an NSEC3, even if it is only 'nonterminalling' to an unsigned delegation? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jad at jadickinson.co.uk Tue Mar 24 11:02:18 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Tue, 24 Mar 2009 11:02:18 +0000 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <1237841184.6637.25.camel@SIDN0022> References: <49C7DAEF.6040309@nlnetlabs.nl> <1237841184.6637.25.camel@SIDN0022> Message-ID: On 23 Mar 2009, at 20:46, Antoin Verschuren wrote: > Op maandag 23-03-2009 om 19:09 uur [tijdzone +0000], schreef John > Dickinson: >> On 23 Mar 2009, at 18:54, Matthijs Mekking wrote: >>> >>> * What to do when a zone moves from one operator to another. >> >> Several people have asked me this as well - Off the top of my head, I >> don't think we can do anything. There are too many variables. I think >> that unless you (as a registrant) are willing to test the interaction >> between operators on a regular basis you have to assume that you will >> go, or at least will risk going, unsigned at change over. > > In current economics, the answer "we can't" won't help to get DNSSEC > deployed. If my choice is between not signing my zone or disappoint my > clients when I'm changing infrastructure, I know I will choose to not > sign. Changing infrastructure is a common thing in current business > processes, and in some countries even a requirement in policy. > > I think we can do it. > Moving a zone has 3 options: > 1. Become insecure, like you say. > 2. Hand over the private keys for the zone to the new operator so he > can > do a key rollover to use his own keys. Not a very safe proces and > certainly not possible when you use certain HSM's. > 3. Have the losing operator sign the new key(s) from the gaining > operator during a special key rollover process. I think that it's > doable. > > Disadvantage of the last 2 is that it needs cooperation of the losing > operator. But that's politics or policy, but I think it must be > possible > to change infrastructure without becoming insecure for DNSSEC to > become > deployed. It is possible as long as the two operators will cooperate. Cooperation is better solved by good process and rules not by technology. In option 3 1. The new operator would have to send a DNSKEY RRs for new KSK and ZSK to the zone owner. 2. The zone owner would have to send them to the old operator to be included in the zone. 3. This would have to happen at some time T before the old operator stops signing or publishing the zone. 4. key rollover process would occur... IMHO the biggest issue here is that we would need two competent, cooperating operators and the zone owner would have to understand what was going on. All that OpenDNSSEC can do is provide a mechanism for the new operator to export a DNSKEY RR for a new zone (possibly before they are actually signing it). I will add that to the requirements. Actually solving this issue is more about education and training. TLDs might want to document this in detail and offer training courses for registrars. Also they could offer advice to registrants on issues like these that they may want to explore when selecting a registrar. If you mean that OpenDNSSEC should provide a mechanism for the cooperating operators to exchange DNSKEY RRs directly then I suppose we could. It will only work if all operators are using OpenDNSSEC or we standardize the API. I don't really want to go down this path but AFAIK nothing we are doing now will prevent this from being done in the future. > >>> * What to do when the HSM is replaced >> >> Just works (I hope). You add a new HSM, update policies to start >> using >> it and new keys will be created in the new HSM. > > Here you actually have the same issue as you have in option 3 above. > You need the old HSM to sign the new keys that are generated by the > new > HSM if you cannot move the private keys around from HSMold to HSMnew. > You cannot just start using a new keyset that was not signed by the > old > one because you will break the chain of trust for signatures that are > still in caches. But you control both HSMs - so keep the old one round long enough to do this. If it has failed then go to your backup. > > >>> And does KASP has the logic >>> if a key for zone A needs to be rollovered, but must be kept for >>> other >>> zones. >> >> No - lets not go there. :) > > I prefer not to go there as well, but as it is common business > practice > to move one zone from operator 1 to operator 2 without moving all the > other zones from operator 1, the advice should be to use a key per > zone, > and not reuse keys. Yes and sharing keys between zones is only an option. John --- John Dickinson http://www.jadickinson.co.uk From roy at nominet.org.uk Tue Mar 24 11:12:36 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Tue, 24 Mar 2009 12:12:36 +0100 Subject: [Opendnssec-develop] opt-out In-Reply-To: <49C8BC69.6060300@NLnetLabs.nl> References: <49C8B287.2000807@NLnetLabs.nl> <49C8BC69.6060300@NLnetLabs.nl> Message-ID: Jelte Jansen wrote on 03/24/2009 11:56:41 AM: > roy at nominet.org.uk wrote: > > Jelte Jansen wrote on 03/24/2009 11:14:31 AM: > > > > Jelte, that is _exactly_ what we had in mind. This is how my little perl > > signer worked, that generated the examples in the RFC: > > > > 1) make a list of all names in the zone: $names > > 2) make a list of all delegations in the zone: $dels > > 3) (OO) add empty non-terminal names in $dels to $names > > 4) create a list of NSEC3s as follows: > > - for each name in $names, > > exit if glue (i.e. subname of any name in $dels) > > (OO) exit if name exists in $dels that does not have DS record. > > create NSEC3 record, add to $nsec3s > > 5) sort $nsec3s, chain'em > > > > This is not the most elegant way, and was solely a proof of concept (and > > subsequently passed all the workshops). Note that only the lines marked > > with (OO) are special to Opt-Out=1. > > > > just to be sure; from this i gather that all empty nonterminals need an > NSEC3, even if it is only 'nonterminalling' to an unsigned delegation? No! (note to self: do not attempt to write pseudo language based on historic perl code) Empty non terminals as a result of unsigned delegations do not have to have an NSEC3 record. (yes, an explicit non-requirement: we do not require NSEC3 records for empty non-terminals derived from insecure delegations covered by an Opt-Out span). rfc5155 7.1 Zone Signing: ... o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless the empty non-terminal is only derived from an insecure delegation covered by an Opt-Out NSEC3 RR. Hope this helps. Apologies for confusion. Roy From roy at nominet.org.uk Tue Mar 24 23:41:47 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Wed, 25 Mar 2009 00:41:47 +0100 Subject: [Opendnssec-develop] hsm-toolkit update, and some open questions Message-ID: Dear list, hsm-toolkit has been updated. I would like some discussion on the points listed below between the square brackets. The command line arguments are as follows: hsm-toolkit -l pkcs11-library [-s slot] [-p pin] [-G [-b keysize]] [-D UUID-string] -l pkcs11-library specifies the PKCS11 library provided by the HSM provider. As an example, on my OSX based machine, using softHSM, I'd specify: -l libsofthsm.dylib. There is no default, and thus has to be specified (see [1]) -s slot is optional. If not given, it will find the first available slot, containing a token. -p pin is optional. If not given, it will ask for the user pin. If no other arguments are given, hsm-toolkit lists some attributes (class, modulus size, label and ID) of public and private key objects of the token. -G generates one keypair (see [3]. If -b is not specified, the default keysize is 1024 bit (see [2]). The CKA_ID is automatically generated, and contains a Version 4 (random) UUID. The CKA_LABEL contains the canonical form of the UUID. The user has no influence on either the CKA_ID or the CKA_LABEL. The default public exponent e is 65537 (see [4]) -D destroys a keypair. The lookup value for the keypair is the UUID in canonical form (for example -D 94be1f7c-b8b9-4f2e-8c3c-0173b24900f8 ). The UUID is matched against the CKA_ID. Though a CKA_LABEL attribute of an object generated by hsm-toolkit is a UUID in canonical form as well, it is NOT used in locating objects. examples (the pin is too short, I know) To generate a key: roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845-G -b 768 hsm-toolkit: Created RSA key pair object, labeled 7bdefa80-09bf-469c-883c-babfdad08443 To list the contents of a softhsm token: roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845 hsm-toolkit: 2048-bit Public key object, label:f4fd3dbf-8b1b-446f-ad86-9b3a0ab46010, id:f4fd3dbf8b1b446fad869b3a0ab46010 hsm-toolkit: 2048-bit Private key object, label:f4fd3dbf-8b1b-446f-ad86-9b3a0ab46010, id:f4fd3dbf8b1b446fad869b3a0ab46010 hsm-toolkit: 1024-bit Public key object, label:c617eb35-f9c0-41ce-af17-f39b05624930, id:c617eb35f9c041ceaf17f39b05624930 hsm-toolkit: 1024-bit Private key object, label:c617eb35-f9c0-41ce-af17-f39b05624930, id:c617eb35f9c041ceaf17f39b05624930 hsm-toolkit: 768-bit Public key object, label:7bdefa80-09bf-469c-883c-babfdad08443, id:7bdefa8009bf469c883cbabfdad08443 hsm-toolkit: 768-bit Private key object, label:7bdefa80-09bf-469c-883c-babfdad08443, id:7bdefa8009bf469c883cbabfdad08443 To destroy a keypair from a softhsm token: roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845 -D 7bdefa80-09bf-469c-883c-babfdad08443 hsm-toolkit: Destroyed Public key object: 7bdefa80-09bf-469c-883c-babfdad08443 hsm-toolkit: Destroyed Private key object: 7bdefa80-09bf-469c-883c-babfdad08443 I would like to have some closure on the following thoughts: [1] Please discuss how we can circumvent this, as it is pretty annoying, and remains probably the same for a very long time for a user. We could do this via an environment setting, via a configuration file, both (or yet something else). [2] Hard configured defaults will hurt eventually. This could also set this via a configuration file, or come to think of it, no default at all. Please discuss this as well. [3] Feature request idea: do we need to be able to generate keys in bulk? Say with an option for -G to generate X keypairs ? Since we don't need to specify anything _per_key_ this seems feasible. This seems to fit the use case for a large amount of zones. [4] I understand from the world of cryptographers to avoid "3" as public exponent, as there might be implementations that are susceptible to Bleichenbacher's RSA signature forgery scheme due to sloppy padding. (see http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html ). It seems that 17 and 65537 are commonly used as a public exponent. I chose 65537, but that was arbitrary. We could also use yet another, very obscure but fixed exponent, solely to be able to identify which zones use OpenDNSSEC by the public exponent in the DNSKEY. Thanks for reading, Regards, Roy Arends Sr. Researcher Nominet UK From rick at openfortress.nl Wed Mar 25 09:01:12 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 25 Mar 2009 09:01:12 +0000 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <49C8203C.1090202@nlnetlabs.nl> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se> <49C8203C.1090202@nlnetlabs.nl> Message-ID: <20090325090112.GD25299@phantom.vanrein.org> Hi, > However, this is no issue if we decide one key should not span multiple > zones. This should neither be the default, nor should it be forbidden. The administrator should be enabled to choose, based on the capacity of the HSM in use (which may be a small USB key, remember). If you forbid it, you disable that cheap range of PKCS #11 devices. If you make it the default, you would not use the full power of a full HSM. -Rick From roy at nominet.org.uk Wed Mar 25 09:11:27 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Wed, 25 Mar 2009 10:11:27 +0100 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <20090325090112.GD25299@phantom.vanrein.org> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se> <49C8203C.1090202@nlnetlabs.nl> <20090325090112.GD25299@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 03/25/2009 10:01:12 AM: > Hi, > > > However, this is no issue if we decide one key should not span multiple > > zones. > > This should neither be the default, nor should it be forbidden. > The administrator should be enabled to choose, based on the capacity > of the HSM in use (which may be a small USB key, remember). > > If you forbid it, you disable that cheap range of PKCS #11 devices. > > If you make it the default, you would not use the full power of a full HSM. I agree. The software should allow for several schemes, without dictating any policy. Regards, Roy Arends Sr. Researcher Nominet UK From matthijs at NLnetLabs.nl Wed Mar 25 16:21:12 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 25 Mar 2009 09:21:12 -0700 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se> <49C8203C.1090202@nlnetlabs.nl> <20090325090112.GD25299@phantom.vanrein.org> Message-ID: <49CA59F8.4060206@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alright, but I think that in that case we need to consider additional measurements to deal with zone transfer between operators and emergency key rollover. Matthijs roy at nominet.org.uk schreef: > Rick van Rein wrote on 03/25/2009 10:01:12 AM: > >> Hi, >> >>> However, this is no issue if we decide one key should not span multiple >>> zones. >> This should neither be the default, nor should it be forbidden. >> The administrator should be enabled to choose, based on the capacity >> of the HSM in use (which may be a small USB key, remember). >> >> If you forbid it, you disable that cheap range of PKCS #11 devices. >> >> If you make it the default, you would not use the full power of a full > HSM. > > I agree. > > The software should allow for several schemes, without dictating any > policy. > > Regards, > > Roy Arends > Sr. Researcher > Nominet UK > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBScpZ+A8yVCPsQCW5AQLH5Af+JUlR3CtUCZZj+IwYWSDbVbwYAiQCdC4I htDrWOwv3pfDAWwmZ5WI7ysnLAV+Aqsjqxmc3BdANfyix9cMkKleBFLWmVbAkebE YEvy+BUcUt9le3g8WlkCS+0+lYEz+6wbkJ315gOmVXwxdkrsmJlEc0hL90nsRkDb lHA7i32+kjFspUgSo0xhG0k2dvDcJ43p9y0z2fzmxpn12VT6rEC9mKhOuP9s6sDD VxGM6lcygZ5eoZR6OHhtUuTZ4uJvSJxw8140Solj6vlcxLw/9K1LUEoUd/yERcfm 1mYRw+uxQ88TZIJW5b2B+zhVwFbDdqlQ0vADSteUnIv3GFRa5sZLWg== =ALSt -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Wed Mar 25 16:24:47 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 25 Mar 2009 08:24:47 -0800 Subject: [Opendnssec-develop] Location of OpenDNSSEC Meeting Today Message-ID: To save you burrowing through the list to find the relevant email, the meeting today is between 13:00 and 15:30 in the LOMBARD ROOM, located on the 6th floor of Tower 3 of the hotel. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Wed Mar 25 17:21:26 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 25 Mar 2009 10:21:26 -0700 Subject: [Opendnssec-develop] v2 topics Message-ID: <49CA6816.2050803@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In the case we have time to discuss opendnssec v2 in the meeting today, I propose some topics. Suprisingly, they almost all deal with handling IXFRs. If you have more topics, please add. * Securing IXFRs requires zone state. What state should be maintained: the latest version I have received, the version I have pushed to my secondaries, the status of the current zone update, ... * Discuss schedule issues. Are they any? There may be in the case that: - the zone update rate is high - updates and key rollover occur at the similar time - resigning needs to replace many signatures Are we going to rely on realtime schedulers that will solve our issues? * Should we consider IXFR bulks, so that we not push out IXFRs every minute in the case zones update rate is high. * Clockskew problems when using a second opendnssec box. Signatures may differ. Secure64 detected this issue that is probably also applicable for opendnssec. Joe Gersch proposed some solutions in the dnsop meeting. Another solution might be to round up the inception time to a minute or even more to ease this problem. * Does key algorithm rollover and/or rollover to a new HSM or DNS operator affect the key maintenance in KASP? What controls must be provided in order to facilitate in these rollovers. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBScpoFg8yVCPsQCW5AQLklgf9ExuV0FcY0QPAVdgosoXqK1SNRdqqZLvB pVJt2YSbGzYd8sChERDuc04QJIVQpL2K65PZ6l15/OGViqksLizumxYqFPla8T8H OPVlTRpl51z/SiApvT8G8NzaL+QTUB7ArseOWjdFf0My7tcPfmLR8cU9pvI6XLpD ixGsRTmxCyr34V+NBhYTSRfkcYZ7pb+/liiCuRgp6fcqVt/BQsoAXVyIL6EJpMyy ZmqaLvkBIpHOlXZw/zC2zfQHCAB1HPAhoU7U1rouIVGic3P8h1ontXvKGr6UKBCZ zBZDhWApFqrfVlVIb32TSUBPnk7gyqUYUBma0cEnRsLBS6dGnVu29Q== =mMf0 -----END PGP SIGNATURE----- From Antoin.Verschuren at sidn.nl Wed Mar 25 23:36:30 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 26 Mar 2009 00:36:30 +0100 Subject: [Opendnssec-develop] Zone moving between operators References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se><49C8203C.1090202@nlnetlabs.nl><20090325090112.GD25299@phantom.vanrein.org> Message-ID: <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> But then perhaps parents will dictate that policy. My worry is that in rollovers, the keys must move to the parent. Processing a giant amount of EPP messages (one per delegation) might be troublesome at a registry. I wouldn'd want our major webhoster to use one key for all it's domains. Our systems simply would not be able to process the changes without impact on other transactions. The updates need to be spread out. I would say one key for multiple zones is unwise. And as a registry, I would probably forbid it in the policy. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec- > develop-bounces at lists.opendnssec.org] On Behalf Of roy at nominet.org.uk > Sent: Wednesday, March 25, 2009 10:11 AM > To: Rick van Rein > Cc: Opendnssec-develop at lists.opendnssec.org; opendnssec-develop- > bounces at lists.opendnssec.org; Matthijs Mekking > Subject: Re: [Opendnssec-develop] Zone moving between operators > > Rick van Rein wrote on 03/25/2009 10:01:12 AM: > > > Hi, > > > > > However, this is no issue if we decide one key should not span > multiple > > > zones. > > > > This should neither be the default, nor should it be forbidden. > > The administrator should be enabled to choose, based on the capacity > > of the HSM in use (which may be a small USB key, remember). > > > > If you forbid it, you disable that cheap range of PKCS #11 devices. > > > > If you make it the default, you would not use the full power of a full > HSM. > > I agree. > > The software should allow for several schemes, without dictating any > policy. > > Regards, > > Roy Arends > Sr. Researcher > Nominet UK > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From Ray.Bellis at nominet.org.uk Thu Mar 26 00:15:25 2009 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Wed, 25 Mar 2009 16:15:25 -0800 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se><49C8203C.1090202@nlnetlabs.nl><20090325090112.GD25299@phantom.vanrein.org> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> Message-ID: > I would say one key for multiple zones is unwise. > And as a registry, I would probably forbid it in the policy. As someone who used to run DNS services at an ISP I'd disagree, and say that it's none of the parent zone's business how many (or few) keys I use across my customers' zones. cheers, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray at nominet.org.uk, t: +44 1865 332211 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Antoin.Verschuren at sidn.nl Thu Mar 26 01:07:28 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 26 Mar 2009 02:07:28 +0100 Subject: [Opendnssec-develop] Zone moving between operators References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se><49C8203C.1090202@nlnetlabs.nl><20090325090112.GD25299@phantom.vanrein.org> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> Message-ID: <850A39016FA57A4887C0AA3C8085F949AE0CFA@KAEVS1.SIDN.local> Hmm, that means an extra thing to think about as a registry to implement DNSSEC: Upgrade your systems to be able handle 10M transactions you normally do in a year to appear in 1 second. I think our management will say no to DNSSEC. It is my business as a parent if I need to verify the trust anchor I'm providing to my children. You can have as many keys in your zone as you want, but if you want me to update your DS in my zone, you better not send them to me all at once. I used to work for a number of ISP's too. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: Ray.Bellis at nominet.org.uk [mailto:Ray.Bellis at nominet.org.uk] > Sent: Thursday, March 26, 2009 1:15 AM > To: Antoin Verschuren > Cc: Matthijs Mekking; Opendnssec-develop at lists.opendnssec.org; opendnssec- > develop-bounces at lists.opendnssec.org; Rick van Rein; roy at nominet.org.uk > Subject: RE: [Opendnssec-develop] Zone moving between operators > > > I would say one key for multiple zones is unwise. > > And as a registry, I would probably forbid it in the policy. > > As someone who used to run DNS services at an ISP I'd disagree, and say > that it's none of the parent zone's business how many (or few) keys I use > across my customers' zones. > > cheers, > > Ray > > -- > Ray Bellis, MA(Oxon) MIET > Senior Researcher in Advanced Projects, Nominet > e: ray at nominet.org.uk, t: +44 1865 332211 From Ray.Bellis at nominet.org.uk Thu Mar 26 06:36:25 2009 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Wed, 25 Mar 2009 22:36:25 -0800 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <850A39016FA57A4887C0AA3C8085F949AE0CFA@KAEVS1.SIDN.local> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se><49C8203C.1090202@nlnetlabs.nl><20090325090112.GD25299@phantom.vanrein.org> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> <850A39016FA57A4887C0AA3C8085F949AE0CFA@KAEVS1.SIDN.local> Message-ID: > Hmm, that means an extra thing to think about as a registry to > implement DNSSEC: Upgrade your systems to be able handle 10M > transactions you normally do in a year to appear in 1 second. I > think our management will say no to DNSSEC. > > It is my business as a parent if I need to verify the trust anchor > I'm providing to my children. > You can have as many keys in your zone as you want, but if you want > me to update your DS in my zone, you better not send them to me all at once. OK, serious question, since I really don't know the answer, but the answer would affect how ISPs would operate their own signing systems: How many key-pairs can a typical HSM manage? Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Thu Mar 26 08:41:56 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 26 Mar 2009 09:41:56 +0100 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <850A39016FA57A4887C0AA3C8085F949AE0CFA@KAEVS1.SIDN.local> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se><49C8203C.1090202@nlnetlabs.nl><20090325090112.GD25299@phantom.vanrein.org> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> <850A39016FA57A4887C0AA3C8085F949AE0CFA@KAEVS1.SIDN.local> Message-ID: "Antoin Verschuren" wrote on 03/26/2009 02:07:28 AM: > Hmm, that means an extra thing to think about as a registry to > implement DNSSEC: Upgrade your systems to be able handle 10M > transactions you normally do in a year to appear in 1 second. I > think our management will say no to DNSSEC. For what its worth, it would be really hard to stop anyone from using a single key for all their zones. public keys can be re-used, just change the ownername, right? This is independent of OpenDNSSEC. One could have 100 keys on their HSM. All copies of the same key. Do you require us to check them all? What about bind's dnssec tools? How can this policy be technically enforced? Are you planning, as a registry, to cross check a millions of DS records? > It is my business as a parent if I need to verify the trust anchor > I'm providing to my children. That is besides the point, right? You authenticate the registrar/registrant. You check if their DS matches their key. The buck stops there I guess. Are you going to check the trust anchor against all existing trust anchors ? What if one matches? Are you then telling the registrar/registrant that they just can't do that? > You can have as many keys in your zone as you want, but if you want > me to update your DS in my zone, you better not send them to me all at once. And _that_ is the way to do it. Drop these policy bits in an SLA, but don't cripple the software. > I used to work for a number of ISP's too. I just worked for one in the past. does that count? ;-) Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jelte at NLnetLabs.nl Thu Mar 26 09:25:18 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Thu, 26 Mar 2009 10:25:18 +0100 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se><49C8203C.1090202@nlnetlabs.nl><20090325090112.GD25299@phantom.vanrein.org> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> Message-ID: <49CB49FE.4090609@NLnetLabs.nl> Antoin Verschuren wrote: > But then perhaps parents will dictate that policy. > My worry is that in rollovers, the keys must move to the parent. > Processing a giant amount of EPP messages (one per delegation) might be troublesome at a registry. > I wouldn'd want our major webhoster to use one key for all it's domains. Our systems simply would not be able to process the changes without impact on other transactions. The updates need to be spread out. > As has been mentioned before, even if you use 1 key for each of your 75000 zones, and store all those keys in one place, chances are that you're going to need to roll 75000 keys if that location is compromised. > I would say one key for multiple zones is unwise. Unwise in general, certainly. But i think there will be valid use-cases. > And as a registry, I would probably forbid it in the policy. > That's your choice. Or you could charge people with that many zones more ;) A better way forward, at least for opendnssec, would imho be a way to spread updates to parents; i.e. an option 'don't-send-more-than-X-DS-records-per-Y' or something. That will affect other timing issues though. Jelte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From rick at openfortress.nl Fri Mar 27 08:45:46 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 27 Mar 2009 08:45:46 +0000 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> References: <49C7DAEF.6040309@nlnetlabs.nl> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> Message-ID: <20090327084546.GC2152@phantom.vanrein.org> Hello Antion, > My worry is that in rollovers, the keys must move to the parent. > Processing a giant amount of EPP messages (one per delegation) might be troublesome at a registry. There's a few reasons why I don't share your feeling of caution. 1. People who only use a single key to sign zones, that is, those using an USB stick instead of an HSM will be small-sized. Why? Because: 2. Although a parent should not dictate that all domains use different keys, it can indicate that a lot of changes will take more time. I think it is reasonable, and will force individual children to behave rationally with their dependency on the parent's resources. 3. If you would really want to support a large-scale emergency rollover, you would be better off if all the keys are equal; given a proper interface for it you could issue a single SQL UPDATE statement. Hope this helps, -Rick From jakob at kirei.se Fri Mar 27 13:20:41 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 27 Mar 2009 06:20:41 -0700 Subject: [Opendnssec-develop] XML capitalisation In-Reply-To: <78B3107D-FD43-432E-AD24-4CFBF38CE810@kirei.se> References: <78B3107D-FD43-432E-AD24-4CFBF38CE810@kirei.se> Message-ID: <6B902824-5A40-4180-9DDC-69ECAEA4ADD5@kirei.se> On 23 mar 2009, at 14.21, Jakob Schlyter wrote: > On 23 mar 2009, at 11.58, Stephen.Morris at nominet.org.uk wrote: > >> How about Upper Camel Case for element names and Lower Camel Case >> for attributes, as used by ebXML? (See >> http://www.wmusers.com/forum/showthread.php?t=8745 for a brief >> desription.) > > as long as we make up our minds, I fine with anything. others? if I don't have any feedback on this issue monday, I'll make the change monday. jakob From roy at nominet.org.uk Fri Mar 27 13:28:14 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Fri, 27 Mar 2009 14:28:14 +0100 Subject: [Opendnssec-develop] XML capitalisation In-Reply-To: <6B902824-5A40-4180-9DDC-69ECAEA4ADD5@kirei.se> References: <78B3107D-FD43-432E-AD24-4CFBF38CE810@kirei.se> <6B902824-5A40-4180-9DDC-69ECAEA4ADD5@kirei.se> Message-ID: Jakob Schlyter wrote on 03/27/2009 02:20:41 PM: > On 23 mar 2009, at 14.21, Jakob Schlyter wrote: > > > On 23 mar 2009, at 11.58, Stephen.Morris at nominet.org.uk wrote: > > > >> How about Upper Camel Case for element names and Lower Camel Case > >> for attributes, as used by ebXML? (See > >> http://www.wmusers.com/forum/showthread.php?t=8745 for a brief > >> desription.) > > > > as long as we make up our minds, I fine with anything. others? > > if I don't have any feedback on this issue monday, I'll make the > change monday. I agree with Upper Camel Case for element names and Lower Camel Case for attributes. Regards, Roy Arends Sr. Researcher Nominet UK From Antoin.Verschuren at sidn.nl Fri Mar 27 18:01:24 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Fri, 27 Mar 2009 19:01:24 +0100 Subject: [Opendnssec-develop] Zone moving between operators References: <49C7DAEF.6040309@nlnetlabs.nl> <41A3F3DD-16E5-41AE-9436-2B43833383E4@kirei.se><49C8203C.1090202@nlnetlabs.nl><20090325090112.GD25299@phantom.vanrein.org> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> <49CB49FE.4090609@NLnetLabs.nl> Message-ID: <850A39016FA57A4887C0AA3C8085F949AE0E56@KAEVS1.SIDN.local> OK, I agree that the number of keys used is not something we can control. I just want to make sure that the consequences of using a single key for multiple zones are understood, and that this behavior is not the "default" or "promoted". I agree with Roy that we can not force a policy on the use of keys, but we can have an SLA on the registry system. The part I'm concerned about most is not the emergency key rollovers, but the regular key rollovers. A dns-operator that has 100.000+ zones signed with a single key will have an operational issue when doing a rollover. A wild guess from me is that the complete process of propagating a key change to the parent will take about 0,1 seconds per delegation. That is including EPP messaging and verification, validation of the key at the child, database processing and changing the parent zone. Changing 100.000+ zones when the key needs a rollover will then take more than 2,7 hours of processing. We cannot justify queuing other regular requests for such a long time, even more because it exceeds the time we generate new zonefiles. I like Jelte's idea of defining some BCP for this, but that remains only a recommendation. My real question is if we need to safeguard such recommendation in the design of OPENDNSSEC, or that we leave it completely to the user without warnings, at the risk the user blaims the software not working properly. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: Jelte Jansen [mailto:jelte at NLnetLabs.nl] > Sent: Thursday, March 26, 2009 10:25 AM > To: Antoin Verschuren > Cc: roy at nominet.org.uk; Rick van Rein; Opendnssec- > develop at lists.opendnssec.org; opendnssec-develop- > bounces at lists.opendnssec.org; Matthijs Mekking > Subject: Re: [Opendnssec-develop] Zone moving between operators > > * PGP Signed by an unknown key > > Antoin Verschuren wrote: > > But then perhaps parents will dictate that policy. > > My worry is that in rollovers, the keys must move to the parent. > > Processing a giant amount of EPP messages (one per delegation) might be > troublesome at a registry. > > I wouldn'd want our major webhoster to use one key for all it's domains. > Our systems simply would not be able to process the changes without impact > on other transactions. The updates need to be spread out. > > > > As has been mentioned before, even if you use 1 key for each of your > 75000 zones, and store all those keys in one place, chances are that > you're going to need to roll 75000 keys if that location is compromised. > > > I would say one key for multiple zones is unwise. > > Unwise in general, certainly. But i think there will be valid use-cases. > > > And as a registry, I would probably forbid it in the policy. > > > > That's your choice. Or you could charge people with that many zones more > ;) > > A better way forward, at least for opendnssec, would imho be a way to > spread updates to parents; i.e. an option > 'don't-send-more-than-X-DS-records-per-Y' or something. That will affect > other timing issues though. > > Jelte > > > * Unknown Key > * 0xC74E9DC5 From rick at openfortress.nl Fri Mar 27 20:50:39 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 27 Mar 2009 20:50:39 +0000 Subject: [Opendnssec-develop] Zone moving between operators In-Reply-To: <850A39016FA57A4887C0AA3C8085F949AE0E56@KAEVS1.SIDN.local> References: <49C7DAEF.6040309@nlnetlabs.nl> <850A39016FA57A4887C0AA3C8085F949AE0CF7@KAEVS1.SIDN.local> <49CB49FE.4090609@NLnetLabs.nl> <850A39016FA57A4887C0AA3C8085F949AE0E56@KAEVS1.SIDN.local> Message-ID: <20090327205039.GA13352@phantom.vanrein.org> Hello, > I just want to make sure that the consequences of using a single key for multiple zones are understood, and that this behavior is not the "default" or "promoted". Yep, it's more like the el cheapo, low-end profile of using DNSSEC I suppose. Still, I'd much rather get a lot of low-budget, few-domain users online with DNSSEC than to outlaw them by way of design choices in OpenDNSSEC and similar tools. Or to make them abandon DNSSEC if the first tool they look at (say, OpenDNSSEC) tells them off for wanting to use a simple RSA stick. ("I'm willing to invest as much as EUR 50 into something I won't see the immediate benefits of, and still it's not enough -- what a lousy technology" kind of reasoning.) > I agree with Roy that we can not force a policy on the use of keys, but we can have an SLA on the registry system. > The part I'm concerned about most is not the emergency key rollovers, but the regular key rollovers. Ah! Same argument -- given a suitable EPP it would be possible to update them all in one (possibly massive) UPDATE statement. > A dns-operator that has 100.000+ zones signed with a single key will have an operational issue when doing a rollover. ...and that's all their own fault... > A wild guess from me is that the complete process of propagating a key change to the parent will take about 0,1 seconds per delegation. So, the total delay would be under 3 hours... which is still quite acceptable! Normal DNSSEC procedures would assume it could take more time. Sounds like you could tell people how much zones under a single key would work *in practice*, which is probably the best way to convince people that they're better off not to take the "el cheapo" shortcut through a USB RSA key if they mean serious business. That's ideal: You want people to feel your pain/gain so they will automatically make the choices you would like them to make. > We cannot justify queuing other regular requests for such a long time, even more because it exceeds the time we generate new zonefiles. Yes, you would want to allow for other changes at the same time, but the DNSSEC policies would allow a week or so for such changes... or to be more accurate, a parent is assumed to be taking some time, perhaps up to a week or so, but at least at their (preferrably well-defined) discretion. > I like Jelte's idea of defining some BCP for this, but that remains only a recommendation. I like it too. Even if it's just an advice formally, it will give registries something to point at while saying "if you think you can get away with having many [bm]illions of domains under the same key, you should not be surprised if it takes more than mere seconds to propagate the update". It is important (and thank you for leading the discussion on it) to make any such issues as clear as possible, so people rolling out DNSSEC will make the choices that are optimal for the system as a whole. A BCP is a great way of writing down any advice on such choices. > My real question is if we need to safeguard such recommendation in the design of OPENDNSSEC, or that we leave it completely to the user without warnings, at the risk the user blaims the software not working properly. The approach I would follow is to setup defaults that are safe (such as having a different key for each domain signed) and allow for enough breadth of choice to enable the domain admin to mindfully make choices that would not be advisable in general. You do not want to make choices "for safety sake" that block functionality that may in some cases be useful. That would land in the same category as "every user should be able to live with 640 k RAM" (*) Best, -Rick (*) I still happen to think this is quite a lot, but that's only because I also do embedded coding ;-) From jakob at kirei.se Sat Mar 28 13:29:39 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Sat, 28 Mar 2009 14:29:39 +0100 Subject: [Opendnssec-develop] ZoneList revisited Message-ID: <2BE57766-3E2D-4576-A37F-3B9877F2E747@kirei.se> hi, I've been thinking about zonelist and how it would be used when you have a lot of zones. Based on this I suggest the following changes: - remove LastUpdate from ZoneList, the signer can simply fstat() the right SignerConf to find out when it was last updated. - Move zone-to-policy mapping from KASP to ZoneList/Zone, thus making it possible to add zones without changing the policy file. - Move adapter configuration from signconf to ZoneList/Zone, the enforcer don't really need to know how the zones are fetched. - Add signerConfiguration attribute to the ZoneList/Zone to tell the signer where to find the SignerConfiguration for a zone. The result of these changes would be that the signer only needs to be fed the ZoneList and all other parameters can be derived from that. So we have: KASP - defines policy. auditable, but free from the actual list of zones (one file for all policies). ZoneList - defines what zones are to be signed, where the signer can find the files and what configuration to use SignerConfiguration- signer configuration parameters (one file per zone) jakob From jelte at NLnetLabs.nl Mon Mar 30 08:36:30 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Mon, 30 Mar 2009 10:36:30 +0200 Subject: [Opendnssec-develop] ZoneList revisited In-Reply-To: <2BE57766-3E2D-4576-A37F-3B9877F2E747@kirei.se> References: <2BE57766-3E2D-4576-A37F-3B9877F2E747@kirei.se> Message-ID: <49D0848E.3010909@NLnetLabs.nl> Jakob Schlyter wrote: > hi, > > I've been thinking about zonelist and how it would be used when you have > a lot of zones. Based on this I suggest the following changes: > > - remove LastUpdate from ZoneList, the signer can simply fstat() the > right SignerConf to find out when it was last updated. i already use fstat() for something like that when the engine starts, but it would save a lot of fstats if i got a hint when to look where :) (otoh. not having to parse the entire list of zone names is probably a good thing if only one changes) > - Move zone-to-policy mapping from KASP to ZoneList/Zone, thus making > it possible to add zones without changing the policy file. > - Move adapter configuration from signconf to ZoneList/Zone, the > enforcer don't really need to know how the zones are fetched. > - Add signerConfiguration attribute to the ZoneList/Zone to tell the > signer where to find the SignerConfiguration for a zone. > > The result of these changes would be that the signer only needs to be > fed the ZoneList and all other parameters can be derived from that. > So we have: > > KASP - defines policy. auditable, but free from the actual list of > zones (one file for all policies). > ZoneList - defines what zones are to be signed, where the signer can > find the files and what configuration to use > SignerConfiguration- signer configuration parameters (one file per zone) > So, the zone list is not written by the kasp/enforcer anymore? Who/what will do it then? (i'm assuming the admin here, (and later) by ways of ui, but it would mean people typing in xml. blerg. otoh the zones will have to be told to the system somehow anyway) The split is nice though, and the reallocations make a lot of sense then. Jelte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From roy at nominet.org.uk Mon Mar 30 11:39:02 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Mon, 30 Mar 2009 13:39:02 +0200 Subject: Reminder : [Opendnssec-develop] hsm-toolkit update, and some open questions In-Reply-To: References: Message-ID: Sorry for top (and re-) posting, but I'd like to have some input on the square brackets below. Roy Arends wrote on 03/25/2009 12:41:47 AM: > Dear list, > > hsm-toolkit has been updated. I would like some discussion on the points > listed below between the square brackets. > > The command line arguments are as follows: > > hsm-toolkit -l pkcs11-library [-s slot] [-p pin] [-G [-b keysize]] [-D > UUID-string] > > -l pkcs11-library specifies the PKCS11 library provided by the HSM > provider. As an example, on my OSX based machine, using softHSM, I'd > specify: -l libsofthsm.dylib. There is no default, and thus has to be > specified (see [1]) > > -s slot is optional. If not given, it will find the first available slot, > containing a token. > > -p pin is optional. If not given, it will ask for the user pin. > > If no other arguments are given, hsm-toolkit lists some attributes (class, > modulus size, label and ID) of public and private key objects of the token. > > -G generates one keypair (see [3]. If -b is not specified, the default > keysize is 1024 bit (see [2]). The CKA_ID is automatically generated, and > contains a Version 4 (random) UUID. The CKA_LABEL contains the canonical > form of the UUID. The user has no influence on either the CKA_ID or the > CKA_LABEL. The default public exponent e is 65537 (see [4]) > > -D destroys a keypair. The lookup value for the keypair is the UUID in > canonical form (for example -D 94be1f7c-b8b9-4f2e-8c3c-0173b24900f8 ). The > UUID is matched against the CKA_ID. Though a CKA_LABEL attribute of an > object generated by hsm-toolkit is a UUID in canonical form as well, it is > NOT used in locating objects. > > examples (the pin is too short, I know) > > To generate a key: > > roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845-G -b 768 > hsm-toolkit: Created RSA key pair object, labeled > 7bdefa80-09bf-469c-883c-babfdad08443 > > To list the contents of a softhsm token: > > roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845 > hsm-toolkit: 2048-bit Public key object, > label:f4fd3dbf-8b1b-446f-ad86-9b3a0ab46010, > id:f4fd3dbf8b1b446fad869b3a0ab46010 > hsm-toolkit: 2048-bit Private key object, > label:f4fd3dbf-8b1b-446f-ad86-9b3a0ab46010, > id:f4fd3dbf8b1b446fad869b3a0ab46010 > hsm-toolkit: 1024-bit Public key object, > label:c617eb35-f9c0-41ce-af17-f39b05624930, > id:c617eb35f9c041ceaf17f39b05624930 > hsm-toolkit: 1024-bit Private key object, > label:c617eb35-f9c0-41ce-af17-f39b05624930, > id:c617eb35f9c041ceaf17f39b05624930 > hsm-toolkit: 768-bit Public key object, > label:7bdefa80-09bf-469c-883c-babfdad08443, > id:7bdefa8009bf469c883cbabfdad08443 > hsm-toolkit: 768-bit Private key object, > label:7bdefa80-09bf-469c-883c-babfdad08443, > id:7bdefa8009bf469c883cbabfdad08443 > > To destroy a keypair from a softhsm token: > > roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845 -D > 7bdefa80-09bf-469c-883c-babfdad08443 > hsm-toolkit: Destroyed Public key object: > 7bdefa80-09bf-469c-883c-babfdad08443 > hsm-toolkit: Destroyed Private key object: > 7bdefa80-09bf-469c-883c-babfdad08443 > > > I would like to have some closure on the following thoughts: > > [1] Please discuss how we can circumvent this, as it is pretty annoying, > and remains probably the same for a very long time for a user. We could do > this via an environment setting, via a configuration file, both (or yet > something else). > > [2] Hard configured defaults will hurt eventually. This could also set this > via a configuration file, or come to think of it, no default at all. Please > discuss this as well. > > [3] Feature request idea: do we need to be able to generate keys in bulk? > Say with an option for -G to generate X keypairs ? Since we don't need to > specify anything _per_key_ this seems feasible. This seems to fit the use > case for a large amount of zones. > > [4] I understand from the world of cryptographers to avoid "3" as public > exponent, as there might be implementations that are susceptible to > Bleichenbacher's RSA signature forgery scheme due to sloppy padding. (see > http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html ). It seems that > 17 and 65537 are commonly used as a public exponent. I chose 65537, but > that was arbitrary. We could also use yet another, very obscure but fixed > exponent, solely to be able to identify which zones use OpenDNSSEC by the > public exponent in the DNSKEY. > > Thanks for reading, > > Regards, > > Roy Arends > Sr. Researcher > Nominet UK > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From jakob at kirei.se Mon Mar 30 11:42:15 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 30 Mar 2009 13:42:15 +0200 Subject: [Opendnssec-develop] ZoneList revisited In-Reply-To: <49D0848E.3010909@NLnetLabs.nl> References: <2BE57766-3E2D-4576-A37F-3B9877F2E747@kirei.se> <49D0848E.3010909@NLnetLabs.nl> Message-ID: <8BCAEF52-6BD3-41AE-9D51-37CBED9CE54E@kirei.se> On 30 mar 2009, at 10.36, Jelte Jansen wrote: > i already use fstat() for something like that when the engine starts, > but it would save a lot of fstats if i got a hint when to look > where :) > (otoh. not having to parse the entire list of zone names is probably a > good thing if only one changes) I'd imagine that 100'000 fstat from time to time is as cheap as reading 100'000 times X lines of XML config. > So, the zone list is not written by the kasp/enforcer anymore? Who/ > what > will do it then? (i'm assuming the admin here, (and later) by ways of > ui, but it would mean people typing in xml. blerg. otoh the zones will > have to be told to the system somehow anyway) yes the enforcer can still write the zonelist, but it wouldn't need to be rewritten at every change (just for zone add/delete). I'm just suggesting keeping the actual list of zones separate the policy file (kasp.xml). jakob From jelte at NLnetLabs.nl Mon Mar 30 11:44:32 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Mon, 30 Mar 2009 13:44:32 +0200 Subject: [Opendnssec-develop] ZoneList revisited In-Reply-To: <8BCAEF52-6BD3-41AE-9D51-37CBED9CE54E@kirei.se> References: <2BE57766-3E2D-4576-A37F-3B9877F2E747@kirei.se> <49D0848E.3010909@NLnetLabs.nl> <8BCAEF52-6BD3-41AE-9D51-37CBED9CE54E@kirei.se> Message-ID: <49D0B0A0.1010100@NLnetLabs.nl> Jakob Schlyter wrote: > On 30 mar 2009, at 10.36, Jelte Jansen wrote: > >> So, the zone list is not written by the kasp/enforcer anymore? Who/what >> will do it then? (i'm assuming the admin here, (and later) by ways of >> ui, but it would mean people typing in xml. blerg. otoh the zones will >> have to be told to the system somehow anyway) > > yes the enforcer can still write the zonelist, but it wouldn't need to > be rewritten at every change (just for zone add/delete). I'm just > suggesting keeping the actual list of zones separate the policy file > (kasp.xml). > ok i'm all for it :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jelte at NLnetLabs.nl Mon Mar 30 12:00:55 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Mon, 30 Mar 2009 14:00:55 +0200 Subject: [Opendnssec-develop] hsm-toolkit update, and some open questions In-Reply-To: References: Message-ID: <49D0B477.1030704@NLnetLabs.nl> roy at nominet.org.uk wrote: > [1] Please discuss how we can circumvent this, as it is pretty annoying, > and remains probably the same for a very long time for a user. We could do > this via an environment setting, via a configuration file, both (or yet > something else). > did we have a token/module mapping somewhere yet? we could take one from there ('Warning: no token specified. Using first token in configuration'). Or something like that. > [2] Hard configured defaults will hurt eventually. This could also set this > via a configuration file, or come to think of it, no default at all. Please > discuss this as well. > Heh, this kind of contradicts your previous statement. I like *sane* defaults (whether from a configuration or hard-coded, or both, in that order). But it may depend on what other uses you see for hsm-toolkit. > [3] Feature request idea: do we need to be able to generate keys in bulk? > Say with an option for -G to generate X keypairs ? Since we don't need to > specify anything _per_key_ this seems feasible. This seems to fit the use > case for a large amount of zones. > I don't see enough reasons to put a lot of work in that. OTOH, it doesn't look like a lot of work either. One advantage if you even want to use such a feature is that it could remember the PIN :) > [4] I understand from the world of cryptographers to avoid "3" as public > exponent, as there might be implementations that are susceptible to > Bleichenbacher's RSA signature forgery scheme due to sloppy padding. (see > http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html ). It seems that > 17 and 65537 are commonly used as a public exponent. I chose 65537, but > that was arbitrary. We could also use yet another, very obscure but fixed > exponent, solely to be able to identify which zones use OpenDNSSEC by the > public exponent in the DNSKEY. > I usually default to F4 (65537). I don't think identification of usage is a compelling argument to choose another exponent. But you may come up with more convincing reasons :) (otherwise my vote would be to use F4). Jelte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jakob at kirei.se Mon Mar 30 12:05:56 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 30 Mar 2009 14:05:56 +0200 Subject: [Opendnssec-develop] common configuration file Message-ID: for a number of stuff, we need a common OpenDNSSEC configuration file that all our tools can use. things that would go into this would be some runtime parameters, like the configured pkcs11-libs etc. what would be the preferred format? 1. YAML-style? (like nsd and unbound) 2. XML. we all hate it, we all know it. 3. [.ini-style] tag=value ? jakob From jakob at kirei.se Mon Mar 30 12:06:05 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 30 Mar 2009 14:06:05 +0200 Subject: [Opendnssec-develop] hsm-toolkit update, and some open questions In-Reply-To: <49D0B477.1030704@NLnetLabs.nl> References: <49D0B477.1030704@NLnetLabs.nl> Message-ID: On 30 mar 2009, at 14.00, Jelte Jansen wrote: > did we have a token/module mapping somewhere yet? we could take one > from > there ('Warning: no token specified. Using first token in > configuration'). Or something like that. I'll post a separate topic regarding this! jakob From roy at nominet.org.uk Mon Mar 30 12:08:46 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Mon, 30 Mar 2009 14:08:46 +0200 Subject: [Opendnssec-develop] common configuration file In-Reply-To: References: Message-ID: Jakob wrote on 03/30/2009 02:05:56 PM: > [Opendnssec-develop] common configuration file > > for a number of stuff, we need a common OpenDNSSEC configuration file > that all our tools can use. things that would go into this would be > some runtime parameters, like the configured pkcs11-libs etc. > > what would be the preferred format? > > 1. YAML-style? (like nsd and unbound) > > 2. XML. we all hate it, we all know it. > > 3. [.ini-style] > tag=value My preferred order: 1 3 2 Roy From matthijs at NLnetLabs.nl Mon Mar 30 12:19:08 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 30 Mar 2009 14:19:08 +0200 Subject: [Opendnssec-develop] common configuration file In-Reply-To: References: Message-ID: <49D0B8BC.8040006@nlnetlabs.nl> roy at nominet.org.uk wrote: >> what would be the preferred format? >> >> 1. YAML-style? (like nsd and unbound) >> >> 2. XML. we all hate it, we all know it. >> >> 3. [.ini-style] >> tag=value > > My preferred order: 1 3 2 +1 Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From roy at nominet.org.uk Mon Mar 30 13:04:13 2009 From: roy at nominet.org.uk (roy at nominet.org.uk) Date: Mon, 30 Mar 2009 15:04:13 +0200 Subject: [Opendnssec-develop] hsm-toolkit update, and some open questions In-Reply-To: <49D0B477.1030704@NLnetLabs.nl> References: <49D0B477.1030704@NLnetLabs.nl> Message-ID: Jelte Jansen wrote on 03/30/2009 02:00:55 PM: > roy at nominet.org.uk wrote: > > [1] Please discuss how we can circumvent this, as it is pretty annoying, > > and remains probably the same for a very long time for a user. We could do > > this via an environment setting, via a configuration file, both (or yet > > something else). > > > > did we have a token/module mapping somewhere yet? we could take one from > there ('Warning: no token specified. Using first token in > configuration'). Or something like that. That does lead to another dependency, right ? i.e. instead of specifying a library, I now need to specify the path and name for the token/module mapping place. Maybe we should indeed have a generic shared config. > > [2] Hard configured defaults will hurt eventually. This could also set this > > via a configuration file, or come to think of it, no default at all. Please > > discuss this as well. > > > > Heh, this kind of contradicts your previous statement. Well, this default has direct impact on the security realm, hence the allergy for currently safe but future-weak defaults. > I like *sane* defaults (whether from a configuration or hard-coded, or both, in that > order). But it may depend on what other uses you see for hsm-toolkit. I have no use for hsm-toolkit other than opendnssec. > > [3] Feature request idea: do we need to be able to generate keys in bulk? > > Say with an option for -G to generate X keypairs ? Since we don't need to > > specify anything _per_key_ this seems feasible. This seems to fit the use > > case for a large amount of zones. > > > > I don't see enough reasons to put a lot of work in that. OTOH, it > doesn't look like a lot of work either. One advantage if you even want > to use such a feature is that it could remember the PIN :) ok. > > [4] I understand from the world of cryptographers to avoid "3" as public > > exponent, as there might be implementations that are susceptible to > > Bleichenbacher's RSA signature forgery scheme due to sloppy padding. (see > > http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html ). It seems that > > 17 and 65537 are commonly used as a public exponent. I chose 65537, but > > that was arbitrary. We could also use yet another, very obscure but fixed > > exponent, solely to be able to identify which zones use OpenDNSSEC by the > > public exponent in the DNSKEY. > > > > I usually default to F4 (65537). I don't think identification of usage > is a compelling argument to choose another exponent. But you may come up > with more convincing reasons :) (otherwise my vote would be to use F4). Heh. It was solely a 'because we can' argument. But lets stick with 65537. Regards, Roy Arends Sr. Researcher Nominet UK From rickard.bondesson at iis.se Mon Mar 30 13:16:28 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 30 Mar 2009 15:16:28 +0200 Subject: [Opendnssec-develop] Meeting 20090415 Message-ID: <69830D4127201D4EBD146B904119971896CFAF@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi During IETF74 San Francisco, we decided that we should have a meeting about phase 1 and future work. Date: 15 April 2009 Time: 10:30-12:00 CEST (09:30-11:00 BST) If all components are ready for system use, then this meeting might be held at an earlier date. More info about the IETF meeting will be posted to the list. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSdDGLOCjgaNTdVjaAQiYygf8Cs5FIW2KLxgPRM9zqtImkHups4OK2Awr yUxPhZSY3ClOTK9BbPuA5a7MvOEDBFAEFhN/nJOjGXzLQRBuH45VP//v3ghk0oqq SMiIlENB12yJYRLCNLxxyl9RQt2dazaMuSVhIloOru0gXQsGr5Vd+8vOOmij3Edk KQNZQWJ2IBXM6oetGHNjAqwor/Wu5OHicL2IcMnV3591IVsL/IEgbC+rHH6UkmHD ZERVN4hnvwaohi+8Gi75k4nyG7yt7lIZvEulmBwW7FkyE8HAHQ2MlSrKj6XaJaAD V3xS0II1JHO1YC3XmWKIkGmN6uUB+E/Z7JUSGylmFXhFh1Wr2sPVAg== =ue7y -----END PGP SIGNATURE----- From patrik.wallstrom at iis.se Mon Mar 30 13:42:18 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Mon, 30 Mar 2009 15:42:18 +0200 Subject: [Opendnssec-develop] common configuration file In-Reply-To: <49D0B8BC.8040006@nlnetlabs.nl> References: <49D0B8BC.8040006@nlnetlabs.nl> Message-ID: <46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se> On Mar 30, 2009, at 2:19 PM, Matthijs Mekking wrote: > roy at nominet.org.uk wrote: >>> what would be the preferred format? >>> >>> 1. YAML-style? (like nsd and unbound) >>> >>> 2. XML. we all hate it, we all know it. >>> >>> 3. [.ini-style] >>> tag=value >> >> My preferred order: 1 3 2 > > +1 Me too -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jakob at kirei.se Mon Mar 30 14:29:26 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 30 Mar 2009 16:29:26 +0200 Subject: [Opendnssec-develop] common configuration file In-Reply-To: <46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se> References: <49D0B8BC.8040006@nlnetlabs.nl> <46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se> Message-ID: it seems that everyone likes YAML (but John hasn't replied yet, so we'll wait a bit more). but, since we all have to link with an XML parser, why not use XML - or we just need YetAnotherParser in the code (like YAML)? this would be my reason to choose ASN.2^H^H^H^H^HXML. however, the following paramters are needed (exact syntax TBD): enforcer: interval: 3600 seconds keygen-interval: 3 months backup-delay: 3 days pkcs11: repository: { sca6k: /usr/lib/pkcs11.so opensc: /usr/lib/opensc-pkcs11.so } question: is there a need to specify a slot# for each key repository? I think not as both the enforcer and the signer needs to enumerate all possible slots anyway and you can probably force a slot# at key generation time. jakob From rickard.bondesson at iis.se Mon Mar 30 14:36:45 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 30 Mar 2009 16:36:45 +0200 Subject: [Opendnssec-develop] common configuration file In-Reply-To: <46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se> References: <49D0B8BC.8040006@nlnetlabs.nl> <46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se> Message-ID: <69830D4127201D4EBD146B904119971896CFB4@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > roy at nominet.org.uk wrote: > >>> what would be the preferred format? > >>> > >>> 1. YAML-style? (like nsd and unbound) > >>> > >>> 2. XML. we all hate it, we all know it. > >>> > >>> 3. [.ini-style] > >>> tag=value > >> > >> My preferred order: 1 3 2 > > > > +1 > > Me too +1 Currently SoftHSM uses the following format for its config: : but can change to: : as in YAML. And allow comments with a hash sign. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSdDY/eCjgaNTdVjaAQh0Vgf6ApT6dG1JJFV2xka56EyGfs05DEIo+Mt3 OPuGz3q5jyjGkPfDfIShgqILHNbtnqqm3NiUs6diu8Dwkj1XqTwtfIEF0GYIIIPb v8vOhPmMPJ8Fw+zXdNLDz/sQW4TlwVfGhTjFIqP8tRR+lTD4CyBGgqDh6OruGBj8 33LqCKnrjDtJa87akDK7Mk3yJgR1hsYpGerUgHPXRUSbS/I3hGgDCth4Vn12BkMM pRCoFKCc95ELdmmiTDhQpHR8d7iJxqGAtkjST6Ab1jrySOSwWLd0wgvr66Qm0Gcl NpMWZ7e30M9AUyvRP2rsLdv3jCclfWfBrb1n3AdD+DnmUJU6+q/Q4w== =qku3 -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Mon Mar 30 14:51:49 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Mon, 30 Mar 2009 15:51:49 +0100 Subject: [Opendnssec-develop] Minutes of San Francisco meeting, 25 March 2009 Message-ID: The minutes of the meeting held in San Francisco last week have been placed on the Wiki at http://www.opendnssec.se/wiki/Meetings/Minutes/2009-03-25?version=1 Please let me know of any errors or omissions. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Mon Mar 30 15:12:20 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 30 Mar 2009 17:12:20 +0200 Subject: [Opendnssec-develop] ZoneList revisited In-Reply-To: References: <2BE57766-3E2D-4576-A37F-3B9877F2E747@kirei.se> <49D0848E.3010909@NLnetLabs.nl> <8BCAEF52-6BD3-41AE-9D51-37CBED9CE54E@kirei.se> <49D0B0A0.1010100@NLnetLabs.nl> Message-ID: so this is my suggestion. one thing that Jelte might want to know is how often (at most) the SignerConfiguration needs to be checked for changes, but I don't know if that's really necessary. jakob -- cut -- datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" start = zonelist zonelist = element ZoneList { element Zone { attribute name { xsd:string }, element Policy { xsd:string }, element SignerConfiguration { xsd:string }, element Adapters { element Input { adapter }, element Output { adapter } } }* } adapter = element File { xsd:string } -- cut -- example: -- cut -- default /var/opendnssec/config/opendnssec.se.xml /var/dnssec/unsigned/opendnssec.se /var/dnssec/signed/opendnssec.se -- cut -- From jakob at kirei.se Mon Mar 30 15:15:44 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 30 Mar 2009 17:15:44 +0200 Subject: Reminder : [Opendnssec-develop] hsm-toolkit update, and some open questions In-Reply-To: References: Message-ID: <62619FD4-842F-4C60-A844-18F73DEAF1C3@kirei.se> I've successfully create 100 rsa1024 keys on the sca6000 in kuriputo using roy's tool. -- excerpt -- kuriputo> pkcs11-tool --login -O --module /usr/lib/libpkcs11.so --pin test:1234 Private Key Object; RSA label: 116b741a-f882-44f3-dbab-c41ff1c89dd2 ID: 116b741af88244f3dbabc41ff1c89dd2 Usage: sign Public Key Object; RSA 1024 bits label: 116b741a-f882-44f3-dbab-c41ff1c89dd2 ID: 116b741af88244f3dbabc41ff1c89dd2 Usage: verify Private Key Object; RSA label: 529d5c74-58fb-47d9-ce7b-e6635d4572eb ID: 529d5c7458fb47d9ce7be6635d4572eb Usage: sign Public Key Object; RSA 1024 bits label: 529d5c74-58fb-47d9-ce7b-e6635d4572eb ID: 529d5c7458fb47d9ce7be6635d4572eb Usage: verify -- excerpt -- strange: if I specify pin as test:1234 on the command line it works. if I input test:1234 when prompted, it does not. jakob From rickard.bondesson at iis.se Mon Mar 30 15:21:26 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 30 Mar 2009 17:21:26 +0200 Subject: Reminder : [Opendnssec-develop] hsm-toolkit update, and some open questions In-Reply-To: <62619FD4-842F-4C60-A844-18F73DEAF1C3@kirei.se> References: <62619FD4-842F-4C60-A844-18F73DEAF1C3@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971896CFC4@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > strange: if I specify pin as test:1234 on the command line it works. > if I input test:1234 when prompted, it does not. Getpass will only read max 8 bytes when in solaris. If this is the case for you? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSdDjduCjgaNTdVjaAQiWxwf+JF53UltrYNFGBIHw7mvLyN/S2MDYNEbi 0Yfm2h2rpG1WsjC4QpMAclg/cDMjw49ex1GD3Chwlugjw/u/rgzlvFEA5BpNu3g2 rtHT/qa9OsoM79DRNySOipY8ILNSti0lPBwUxNiMuKxPNOIg8TposbMtXqUULfi5 TSAvlTzLSavPvtivBWT3i+skF1x3eKppbbIUD/K8wdhGMxtSd8MiYA9vhi6ReYUw MsTtnJ/TMmHf3QjiHpuTARKCZVo1f4h0TgJudZXG1+nY70OP1FPV6Fhv8pzaZw+P NsEvx/9C78JaMd4ZZbNR19bAzSzzIa25AQR87BxxtWaTzpUncL0Yaw== =8TyI -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Mar 30 14:53:32 2009 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 30 Mar 2009 15:53:32 +0100 Subject: [Opendnssec-develop] ZoneList revisited In-Reply-To: <49D0B0A0.1010100@NLnetLabs.nl> References: <2BE57766-3E2D-4576-A37F-3B9877F2E747@kirei.se> <49D0848E.3010909@NLnetLabs.nl> <8BCAEF52-6BD3-41AE-9D51-37CBED9CE54E@kirei.se> <49D0B0A0.1010100@NLnetLabs.nl> Message-ID: > > yes the enforcer can still write the zonelist, but it wouldn't need to > > be rewritten at every change (just for zone add/delete). I'm just > > suggesting keeping the actual list of zones separate the policy file > > (kasp.xml). > > > > ok i'm all for it :) > Sounds good to me too. It means that the XML is a closer reflection of the database structure that John and I are using. From jakob at kirei.se Mon Mar 30 17:48:48 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 30 Mar 2009 19:48:48 +0200 Subject: Reminder : [Opendnssec-develop] hsm-toolkit update, and some open questions In-Reply-To: <69830D4127201D4EBD146B904119971896CFC4@EXCHANGE.office.nic.se> References: <62619FD4-842F-4C60-A844-18F73DEAF1C3@kirei.se> <69830D4127201D4EBD146B904119971896CFC4@EXCHANGE.office.nic.se> Message-ID: <7F48AFC7-68B5-4B38-B944-0F9EC3E57889@kirei.se> On 30 mar 2009, at 17.21, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> strange: if I specify pin as test:1234 on the command line it works. >> if I input test:1234 when prompted, it does not. > > Getpass will only read max 8 bytes when in solaris. If this is the > case for you? likely. jakob From jelte at NLnetLabs.nl Tue Mar 31 07:51:11 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Tue, 31 Mar 2009 09:51:11 +0200 Subject: [Opendnssec-develop] common configuration file In-Reply-To: References: <49D0B8BC.8040006@nlnetlabs.nl> <46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se> Message-ID: <49D1CB6F.8060009@NLnetLabs.nl> Jakob Schlyter wrote: > it seems that everyone likes YAML (but John hasn't replied yet, so we'll > wait a bit more). but, since we all have to link with an XML parser, why > not use XML - or we just need YetAnotherParser in the code (like YAML)? > this would be my reason to choose ASN.2^H^H^H^H^HXML. > > > however, the following paramters are needed (exact syntax TBD): > > enforcer: > interval: 3600 seconds > keygen-interval: 3 months > backup-delay: 3 days > pkcs11: > repository: { > sca6k: /usr/lib/pkcs11.so > opensc: /usr/lib/opensc-pkcs11.so > } > > question: is there a need to specify a slot# for each key repository? I > think not as both the enforcer and the signer needs to enumerate all > possible slots anyway and you can probably force a slot# at key > generation time. > the engine currently also accepts an optional PIN for a token, and a few configurable directories (some of which could be 'hard'coded, but the input and final output dir shouldn't imo). Oh and i was about to add a config option for alerting an auth server that zones have changed. Jelte ps. for simplicity, atm it's key: value pairs with hashed comments (like softhsm) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From rickard.bondesson at iis.se Tue Mar 31 07:52:55 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 31 Mar 2009 09:52:55 +0200 Subject: [Opendnssec-develop] Newsletter #5 Message-ID: <69830D4127201D4EBD146B904119971896CFE0@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 * The project We have decided that we will focus more on phase 1 and making sure that it will be a product that can be used. Phase 1 will be delivered in iterations, where functionalities are added/upgraded in different releases. The wiki page will be updated with this information as soon as possible. All components should be ready for system integration by the next meeting. The aim is to present OpenDNSSEC at the next RIPE meeting in May, and a full release at IETF75 in Stockholm. The requirements for OpenDNSSEC will be updated to be able to perform the system tests. Please send any requirements concerning this project to Stephen. * Meetings We had a meeting at IETF74, San Francisco. See meeting minutes at our wiki page, please ready the action points that are assigned to you. Next meeting will be a telephone conference, 15 April 10:30 CEST. * KSM and KASP Enforcer John Dickinson is writing the enforcer. Currently there are some problems, but Sion was confident these could be overcome. He thought that the component would be finished in a week or two. * Signer Engine Matthijs reported that the signer engine is missing is error handling (Jelte is working on that) and documentation. Estimated 2 - 3 weeks to finish. * SoftHSM Rickard need to tidy up the source code. Rickard estimated mid-April for completion. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSdHL1uCjgaNTdVjaAQiJWgf/fKHGgUbdlHcMVcG3vmCJjluwUDPSUyB2 gadx+wm8iVnCa7hwBaA5pxVa4/w7HzfqAsqPdYrweGnPS5msOiNo5o//roj9qljy J0qd6Qmwuzy7XjE06+m4TDIfzr0cox0hQt2eeBvGaqYUe7p10/xX6muFLc/viB2r SaM/4/QFQAnixSh5VtkoJdISAdNddbD7wQylS0nPI7qurzb0j7dNkgwqwXQttFT0 PrjSZu1MADjqcPWavc+qqmjBp8dzEsYsJT/nDUTdPbfRG19ZiU6+JuZqIn6aG41T gKeCYxN2mQemJxIAE0amSqqmrDlQOzuO0n8NlxXDLGWmD38Jf0EuUA== =1tF7 -----END PGP SIGNATURE----- From jakob at kirei.se Tue Mar 31 08:27:58 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 31 Mar 2009 10:27:58 +0200 Subject: [Opendnssec-develop] common configuration file In-Reply-To: <49D1CB6F.8060009@NLnetLabs.nl> References: <49D0B8BC.8040006@nlnetlabs.nl> <46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se> <49D1CB6F.8060009@NLnetLabs.nl> Message-ID: On 31 mar 2009, at 09.51, Jelte Jansen wrote: > the engine currently also accepts an optional PIN for a token, and a > few > configurable directories (some of which could be 'hard'coded, but the > input and final output dir shouldn't imo). one pin per repository that is. > Oh and i was about to add a config option for alerting an auth server > that zones have changed. true. the more I think about it, the more I think we should take that ugly XML-pill and just do it... a simple OpenDNSSEC-config library should be enough. will you hate me forever if we do an XML config file? jakob From matthijs at NLnetLabs.nl Tue Mar 31 18:08:23 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 31 Mar 2009 11:08:23 -0700 Subject: [Opendnssec-develop] Minutes of San Francisco meeting, 25 March 2009 Message-ID: <49D25C17.3090309@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Action: Matthijs - speak to Jaap Akkerhuis to tell him that we may want a presentation slot at the RIPE DNS WG meeting. - -------------------------------------------------------------------------- We can always get a 15min slot to present our stuff. If we want a longer slot, we have to submit in advance. Currently, no submissions are made yet. Jaap will warn me if it gets crowded. - -------------------------------------------------------------------------- Action: Matthijs - forward signing requirements from .org to the list. - -------------------------------------------------------------------------- Interesting tidbits: * ORG has almost 8 million delegations with about 17.5 million RR. It takes about 2 gibibyte of RAM to run unsigned. * INFO has over 5 million delegations and about 11.5 million RR. It takes about 1.5 gibibyte of RAM to run unsigned. * Updates occur every minute (the might happen faster in the future, if we can get our SQL database to keep up with the queries), and are transmitted via NOTIFY/XFR. * The infrastructure includes hidden distribution masters as well as user-facing DNS servers. BIND does all distribution (we don't care about diversity on our internal infrastructure so much). * The average serial increase seems to have about 100 deletions/additions. * Signing occurs when a new serial arrives. Here are our minimal needs: * NSEC3 support * IXFR support * TSIG support * Time for incremental signing < 1 minute Our plans now include a 2048-bit KSK that we do not roll, a 1024-bit ZSK that we roll monthly, and a 7-day signature lifetime. In theory this list should be quite straightforward for a signer. If we assume each deletion or addition will result in 3 new records to be signed then that is only 300 signatures per minute from changes to the zone. If we assume a 1-week signature lifetime, then we will also have something like: * 8 million signatures in zone from RRSET * 8 million RR in zone from NSEC3 (worst case) * 16 million RR / (7 days * 24 hours * 60 minutes) = 1600 sign/minute So we need something that can sign or re-sign about 1900 times a minute, or say 35 times a second - something that should be possible without too much work if it is done with a proper design. - -------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBSdJcFw8yVCPsQCW5AQIdRwf5ASRR7V+QD6jQTDOjg4sVPAWP920Mu4mX vLzPZjYZvQ1yWHIJWQ8HnG7CGo0ygF1SROhmTg/vQ1758OD0aOHUyST9SYnmnSiB Nd+7NVFHeeWz1nhffygkLMPepykX03oQMl2TNLm5OBg9JxHDcM6MCargj4epvhNl 8dzkVtIFDcF7bcYFqaa0fw9S0hGUcHXX3v1MqgiuKEzGSbDlMICZgnFjrvg9JLM9 YthrOMWiB8gc5itpzNEp6NQs529pNwundRsvZffPHm24EN5R1vsfar/SGb2KM6nc 9PcM4NRmZzxedeF1YeVkBTxRIJ8Ak4I2dlyRZjH9hVWtpKwAofMkpw== =sRlw -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Tue Mar 31 09:09:57 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Tue, 31 Mar 2009 11:09:57 +0200 Subject: [Opendnssec-develop] Minutes of San Francisco meeting, 25 March 2009 In-Reply-To: <49D25C17.3090309@nlnetlabs.nl> References: <49D25C17.3090309@nlnetlabs.nl> Message-ID: <49D1DDE5.4060201@NLnetLabs.nl> Matthijs Mekking wrote: > -------------------------------------------------------------------------- > > Action: Matthijs - forward signing requirements from .org to the list. > > -------------------------------------------------------------------------- > Interesting tidbits: > * Signing occurs when a new serial arrives. this also includes the requirement that the serial number not be changed btw Jelte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: