From roy at nominet.org.uk Sun Feb 1 08:16:54 2009 From: roy at nominet.org.uk (Roy Arends) Date: Sun, 1 Feb 2009 09:16:54 +0100 Subject: [Opendnssec-develop] note on pcks11 library linking Message-ID: We should make a note somewhere that for production purposes, OpenDNSSEC should statically link the SoftHSM libraries, to avoid snooping by rogue pkcs11 library proxies. Regards, Roy Arends Sr. Researcher Nominet UK From roy at nominet.org.uk Sun Feb 1 09:06:57 2009 From: roy at nominet.org.uk (Roy Arends) Date: Sun, 1 Feb 2009 10:06:57 +0100 Subject: [Opendnssec-develop] note on pcks11 library linking In-Reply-To: References: Message-ID: opendnssec-develop-bounces at lists.opendnssec.org wrote on 02/01/2009 09:16:54 AM: > We should make a note somewhere that for production purposes, OpenDNSSEC > should statically link the SoftHSM libraries, That should be singular, ofcourse: the SoftHSM library :-) > to avoid snooping by rogue pkcs11 library proxies. Note that a pkcs11 proxy, like the one from OpenSC is handy for debugging (though just not secure in production). Thanks JAD for pointing that out. Regards, Roy Arends Sr. Researcher Nominet UK From rickard.bondesson at iis.se Mon Feb 2 07:18:29 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 2 Feb 2009 08:18:29 +0100 Subject: [Opendnssec-develop] 9th Feb meeting Message-ID: <69830D4127201D4EBD146B904119971880B7B9@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi When can you be available at Science Park 400 (Matrix II building), Room 1B in Amsterdam (pure meeting time)? Please fill in the Doodle. http://www.doodle.com/sp8x86uabxkwe8bq // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSYaeReCjgaNTdVjaAQjCrgf+Jtd0QRLXm72LpLIYNt1gDU4NKyW0XMT6 BYcPh/G2pi9btHAT8nP2l9LuPg5M0rtztrUMO5JsLr5NST1amq2vIjfe4EVmwmwT JKOFjRIDoE456o+ucTWjrIRsmT2jIYqKlbrC45eyyY9oO3blla43WiSsDexgefGI 2ADxMUBGu8I/fKnbv9HZ7h/ilvU+cGlUjW+fdfA8OOpMPBJdM296ba8lHlMk6FRH lXrVj4Pmjnj8wrbfJrlG7zHw6EYOutpOkDjr+ppJocMF17doAzx2B0VH163XWYMq unpgZMOAWk7M0g3jgZP4Pe6bVJLSUj+cnY9xYPOHqYSfPf9cb7kiwQ== =CbE3 -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Mon Feb 2 08:50:11 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 2 Feb 2009 09:50:11 +0100 Subject: [Opendnssec-develop] 20080209 Meeting Agenda Message-ID: <69830D4127201D4EBD146B904119971880B7BE@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 These are the meeting topics: ************************************* 1. Who will write minutes? - - Decide who will write minutes during this meeting. 2. System architect - - Do we need an architect who makes the end decisions about the overall architecture? What are the responsibilities? 3. Marketing plan - - Use Cases Discuss the use cases presented on the mailing list. Do we need to fulfil all of the use cases? What do we need to fulfil the individual use case? - - Market study What experiences do we have from the market? Do we need to do a study of what our potential users might want? How should such study be performed? Who should we ask? - - Marketing of our product Do we want our product to be noticed by other parties than us? Who would that be? How do we reach them? 4. Tasks, priorities, scheduling Discuss what tasks pop up, where they come from, which component is in charge of scheduling. This can be a major source of complexity if we want to deliver a reliable signer. One of the possible problems that could arise is that there are many sources of events, and nobody has an overview of what should be done when. Let alone that it would be possible to schedule downtime for maintenance. (Matthijs pointed out this issue.) All these issues may suggest that we need some form of realtime scheduler, so we don't have to invent too many wheels. 5. Robustness through redundancy For some applications, such as TLDs and the root zone, we should look into what it takes to create a robust setup. We do not want to fail our most important domains "just" because of a local earthquake. Designing this into the system is not very difficult, using existing clustering techniques, but it is good to have in mind early in the design process. This can probably be established in the KASP with either of the following approaches: a) The KASP is redundant, for example because it uses a distributed redundancy mechanism (think of MySQL replication, DRBD, ...) and the result is that keys are available to all signers. Slaves can simply be directed to the signer that is currently to be trusted. b) The DNSKEY records of each of two (or more) independent signers are brought into all the signers, in some way that integrates with the IXFR approach and/or with the master name server. 6. Design diagrams - - What proposals of system design do we have? Pros and cons? Can we bring them together? 7. System design for phase 1 and 2 - - General architecture Do we agree on the general concept? Is there something we would like to change? - - Components Can we specify the components any more? Any requirements? - - Data flow diagram Discuss how the data is flowing through the architecture. - - API between the components How should each component talk to its neighbours? 8. Discussion about each component - - What has been done? - - What needs to be done? - - How much time does each subtask need? - - Testing? 9. SoftHSM - - Should the object information be kept further away than they are now? As of now, all object information is available within the linked library. Should this information be kept away more securely in a form of ?server?, which the linked library talks to? 10. OpenDNSSEC v1.0 and v1.1 - - How should we fit everything together? - - Testing? 11. Comparison of HSM:s - - What information do we want on the wiki? A more detailed comparison? A how-to? Configurations? Recommendations? 12. About the project - - Trademark How should we protect our trademark? - - Packaging the code How should our program/code be published? Debian/RPM/?? - - Statistics Do we want to keep statistics on our wiki visitors? Page views, downloads, etc. 13. Next meeting - - How and when? -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSYazw+CjgaNTdVjaAQg1Fwf+NVnvwd5wmOTpaCU8UEPhi0m11LAeUamx jixHnshTw1BgeskKNpsXHBTga6pFLxQwHOLhTqmyu2Qi6RT9XcXiOnvu0FN2FRfR SXYSx3FOpQZtRqsUcMKauV2pgk1b2cjPvJTbgNySZEcGygqZ4+BrFmp9yDWO20iQ QUtVOt8hYa5Ao25KJzr4CXTCSW0pn6XBCOklmhPG3j3cnc3QnEBOWe6zqI1jkTVo 3EbseqJg2Z4lKI2ySS+BKswz+qsO1Gqk2VmSB4Lm+gLF2AuVeUavqHMKs2gNZv/6 tG6mEUq1H9q6IrPW3J8EQEb5Nky9vfb4q3yR9xTtUBMEHf6Si1SlQA== =IN0C -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Mon Feb 2 11:57:47 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Mon, 2 Feb 2009 06:57:47 -0500 Subject: [Opendnssec-develop] face2face agenda: design diagrams In-Reply-To: <20090130090541.GA17076@phantom.vanrein.org> References: <20090127084520.GB32586@phantom.vanrein.org> <69830D4127201D4EBD146B904119971880B531@EXCHANGE.office.nic.se> <20090130090541.GA17076@phantom.vanrein.org> Message-ID: <75180696-C61F-4DC4-8A13-CA4A03B21241@NLnetLabs.nl> On Jan 30, 2009, at 4:05 AM, Rick van Rein wrote: > * Robustness through redundancy > > For some applications, such as TLDs and the root zone, we should look > into what it takes to create a robust setup. We do not want to fail > our most important domains "just" because of a local earthquake. > Designing this into the system is not very difficult, using existing > clustering techniques, but it is good to have in mind early in the > design process. > Although I agree that you need to design for robustness I think that you will need to define some timescales that one would like to achieve here. If you say clustering I interpret that as near-real-time replication of the systems state. Following the first-walk-then-run principle I wonder if we want to design towards that in version 1. > This can probably be established in the KASP with either of the > following > approaches: > > a) The KASP is redundant, for example because it uses a distributed > redundancy mechanism (think of MySQL replication, DRBD, ...) and > the result is that keys are available to all signers. Slaves > can > simply be directed to the signer that is currently to be > trusted. > > b) The DNSKEY records of each of two (or more) independent > signers are > brought into all the signers, in some way that integrates with > the > IXFR approach and/or with the master name server. > Remember... version 1 does not do IXFR! As for b): My first thoughts on that that seem to lead to redundancy at the cost of packet size: if you want to do a valid rollover from system 1 to system 2 you have to pre-publish the DNSKEY... --Olaf --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- 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 rick at openfortress.nl Mon Feb 2 12:39:03 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 2 Feb 2009 12:39:03 +0000 Subject: [Opendnssec-develop] face2face agenda: design diagrams In-Reply-To: <75180696-C61F-4DC4-8A13-CA4A03B21241@NLnetLabs.nl> References: <20090127084520.GB32586@phantom.vanrein.org> <69830D4127201D4EBD146B904119971880B531@EXCHANGE.office.nic.se> <20090130090541.GA17076@phantom.vanrein.org> <75180696-C61F-4DC4-8A13-CA4A03B21241@NLnetLabs.nl> Message-ID: <20090202123903.GA26684@phantom.vanrein.org> Hello, > >* Robustness through redundancy > > Following the first-walk-then-run principle I wonder if we want to > design towards that in version 1. It should absolutely not be coded. But being aware of potential future issues is useful. -Rick From roy at nominet.org.uk Mon Feb 2 17:43:12 2009 From: roy at nominet.org.uk (Roy Arends) Date: Mon, 2 Feb 2009 12:43:12 -0500 Subject: [Opendnssec-develop] hsm-toolkit Message-ID: The hsm-toolkit can generate, list and remove RSA key-pairs from the HSM. usage: hsm-toolkit [-s slot] [-p pin] [-G [-b keysize] label] [-R label] If no arguments are given, the toolkit will try to list objects on slot 0, and will prompt for the pin. (Question: should I change the default to match softHSM's default slot 1?) If a label (an arbitrary string) is given as argument, the only matching keys will be listed. -G generates a key. default is 1024 bits, which can be change by using -b. A label is required. If the label already exists, a new key with the same label will not be generated. Key ID is not used at all (CKA_ID). (Note: I will add CKA_ID as well, and require that that the tuple is unique). -R removes a key. A label is required. (Question: should I change this to -D to avoid that -R is interpreted as "Read" instead of "Remove") Requests for functionality are welcome. Thanks. Regards, Roy Arends Sr. Researcher Nominet UK From rickard.bondesson at iis.se Tue Feb 3 07:31:52 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 3 Feb 2009 08:31:52 +0100 Subject: [Opendnssec-develop] hsm-toolkit In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B904119971880B81B@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > (Question: should I change the default to match softHSM's > default slot 1?) Or you could use the list given by C_GetSlotList? I use slot 1 because all the other identifiers (session and object) starts at 1. It is ok to use slot 0 by a HSM, but it is not mandatory. - - "A priori, any value of CK_SLOT_ID can be a valid slot identifier?in particular, a system may have a slot identified by the value 0. It need not have such a slot, however." // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSYfy6OCjgaNTdVjaAQiTDQf9Htt56REFC/uisc3DYlfkOruCoBhcdJVi /5YheGvZLhN/AfMbjxJbhJhSJceUGQA3rBYQPcGcWhWx8cDRX90OfOyiaLhCXOTx 0xl5o3e+0roxJGz09y6pCxjVK4Im5r+Lj9bwqnyfZQfPxLGra5nL7DX7xPyv2zOh GW9MNDT+FfWQAfpsBYNeI6PIxW41U4u8STi8lDI66s7iZDGObMTr/rQqDq4ZJhnA 9muBArJgNBvNcv4wz4y6J1aak0hQuD98EewvqoIDieW01/vs3yz02eDvd2aJtGvM sYZKYlV/xCZnmYlVB1uudBTKdAFvUr15gNojJj/3zHzAKOH7y9tgvA== =0mtO -----END PGP SIGNATURE----- From roy at nominet.org.uk Tue Feb 3 12:18:34 2009 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 3 Feb 2009 07:18:34 -0500 Subject: [Opendnssec-develop] hsm-toolkit In-Reply-To: <69830D4127201D4EBD146B904119971880B81B@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B81B@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 02/03/2009 02:31:52 AM: > > (Question: should I change the default to match softHSM's > > default slot 1?) > > Or you could use the list given by C_GetSlotList? Good point, will add. > I use slot 1 because all the other identifiers (session and object) > starts at 1. It is ok to use slot 0 by a HSM, but it is not mandatory. > > - - "A priori, any value of CK_SLOT_ID can be a valid slot > identifier?in particular, a system may have a slot identified by the > value 0. It need not have such a slot, however." Thanks Rickard. I'm not implying that the slot ID in softHSM should change. It is fine the way it is :-) Roy From rickard.bondesson at iis.se Thu Feb 5 15:35:15 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 5 Feb 2009 16:35:15 +0100 Subject: [Opendnssec-develop] 9th Feb meeting In-Reply-To: <69830D4127201D4EBD146B904119971880B7B9@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B7B9@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880B95F@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi The meeting will be held between 10:30 and 17:00, in accordance with the Doodle. Meeting in Amsterdam, 9th Feb 2009. Host: NLnet Labs Location: Science Park 400 (Matrix II building), Room 1B Time: 10:30-17:00 (local time) The meeting agenda is published on the wiki: http://www.opendnssec.se/wiki/Meetings/Agenda/2009-02-09 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSYsHM+CjgaNTdVjaAQi7xgf/TOCjPIgzON0eOoVzJ76HLMUpWadJaXfx kb1DPLDM8/4LVyMWpNa0pSBAJqXBggK+AldYWXKKrbxPmKgcxrmAcFyFDdEY9SS7 cowSkjJkfvDkfplefO+TgIdRUWJ+Lfz4vahHRVYWlmQeTPVT/c+1TOWqkwUJea1M nSKtkhHFxR5L3VDM9WcZHC/gBjA3fqhRlB5xu7Ywc+4GXHoLlZHvxm4Wu2rLfrXj UHixru72FRG72byqvSLMvi2i7FRVjNwAH4TREnIY7BUdiwkSojjLvaFl55qq+8W9 LULhqIXyy8zTR8YF4omxV2q6kt5OwXLXhMaTD6FHksKV11O5YRqZ7A== =CvzX -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Fri Feb 6 11:02:23 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 06 Feb 2009 12:02:23 +0100 Subject: [Opendnssec-develop] 9th Feb meeting In-Reply-To: <69830D4127201D4EBD146B904119971880B95F@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B7B9@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880B95F@EXCHANGE.office.nic.se> Message-ID: <498C18BF.5010503@nlnetlabs.nl> About the facilities: There are plenty of Internet access points. However, there is no wireless. There are two white boards, a paper-version of a whiteboard, chairs and a table. If I am correct, coffee and lunch has been taken care of. - Matthijs Rickard Bondesson wrote: > Hi > > The meeting will be held between 10:30 and 17:00, in accordance with the Doodle. > > Meeting in Amsterdam, 9th Feb 2009. > Host: NLnet Labs > Location: Science Park 400 (Matrix II building), Room 1B > Time: 10:30-17:00 (local time) > > The meeting agenda is published on the wiki: > http://www.opendnssec.se/wiki/Meetings/Agenda/2009-02-09 > > // Rickard ------------------------------------------------------------------------ _______________________________________________ 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 Fri Feb 6 11:55:22 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 06 Feb 2009 12:55:22 +0100 Subject: [Opendnssec-develop] 9th Feb meeting In-Reply-To: <498C18BF.5010503@nlnetlabs.nl> References: <69830D4127201D4EBD146B904119971880B7B9@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880B95F@EXCHANGE.office.nic.se> <498C18BF.5010503@nlnetlabs.nl> Message-ID: <498C252A.6090805@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthijs Mekking wrote: > About the facilities: > > There are plenty of Internet access points. However, there is no wireless. > > There are two white boards, a paper-version of a whiteboard, chairs and > a table. > > If I am correct, coffee and lunch has been taken care of. > if i don't forget, i'll bring my wireless AP (b/g/n) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmMJSoACgkQ4nZCKsdOncVofgCgrIuj2bOkYpUmiWZAiUJ9Tnhj lpcAoKapIha0q0rc944CwHu09kOrXH9K =lIyB -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Fri Feb 6 14:33:50 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 6 Feb 2009 15:33:50 +0100 Subject: [Opendnssec-develop] 9th Feb meeting In-Reply-To: <69830D4127201D4EBD146B904119971880B95F@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B7B9@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880B95F@EXCHANGE.office.nic.se> Message-ID: I will not be present. My mother is undergoing hart-surgery and my priorities are therefore elsewhere. --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 roland.vanrijswijk at surfnet.nl Tue Feb 10 08:04:25 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 10 Feb 2009 09:04:25 +0100 Subject: [Opendnssec-develop] Thoughts about redundancy Message-ID: <49913509.5070000@surfnet.nl> Hi guys, Just a thought I would like to bounce of you all... After yesterday's meeting I started thinking a bit about redundancy and how we (as SURFnet) could deploy OpenDNSSEC within our network. We have four datacenters in The Netherlands and our current DNS infrastructure is distributed over three of these points-of-presence. Ideally, I would want an OpenDNSSEC deployment to be redundant as well with at least two different points-of-presence within the network. This would mean duplicating the entire setup, including a HSM. This is where my questions/ponderings come in. This setup raises two questions for me: - How do I keep the two OpenDNSSEC systems synchronised? Is that something that would need to be defined/designed (obviously this is a 2.0+ feature)? - I think there is consensus within the project that HSMs and all things related to HSM management fall outside of the OpenDNSSEC system. This would mean that keeping the HSMs synchronised would be my job. But I can imagine that OpenDNSSEC could/should in some way facilitate this, for instance by firing of triggers when a modification of the data in the HSM has taken place (e.g. key generation), and for instance by enabling scheduled downtime (for a couple of minutes) to allow for HSM synchronisation/snapshotting. (Both of these could be considered policies, I guess) I realise that these features may be way beyond version 1.0. My impression was that some people in the project would like to postpone discussion of such features, which I understand and agree with as the focus should now be on version 1.0. I think it would be a shame, however, if ideas about new features for future versions (starting with 2.0) cannot be discussed at all; so I would like to propose the following: how about we define a second mailinglist for 'feature requests' or 'future features' or something like that? In that way, the development list stays "clean" and is only for current development, thus maintaining focus. Just my 2 cents... Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From matthijs at NLnetLabs.nl Tue Feb 10 09:25:14 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 10 Feb 2009 10:25:14 +0100 Subject: [Opendnssec-develop] meeting 9 feb 2009: minutes Message-ID: <499147FA.8040409@nlnetlabs.nl> Here are the minutes (attached). Please take a look at them for completeness and correctness. Matthijs -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: minutes URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From rickard.bondesson at iis.se Tue Feb 10 15:32:54 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Tue, 10 Feb 2009 16:32:54 +0100 Subject: [Opendnssec-develop] Doodle for telephone meetings Message-ID: <69830D4127201D4EBD146B904119971880BB1D@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Which weekdays do you prefer to have telephone meetings on? We want to have a meeting every second week starting from this week. http://www.doodle.com/xqyi8myu6m35xaw2 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZGeJuCjgaNTdVjaAQj/wQgAl0l/roDIsUM8K6ttKwYg5B71L2Rh6ysW rMxI4Yrq3+7Aco7wOpLv54h1vrRstch0JBUwtJ0+/EUG392x8jEEnEjQqDxbCuoh 4Q5hYieXCay+1E0Db0ply8UYPJVf+ug/TKq9c1vYvtqvjvd2I/VjZapcf8mCABKJ 5f5N5NDsF9yoPP00GLi2fjyCjO8kE+qSDTa6kRv2fTj/QDSPRsOJmDiD1YZtjLbI NLbTZHWYxXVIBu9vy810MauBu6s70Zi3HVik2PS9IlHwjVbOe/PKjx0R3zTVqIGY Pegf9RGXmjpB5jxGwlGl/jLkjjn67WPg1HK11Kb7gaFATG+1EzQEzw== =KWo+ -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Wed Feb 11 09:13:25 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Feb 2009 10:13:25 +0100 Subject: [Opendnssec-develop] Newsletter #2 Message-ID: <69830D4127201D4EBD146B904119971880BB5E@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi This is our second newsletter, which summarizes our current work. The next one will be published in two weeks. **************************************** * The project We have appointed Jakob as the system architect. He will make the final decisions concerning the general system design. * Meetings 2009-02-09 We had a meeting in Amsterdam. The minutes from the meeting will be published on the wiki shortly. This newsletter is essentially a summery of the meeting. Next Face-To-Face meeting will be in: 22-27 March 2009 ? IETF, San Francisco 4-8 May 2009 - RIPE, Amsterdam We will also have telephone meetings starting from this week. * Use cases Stephen will update the wiki with the current use cases. * Marketing plan No marketing is needed until we have a software that we can deliver. The main focus is now on developing. The reason is to avoid so called vapourware. One first step in the marketing area would be to add a new first page on the OpenDNSSEC web page, thus separating it from the wiki information which is for development. * System architecture The architecture has been more precisely defined, making all of us to have a common view of the project and current development. Auditing functionalities has also been added (like consistency checks). All logging information will go to syslog. * Windows We will not explicitly support Windows, but we should make it easy to create a porting for Windows. * API Most of the communication is between the KASP and Signer Engine, an interface which needs to be more specified. John, together with Jelte, will publish this on the wiki. * Key referencing Jakob will work out a draft on how to internally, within OpenDNSSEC, reference a set of keys. * Signer Engine with RRset Signer and NSEC-ifier The Signer Engine is essentially finished for version 1.0. Just needs a script which bundles the parts together and can communicate with the KASP Enforcer. A proof-of-concept is available in the source code repository. * SoftHSM All the functionality is in place to be able to function with the OpenDNSSEC software bundle. Some concerns were raised at the Amsterdam meeting regarding how the information is stored within the SoftHSM (security considerations). The changes are planned for the next iterations of development. * KASP and KSM We have a partly finished version of KASP. John and Sion will finalize it. The current work is also depending on a RFC draft concerning key management which will be published in shortly. * Inbound and outbound adapters They will be part of version 2. * Testing We have all agreed on that we must test our software very thoroughly. Testing guidelines will be written, so that each component is tested in the same way. The source code will be checked both manually and by automated tools. The entire system will also be tested to see that it conforms to the requirements. More details will be published by Stephen and Rick. * HSM A buyer?s guide will be written and published by Roland. A compliancy tool will also be developed, to be able to test HSMs if they have the functionality needed for OpenDNSSEC. * Robustness through redundancy Redundancy regarding keys is depending on the choice of HSM, and not explicitly part of OpenDNSSEC. However, we need to produce a set of operating guidelines. SURFNet can sponsor this kind of documents. This is not part of this stage, but for version 2. * Deadline for version 1 Each developer should report their estimates, on how much time they need, to Rickard. Rickard should then plan the finalization of version 1 according to this. ******************************************* // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZKWteCjgaNTdVjaAQgF5Qf/fsGlDPhFEG2WLwj/U/Ouj3ExEfIl3br/ CVzW9RP1sTEGEYPnqYeNW79cWBA/7z+EOzJH99nGNsKZBmhmd+1fifMiOyrM+vTb YochLdfJDhyuC77eUDeNUf3ywq/vh+Oxjvx/TUFfFYtJ5PoQeYQf809yI9WS1McJ QJ4JMl2REEE/tOc2Mk/WIkP1vsWuQhrUantPl5l5RL/YH1+lzT0vnpaqU510qHC2 xqfGSvX3TxcxZ6ZwROoUfEblA+Ih8L2yAKcxAcIpU7rIT+5dS1LlbK4CqBVyaNVT TIsjekM/IJ/IbSERVglyhxarEkCE+W2eIAd6OrZOq/PA/1slK6EB7w== =5fYu -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Wed Feb 11 10:51:00 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Feb 2009 11:51:00 +0100 Subject: [Opendnssec-develop] Creating tokens for SoftHSM Message-ID: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi During the last meeting we said that only one user PIN should be used per token. And that a security officer (SO) should be able to create a number of tokens. Is it ok to utilize the C_InitToken for this task? This means that no slots will exist from scratch. By giving an arbitrary slotID, C_InitToken will create a new token and tie it to that slotID. Thus can everything be handled via the PKCS#11 interface. The first call to C_InitToken would create the SO PIN and that is what is used later on for creating other tokens. The user PIN is then created by the C_InitPIN when the SO has logged in to the token. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZKtlOCjgaNTdVjaAQhpgwf/YYPqa/xa1FrGOZctONVcUhe3TW/1z3QO wo9kvdb4UJquXj5ouIhZLM7QGy0uliJnL3EWpCRLlpS+IdjkxWMJfShk/66+YwrX QiGDV8AO4WyEAVsEe6/i3E2mpvmXhCpMNRZpmEJucK02HbxrWbAXkD0zvNcsDXD3 qdeNU9xDkIfHXUVyKEIPs9YjDONtWK4lK8kc73VTJxWBDE7R+YBD0aZjm7lN5+sK M+k0DtM5+xjDPSmci0dWg5fM5vS3xcYAQNfbVs3iAW2saOYhpNYKfzwSeNp1A3yI YffDodrJ+dPxtd1Yi8rb33MjCdj1gP4mUVyU4jeHqjO95CYguWp/fw== =et03 -----END PGP SIGNATURE----- From rick at openfortress.nl Wed Feb 11 11:04:09 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Feb 2009 11:04:09 +0000 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> Message-ID: <20090211110409.GA24775@phantom.vanrein.org> Hi Rickard, > During the last meeting we said that only one user PIN should be used per token. And that a security officer (SO) should be able to create a number of tokens. Is it ok to utilize the C_InitToken for this task? No, that is not the intention of this function. This function is used when a token is present in a slot, but yet has to be initialised. As Roland explained, there is no PKCS #11 support for creating a new token. If I were you, I'd simply use a simple configuration file to setup the softHSM's out-of-band creation of new instances, or otherwise, I'd use a simple commandline option or run some special command to create new instances. Or you could simply run the daemon in multiple processes. The reason why we are a bit pesky about keeping PKCS #11 implemented as cleanly as possible by the SoftHSM is that we don't want OpenDNSSEC (or any other clients using the SoftHSM) to rely on non-standard functionality. If the SoftHSM is to service as a prepare-for-the-real-thing-device, it better behave like the real-thing-device :) > This means that no slots will exist from scratch. By giving an arbitrary slotID, C_InitToken will create a new token and tie it to that slotID. Thus can everything be handled via the PKCS#11 interface. You cannot call C_InitToken if there's no token in the slot. Doing so would (as far as I recall) violate the standard. Hope this helps, Cheers, Rick van Rein OpenFortress From jad at jadickinson.co.uk Wed Feb 11 12:44:46 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 11 Feb 2009 12:44:46 +0000 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <20090211110409.GA24775@phantom.vanrein.org> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org> Message-ID: <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> On 11 Feb 2009, at 11:04, Rick van Rein wrote: > Hi Rickard, > >> During the last meeting we said that only one user PIN should be >> used per token. And that a security officer (SO) should be able to >> create a number of tokens. Is it ok to utilize the C_InitToken for >> this task? > > No, that is not the intention of this function. This function is > used when > a token is present in a slot, but yet has to be initialised. As > Roland > explained, there is no PKCS #11 support for creating a new token. > > If I were you, I'd simply use a simple configuration file to setup the > softHSM's out-of-band creation of new instances, or otherwise, I'd use > a simple commandline option or run some special command to create new > instances. Or you could simply run the daemon in multiple processes. There is no daemon. > > > The reason why we are a bit pesky about keeping PKCS #11 implemented > as > cleanly as possible by the SoftHSM is that we don't want OpenDNSSEC > (or > any other clients using the SoftHSM) to rely on non-standard > functionality. > If the SoftHSM is to service as a prepare-for-the-real-thing-device, > it > better behave like the real-thing-device :) I don't really understand what is wrong with the current softHSM. It works with the tools like Roy's hsm-toolkit, opensc's pkcs11-tool etc. What is non-standard about these that you are worried about? As I understand it the difference is only that you don't have to go through the step of initializing the HSM before you use it by setting the SO pin and user PIN. The fact that this step is missing doesn't have any effect on OpenDNSSEC. Rather it only changes the setup instructions for the HSM. That said, I am all for softHSM working properly. John --- John Dickinson http://www.jadickinson.co.uk From jakob at kirei.se Wed Feb 11 13:08:22 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Feb 2009 14:08:22 +0100 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org> <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> Message-ID: <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> what about this idea: 1. the SO can create a token using a program (called "softhsm"). one database file per token. softhsm --init --pin mekmitasdigoat /var/lib/softhsm/mytoken.db (if --pin is omitted, it will ask for the pin) the private keys of the token is possible encrypted with the pin. also, the softhsm utility could be used to export keys in standard PEM format. ultimately this should only be done by the SO, but since the app needs to be able to decrypt the keys, I guess we can allow export using the user PIN only. softhsm --export --pin mekmitasdigoat --label mykey --out mykey.key / var/lib/softhsm/mytoken.db (and no, normally you wouldn't specify the pin on the command-line - softhsm would ask for it on the tty) 2. a configuration file is used to map each file data to slot ("insert the token into the slot") /etc/softhsm.conf slot0 = /var/lib/softhsm/mytoken.db slot1 = /var/lib/softhsm/yourtoken.db ... 3. the app links to the softhsm library and authenticates using the pin. this scheme would also let you "unplug" the token from the slot and move it somewhere else. just like a smartcard. would this be a resonable solution? jakob From rickard.bondesson at iis.se Wed Feb 11 13:13:29 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Feb 2009 14:13:29 +0100 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se><20090211110409.GA24775@phantom.vanrein.org><0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971880BB8E@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > what about this idea: +1 Seems like a good solution. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZLO+eCjgaNTdVjaAQh97Af8CIGyBxtbjAd+BVtODsoLzqk+pSrYOhKc AbJqNJqPZFHSbvGrjHC4SvDwMQ0rU0SyOzUo+w6PKMsLLKbMQeDB6vxI4f/tG8uD d0/DwPWhDOxpWYWKoBJEg7U264wnxjUM5UEm/78cI1N6huzaSRfZE9g0+sboBW+/ znFYwlTsOZ6pdupn67kN+m7HKWzKlh2L+s6fDBnH5OWT58+4pXJLuRlv36FyaAbU NtOn2d0uDdt2lpJIGLy/84x92glG6UV0ucBJvrsGQXpqkT4L3jjEgy9CgNAfGCDi Ikcg6vNbkxPHpOkJYVDhwSWAwP3e021VoXLA4GJHSF+XcqzcgnGuFg== =Rq5N -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Wed Feb 11 14:21:35 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 11 Feb 2009 15:21:35 +0100 Subject: [Opendnssec-develop] Test framework Message-ID: <69830D4127201D4EBD146B904119971880BC1F@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Any suggestions on good test frameworks? So we can do automated testing for both C and C++. Any reference on how the tests should be written to be able to work with the framework? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZLe7uCjgaNTdVjaAQjHWQf+Ljfn95TLds7qy6OobC99JermnEWrFdD8 ldzcVV1X3m4ehHY6NYOoW9rGlcMERN84TzuSSbIMu2wDfBaWHpOtT1tUHo7CZ18n kCNemVt5K2Q+zXbTL48cwa8nAw1neQ2Lwkik6XkMZnvXxGCYiIMDBBnqypXsmSoB kNX8AFApFjm367sHAUfiNdc0cA8DVNNEmKWk3zHvaPHLry9/lI9N/abPbkMp0qj2 lPnnjoedI2FN0tIK7DkINvSZO+O0fHHeuc/dv7qpZA6OvKde5YpZTdzryc1oKLdm 6dvz8GhopeGI9eNubUsoJNA0oafe+BExaL4BZfmpsUheZa/LwKkAdA== =tRxj -----END PGP SIGNATURE----- From rick at openfortress.nl Wed Feb 11 14:46:13 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Feb 2009 14:46:13 +0000 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org> <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> Message-ID: <20090211144613.GB386@phantom.vanrein.org> Hi, > I don't really understand what is wrong with the current softHSM. It > works with the tools like Roy's hsm-toolkit, opensc's pkcs11-tool etc. > What is non-standard about these that you are worried about? It supports standards-conflicting behaviour, making it less suitable as an early development platform. > As I understand it the difference is only that you don't have to go > through the step of initializing the HSM before you use it by setting > the SO pin and user PIN. No, the issue is the support of multiple users on one token. > That said, I am all for softHSM working properly. Cool :) -Rick From rick at openfortress.nl Wed Feb 11 14:55:09 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Feb 2009 14:55:09 +0000 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org> <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> Message-ID: <20090211145509.GC386@phantom.vanrein.org> Hi, Good, constructive ideas! > 1. the SO can create a token using a program (called "softhsm"). one > database file per token. Sounds good. Of course there would be no check that it was the SO, so it would actually be any user. Unless he sets himself up as the SO, which may be the intention of the PIN you are referring to below. > softhsm --init --pin mekmitasdigoat /var/lib/softhsm/mytoken.db > (if --pin is omitted, it will ask for the pin) Great, especially the 2nd line ;-) Creating users can all be done when logged in. > the private keys of the token is possible encrypted with the pin. So it is the user PIN, and not the SO-PIN? (which is fine, it just means that the user runs the program and not anyone in an SO capacity -- which is right as we don't have that role at all.) > also, the softhsm utility could be used to export keys in standard PEM > format. This is normally done through PKCS #11 and there are tools that do it. Of course, the access scrutiny of the token is applied -- which I think is the proper setup to support. If you cannot export it through PKCS #11 then your code is off -- which is just the sort of thing that you want to learn from using the SoftHSM. > ultimately this should only be done by the SO, 1. We have no SO role in the SoftHSM 2. Anyone with the proper privileges may export their own keys; the SO role is for managing users and tokens, not so much for managing keys. > 2. a configuration file is used to map each file data to slot ("insert > the token into the slot") > > /etc/softhsm.conf > slot0 = /var/lib/softhsm/mytoken.db > slot1 = /var/lib/softhsm/yourtoken.db > ... Yeah, that's the sort of configfile I was thinking about. Thanks for being as concrete as perhaps I should have been. Good stuff. > 3. the app links to the softhsm library and authenticates using the pin. Yeah. > this scheme would also let you "unplug" the token from the slot and > move it somewhere else. just like a smartcard. Do note that we're simulating an HSM, not a smart card or crypto-token setup, but yes, that is a good degree of flexibility. Although I haven't seen concrete commands for doing this plugging and unplugging. > would this be a resonable solution? Given the remarks I made, yes indeed. -Rick From jakob at kirei.se Wed Feb 11 15:03:47 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Feb 2009 16:03:47 +0100 Subject: [Opendnssec-develop] FYI: PKCS#11 proxy sketch References: <20090211145527.C370A64C28@mail.kirei.se> Message-ID: <7D90E50A-B9FB-43FE-8762-9C82C116D7CD@kirei.se> I've made a small sketch of my PKCS#11 idea and put it at http://svn.opendnssec.se/home/jakob/p11proxy.pdf . jakob From jakob at kirei.se Wed Feb 11 19:33:26 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Feb 2009 20:33:26 +0100 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <20090211145509.GC386@phantom.vanrein.org> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org> <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> <20090211145509.GC386@phantom.vanrein.org> Message-ID: <5FB7FB20-3EE5-49A3-B753-B79F7F921AAF@kirei.se> On 11 feb 2009, at 15.55, Rick van Rein wrote: >> 1. the SO can create a token using a program (called "softhsm"). one >> database file per token. > > Sounds good. Of course there would be no check that it was the SO, > so it would actually be any user. Unless he sets himself up as the > SO, which may be the intention of the PIN you are referring to below. in my view, there is no real SO for SoftHSM. > So it is the user PIN, and not the SO-PIN? > (which is fine, it just means that the user runs the program and > not anyone in an SO capacity -- which is right as we don't have > that role at all.) yes, it is the user PIN. the only USER. >> also, the softhsm utility could be used to export keys in standard >> PEM >> format. > > This is normally done through PKCS #11 and there are tools that do it. > Of course, the access scrutiny of the token is applied -- which I > think > is the proper setup to support. If you cannot export it through > PKCS #11 > then your code is off -- which is just the sort of thing that you > want to > learn from using the SoftHSM. sure, but it would sure be nice if the softhsm utility could export/ import keys directly into the database, yes? >> ultimately this should only be done by the SO, > > 1. We have no SO role in the SoftHSM > 2. Anyone with the proper privileges may export their own keys; the SO > role is for managing users and tokens, not so much for managing > keys. correct. >> this scheme would also let you "unplug" the token from the slot and >> move it somewhere else. just like a smartcard. > > Do note that we're simulating an HSM, not a smart card or crypto-token > setup, but yes, that is a good degree of flexibility. Although I > haven't > seen concrete commands for doing this plugging and unplugging. when you change the config file, you plug/unplug. you cannot do this after the softhsm has initialized itself (i.e. opened the database). jakob From rick at openfortress.nl Wed Feb 11 22:42:30 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Feb 2009 22:42:30 +0000 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <5FB7FB20-3EE5-49A3-B753-B79F7F921AAF@kirei.se> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org> <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> <20090211145509.GC386@phantom.vanrein.org> <5FB7FB20-3EE5-49A3-B753-B79F7F921AAF@kirei.se> Message-ID: <20090211224230.GA13079@phantom.vanrein.org> Hi, > sure, but it would sure be nice if the softhsm utility could export/ > import keys directly into the database, yes? It sounds like a waste of time to me, as PKCS #11 and relating tools can do it. Also it sounds like a way to get things done that oughtn't be doable. > when you change the config file, you plug/unplug. you cannot do this > after the softhsm has initialized itself (i.e. opened the database). OK. Removing a token from a slot usually indicates doing so while the PKCS #11 library is operational. I suppose what you are saying is that the SoftHSM, which runs as a library to implement PKCS #11, cannot actually plug/unplug tokens into/from slots. As said before, this (un)plugging behaviour would only be useful when mimicing a USB-token or smart card; an HSM would not have this behaviour. Note that tokens are so low-cost (EUR 50 range) that simulating them is not really necessary. -Rick From roy at nominet.org.uk Wed Feb 11 23:25:21 2009 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 11 Feb 2009 23:25:21 +0000 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: <20090211224230.GA13079@phantom.vanrein.org> References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org> <0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se> <20090211145509.GC386@phantom.vanrein.org> <5FB7FB20-3EE5-49A3-B753-B79F7F921AAF@kirei.se> <20090211224230.GA13079@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 02/11/2009 10:42:30 PM: > Hi, > > > sure, but it would sure be nice if the softhsm utility could export/ > > import keys directly into the database, yes? > > It sounds like a waste of time to me, as PKCS #11 and relating tools can do it. > Also it sounds like a way to get things done that oughtn't be doable. I'm ambivalent about this. I'd leave this one to Rickard. Note that many HSM providers, though PKCS11 compatible, also allow for proprietary methods to import keys. My point is that I agree with the notion that this can be done using PKCS#11, though that the assertion that this is a way to get things done that should not be doable is false. > > when you change the config file, you plug/unplug. you cannot do this > > after the softhsm has initialized itself (i.e. opened the database). > > OK. Removing a token from a slot usually indicates doing so while the > PKCS #11 library is operational. I suppose what you are saying is that > the SoftHSM, which runs as a library to implement PKCS #11, cannot > actually plug/unplug tokens into/from slots. Jakob is saying, when you want to emulate plug/unplug, change the config file. > As said before, this (un)plugging behaviour would only be useful when > mimicing a USB-token or smart card; an HSM would not have this behaviour. > Note that tokens are so low-cost (EUR 50 range) that simulating them is > not really necessary. I want to make a general statement, addressed to the group, not particularly to the discussion at hand. I want to iterate that the need for a software emulated HSM is to provision for OpenDNSSEC, since that uses the pkcs11 API. There is no requirement from our OpenDNSSEC project on softHSM to be fully compatible with all the functionality that a HSM (be it smartcards, usb sticks, appliances, PCIe cards or what not) might possibly provide. Furthermore, we have the resources to test OpenDNSSEC with a plethora of HSM's. This restricts OpenDNSSEC to only use a minimal set of necessary calls to still be pkcs11 compliant (i.e. not violate the specification). These calls need to be implemented in SoftHSM. Regards, Roy Arends Sr. Researcher Nominet UK From roland.vanrijswijk at surfnet.nl Thu Feb 12 07:52:45 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 12 Feb 2009 08:52:45 +0100 Subject: [Opendnssec-develop] Test framework In-Reply-To: <69830D4127201D4EBD146B904119971880BC1F@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BC1F@EXCHANGE.office.nic.se> Message-ID: <4993D54D.8040900@surfnet.nl> Hi Rickard, For C++ the best test framework I know is CPPUnit: http://cppunit.sourceforge.net For C there is a similar framework called CUnit (I haven't tried it but heard good things about it...) http://cunit.sourceforge.net Cheers, Roland Rickard Bondesson wrote: > Hi > > Any suggestions on good test frameworks? So we can do automated testing for both C and C++. Any reference on how the tests should be written to be able to work with the framework? > > // Rickard ------------------------------------------------------------------------ _______________________________________________ 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 roland.vanrijswijk at surfnet.nl Thu Feb 12 07:55:08 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 12 Feb 2009 08:55:08 +0100 Subject: [Opendnssec-develop] FYI: PKCS#11 proxy sketch In-Reply-To: <7D90E50A-B9FB-43FE-8762-9C82C116D7CD@kirei.se> References: <20090211145527.C370A64C28@mail.kirei.se> <7D90E50A-B9FB-43FE-8762-9C82C116D7CD@kirei.se> Message-ID: <4993D5DC.9000709@surfnet.nl> Hi Jakob, It's a good idea. Have you checked whether there already any open source tools available that can do this (last time I checked there weren't, but that was about 4 years ago). If you need any help let me know, I've done something like this before (again, some time ago...) Cheers, Roland Jakob Schlyter wrote: > I've made a small sketch of my PKCS#11 idea and put it at > http://svn.opendnssec.se/home/jakob/p11proxy.pdf. > > > 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 rickard.bondesson at iis.se Thu Feb 12 07:57:34 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 12 Feb 2009 08:57:34 +0100 Subject: [Opendnssec-develop] Creating tokens for SoftHSM In-Reply-To: References: <69830D4127201D4EBD146B904119971880BB73@EXCHANGE.office.nic.se> <20090211110409.GA24775@phantom.vanrein.org><0D4ACE19-E0A7-405B-B25A-11A1879BE238@jadickinson.co.uk> <02D2BE32-DE3A-4EE4-95AA-D0B21533B507@kirei.se><20090211145509.GC386@phantom.vanrein.org> <5FB7FB20-3EE5-49A3-B753-B79F7F921AAF@kirei.se><20090211224230.GA13079@phantom.vanrein.org> Message-ID: <69830D4127201D4EBD146B904119971880BC52@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I'm ambivalent about this. I'd leave this one to Rickard. > Note that many HSM providers, though PKCS11 compatible, also > allow for proprietary methods to import keys. My point is > that I agree with the notion that this can be done using > PKCS#11, though that the assertion that this is a way to get > things done that should not be doable is false. I will copy the current version of SoftHSM to /tags/softHSM-0.4 and start the work with the new features. Exporting and importing keys is not the top priority as of now, but will be added later. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZPWbuCjgaNTdVjaAQgGhgf/eUFZgIMWVrlBkVg112PWbABy0ZnLLAMH YNrxstVu3PwYIT1xQ9n53aNidzfL9CJ4YElKeHolLdk5ZwmQAbJrKA/BQ+1/6V5t S8osa7PwMQsEfwAUMK+j2GgFYv/ytO0zPK0qmnJ6gOMLku8GMJADku5xBK2cN+Ai rlSfiAAn/PuzzRrov6FD5O2/46n1Mu3VgCMUWP0en3ueCCz4EmOmd8hZ3Cq5RQW/ w1bi2obHodr5yh3rhx8M+Z/nv6BjfhmHhVc1vLdYwU5ADkLp4Uv9+FAXHZSXsjq9 JwvyLIzH41tzHdr8aWiSIvwIaJ14BomhFHkP8ZINoOBk5DLowLCw4A== =r+Li -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Thu Feb 12 10:59:41 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 12 Feb 2009 10:59:41 +0000 Subject: [Opendnssec-develop] Test framework In-Reply-To: <4993D54D.8040900@surfnet.nl> Message-ID: Roland van Rijswijk wrote on 12/02/2009 07:52:45: > Hi Rickard, > > For C++ the best test framework I know is CPPUnit: > > http://cppunit.sourceforge.net > > For C there is a similar framework called CUnit (I haven't tried it but > heard good things about it...) > > http://cunit.sourceforge.net I've used CUnit and it works well. > > Cheers, > > Roland > > Rickard Bondesson wrote: > > Hi > > > > Any suggestions on good test frameworks? So we can do automated > testing for both C and C++. Any reference on how the tests should be > written to be able to work with the framework? > > > > // Rickard The documentation for both CUnit and CPPUnit give instructions on writing tests. For a real example, the KSM (KASP) code available on the Nominet download site (http://download.nominet.org.uk/KASP/ksm_20090119.tar.gz) uses CUnit for its unit tests. Please feel free to refer to it or copy anything you need from it. Stephen From jakob at kirei.se Mon Feb 16 07:33:21 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 16 Feb 2009 08:33:21 +0100 Subject: [Opendnssec-develop] FYI: PKCS#11 proxy sketch In-Reply-To: <4993D5DC.9000709@surfnet.nl> References: <20090211145527.C370A64C28@mail.kirei.se> <7D90E50A-B9FB-43FE-8762-9C82C116D7CD@kirei.se> <4993D5DC.9000709@surfnet.nl> Message-ID: would you mind taking a look and see if you can find such a thing? if not, we should push this task onto our stack. perhaps we can convince Rickard to write one once SoftHSM is readyish. jakob From matthijs at NLnetLabs.nl Mon Feb 16 08:02:49 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 16 Feb 2009 09:02:49 +0100 Subject: [Opendnssec-develop] meeting 9 feb 2009: minutes revised Message-ID: <49991DA9.4000404@nlnetlabs.nl> I have updated the minutes with comments received last week. If no one else have comments they can be put on the wiki, I guess. Matthijs -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: minutes2 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From rickard.bondesson at iis.se Thu Feb 19 07:29:44 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 19 Feb 2009 08:29:44 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb Message-ID: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The Doodle says that we should have the telephone meetings on Monday afternoons. So next meeting is: Monday 23rd Feb 14:00-15:00 CET 1. Please reply the topics you want to discuss. 2. What telephone number to call in to? Same as last time? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZ0KaOCjgaNTdVjaAQg2Agf/aHTR7Xj+cuBQF7b7dysLJchnUNAYLZdK XbS5HvyZ19eWBSVPhr3dEyXBEll+e5pa4wCf6NJvbyH5Ee/fGOrHvU24iMfrDQgD Znp5lEqqQO2tdFkdNsfkAJt9XOhMWSqhVCz5nfqJ25K70m9bSYpVoixpqPyLJ+dj yQZxpz4PZIskwQD96UhRTowoJ0J8M0PxsSUZORTkXjz1R2Hw0hySjyzlLJqmTSsL muHuVo7cz2q6V4hM3zONN6mFhZRagQaCKBrZxaVECsxRvN5/aUC5AXDHjYENMHF4 mtGgoaoFZRpS5ANdgrbR1rg4Wa7lVPMhQsAsP5y1YMenCTIh5H5j0w== =2rCz -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Thu Feb 19 07:42:08 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 19 Feb 2009 08:42:08 +0100 Subject: [Opendnssec-develop] FYI: PKCS#11 proxy sketch In-Reply-To: References: <20090211145527.C370A64C28@mail.kirei.se> <7D90E50A-B9FB-43FE-8762-9C82C116D7CD@kirei.se> <4993D5DC.9000709@surfnet.nl> Message-ID: <499D0D50.3040405@surfnet.nl> Hi Jakob, I'll have a look around and get back to you. I've been down with the flu the last couple of days so give me some time as I have to catch up on a lot of stuff. I'll try to come back on this end of next week. Cheers, Roland Jakob Schlyter wrote: > would you mind taking a look and see if you can find such a thing? if > not, we should push this task onto our stack. perhaps we can convince > Rickard to write one once SoftHSM is readyish. > > jakob > -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jad at jadickinson.co.uk Thu Feb 19 12:41:07 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 19 Feb 2009 12:41:07 +0000 Subject: [Opendnssec-develop] Key removal Message-ID: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> Stephen and I have been thinking about how the Enforcer should work. Initially I was thinking that the Enforcer will tell the Signer Engine which keys should be published in the zone and which should be used to sign the zone. The Enforcer would make all the decisions about which keys are in which states (generated, published, active, retired, dead and no longer published). However, I am now wondering if the Enforcer should only be concerned with the states from generated to retired and that it should be up to the signer to decide when it is OK for a key that is no longer used for new signing operations (but may have been used to generate existing signatures) to be removed from the zone. Thoughts? John --- John Dickinson http://www.jadickinson.co.uk From olaf at NLnetLabs.nl Thu Feb 19 12:46:50 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 19 Feb 2009 13:46:50 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> Message-ID: <81DAFBCE-66D4-4EEE-9FCD-07983F0063A2@NLnetLabs.nl> On 19 feb 2009, at 08:29, Rickard Bondesson wrote: > > Monday 23rd Feb 14:00-15:00 CET Apologies, I will be on a plane. --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 Feb 19 12:58:42 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 19 Feb 2009 13:58:42 +0100 Subject: [Opendnssec-develop] Key removal In-Reply-To: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> References: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> Message-ID: On 19 feb 2009, at 13.41, John Dickinson wrote: > Stephen and I have been thinking about how the Enforcer should work. > > Initially I was thinking that the Enforcer will tell the Signer > Engine which keys should be published in the zone and which should > be used to sign the zone. The Enforcer would make all the decisions > about which keys are in which states (generated, published, active, > retired, dead and no longer published). However, I am now wondering > if the Enforcer should only be concerned with the states from > generated to retired and that it should be up to the signer to > decide when it is OK for a key that is no longer used for new > signing operations (but may have been used to generate existing > signatures) to be removed from the zone. I would really like the enforcer to make all decisions regarding what keys are used for signing and publication, and that we can keep the signer stateless and "dumb". jakob From matthijs at NLnetLabs.nl Thu Feb 19 12:59:16 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 19 Feb 2009 13:59:16 +0100 Subject: [Opendnssec-develop] Key removal In-Reply-To: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> References: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> Message-ID: <499D57A4.9090904@nlnetlabs.nl> Imo, the *decisions* whether to use a key for signing and publishing should not be the task of the Signer Engine. So I would say: No, this intelligence should stay in the Enforcer. Matthijs John Dickinson wrote: > Stephen and I have been thinking about how the Enforcer should work. > > Initially I was thinking that the Enforcer will tell the Signer Engine > which keys should be published in the zone and which should be used to > sign the zone. The Enforcer would make all the decisions about which > keys are in which states (generated, published, active, retired, dead > and no longer published). However, I am now wondering if the Enforcer > should only be concerned with the states from generated to retired and > that it should be up to the signer to decide when it is OK for a key > that is no longer used for new signing operations (but may have been > used to generate existing signatures) to be removed from the zone. > > Thoughts? > John > --- > John Dickinson > http://www.jadickinson.co.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 rickard.bondesson at iis.se Thu Feb 19 13:01:30 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 19 Feb 2009 14:01:30 +0100 Subject: [Opendnssec-develop] Key removal In-Reply-To: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> References: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> Message-ID: <69830D4127201D4EBD146B904119971880BFA1@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Thoughts? > John I think it should be the KASP Enforcer that removes the keys (from the HSM). It is the one that keeps track of the key states. If it knows that a key is no longer published, then Signer Engine should not use it for signing or having the DNSKEY in the zone. Thus would it not be a problem for the Enforcer to remove the key. If this is not true then the knowledge of the key is incorrect, thus would the Enforcer not fulfil its purpose. The KASP Enforcer knows about the past, future, and present. Whilst the Signer Engine only knows what the Enforcer is saying to it. If a key is to be removed from a token that is not present, then an operator must be called upon. That is the job of the Enforcer, not the Signer Engine. Just my thoughts? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZ1YKuCjgaNTdVjaAQgzVgf+IgLQNIw96A8H2OP9sghYbCZCfg36V6M/ s2MY+27xlxLlvADvLfn0D6JC1Cnpy3P2PLy0t+yQM8MVbYXa9VwQ6TXAsyknAm9w W14Kwk2nBNa2ucWgvWOi06j4doGLriu3svDH8AJiuhGFY/PKf86MQUuNrCEBAibk g1/QUX6VXaV+7u51Qjx9VXp1ocRpqHVW3HNHTI18/VMsHgVFXMA8jaYffJnNsG0M UCXRHATg+PPoo7EmXAqqkFbrRTCv0uZJjORz28gNBHEmuscc/jH2Tbpa2URlVXOq BLf74A3xtmGMCWhrwVfcTOK6x1bkdZQ8zU7qx5hI0fY6+CQmFcthBA== =tS3Z -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Thu Feb 19 13:08:43 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 19 Feb 2009 13:08:43 +0000 Subject: [Opendnssec-develop] Key removal In-Reply-To: References: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> Message-ID: On 19 Feb 2009, at 12:58, Jakob Schlyter wrote: > On 19 feb 2009, at 13.41, John Dickinson wrote: > >> Stephen and I have been thinking about how the Enforcer should work. >> >> Initially I was thinking that the Enforcer will tell the Signer >> Engine which keys should be published in the zone and which should >> be used to sign the zone. The Enforcer would make all the decisions >> about which keys are in which states (generated, published, active, >> retired, dead and no longer published). However, I am now wondering >> if the Enforcer should only be concerned with the states from >> generated to retired and that it should be up to the signer to >> decide when it is OK for a key that is no longer used for new >> signing operations (but may have been used to generate existing >> signatures) to be removed from the zone. > > I would really like the enforcer to make all decisions regarding > what keys are used for signing and publication, and that we can keep > the signer stateless and "dumb". It still does but since the Enforcer can not see the signed zone it will not "know" how the signer is doing the signing (i.e. replacing all RRSIG every time or just signing new stuff and expiring RRSIGS) and if there are any signatures remaining from an old key. Therefore it will have to calculate from the KASP signature parameters when it is safe to stop publishing the old key. Something along the lines of the key must continue to be published for at least signature lifetime + TTLsig + clockskew (this equation is not correct, needs work and is what got me thinking this in the first place). This equation depends largely on parameters related to signatures and so I wondered if that indicated that it might be in the signers realm of responsibility. However you all seem to be in agreement that the Enforcer should do it and I am happy with that. John --- John Dickinson http://www.jadickinson.co.uk From matthijs at NLnetLabs.nl Thu Feb 19 13:45:55 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 19 Feb 2009 14:45:55 +0100 Subject: [Opendnssec-develop] Key removal In-Reply-To: References: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> Message-ID: <499D6293.3000609@nlnetlabs.nl> John Dickinson wrote: > It still does but since the Enforcer can not see the signed zone it will > not "know" how the signer is doing the signing (i.e. replacing all RRSIG > every time or just signing new stuff and expiring RRSIGS) and if there > are any signatures remaining from an old key. I say if there are any signatures remaining from an old key, you have (at least) two choices: * Remove all signatures corresponding to the old key. * Keep these signatures until its lifetime exceeded and they still validate. However, the Signer Engine should not generate new signatures anymore. Therefore it will have to > calculate from the KASP signature parameters when it is safe to stop > publishing the old key. Something along the lines of the key must > continue to be published for at least signature lifetime + TTLsig + > clockskew (this equation is not correct, needs work and is what got me > thinking this in the first place). This equation depends largely on > parameters related to signatures and so I wondered if that indicated > that it might be in the signers realm of responsibility. I prefer this to be optional. When KASP tells us not to use a key for signing/publishing anymore, it should be safe to stop publishing the old key immediately. Matthijs > However you all seem to be in agreement that the Enforcer should do it > and I am happy with that. > John > --- > John Dickinson > http://www.jadickinson.co.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 roland.vanrijswijk at surfnet.nl Fri Feb 20 10:30:39 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Fri, 20 Feb 2009 11:30:39 +0100 Subject: [Opendnssec-develop] HSM information Message-ID: <499E864F.4040600@surfnet.nl> Guys, I am talking to SafeNet w.r.t. their HSM products as I am trying to create a shortlist of HSM products because we (SURFnet) will need to buy one or two HSMs for our DNSSEC setup. I told them that we are participating in the OpenDNSSEC project. They had a look at the site and sent me the following request: "By the way, I checked the web-site - most interesting. I note that you include the study by Mike Bond that identifies potential vulnerabilities in a CA3. I am very uncomfortable with this!! The CA3 is now EOL and repaced with CA4 The vulnerability identified has been fixed (and was at the time of testing) The vulnerability relied on all permissions around the HSM being fulfilled in any case. How can I request that this is removed or a repudiation document published along-side" Can someone please honour their request and correct this information? I know I shouldn't say this but this is precisely why I think there shouldn't be HSM vendor specific information on the OpenDNSSEC website. I've scheduled some time next week to work on a HSM buyer's guide. I'll keep you guys up-to-date. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Fri Feb 20 11:06:41 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 20 Feb 2009 12:06:41 +0100 Subject: [Opendnssec-develop] HSM information In-Reply-To: <499E864F.4040600@surfnet.nl> References: <499E864F.4040600@surfnet.nl> Message-ID: <263388C6-2302-4506-B438-A57CFB945DB2@kirei.se> On 20 feb 2009, at 11.30, Roland van Rijswijk wrote: > I told them that we are participating in the OpenDNSSEC project. They > had a look at the site and sent me the following request: ... > Can someone please honour their request and correct this information? I'll update the information. I still believe its useful for us to publish the summary, but we should update any information that is wrong. jakob -- Jakob Schlyter Kirei AB tel:+46705950794 tel:+46317878007 sip:jakob at kirei.se mailto:jakob at kirei.se From rickard.bondesson at iis.se Fri Feb 20 14:15:41 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 20 Feb 2009 15:15:41 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Suggestion on agenda: ************* 1. Who will write minutes? 2. Use cases - - The wiki has been updated 3. Updates on the API between the Enforcer and Signer Engine 4. Discussion about each component - - What has been done since last time? - - What to be done in the nearest future? - - How much time is needed? 5. DNSSEC Signer - - How should we test and integrate the different components for version 1? 6. Project requirements - - Are we missing any requirements? - - Do we need to update the requirements to be able to do the system tests? - - Who will make the updates? 7. HSM buyer?s guide - - What should the HSM buyer?s guide include? 8. DS to parent - - How should we transport the DS to the parent? 9. Next meeting ************** Call in to: sip:conference at NLnetLabs.nl the pin number is 5227# (Jelte needs to verify this) If you don't have a sip phone or client available, the room should also be available at +31 20 7508314 extension 263 (just dial 263 when olaf's recorded voice starts talking) // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSZ67DeCjgaNTdVjaAQhFuAf/Utl6kA32KaorzF2T3NN7AwP309NIV5BT ImUyUYHCbYvWG+O0O3MGNs5ERDWxY0i2pLbtWKqM7QEDBxhpirhS0a+G8MCvKTF0 wkkRL1ljiGkxLj9ojbuyRxAP/Cu7bCOET7L6JjdEvuww7NHpL/BKg+vGc/7tj0Fa G2wX+5zmNzTlW3AVTPWBnyWgE4q/nypFchmQ577fRfcpBMs6Ulg0POsGmllH47Ki 4AyzLdZJb1yDOPSke4ViDzgEnNvB8iG4n32TEY+X5opwHFDbhLwrKpZpXHUigMVh DaWgZH/cigAu8bIohsgwVOQ+ZKIFBBY5v6usOV5DK9KtJkPUN9Hhpg== =OFFz -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Fri Feb 20 14:31:41 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 20 Feb 2009 15:31:41 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> Message-ID: <72633800-4C93-4465-849F-45E2D85D467D@NLnetLabs.nl> Although I will most probably (plane leave later than I thought) not attend... here is one suggestion for an explicit question and a suggestion for an answer to a question On 20 feb 2009, at 15:15, Rickard Bondesson wrote: > 4. Discussion about each component > - - What has been done since last time? > - - What to be done in the nearest future? > - - How much time is needed? - - What are potential blocking factors and/or dependencies? > > 8. DS to parent > - - How should we transport the DS to the parent? As a key, or at least allow transport as a key. I still believe Registries should keep record of the keys so that they can use a database operation (and not need to query X million keys) when a DS hash algorithm role is needed. --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 joao at shuttle.c-l-i.net Fri Feb 20 14:35:36 2009 From: joao at shuttle.c-l-i.net (Joao Damas) Date: Fri, 20 Feb 2009 14:35:36 +0000 (GMT) Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <72633800-4C93-4465-849F-45E2D85D467D@NLnetLabs.nl> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> <72633800-4C93-4465-849F-45E2D85D467D@NLnetLabs.nl> Message-ID: On Fri, 20 Feb 2009, Olaf Kolkman wrote: > As a key, or at least allow transport as a key. > > I still believe Registries should keep record of the keys so that they can > use a database operation (and not need to query X million keys) when a DS > hash algorithm role is needed. > I agree with Olaf. In addition, a DS is a digest and there can be many DS records for the same key. The key is the important component. Joao From jakob at kirei.se Fri Feb 20 16:35:43 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 20 Feb 2009 17:35:43 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer Message-ID: John, Jelte and myself now has a proposal ready for the interface between the enforcer and signer. http://www.opendnssec.se/wiki/Signer/Configuration http://www.opendnssec.se/browser/docs/signconf.xml http://www.opendnssec.se/browser/docs/zonelist.xml also a draft of the KASP XML format in: http://www.opendnssec.se/browser/docs/kasp.xml have a nice weekend! jakob From rickard.bondesson at iis.se Mon Feb 23 08:44:39 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 23 Feb 2009 09:44:39 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Updates on the agenda: *************** 1. Who will write minutes? 2. Use cases - - The wiki has been updated 3. Updates on the API between the Enforcer and Signer Engine 4. Discussion about each component - - What has been done since last time? - - What to be done in the nearest future? - - How much time is needed? - - What are potential blocking factors and/or dependencies? 5. DNSSEC Signer - - How should we test and integrate the different components for version 1? 6. Project requirements - - Are we missing any requirements? - - Do we need to update the requirements to be able to do the system tests? - - Who will make the updates? 7. HSM buyer?s guide - - What should the HSM buyer?s guide include? 8. Transport trust-anchor/secure-entry-point to the parent - - How should we inform the parent of the trust-anchor/secure-entry-point? 9. Next meeting ************** Call in to: sip:conference at NLnetLabs.nl the pin number is 5227# (Jelte needs to verify this) If you don't have a sip phone or client available, the room should also be available at +31 20 7508314 extension 263 (just dial 263 when olaf's recorded voice starts talking) // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaJh9+CjgaNTdVjaAQgD0Af/XPOzQSaHCGcFsPWD0jnXfRtN/35sQxA3 H7mJFeHV1k8cAPjXKCGkAc7lut3RtBFudbT8I9+k+NncXSanuJ/Mp1+EZZ12VWN0 YrFnO4KsUKMSoInyCd7yYPUY04fXtzSzaZz6O5BaHHpUNjkOhl8QszSyfUN7v2jk tBOxnwIbPzGwdC+q1rBjVx7GGZ9Hqd0iyIO1zuzBqfnda0nzymmmx68jvZpZUX4b uzOmMnyZJ4E2As45iAzRiyohyiiPcG6D7AK/v08yqPrhlbMHzwbMgPZvqFTqIx+j RpSOxyY0nNj3cXFy1CKYhuJzzhy3t+YWmjY6GnCO95JILeBybe2XTw== =IU7+ -----END PGP SIGNATURE----- From roy at nominet.org.uk Mon Feb 23 08:58:38 2009 From: roy at nominet.org.uk (Roy Arends) Date: Mon, 23 Feb 2009 09:58:38 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> Message-ID: Rickard Bondesson wrote on 02/23/2009 09:44:39 AM: > Call in to: > > sip:conference at NLnetLabs.nl > the pin number is 5227# (Jelte needs to verify this) > > If you don't have a sip phone or client available, the room > should also be available at +31 20 7508314 extension 263 > (just dial 263 when olaf's recorded voice starts talking) What time? Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Mon Feb 23 09:05:51 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Feb 2009 10:05:51 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: References: Message-ID: On 20 feb 2009, at 17.35, Jakob Schlyter wrote: > John, Jelte and myself now has a proposal ready for the interface > between the enforcer and signer. > > http://www.opendnssec.se/wiki/Signer/Configuration > http://www.opendnssec.se/browser/docs/signconf.xml > http://www.opendnssec.se/browser/docs/zonelist.xml > > also a draft of the KASP XML format in: > > http://www.opendnssec.se/browser/docs/kasp.xml btw, I'll write RelaxNG or some other formal schema definition as soon as we've agreed on the examples. jakob From rickard.bondesson at iis.se Mon Feb 23 09:03:55 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 23 Feb 2009 10:03:55 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se><69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880C0A4@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > What time? Monday 23rd Feb 14:00-15:00 CET -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaJme+CjgaNTdVjaAQgLPQf/ZEtkow4vbMJ3GgEbmkWLuLxOmZ0EwtHa uysCby0645ZFmnmlCTqFoV31qA+oaYwOWdNztvg7S+/kWhtu7PSjsIZldxgP3gc1 tdgRm/fLWzw2CsONfUqFvaUDO68TTTXBWYPRkHZUuEAEbtXs/eb1NdyuBFCtE6dd Wwi1izGNG+TF7k9PaIUPO+uc9c2urKEt3Q9L77twAeL79dIBuZWMfsi1qFDC1LvO S3SxiiMbcISitcjCYkt6gE00xXDp+N0ect30OC95RcJlsH6TgNOuIxjqPU7Xd362 sXzbfUApSlzRCWacLyRLKvjrcBzS8xxZLplFa4hP/rIxegdn++ZvsA== =u9zw -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Mon Feb 23 09:13:06 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 23 Feb 2009 09:13:06 +0000 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> Message-ID: <173114bc0902230113p656383e1t97eecffb9e8f02ec@mail.gmail.com> 2009/2/23 Rickard Bondesson : > ************** > > Call in to: > > sip:conference at NLnetLabs.nl > the pin number is 5227# (Jelte needs to verify this) > > If you don't have a sip phone or client available, the room > should also be available at +31 20 7508314 extension 263 > (just dial 263 when olaf's recorded voice starts talking) > Stephen, you said once that Nominet could provide a conferencing service with local call in numbers in various countries. Is that available? Thanks John From roy at nominet.org.uk Mon Feb 23 09:19:41 2009 From: roy at nominet.org.uk (Roy Arends) Date: Mon, 23 Feb 2009 10:19:41 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <173114bc0902230113p656383e1t97eecffb9e8f02ec@mail.gmail.com> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> <173114bc0902230113p656383e1t97eecffb9e8f02ec@mail.gmail.com> Message-ID: John Dickinson wrote on 02/23/2009 10:13:06 AM: > 2009/2/23 Rickard Bondesson : > > ************** > > > > Call in to: > > > > sip:conference at NLnetLabs.nl > > the pin number is 5227# (Jelte needs to verify this) > > > > If you don't have a sip phone or client available, the room > > should also be available at +31 20 7508314 extension 263 > > (just dial 263 when olaf's recorded voice starts talking) > > > > Stephen, you said once that Nominet could provide a conferencing > service with local call in numbers in various countries. Is that > available? It is. I'll talk to Rickard. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bondesson at iis.se Mon Feb 23 09:38:40 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 23 Feb 2009 10:38:40 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880C0B6@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Monday 23rd Feb 14:00-15:00 CET Please call in to the conferencing service provided by Nominet. No SIP is available. These are the international phone numbers: UK 08702407821 UK toll free 08081005145 SE 0858536827 SE toll free 0200110476 NL 0202013852 NL toll free 08000223422 Contact Roy if you want numbers in other countries. The passcode for the participants is: 4227104 ********************** 1. Who will write minutes? 2. Use cases - - The wiki has been updated 3. Updates on the API between the Enforcer and Signer Engine 4. Discussion about each component - - What has been done since last time? - - What to be done in the nearest future? - - How much time is needed? - - What are potential blocking factors and/or dependencies? 5. DNSSEC Signer - - How should we test and integrate the different components for version 1? 6. Project requirements - - Are we missing any requirements? - - Do we need to update the requirements to be able to do the system tests? - - Who will make the updates? 7. HSM buyer?s guide - - What should the HSM buyer?s guide include? 8. Transport trust-anchor/secure-entry-point to the parent - - How should we inform the parent of the trust-anchor/secure-entry-point? 9. Next meeting *********************** // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaJuoOCjgaNTdVjaAQgpSggAp1kNh5kSLxVRP4+AyjmSSs9+tZaz0GkP prv2B1mpAmm5mkYFlBpEDZ6Wf3k7pIjbMvd3RobWmsZhQrfDvx5f1NPWZj2X5y11 5cD17EMCbPe1aspF9Dx30wHHBiA0rwZf8bsWVhnUAJQJY/ytqcADan8pVCnI4mM4 bl0c0bspt8+BRR5QWGB6mfbeg/oBnJolOzuC9c6cgJzJol8T88Aeup25eOWholn4 jZw72DczqKF7YHGtT2aor1q7FPqfOIvZQ6PAMiPBRpIxpiBPArxm/iTAVJS8wF8v pEIpaTgVpUmvDj5MJFkLgFXfOqAhZGXEVqIADbZmgwNVMRsGM2tznw== =stFl -----END PGP SIGNATURE----- From roy at nominet.org.uk Mon Feb 23 12:54:51 2009 From: roy at nominet.org.uk (Roy Arends) Date: Mon, 23 Feb 2009 13:54:51 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880C0B6@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C0B6@EXCHANGE.office.nic.se> Message-ID: Apologies, but I will have to miss todays meeting. Roy opendnssec-develop-bounces at lists.opendnssec.org wrote on 02/23/2009 10:38:40 AM: > "Rickard Bondesson" > Sent by: opendnssec-develop-bounces at lists.opendnssec.org > > 02/23/2009 10:38 AM > > To > > "Rickard Bondesson" , develop at lists.opendnssec.org> > > cc > > Subject > > [Opendnssec-develop] Telephone meeting 23rd Feb > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Monday 23rd Feb 14:00-15:00 CET > > Please call in to the conferencing service provided by Nominet. No > SIP is available. > > These are the international phone numbers: > > UK 08702407821 > UK toll free 08081005145 > SE 0858536827 > SE toll free 0200110476 > NL 0202013852 > NL toll free 08000223422 > > Contact Roy if you want numbers in other countries. > > The passcode for the participants is: 4227104 > > ********************** > > 1. Who will write minutes? > > 2. Use cases > - - The wiki has been updated > > 3. Updates on the API between the Enforcer and Signer Engine > > 4. Discussion about each component > - - What has been done since last time? > - - What to be done in the nearest future? > - - How much time is needed? > - - What are potential blocking factors and/or dependencies? > > 5. DNSSEC Signer > - - How should we test and integrate the different components for version 1? > > 6. Project requirements > - - Are we missing any requirements? > - - Do we need to update the requirements to be able to do the system tests? > - - Who will make the updates? > > 7. HSM buyer?s guide > - - What should the HSM buyer?s guide include? > > 8. Transport trust-anchor/secure-entry-point to the parent > - - How should we inform the parent of the trust-anchor/secure-entry-point? > > 9. Next meeting > > *********************** > > // Rickard > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSaJuoOCjgaNTdVjaAQgpSggAp1kNh5kSLxVRP4+AyjmSSs9+tZaz0GkP > prv2B1mpAmm5mkYFlBpEDZ6Wf3k7pIjbMvd3RobWmsZhQrfDvx5f1NPWZj2X5y11 > 5cD17EMCbPe1aspF9Dx30wHHBiA0rwZf8bsWVhnUAJQJY/ytqcADan8pVCnI4mM4 > bl0c0bspt8+BRR5QWGB6mfbeg/oBnJolOzuC9c6cgJzJol8T88Aeup25eOWholn4 > jZw72DczqKF7YHGtT2aor1q7FPqfOIvZQ6PAMiPBRpIxpiBPArxm/iTAVJS8wF8v > pEIpaTgVpUmvDj5MJFkLgFXfOqAhZGXEVqIADbZmgwNVMRsGM2tznw== > =stFl > -----END PGP SIGNATURE----- > > > _______________________________________________ > 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 jakob at kirei.se Mon Feb 23 13:01:37 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Feb 2009 14:01:37 +0100 Subject: [Opendnssec-develop] Telephone meeting 23rd Feb In-Reply-To: <69830D4127201D4EBD146B904119971880C0B6@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880BF56@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C054@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C098@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880C0B6@EXCHANGE.office.nic.se> Message-ID: <0F13B41F-4ADD-436A-9116-2C76B388F5F1@kirei.se> xmpp:opendnssec at conference.kirei.se if people like to join. jakob From jad at jadickinson.co.uk Mon Feb 23 13:26:05 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 23 Feb 2009 13:26:05 +0000 Subject: [Opendnssec-develop] draft of document describing the enforcer Message-ID: <761A0E96-0657-408A-A041-0D9FDEAD23BE@jadickinson.co.uk> Thoughts? --- John Dickinson http://www.jadickinson.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: Enforcer-use-cases-and-other-stuff.pdf Type: application/pdf Size: 477699 bytes Desc: not available URL: From jakob at kirei.se Mon Feb 23 14:55:08 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Feb 2009 15:55:08 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: References: Message-ID: On 23 feb 2009, at 10.05, Jakob Schlyter wrote: > btw, I'll write RelaxNG or some other formal schema definition as > soon as we've agreed on the examples. a set of draft schemas are now available at http://www.opendnssec.se/browser/docs/xml . jakob From rickard.bondesson at iis.se Mon Feb 23 15:12:33 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 23 Feb 2009 16:12:33 +0100 Subject: [Opendnssec-develop] draft of document describing the enforcer In-Reply-To: <761A0E96-0657-408A-A041-0D9FDEAD23BE@jadickinson.co.uk> References: <761A0E96-0657-408A-A041-0D9FDEAD23BE@jadickinson.co.uk> Message-ID: <69830D4127201D4EBD146B904119971880C117@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Thoughts? 9.2 KASP TABLE * First "ZSK | ZSK key size" in the table should be "KSK | KSK key size". * The policy for key creation: "0=fill the hsm", is this a good option? Thinking that this will exhaust the memory and harddisk space for SoftHSM. Or is this linked to "capacity" under 10.8? 10.7 * Does this assumption make it unpossible to have any DNSSEC signatures / keys in the incomming zone? *.* * Missing information about emergency key rollovers -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaK84eCjgaNTdVjaAQgy+wf6AnbXSVyWaVEXdPp53C/YqZuQBq0HjWpT /en+RpajOVhBsVmiideWwuBcnjsGWs0rGPQG1gWxxYzFfc6JW/QLv529KsMDTKC6 UmhqUEGXQ0v6hJaSJSNETL+sRhayrEz6uJ88AN/+eb+012SPSc2FzWpc67h2EheM pw6YpJ/rnXCqDqAImbqGsPEQNhEaHjpbd2JOQHFUctgqUgVOYZhDFHV/pICX3xbe ZQPE0zRE6VWBXasAY24J35NLPGxRAtFSE2eTGmEzn3oiKCR+IiwvpS5sOyiJUQ/M zMW2pI0Xvia0hdgCmO2Li6sVZPZ4XljO3wggMUQM/ZISx6nmy6F0/Q== =jG1J -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Mon Feb 23 15:23:55 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Mon, 23 Feb 2009 16:23:55 +0100 Subject: [Opendnssec-develop] draft of document describing the enforcer In-Reply-To: <761A0E96-0657-408A-A041-0D9FDEAD23BE@jadickinson.co.uk> References: <761A0E96-0657-408A-A041-0D9FDEAD23BE@jadickinson.co.uk> Message-ID: <69830D4127201D4EBD146B904119971880C11B@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Thoughts? Some more thoughts: 10.11 Key creation * C_DigestKey can only be used on secret keys, thus not applicable on asymmetric keys such as RSA key pairs. C_DigestKey digest the value of the key, but a RSA key does not have the CKA_VALUE attribute as secret keys do. pkcs11-tool also assume that the CKA_VALUE exists for RSA objects, but I can not find that anywhere in the PKCS#11. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaK/i+CjgaNTdVjaAQik9gf/SXh+MmC+PLuMx83L5jq5lKTPqPYcOab/ Czc+8Xc8oYXhaurNgnfa/6qsISdCAfxUR68W0S34bRVD+gIPsQQQusoCOOTqucNX BIbkkDEnzBwbQSCxPJm5m6wdhuNqJI3/XuPiJBfUoVa5E5WiVxKqrxmPh4SiTl7o zJgJ23C/JzfNy/LNO8ukmbImHcc0FDvrcqC0t14hOo2wtSV6CkL3gqtKdDuXaOZ3 k1w+P3KyK3VL1q0C2Gm+rfZ3h94xO/A9fyU8Oup72PpG3UrMrsjgujhKSW5SJ0v9 aq9p0KRZvsYwfoTFVaFtp1zJfD3qerKpkQGmYdFbfcYa9Pw4duIKPw== =GTul -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Mon Feb 23 16:41:24 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 23 Feb 2009 16:41:24 +0000 Subject: [Opendnssec-develop] Fwd: [keihatsu.kirei.se/svn/dnssec] r193 - docs References: <20090223163759.AC21464C0D@mail.kirei.se> Message-ID: Begin forwarded message: > From: "John Dickinson" > Date: 23 February 2009 16:37:59 GMT > To: dnssec-svn at kirei.se > Subject: [keihatsu.kirei.se/svn/dnssec] r193 - docs > > Author: jad > Date: 2009-02-23 17:37:59 +0100 (Mon, 23 Feb 2009) > New Revision: 193 > > Added: > docs/draft-opendnssec-terms.odt > docs/draft-opendnssec-terms.pdf > Log: > Added comparison of draft and opendnssec terms I started adding a table comparing the terms in the draft Stephen and I wrote and those used in the xml in OpenDNSSEC. I suspect we need more terms in OpenDNSSEC but I will give it some more thought tomorrow. John --- John Dickinson http://www.jadickinson.co.uk From rick at openfortress.nl Mon Feb 23 17:47:10 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 23 Feb 2009 17:47:10 +0000 Subject: [Opendnssec-develop] Minutes 2009-02-23 (phone meeting) Message-ID: <20090223174710.GA22412@phantom.vanrein.org> Hello, Here are the notes of this afternoon's phone discussion. Any comments, please let me know before I put them on the Wiki. Cheers, -Rick ------- 8< ------- 8< ------- 8< ------- 8< ------- 8< ------- Notes of the OpenDNSSEC phone meeting on 2009-02-23 =================================================== Present: Jakob, Jelte, John, Rick, Rickard. Not present with notification: Matthijs, Olaf, Roland, Roy. 1. Who will write minutes? Rick will. 2. Use cases Stephen updated the Use Cases and published them on the Wiki. These cover only phase 1, and he is asking whether to go ahead with phase 2 as well. We decide to focus on phase 1 for now and do the work towards phase 2 later. 3. Updates on the API between the Enforcer and Signer Engine There is good progress in the XML specifications that define the interface between these two components. Issues covered include * import data into the KASP, and getting it into the database * a text format for the strings that identify keys in the repository * utilities that enable the Signer Engine to scan through the key set The designers believe that they have covered all the issues that enable the coding at both ends to commence. Jakob offered to formalise the schema using RelaxNG. He explains that this would formalise the syntax only; what RelaxNG adds with respect to DTD or XML Schema is that it is readable to humans. 4. Discussion about each component KASP and KASP Enforcer: The internal database is moving from an old to a new schema, and that is currently taking some effort. Support for XML has been started on. An internal component called KSM is the one that will do the key rollover; a document including the algorithms for such key rollover has been posted, and the authors are actively seeking feedback on it. Stephen and John will add their time estimates to the Wiki. Signing Engine: Jelte is working on v1, while Matthijs prepares for v2. The engine has been updated to a queue-based architecture, which is intended to make it scale up without bounds. It won't sign 5000 zones a minute, but it can keep 5000 zones signed at a normal pace. Jelte estimates that this work will be finished in about 2 weeks, to a level where it is ready for integration. SoftHSM: Rickard has made internal changes: slots can now be configures out-of-band, as discussed during the previous meeting, and each slot contains one token for one user. The speed of the system is not impaired by this change; it creates 6158 signatures a second, compared to 8300 for OpenSSL on the same 64-bit configuration. Rickard wants to take some time to overlook the design, run test cases and have it reviewed. This will easily be done before phase 1 is complete, so it should not introduce any locking problems. 5. DNSSEC Signer We agree that it is ideal if we can test components in isolation, challenging them with "funny" usage patterns, so that the integration should not introduce many novel problems. This ought to be possible because all component interfaces are known (PKCS #11, an XML format) and so are the interaction patterns. Stephen requests that someone draw up a diagram similar to a UML package diagram to work out the architecture in a bit more detail. Rickard volunteers. Rickard will also set up guidelines that detail all the thiings that are needed for phase 1. 6. Project requirements Stephen and Rick are working on these; Rick hasn't done much because he was ill since last meeting, but Stephen has written an initial document, for which he actively requests feedback. The requirements (also from last meeting) will be brought onto the Wiki by Stephen and Rick, and the intention is to make them suitable for deriving tests from. 7. HSM-buyers guide Without Roland present at the meeting, we cannot come to conclusions on this point. 8. Transport trust-anchor/secure-entry-point to the parent There are no standards for transporting new signing keys to the parent; the KASP Enforcer will log it over syslog. We discuss a few other mechanisms (email, syslog NG, shell script, HTTP POST) and Jelte envisions an adapter into which an admin's favourite could be plugged. We will defer this disucssion until v2 or later. 8.1/2. Other parties (extra topic) Afilias has recently contacted NLnet Labs about OpenDNSSEC. They may have something to contribute, and say that they have special requirements. NLnet Labs will see them, and gather requirements that may influence our thinking about the project. We are not looking for extra partners at this time, and will not promise them anything more than using their requirements as an inspiration that we may choose to add. The rationale behind this is that we do not want to slow down the project with late requirement entries. ISC is interested in OpenDNSSEC as well, and for bind 9.7 they are looking into something similar to the KASP. We see no harm in sharing our work with them, but at the same time we would not mind if two independent DNSSEC signers would co-exist in the open source realm; this can be a great asset in times when one of these fails. Secure64 also shows interest in OpenDNSSEC, but this may be due to an interest in alternatives moving on the DNSSEC market. 9. Next meeting We will meet on the phone again in 2 weeks from now, on Monday the 9th of March, 14:00 to 15:00 CET. From rick at openfortress.nl Tue Feb 24 10:11:38 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 24 Feb 2009 10:11:38 +0000 Subject: [Opendnssec-develop] Key removal In-Reply-To: <499D6293.3000609@nlnetlabs.nl> References: <44081CD9-7DCB-484C-943F-A2F7E2908710@jadickinson.co.uk> <499D6293.3000609@nlnetlabs.nl> Message-ID: <20090224101138.GC2426@phantom.vanrein.org> Hello, > I say if there are any signatures remaining from an old key, you have > (at least) two choices: > * Remove all signatures corresponding to the old key. > * Keep these signatures until its lifetime exceeded and they still > validate. I see a third option: * Keep these signatures until timing parameters of DNS establish that no cache can hold those signatures. This assumes that some parties could have cached the old key and have not felt a need to upgrade, but for newly accessed parts of a zone they would still fetch new records with new signatures. Cheers, -Rick From rick at openfortress.nl Tue Feb 24 11:13:27 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 24 Feb 2009 11:13:27 +0000 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: References: Message-ID: <20090224111327.GD2426@phantom.vanrein.org> Hello Jacob, > John, Jelte and myself now has a proposal ready for the interface > between the enforcer and signer. I've had a look. Thanks for creating these docs, they look good. > http://www.opendnssec.se/wiki/Signer/Configuration Can you indicate _between_ which components these formats are sent, instead of just _to_ which one it is sent? > http://www.opendnssec.se/browser/docs/signconf.xml Perhaps rename to as people tend to do in plain English to avoid confusion? It is not clear yet what PT2H means, and how it differs from 2H. Similarly for P3D, P7D, P14D, PT12H, PT300S. Do I read from the element that SOA parameters are decided upon by the KASP/Enforcer? In the you refer to and and values by numbers. These clearly depend on some external register of definitions. Please make clear where these are defined, so software builders know where to look. It is always good to define what happens in case an unknown bit is encountered. There's double information in this setup: 1. versus 2. bit 0 What rules dictate consistency, what happens if there is a failure, and is it the best course of action to have such double specs? As for the timing constants, what relationships do they have, and is it possible to trick the system into, say, a dropped domain if it gets confused with contradicting information? If I recall well (but I am not 100% sure) the allowed for partial opt-outs in the zone list. I am not convinced this would be practically usable to have part of a zone opted in and part of it opted out. If it could be useful, this interface description should _consider_ taking it into account. (This is a weak point, just trying to provoke thought.) For subdomains an opt-out may be really useful, say for dyn.harderwijk.edu which would hold the DHCP-assigned IPs within this University. > http://www.opendnssec.se/browser/docs/zonelist.xml I would not be surprised if we'll need for more than one thing; perhaps adding a parameter could help. Just a thought. It would certainly give a somewhat stronger suggestion as to its semantics. > also a draft of the KASP XML format in: > > http://www.opendnssec.se/browser/docs/kasp.xml Similar remarks to the ones above: - time prefixed P and PT - and - should be linked to its spot of definition - maybe over partial domains? Additionally, -> what does that mean? -> perhaps rename it to or -> I think it is generally good to distinguish between generating and accepting this standard, as it is somewhat controversial material and may be replaced with an alternative some day. But the only utility of RFC 5011 in this spec would be generating, right? I hope these remarks / questions are helpful. Cheers, -Rick From rick at openfortress.nl Tue Feb 24 11:32:07 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 24 Feb 2009 11:32:07 +0000 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: References: Message-ID: <20090224113207.GE2426@phantom.vanrein.org> Hello, > a set of draft schemas are now available at > http://www.opendnssec.se/browser/docs/xml . In addition to my remarks on the instance files: kasp / policy / denial / nsec | nsec3 Strictly speaking, a party could decide to support both. For instance while moving away from one and going to the other. Similarly, multiple nsec-chains and/or multiple nsec3-chains could co-exist. Would those setups be represented by different policies? kasp / zone / policy Should a zone not be able to move from one policy to another? And as a result, should there not be an old and new policy? Several of these remarks may turn out to be unfashionable for v1. One remark is not, and that's the general problem of XML: it only defines syntax. Several of my questions relate to semantics, or how to interpret the values described by the XML syntax. It could be very helpful to annotate as much as possible of the intended use of each data element, either in a separate text or in comments alongside each element/attribute. In writing them, please try to misinterpret the data in as many ways as possible, and try to write with a clarity that avoids such misinterpretations. Note that several of my comments can be ranked as possible mis-interpretations, or in other words, as calls for such semantics clarifications in text. I hope .rnc can incorporate such comments, because I like the format _much_ better than either DTD or XML Schema -- that is, there does not seem to be a way to read these formats falsely, given a bit of eperience with regexps. A good find! What tools do you use to process RNC files into XML Schema and/or DTD? Cheers, -Rick From jad at jadickinson.co.uk Tue Feb 24 11:42:21 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Tue, 24 Feb 2009 11:42:21 +0000 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: <20090224111327.GD2426@phantom.vanrein.org> References: <20090224111327.GD2426@phantom.vanrein.org> Message-ID: <5BC95463-D2D7-4934-9533-FCAC8757AAF8@jadickinson.co.uk> On 24 Feb 2009, at 11:13, Rick van Rein wrote: > Hello Jacob, > >> John, Jelte and myself now has a proposal ready for the interface >> between the enforcer and signer. > > I've had a look. Thanks for creating these docs, they look good. > >> http://www.opendnssec.se/wiki/Signer/Configuration > > Can you indicate _between_ which components these formats are sent, > instead of just _to_ which one it is sent? > >> http://www.opendnssec.se/browser/docs/signconf.xml > > Perhaps rename to as people tend to do in > plain English to avoid confusion? > > It is not clear yet what PT2H means, and how it differs from 2H. > Similarly for P3D, P7D, P14D, PT12H, PT300S. Do I read from the > element that SOA parameters are decided upon by > the KASP/Enforcer? PT2H and friends are defined here http://www.w3schools.com/Schema/schema_dtypes_date.asp The Enforcer needs to know the SOA parameters in order to correctly calculate key rollover. I think it is best if the signer ensures that the signed zone uses parameters that the Enforcer expects. Of course, it would be nice if there was a link between the registry system that builds the un-signed zone and the KASP DB as well. > > > In the you refer to and and > values by numbers. These clearly depend on some > external register of definitions. Please make clear where these > are defined, so software builders know where to look. It is always > good to define what happens in case an unknown bit is encountered. > > There's double information in this setup: > 1. versus > 2. bit 0 > What rules dictate consistency, what happens if there is a failure, > and is it the best course of action to have such double specs? I don't understand what you mean by double specs. > > > As for the timing constants, what relationships do they have, and > is it possible to trick the system into, say, a dropped domain if > it gets confused with contradicting information? I don't think so. But we do need to define what makes the parameters consistent and valid. This is on the Enforcer todo list. > > > If I recall well (but I am not 100% sure) the allowed > for partial opt-outs in the zone list. I am not convinced this Partial opt outs are bad and would make dynamic updates impossible. Lets just not go there. > > would be practically usable to have part of a zone opted in and > part of it opted out. If it could be useful, this interface > description should _consider_ taking it into account. (This is > a weak point, just trying to provoke thought.) For subdomains > an opt-out may be really useful, say for dyn.harderwijk.edu > which would hold the DHCP-assigned IPs within this University. > >> http://www.opendnssec.se/browser/docs/zonelist.xml > > I would not be surprised if we'll need for more than > one thing; perhaps adding a parameter could help. Just a thought. > It would certainly give a somewhat stronger suggestion as to its > semantics. The timestamp allows the signer to know if it needs to re-read the signer config for that zone. So the signer can scan the minimal zone list and only read the policy in the signer config when necessary. Hopefully this will scale better than having all zones in one big xml doc. > > >> also a draft of the KASP XML format in: >> >> http://www.opendnssec.se/browser/docs/kasp.xml > > Similar remarks to the ones above: > - time prefixed P and PT > - and > - should be linked to its spot of definition > - maybe over partial domains? > > Additionally, > > -> what does that mean? This is being written up - see http://www.opendnssec.se/browser/docs/draft-opendnssec-terms.pdf > > > -> perhaps rename it to or length is the term used in RFC5155 > > > -> I think it is generally good to distinguish between > generating and accepting this standard, as it is somewhat > controversial material and may be replaced with an alternative > some day. But the only utility of RFC 5011 in this spec would > be generating, right? I don't remember anything about 5011 off the top of my head, I keep reading it and always forget it totally - My understanding is that this is more a flag that will be used in a future version of OpenDNSSEC - possibly with additional parameters defined. > > > I hope these remarks / questions are helpful. Yes, thanks John --- John Dickinson http://www.jadickinson.co.uk From jad at jadickinson.co.uk Tue Feb 24 11:56:28 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Tue, 24 Feb 2009 11:56:28 +0000 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: <20090224113207.GE2426@phantom.vanrein.org> References: <20090224113207.GE2426@phantom.vanrein.org> Message-ID: On 24 Feb 2009, at 11:32, Rick van Rein wrote: > Hello, > >> a set of draft schemas are now available at >> http://www.opendnssec.se/browser/docs/xml . > > In addition to my remarks on the instance files: > > kasp / policy / denial / nsec | nsec3 > Strictly speaking, a party could decide to support both. > For instance while moving away from one and going to the other. > Similarly, multiple nsec-chains and/or multiple nsec3-chains > could co-exist. > Would those setups be represented by different policies? The signer can do the switch once the new chain is complete. > > > kasp / zone / policy > Should a zone not be able to move from one policy to another? > And as a result, should there not be an old and new policy? There is only the current, to be used from now on policy. The signer must ensure that existing signatures and nsec chains don't break while implementing the current policy no matter how different the current policy is from the one moments before. I will admit this may be ambitious - Jelte does this scare you? Do we need any additional info? > > > > Several of these remarks may turn out to be unfashionable for v1. > > One remark is not, and that's the general problem of XML: it only > defines syntax. Several of my questions relate to semantics, or how > to interpret the values described by the XML syntax. It could be > very helpful to annotate as much as possible of the intended use > of each data element, either in a separate text or in comments > alongside each element/attribute. In writing them, please try to > misinterpret the data in as many ways as possible, and try to write > with a clarity that avoids such misinterpretations. Note that several > of my comments can be ranked as possible mis-interpretations, or in > other words, as calls for such semantics clarifications in text. Hopefully, this is begin covered by linking KASP to the draft that Stephen and I wrote. > > > I hope .rnc can incorporate such comments, because I like the format > _much_ better than either DTD or XML Schema -- that is, there does not > seem to be a way to read these formats falsely, given a bit of > eperience with regexps. A good find! What tools do you use to > process > RNC files into XML Schema and/or DTD? I don't think you actually have to go to XML Schema. e.g. libxml2 will do relax-ng validation directly I think - http://xmlsoft.org/html/libxml-relaxng.html#xmlRelaxNGValidateDoc John --- John Dickinson http://www.jadickinson.co.uk From jakob at kirei.se Tue Feb 24 12:56:12 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 24 Feb 2009 13:56:12 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: <20090224113207.GE2426@phantom.vanrein.org> References: <20090224113207.GE2426@phantom.vanrein.org> Message-ID: On 24 feb 2009, at 12.32, Rick van Rein wrote: > I hope .rnc can incorporate such comments, because I like the format > _much_ better than either DTD or XML Schema -- that is, there does not > seem to be a way to read these formats falsely, given a bit of > eperience with regexps. A good find! What tools do you use to > process > RNC files into XML Schema and/or DTD? you can convert RNC (RelaxNG Compact) to RNG (RelaxNG), XML Schema and/ or DTD using Trang (http://code.google.com/p/jing-trang/). jakob From rickard.bondesson at iis.se Wed Feb 25 08:25:56 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 25 Feb 2009 09:25:56 +0100 Subject: [Opendnssec-develop] Newsletter #3 Message-ID: <69830D4127201D4EBD146B904119971896C24A@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Here is the news from the two latest weeks: ******************************************* * The project Use cases for phase 1 are published on the wiki. Phase 2 will be documented later. Phase 1 is scheduled to be finished in the beginning of April. Each component should be finished within a couple of weeks. The integration of the components is to be planned by Rickard and then presented to the group. We are noting attention from other vendors and customers. And we agreed upon focusing on our own goals primarily to be able to produce phase 1 and 2. Any requirements or request by other parties might be taken in to consideration, but we are not looking for extra partners at this time. SURFnet has released a white paper on DNSSEC (but not as a part of this project). http://www.surfnet.nl/Documents/DNSSSEC-web.pdf * Meetings We had a telephone meeting on the 23rd of February. Minutes will be published on the wiki. Next telephone meeting is on Monday the 9th of March, 14:00-15:00 CET. * API The API between the KASP Enforcer and the Signer Engine has been agreed upon. A more detailed version will be explained by using RelaxNG. * KSM and KASP Enforcer A RFC draft on DNSSEC Key Timing Consideration has been published by Stephen, Johan Ihren (not a member of this project), and John. http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-00 The authors are seeking feedback on it. This draft will be implemented in OpenDNSSEC. * Signer Engine The Engine has been updated with a new design. This new design gives improved scalability and performance. It won't sign 5000 zones a minute, but it can keep 5000 zones signed at a normal pace. * SoftHSM SoftHSM has also been updated with a new internal design. It now supports multiple tokens, where each has its own user. All private keys of the type private token objects are now encrypted when stored in the database. The signing performance has not been decreased because of this change. ******************************************* // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaUAlOCjgaNTdVjaAQj6TQf/cqw0hml6nYrCcgOttZdv8BAOTYe8+B5f ra2FGsPqMQl5jH1XGiWEL6CG8TgSFUZwFieVaFzrYMiFKOJ2ZIdwmU4w754RE5pJ Dz864cqpi7oiDjhpjEagSVpQ/nF9Rjkm3QLbGyT79ERF3leUN8fljOJ58IumYbRL z6Lvzp8k9ty9AgYTxJoVDvY5pSSMTCQlCElFP3YrG95w6grMqVISHmK2ekl2XDnX Vw8agQ6iNl1imPUWq5svYWLZrEJHk+Hp6Q89iYUb4sqoThHY568/3/e5wu0TqlrP De5WTH/42XQd01lVF9oe7cwPN4cEHYRxVvjUgUW2OX/U1PrwTDgnCA== =RjBf -----END PGP SIGNATURE----- From jakob at kirei.se Wed Feb 25 09:12:08 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 25 Feb 2009 10:12:08 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: <20090224113207.GE2426@phantom.vanrein.org> References: <20090224113207.GE2426@phantom.vanrein.org> Message-ID: On 24 feb 2009, at 12.32, Rick van Rein wrote: > One remark is not, and that's the general problem of XML: it only > defines syntax. Several of my questions relate to semantics, or how > to interpret the values described by the XML syntax. It could be > very helpful to annotate as much as possible of the intended use > of each data element, either in a separate text or in comments > alongside each element/attribute. I'll add comments to the RelaxNG files later this week jakob From jakob at kirei.se Wed Feb 25 09:18:21 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 25 Feb 2009 10:18:21 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: <20090224111327.GD2426@phantom.vanrein.org> References: <20090224111327.GD2426@phantom.vanrein.org> Message-ID: <514AB9C6-C4EF-44D3-869F-9D80436AF020@kirei.se> On 24 feb 2009, at 12.13, Rick van Rein wrote: > There's double information in this setup: > 1. versus > 2. bit 0 no, the flag indicates if a key is a Secure Entry Point, not if it is used to sign the DNSKEY RRset (which a KSK does). > I would not be surprised if we'll need for more than > one thing; perhaps adding a parameter could help. Just a thought. > It would certainly give a somewhat stronger suggestion as to its > semantics. yes, I'll look into this. jakob From jelte at NLnetLabs.nl Wed Feb 25 09:27:55 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 25 Feb 2009 10:27:55 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: <5BC95463-D2D7-4934-9533-FCAC8757AAF8@jadickinson.co.uk> References: <20090224111327.GD2426@phantom.vanrein.org> <5BC95463-D2D7-4934-9533-FCAC8757AAF8@jadickinson.co.uk> Message-ID: <49A50F1B.6030900@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Dickinson wrote: >> >> It is not clear yet what PT2H means, and how it differs from 2H. >> Similarly for P3D, P7D, P14D, PT12H, PT300S. Do I read from the >> element that SOA parameters are decided upon by >> the KASP/Enforcer? > > PT2H and friends are defined here > http://www.w3schools.com/Schema/schema_dtypes_date.asp > btw, for now, i'm interpreting month and year to be a wild guess at the number of seconds (they only have meaning in the context of a specific time). The right way to do this is to calculate the actual time to wait depending on the full datetime when it is needed. That is a todo. > The Enforcer needs to know the SOA parameters in order to correctly > calculate key rollover. I think it is best if the signer ensures that > the signed zone uses parameters that the Enforcer expects. Of course, it > would be nice if there was a link between the registry system that > builds the un-signed zone and the KASP DB as well. should we make an interface back so the kasp can query the engine for the soa of a zone? >> >> If I recall well (but I am not 100% sure) the allowed >> for partial opt-outs in the zone list. I am not convinced this > > Partial opt outs are bad and would make dynamic updates impossible. Lets > just not go there. > to leave the option open, we opted (heh) for just the element as opposed to something like yes, so if we decide we can actually do partial opt-out, the names to opt-out or not could be added as child elements. But as opt-out is performed in the 'nsec3-hash' namespace, in the end it will be pretty unpredictable what ranges in the 'normal' zone are opted-out, and that makes me wary of having partial optout. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmlDxsACgkQ4nZCKsdOncXsZQCeIbxDoFhUEe7GqgaNzqj6TzHj FxAAoKgkY253ftv2p6iZQGsUGN+U5yy+ =IzZG -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Wed Feb 25 09:33:14 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 25 Feb 2009 10:33:14 +0100 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: References: <20090224113207.GE2426@phantom.vanrein.org> Message-ID: <49A5105A.9070705@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > There is only the current, to be used from now on policy. The signer > must ensure that existing signatures and nsec chains don't break while > implementing the current policy no matter how different the current > policy is from the one moments before. I will admit this may be > ambitious - Jelte does this scare you? Do we need any additional info? > Yes it scares me, but so do a lot of the things we are trying to build here. I'm not sure whether we need additional info yet. I'm also not sure whether we shouldn't define specific ways in which policies must change and let the kasp 'roll' those from current to new with multiple steps if needed. But i don't think so, at the moment. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmlEFoACgkQ4nZCKsdOncWswQCdFJKTAJTfjIli9m9F3W1PnZFs QX8An02vtCimgOVRx1bGQX8RsNFl3IwU =wWhT -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Wed Feb 25 13:08:09 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 25 Feb 2009 14:08:09 +0100 Subject: [Opendnssec-develop] UML package diagram Message-ID: <69830D4127201D4EBD146B904119971896C288@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Stephen, is that similar to what you had in mind? http://www.opendnssec.se/wiki/Signer/Phase1/HowItWorks You requested a diagram similar to an UML package diagram, which describes the architecture for phase 1. There should also be a text describing the different control and dataflows. Perhaps adding some more flows to/from the KASP part in the picture? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaVCueCjgaNTdVjaAQjC8wf+LJsVXgHlKT53ELhwky4CVz6qJalO4scm VA8bMufUBBwdW+SGTjHuaAWbMcUHSXtdCVapY+oW6iJpu6J3kvCxXAYqWlYNc7Ko AYvJsMPPuGpyTgpZnxDUwxV8W5KbhDvO2ukMBT2WXZ23pPmjV7wHMQBoeJt9+u9M crigwZ7W39INRrAIe3vukpRmjMOX92ctDyJz6W1NmWMo+oqxBR3bzWHd2mPGE7LT p0Koe0oOPWoca/+s7wo5+dAVwWUEYeIx07wTKkaBmfJC4TErWOuKv06iGUyOKh8b iTkPkkDVGvvgVzEtEzulup8nrsb5PKIVGe+jOClhXZLHMXGhgAZE+Q== =zwYa -----END PGP SIGNATURE----- From rick at openfortress.nl Wed Feb 25 13:44:22 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 25 Feb 2009 13:44:22 +0000 Subject: [Opendnssec-develop] UML package diagram In-Reply-To: <69830D4127201D4EBD146B904119971896C288@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971896C288@EXCHANGE.office.nic.se> Message-ID: <20090225134422.GA19044@phantom.vanrein.org> Rickard, > Stephen, is that similar to what you had in mind? > > http://www.opendnssec.se/wiki/Signer/Phase1/HowItWorks This diagram brings a lot of clarity. I cautiously checked it to conform to my ideas (which is what I think these diagrams are there for) and I see a full match. Well done! -Rick From rick at openfortress.nl Wed Feb 25 13:47:09 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 25 Feb 2009 13:47:09 +0000 Subject: [Opendnssec-develop] Minutes -> Wiki? Message-ID: <20090225134709.GB19044@phantom.vanrein.org> Rickard, I got no feedback on the minutes I made. Is it helpful if I upload it to the Wiki? I cannot seem to find earlier entries. -Rick From rickard.bondesson at iis.se Wed Feb 25 13:54:55 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Wed, 25 Feb 2009 14:54:55 +0100 Subject: [Opendnssec-develop] Minutes -> Wiki? In-Reply-To: <20090225134709.GB19044@phantom.vanrein.org> References: <20090225134709.GB19044@phantom.vanrein.org> Message-ID: <69830D4127201D4EBD146B904119971896C299@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Is it helpful if I upload it to the Wiki? > I cannot seem to find earlier entries. I have now added your minutes to the wiki: http://www.opendnssec.se/wiki/Meetings/Minutes/2009-02-23 The minutes can be found by clicking on this on the first page: "Information about our meetings can be found here" // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaVNr+CjgaNTdVjaAQiWkAf/RHYSCnO7AWvYtAG6sXUDVbD1T6Q6z6jN IdvArfhzBQcJV4HIxGBxGE77k/SWePvEAtz5AnTE/1oGg+1AqrkzqOcyOU8usHVW WuAVJZltsyBVM9eLsOkhzqp4Lsd2CkDU0KxH38lpx5degS1SOOO4cuLHwfs3QdzJ Zl0vFlI6IL0zRA3Fk9m36gM1ywXPrIdDzTy5aQKlXjJyPY7amjoXWvmwMGaewKO6 LWcLSuQGuXNn46Qsi0zN2wn3KOo9gLmOwy9FmZnlifuTN7wT1x6YKjdjAkC9gmZl Oo2L+6ApeWkVt2/jxWTpARzWLC5ZsYhdQul4q/Q5VvWB6mJ2DRhwOQ== =qzlp -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Wed Feb 25 14:21:02 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 25 Feb 2009 14:21:02 +0000 Subject: [Opendnssec-develop] interface between enforcer and signer In-Reply-To: <514AB9C6-C4EF-44D3-869F-9D80436AF020@kirei.se> References: <20090224111327.GD2426@phantom.vanrein.org> <514AB9C6-C4EF-44D3-869F-9D80436AF020@kirei.se> Message-ID: <85A99ADA-F904-4256-A5A6-51CCCDDCAA50@jadickinson.co.uk> On 25 Feb 2009, at 09:18, Jakob Schlyter wrote: > On 24 feb 2009, at 12.13, Rick van Rein wrote: > >> There's double information in this setup: >> 1. versus >> 2. bit 0 > > no, the flag indicates if a key is a Secure Entry Point, not if it > is used to sign the DNSKEY RRset (which a KSK does). > >> I would not be surprised if we'll need for more than >> one thing; perhaps adding a parameter could help. Just a thought. >> It would certainly give a somewhat stronger suggestion as to its >> semantics. > > yes, I'll look into this. I suggest that we add an optional description attribute to all the elements in the KASP xml. The database already has description fields ready to accept this data and it would be useful in any future GUI. It should be easy to write a stylesheet to remove this attribute for those uses that do not require it. Jakob - I am altering the kasp.xml at the moment to make it consistent with the draft. I can alter the relax-ng as well. John --- John Dickinson http://www.jadickinson.co.uk From rickard.bondesson at iis.se Thu Feb 26 08:49:07 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 26 Feb 2009 09:49:07 +0100 Subject: [Opendnssec-develop] Finalizing phase 1 Message-ID: <69830D4127201D4EBD146B904119971896C2F1@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi This is my view on how we should finalize phase 1. http://www.opendnssec.se/wiki/Signer/Phase1/Finalizing There is no time plan or resources connected to this one yet. Any comments? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaZXg+CjgaNTdVjaAQhU8wf9Fuqn1XFfnedYu90I4zQHViuJDkY4UgrN UHaWNQxLXXfmFzHWAQh0GhNN1FDKgQcAYNnr7rt5TLWvkzSzh/wDkgQaf61ppido aHY8ENR0fgy5VfuEp1Dg2GhDvIrWqIkww3ccgxleK/UxM/q5THrl9ftpeubDTGcN GQOobUylxHTt87lRfUuv6EaZQEUz/bzZKTemsz+68lGqsVQm3xfx29YKIFamZj7r CFvL3WtXycBle66GoblPFIrH8StgWVfrxlgGvOop8cfstUDLZmT0shGMjm04P8ts saVt2mQxnASoUQt8qjVjPvONftt2MYUi6+EA/0ASJc3kZUsm9flGtA== =9LTn -----END PGP SIGNATURE----- From jakob at kirei.se Thu Feb 26 14:32:45 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 26 Feb 2009 15:32:45 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM Message-ID: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> greetings PKCS#11 friends, John and I was just discussing where to store non-policy data like the NSEC3 salt. would it be possible to store it as a blob in the HSM? would it be accessible just as the keys? jakob From rickard.bondesson at iis.se Thu Feb 26 14:42:03 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 26 Feb 2009 15:42:03 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM In-Reply-To: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> References: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971896C332@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > John and I was just discussing where to store non-policy data like the > NSEC3 salt. would it be possible to store it as a blob in the HSM? > would it be accessible just as the keys? You could store data in the object class CKO_DATA It has these attributes becides the common ones. CKA_APPLICATION - RFC2279 string Description of the application that manages the object (default empty) CKA_OBJECT_ID - Byte Array DER-encoding of the object identifier indicating the data object type (default empty) CKA_VALUE - Byte Array Value of the object (default empty) But SoftHSM does not have support for data objects. But could after some modifications. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaaqO+CjgaNTdVjaAQgU0Qf/cs9In25pO5YdJctUiAMCsJteXyM2MdDC 56Noqx0LG6G+bCddnAMuXIV6QIW7BYJQ8POjsubAlvHSMWgpZd4ZPe48ZJHkcCwi azMt1ThWChXI2BTG3hajyGoWc/AdDIHkYW5vxl97KECOvG57ZcFyZB0Ke04nzH4m BGkY4fNz2c4+AKp2oZ233e6Icexrs5yU5Xjj5HDZ6srevSFQp5MP9O4JISQz6qm1 ES3iw8hMTFti2mCVuMiv7JA+cK4XpI8KcJXdJ81uq2aQMj80G5EmetuhjyifOk0V XMt3l8LYx+cSzRx7Mn705s/QzHWNzvEhQFsWa4GUX55D3FcS5zWTag== =BXd5 -----END PGP SIGNATURE----- From rickard.bondesson at iis.se Thu Feb 26 14:47:32 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Thu, 26 Feb 2009 15:47:32 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM In-Reply-To: <69830D4127201D4EBD146B904119971896C332@EXCHANGE.office.nic.se> References: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> <69830D4127201D4EBD146B904119971896C332@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971896C334@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 C_CreateObject to create the data object. C_FindObjectsInit / C_FindObjects / C_FindObjectsFinal to find the object C_GetAttributeValue to get the salt value // Rickard > > John and I was just discussing where to store non-policy > data like the > > NSEC3 salt. would it be possible to store it as a blob in the HSM? > > would it be accessible just as the keys? > > You could store data in the object class CKO_DATA > > It has these attributes becides the common ones. > > CKA_APPLICATION - RFC2279 string > Description of the application that manages the object (default empty) > > CKA_OBJECT_ID - Byte Array > DER-encoding of the object identifier indicating the data > object type (default empty) > > CKA_VALUE - Byte Array > Value of the object (default empty) > > But SoftHSM does not have support for data objects. But could > after some modifications. > > // Rickard > > * Rickard Bondesson > * 0x537558DA(L) > > > -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSaarhOCjgaNTdVjaAQipcAf+PoCSfpdtr03FJGxdxXV6atK6U5UkFbBJ d5x3YkF0g36KU1mqjG5o7KW16DFOzUca1C3YT5EvfGCreLQ4N5qkos+TD/bMCxXT FP/U/o6IRdJROC+queTs2DF3oobWOAhdp4fuAGa7D/NKfxkorJjjip9jc904meDG 7UYsRPssmbydo5tO3RjXh+Zvz/kOH7Femptasdm26vjJ4d/+VjyxsuFAnbK8acDl cJEkhK2NtlpiIQYwW5ooTSLQYX+1zef5Zo82Fbx3xf5QWRmy677uJQIUTXIRywjM OvkmBsrqlXpLmtuPulU5NKSTUE6dNntxmT9i9rjkfA6akXmgJwXhpw== =Svlu -----END PGP SIGNATURE----- From jakob at kirei.se Thu Feb 26 14:49:01 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 26 Feb 2009 15:49:01 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM In-Reply-To: <69830D4127201D4EBD146B904119971896C332@EXCHANGE.office.nic.se> References: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> <69830D4127201D4EBD146B904119971896C332@EXCHANGE.office.nic.se> Message-ID: <1F37D275-8148-4776-BBFC-ACEDEF6A689B@kirei.se> On 26 feb 2009, at 15.42, Rickard Bondesson wrote: > But SoftHSM does not have support for data objects. But could after > some modifications. what about other HSMs? is support for data objects common? jakob From Stephen.Morris at nominet.org.uk Thu Feb 26 15:02:44 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 26 Feb 2009 15:02:44 +0000 Subject: [Opendnssec-develop] UML package diagram In-Reply-To: <20090225134422.GA19044@phantom.vanrein.org> Message-ID: opendnssec-develop-bounces at lists.opendnssec.org wrote on 25/02/2009 13:44:22: > Rickard, > > > Stephen, is that similar to what you had in mind? > > > > http://www.opendnssec.se/wiki/Signer/Phase1/HowItWorks > > This diagram brings a lot of clarity. I cautiously checked it to conform > to my ideas (which is what I think these diagrams are there for) and I see > a full match. Well done! > > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop It is very close to what I had in mind and I fully agree with Rick in that it brings a lot of clarity. I would, however, suggest some minor changes: * Change "KSM CLI" to KSM, remove "libksm", and have both "KSM" and "KASP Enforcer" communicate directly with the database. The reasoning here is that KSM and the enforcer will exist as separate processes in the running system. The fact that they use libksm is just a detail of their implementation. * Change "Signer Engine CLI" to something like "SECP" (Signer Engine Control Program - sorry, it's the best I could come up with at short notice). I suggest removing "CLI" from "KSM CLI" and "Signer Engine CLI" again because the CLI is just an implementation detail. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy at nominet.org.uk Thu Feb 26 15:43:37 2009 From: roy at nominet.org.uk (Roy Arends) Date: Thu, 26 Feb 2009 16:43:37 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM In-Reply-To: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> References: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> Message-ID: > greetings PKCS#11 friends, > > John and I was just discussing where to store non-policy data like the > NSEC3 salt. would it be possible to store it as a blob in the HSM? > would it be accessible just as the keys? Why would you store it in the HSM? I'd store it on disk! Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.vanrijswijk at surfnet.nl Thu Feb 26 16:26:17 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 26 Feb 2009 17:26:17 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM In-Reply-To: <1F37D275-8148-4776-BBFC-ACEDEF6A689B@kirei.se> References: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> <69830D4127201D4EBD146B904119971896C332@EXCHANGE.office.nic.se> <1F37D275-8148-4776-BBFC-ACEDEF6A689B@kirei.se> Message-ID: <49A6C2A9.4060206@surfnet.nl> Hi all, Jakob Schlyter wrote: > On 26 feb 2009, at 15.42, Rickard Bondesson wrote: > >> But SoftHSM does not have support for data objects. But could after >> some modifications. > > what about other HSMs? is support for data objects common? >From my experience, support for CKO_DATA objects is quite a common feature on both HSMs as well as smart cards and USB tokens. Cheers, Roland -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jad at jadickinson.co.uk Fri Feb 27 10:15:50 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Fri, 27 Feb 2009 10:15:50 +0000 Subject: [Opendnssec-develop] KASP parameters Message-ID: <1199D7C6-B0F1-42C2-A5F5-5DD08C40A735@jadickinson.co.uk> Hi, Jakob and I have been through KASP and the draft that Stephen and I wrote to try and ensure they contain the same information. So http://www.opendnssec.se/browser/docs/xml/kasp.xml http://www.opendnssec.se/browser/docs/xml/kasp.rnc should now contain all the information necessary for key rollover to occur according to the procedures contained in the draft. And the draft should be able to act as documentation for the key rollover in libKSM (part of the Enforcer). There are one or two minor tweaks where I plan to modify the draft and the terminology in the xml has been selected to make it readable so that the XML can be used as a standalone document for security audits. Can anyone see anything wrong? John --- John Dickinson http://www.jadickinson.co.uk From rickard.bondesson at iis.se Fri Feb 27 10:49:36 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 27 Feb 2009 11:49:36 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM In-Reply-To: References: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971896C39F@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Why would you store it in the HSM? > > I'd store it on disk! Agree Why make more dependencies with HSM:s than necessary? Is the salt value as important to protect as the private keys? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSafFQOCjgaNTdVjaAQh9Ogf8C6cZj7vrKmM4c1hgRWv4mDmQKxLBBy5i KWL2FbEj+6ZVaGBkAtQT42yRVQohFNW2yBy6V9qfrb7nYLnP3YS65fTAXTuSN4p+ VSUSE/VZjgX+rHGlSyPtoponHCf48ueFOrufss7M8iAcnumLVd34XPVVQKnHv41F U4ihh8y1uAE6cJ1vHoDjQXpl2/LpNv8FIRjfhEymgr3vBSDu98otv4bcs4nLdwCs 94OAePU1dkiczWfDjZlXqauWaI9DS2CJo+9/Ty97uvQ1ffENA7ToYQ9BXRgY/NYO dBlUU251MF64M+cjnmBtay/weNe2k4DQRPOb5bW5155P2VSVFYuk/w== =aqH6 -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Fri Feb 27 11:05:47 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 27 Feb 2009 12:05:47 +0100 Subject: [Opendnssec-develop] storing blobs in the HSM In-Reply-To: <69830D4127201D4EBD146B904119971896C39F@EXCHANGE.office.nic.se> References: <5AF8BF33-E93F-449B-8222-EF5BA4A3C82B@kirei.se> <69830D4127201D4EBD146B904119971896C39F@EXCHANGE.office.nic.se> Message-ID: <49A7C90B.5010600@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: >> Why would you store it in the HSM? > >> I'd store it on disk! > > Agree > > Why make more dependencies with HSM:s than necessary? Is the salt value as important to protect as the private keys? > Actually, what I'm wondering now is where you store the metadata of currently running policies, like what keys are in use, since when, etc. Looks to me like that would also be the place to store current salt values. Or was the place to store that also included in the original question? Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmnyQcACgkQ4nZCKsdOncWooQCfcK2XDdjPYVz62fbiLsQtDmk5 ERAAnj8ZvUe2L0j1x2Kdu20opuEGVxyU =7YH3 -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Fri Feb 27 13:45:28 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 27 Feb 2009 14:45:28 +0100 Subject: [Opendnssec-develop] resigning the resignation of the resign element name In-Reply-To: <20090224111327.GD2426@phantom.vanrein.org> References: <20090224111327.GD2426@phantom.vanrein.org> Message-ID: <49A7EE78.4030006@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (bikeshed, say hello to my little paintgun friend) Rick van Rein wrote: > > Perhaps rename to as people tend to do in > plain English to avoid confusion? > I see that the last change made it , which IMHO is both extremely ugly and inconsistent with other names. As I understand, it was chosen over because of worries about xml parsers not being able to parse dashes. It this an actual worrying point? While i'm certainly not opposed to the correct use of , I prefer over if that is not an option. Oh and if so, xml just made another step towards my personal pit of would-not-buy-again. Jelte ps. same for optout<>opt-out<>optOut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmn7ngACgkQ4nZCKsdOncVkUgCfXEVYCJeqONk3Euny01wRZjv0 IPwAn0hqHX8NKnKHCog+aWxlH4oM9fF6 =/jcj -----END PGP SIGNATURE----- From roy at nominet.org.uk Fri Feb 27 13:53:55 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 27 Feb 2009 14:53:55 +0100 Subject: [Opendnssec-develop] resigning the resignation of the resign element name In-Reply-To: <49A7EE78.4030006@NLnetLabs.nl> References: <20090224111327.GD2426@phantom.vanrein.org> <49A7EE78.4030006@NLnetLabs.nl> Message-ID: Jelte wrote on 02/27/2009 02:45:28 PM: > (bikeshed, say hello to my little paintgun friend) > > Rick van Rein wrote: > > > > Perhaps rename to as people tend to do in > > plain English to avoid confusion? > > I see that the last change made it , which IMHO is both extremely ugly > and inconsistent with other names. > > As I understand, it was chosen over because of worries about xml > parsers not being able to parse dashes. It this an actual worrying > point? While > i'm certainly not opposed to the correct use of , I prefer > over if that is not an option. > > Oh and if so, xml just made another step towards my personal pit of > would-not-buy-again. Fwiw, it doesn't matter what you pick, as long as it is machine readable. Some resemblance to human readable form is desirable of course, but just pick one. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at jadickinson.co.uk Fri Feb 27 14:21:33 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Fri, 27 Feb 2009 14:21:33 +0000 Subject: [Opendnssec-develop] resigning the resignation of the resign element name In-Reply-To: References: <20090224111327.GD2426@phantom.vanrein.org> <49A7EE78.4030006@NLnetLabs.nl> Message-ID: <09C5A926-EE3E-4ABC-82C2-810236E6D0CC@jadickinson.co.uk> On 27 Feb 2009, at 13:53, Roy Arends wrote: > > Fwiw, it doesn't matter what you pick, as long as it is machine > readable. Some resemblance to human readable form is desirable of > course, but just pick one. It is intended for humans to read - the xml exists so that a human can audit the policy. However, A human can read any of these. John --- John Dickinson http://www.jadickinson.co.uk