From roy at nominet.org.uk  Wed Apr  1 19:29:23 2009
From: roy at nominet.org.uk (Roy Arends)
Date: Wed, 1 Apr 2009 21:29:23 +0200
Subject: Reminder : [Opendnssec-develop] hsm-toolkit update, and some open
	questions
In-Reply-To: <69830D4127201D4EBD146B904119971896CFC4@EXCHANGE.office.nic.se>
References: <OF77073CD8.446EF8A0-ON80257583.007A32C0-C1257583.00822B70@nominet.org.uk><OF8DBBCA9C.FDD00F02-ON80257589.003FCB05-C1257589.003FFF81@nominet.org.uk>
	<62619FD4-842F-4C60-A844-18F73DEAF1C3@kirei.se>
	<69830D4127201D4EBD146B904119971896CFC4@EXCHANGE.office.nic.se>
Message-ID: <OF161491DE.69567B95-ON8025758B.006AE4FE-C125758B.006B0FE9@nominet.org.uk>

"Rickard Bondesson" <rickard.bondesson at iis.se> wrote on 03/30/2009 
05:21:26 PM:

> > strange: if I specify pin as test:1234 on the command line it works. 
> > if I input test:1234 when prompted, it does not.
> 
> Getpass will only read max 8 bytes when in solaris. If this is the 
> case for you?

That is indeed the problem. I wrote about that issue last year: 
http://blog.nominet.org.uk/tech/2008/06/02/40k-signatures-second-on-fips-140-2-level-3-hardware/

will fix

Regards,

Roy Arends
Sr. Researcher
Nominet UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090401/b37525e0/attachment.htm>

From rickard.bondesson at iis.se  Wed Apr  1 19:54:09 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 1 Apr 2009 21:54:09 +0200
Subject: Reminder : [Opendnssec-develop] hsm-toolkit update,
	and some open questions
In-Reply-To: <OF161491DE.69567B95-ON8025758B.006AE4FE-C125758B.006B0FE9@nominet.org.uk>
References: <OF77073CD8.446EF8A0-ON80257583.007A32C0-C1257583.00822B70@nominet.org.uk><OF8DBBCA9C.FDD00F02-ON80257589.003FCB05-C1257589.003FFF81@nominet.org.uk>
	<62619FD4-842F-4C60-A844-18F73DEAF1C3@kirei.se>
	<69830D4127201D4EBD146B904119971896CFC4@EXCHANGE.office.nic.se>
	<OF161491DE.69567B95-ON8025758B.006AE4FE-C125758B.006B0FE9@nominet.org.uk>
Message-ID: <4C71B4D4-F682-4820-B4A9-CDC4942A208D@iis.se>

I have a fix that looks for the solaris versions which handled max 256  
chars. Look in the repository for the config program for SoftHSM, but  
it uses autoconf.

1 apr 2009 kl. 21.29 skrev "Roy Arends" <roy at nominet.org.uk>:

> "Rickard Bondesson" <rickard.bondesson at iis.se> wrote on 03/30/2009  
> 05:21:26 PM:
>
> > > strange: if I specify pin as test:1234 on the command line it  
> works.
> > > if I input test:1234 when prompted, it does not.
> >
> > Getpass will only read max 8 bytes when in solaris. If this is the
> > case for you?
>
> That is indeed the problem. I wrote about that issue last year: http://blog.nominet.org.uk/tech/2008/06/02/40k-signatures-second-on-fips-140-2-level-3-hardware/
>
> will fix
>
> Regards,
>
> Roy Arends
> Sr. Researcher
> Nominet UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090401/484c40f3/attachment.htm>

From roy at nominet.org.uk  Wed Apr  1 20:21:24 2009
From: roy at nominet.org.uk (Roy Arends)
Date: Wed, 1 Apr 2009 22:21:24 +0200
Subject: Reminder : [Opendnssec-develop] hsm-toolkit update, and some open
	questions
In-Reply-To: <4C71B4D4-F682-4820-B4A9-CDC4942A208D@iis.se>
References: <OF77073CD8.446EF8A0-ON80257583.007A32C0-C1257583.00822B70@nominet.org.uk><OF8DBBCA9C.FDD00F02-ON80257589.003FCB05-C1257589.003FFF81@nominet.org.uk>
	<62619FD4-842F-4C60-A844-18F73DEAF1C3@kirei.se>
	<69830D4127201D4EBD146B904119971896CFC4@EXCHANGE.office.nic.se>
	<OF161491DE.69567B95-ON8025758B.006AE4FE-C125758B.006B0FE9@nominet.org.uk>
	<4C71B4D4-F682-4820-B4A9-CDC4942A208D@iis.se>
Message-ID: <OF88E6C793.4F01AD9B-ON8025758B.006ECDFD-C125758B.006FD2C0@nominet.org.uk>

"Rickard Bondesson" <rickard.bondesson at iis.se> wrote on 04/01/2009 
09:54:09 PM:

> I have a fix that looks for the solaris versions which handled max 
> 256 chars. Look in the repository for the config program for 
> SoftHSM, but it uses autoconf.

I understand that the following will do, right?

add AC_CHECK_FUNCS(getpassphrase) to configure.ac and

#ifdef HAVE_GETPASSPHRASE
  // getpassphrase()
#else
  // getpass()
#endif

where appropriate in the code, right?

Thanks for the pointer!

Regards,

Roy Arends
Sr. Researcher
Nominet UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090401/6eb600ed/attachment.htm>

From jakob at kirei.se  Thu Apr  2 06:22:32 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 2 Apr 2009 08:22:32 +0200
Subject: [Opendnssec-develop] Re: common configuration file
In-Reply-To: <A1E6C0DF-2C1D-4D74-B12F-F53F1D5168B1@kirei.se>
References: <A1E6C0DF-2C1D-4D74-B12F-F53F1D5168B1@kirei.se>
Message-ID: <5C3A7F03-40BD-4522-AFD1-214D44B38CCD@kirei.se>

On 30 mar 2009, at 14.05, Jakob Schlyter wrote:

> for a number of stuff, we need a common OpenDNSSEC configuration  
> file that all our tools can use. things that would go into this  
> would be some runtime parameters, like the configured pkcs11-libs etc.

dispite our less liking of XML, I've made small draft XML config that  
I would like us to consider.

	http://www.opendnssec.se/browser/docs/xml/opendnssec.xml
	http://www.opendnssec.se/browser/docs/xml/opendnssec.rnc

this would allow us to parse all text input as XML. if we want to do  
YAML it would look like this if I understand YAML correctly:

# OpenDNSSEC.yaml
#
HSM:
  sca6000: { Module: /usr/lib/libpkcs11.so, PIN: test:1234 }
  softHSM: { Module: /usr/local/lib/libsofthsm.so, PIN: test:5678 }
#
Enforcer:
  Interval: 3600
  KeygenInterval: 3
  BackupDelay: 3

At first sight, it seems like the YAML is much more compact (and thus  
better), but there are of course other issues lurking. I'd prefer XML  
since it would be only one parser to link to (and we already depend on  
XML for other stuff) and that we'd keep all our config-files in one  
single format, but I really don't care that much if becomes and issue.  
However, I do care that the parsing is done correctly, i.e. if we do  
YAML we parse with a real YAML library (so we can do fancy data  
structures like mappings of mappings) or we do XML (with XPath or the  
like).


	jakob



From jakob at kirei.se  Thu Apr  2 07:18:55 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 2 Apr 2009 09:18:55 +0200
Subject: [Opendnssec-develop] OpenDNSSEC Prerequisites
Message-ID: <FDD65633-040F-4612-B002-7CDEEF983FA2@kirei.se>

Please check http://www.opendnssec.se/wiki/Signer/Prerequisites and  
add any dependencies etc.

	jakob



From jakob at kirei.se  Thu Apr  2 07:53:36 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 2 Apr 2009 09:53:36 +0200
Subject: [Opendnssec-develop] reminder: build in separate dirs
Message-ID: <17B401F0-8087-4DD8-8843-9427C37BCBF3@kirei.se>

I'd just like to remind everyone that writes code in the project, to  
make sure their code builds out of tree, e.g.:

	mkdir build
	cd build
	../configure --xyzzy
	make
	make install

just tested with SoftHSM and it works as expected.

	jakob



From jakob at kirei.se  Thu Apr  2 13:40:19 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 2 Apr 2009 15:40:19 +0200
Subject: [Opendnssec-develop] IXFR?
References: <40827654-F02D-403C-B26C-E59495FEE3E7@kirei.se>
Message-ID: <9CE208B8-5489-4D0D-99C7-D55A8C3AF1B3@kirei.se>

noone noticed my little april's fool yesterday?

Begin forwarded message:

> From: Jakob Schlyter <jakob at kirei.se>
> Date: on 1 apr 2009 19.48.15 GMT+02:00
> To: dnssec-svn at kirei.se
> Subject: [keihatsu.kirei.se/svn/dnssec] r338 - trunk/signer_engine
>
> Author: jakob
> Date: 2009-04-01 19:44:00 +0200 (Wed, 01 Apr 2009)
> New Revision: 338
>
> Modified:
>  trunk/signer_engine/engine.py
> Log:
> implement in- och outbound incremental zonetransfer (IXFR) as well  
> as basic support for dynamic updates (DDNS).
> requires OpenSSL 1.0.0-beta1 to compile.
>



From roy at nominet.org.uk  Thu Apr  2 13:49:41 2009
From: roy at nominet.org.uk (roy at nominet.org.uk)
Date: Thu, 2 Apr 2009 15:49:41 +0200
Subject: [Opendnssec-develop] IXFR?
In-Reply-To: <9CE208B8-5489-4D0D-99C7-D55A8C3AF1B3@kirei.se>
References: <40827654-F02D-403C-B26C-E59495FEE3E7@kirei.se>
	<9CE208B8-5489-4D0D-99C7-D55A8C3AF1B3@kirei.se>
Message-ID: <OF10A510F1.DA3793FB-ON8025758C.004BBA8B-C125758C.004BF5AC@nominet.org.uk>

Jakob wrote on 04/02/2009 03:40:19 PM:

> noone noticed my little april's fool yesterday?

I normally don't pay much attention to the svn-mail. If I'd seen it, I'd
probably 'bought' it completely, and might have congratulated Ben with his
1.0.0-beta1 release.

Cool joke! Sorry it passed me by.

Regards,

Roy Arends
Sr. Researcher
Nominet UK





> Begin forwarded message:
>
> > From: Jakob Schlyter <jakob at kirei.se>
> > Date: on 1 apr 2009 19.48.15 GMT+02:00
> > To: dnssec-svn at kirei.se
> > Subject: [keihatsu.kirei.se/svn/dnssec] r338 - trunk/signer_engine
> >
> > Author: jakob
> > Date: 2009-04-01 19:44:00 +0200 (Wed, 01 Apr 2009)
> > New Revision: 338
> >
> > Modified:
> >  trunk/signer_engine/engine.py
> > Log:
> > implement in- och outbound incremental zonetransfer (IXFR) as well
> > as basic support for dynamic updates (DDNS).
> > requires OpenSSL 1.0.0-beta1 to compile.
> >
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>



From jelte at NLnetLabs.nl  Thu Apr  2 14:16:24 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Thu, 02 Apr 2009 16:16:24 +0200
Subject: [Opendnssec-develop] IXFR?
In-Reply-To: <OF10A510F1.DA3793FB-ON8025758C.004BBA8B-C125758C.004BF5AC@nominet.org.uk>
References: <40827654-F02D-403C-B26C-E59495FEE3E7@kirei.se>	<9CE208B8-5489-4D0D-99C7-D55A8C3AF1B3@kirei.se>
	<OF10A510F1.DA3793FB-ON8025758C.004BBA8B-C125758C.004BF5AC@nominet.org.uk>
Message-ID: <49D4C8B8.1080507@NLnetLabs.nl>

roy at nominet.org.uk wrote:
> Jakob wrote on 04/02/2009 03:40:19 PM:
> 
>> noone noticed my little april's fool yesterday?
> 

apparently not, maybe a good way to sneak in some undiscussed items...

> I normally don't pay much attention to the svn-mail. If I'd seen it, I'd
> probably 'bought' it completely, and might have congratulated Ben with his
> 1.0.0-beta1 release.
> 

err, but that one doesn't appear to be a joke; there's a tarball which
compiles and installs fine here :)

most comments they got was on the versioning scheme of openssl (and that
one shouldn't release stuff on april 1st).

Geoff Thorpe did have an april's fools joke about it;

The choice of a 1.0 release is to clearly mark the fact that openssl is
shifting to a common base platform, namely Java. Platform independence
is going to make future development much easier, but represents a
significant enough change to warrant the new major version. This
decision has been driven by increasing demands to support as-yet
unsupported platforms; primarily Amiga, Z80, Casiotone, and Windows.

> Cool joke! Sorry it passed me by.
> 

indeed, and same here :/

Jelte

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090402/1fd9b9e7/attachment.bin>

From olaf at NLnetLabs.nl  Thu Apr  2 14:16:35 2009
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Thu, 2 Apr 2009 16:16:35 +0200
Subject: [Opendnssec-develop] common configuration file
In-Reply-To: <C3D58609-747B-4AEF-A84F-E74EB13C22C0@kirei.se>
References: <A1E6C0DF-2C1D-4D74-B12F-F53F1D5168B1@kirei.se>	<OFA338B8E5.0E45316B-ON80257589.00429928-C1257589.0042B8A5@nominet.org.uk>	<49D0B8BC.8040006@nlnetlabs.nl>	<46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se>
	<C9E5BE2C-DCCD-43EE-AEE5-95918A0CE338@kirei.se>
	<49D1CB6F.8060009@NLnetLabs.nl>
	<C3D58609-747B-4AEF-A84F-E74EB13C22C0@kirei.se>
Message-ID: <BA5F8B12-B3F4-4621-9B95-2512E3381EF5@NLnetLabs.nl>


On 31 mrt 2009, at 10:27, Jakob Schlyter wrote:

> he more I think about it, the more I think we should take that ugly  
> XML-pill and just do it... a simple OpenDNSSEC-config library should  
> be enough. will you hate me forever if we do an XML config file?

With XML you have the added benefit that for those that edit config  
data with their favorite XML aware editor one gets a schema check for  
free.

--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: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090402/c9411553/attachment.bin>

From Ray.Bellis at nominet.org.uk  Thu Apr  2 14:40:58 2009
From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk)
Date: Thu, 2 Apr 2009 15:40:58 +0100
Subject: [Opendnssec-develop] common configuration file
In-Reply-To: <BA5F8B12-B3F4-4621-9B95-2512E3381EF5@NLnetLabs.nl>
References: <A1E6C0DF-2C1D-4D74-B12F-F53F1D5168B1@kirei.se>	<OFA338B8E5.0E45316B-ON80257589.00429928-C1257589.0042B8A5@nominet.org.uk>
	<49D0B8BC.8040006@nlnetlabs.nl>	<46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se>
	<C9E5BE2C-DCCD-43EE-AEE5-95918A0CE338@kirei.se>	<49D1CB6F.8060009@NLnetLabs.nl>
	<C3D58609-747B-4AEF-A84F-E74EB13C22C0@kirei.se>
	<BA5F8B12-B3F4-4621-9B95-2512E3381EF5@NLnetLabs.nl>
Message-ID: <OF7A5AEA39.D484F9D8-ON8025758C.0050926C-8025758C.0050A7C3@nominet.org.uk>

> With XML you have the added benefit that for those that edit config 
> data with their favorite XML aware editor one gets a schema check for 
> free.

and those that do edit config data without such an editor get to do it at 
least twice, every time ;-)

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090402/c01b7f3d/attachment.htm>

From roy at nominet.org.uk  Thu Apr  2 14:45:26 2009
From: roy at nominet.org.uk (roy at nominet.org.uk)
Date: Thu, 2 Apr 2009 16:45:26 +0200
Subject: [Opendnssec-develop] IXFR?
In-Reply-To: <49D4C8B8.1080507@NLnetLabs.nl>
References: <40827654-F02D-403C-B26C-E59495FEE3E7@kirei.se>	<9CE208B8-5489-4D0D-99C7-D55A8C3AF1B3@kirei.se>
	<OF10A510F1.DA3793FB-ON8025758C.004BBA8B-C125758C.004BF5AC@nominet.org.uk>
	<49D4C8B8.1080507@NLnetLabs.nl>
Message-ID: <OFE24A9F67.25BC7D67-ON8025758C.0050D6A4-C125758C.00511068@nominet.org.uk>

Jelte Jansen wrote on 04/02/2009 04:16:24 PM:

> roy at nominet.org.uk wrote:
>
> > I normally don't pay much attention to the svn-mail. If I'd seen it,
I'd
> > probably 'bought' it completely, and might have congratulated Ben with
his
> > 1.0.0-beta1 release.
> >
>
> err, but that one doesn't appear to be a joke; there's a tarball which
> compiles and installs fine here :)

Oh, brilliant. Fooled twice.

> most comments they got was on the versioning scheme of openssl (and that
> one shouldn't release stuff on april 1st).
>
> Geoff Thorpe did have an april's fools joke about it;
>
> The choice of a 1.0 release is to clearly mark the fact that openssl is
> shifting to a common base platform, namely Java. Platform independence
> is going to make future development much easier, but represents a
> significant enough change to warrant the new major version. This
> decision has been driven by increasing demands to support as-yet
> unsupported platforms; primarily Amiga, Z80, Casiotone, and Windows.

*snif* Amiga, Z80, Casiotone, and Windows. Now that was really funny.

Regards,

Roy Arends
Sr. Researcher
Nominet UK



From jakob at kirei.se  Thu Apr  2 14:58:54 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 2 Apr 2009 16:58:54 +0200
Subject: [Opendnssec-develop] common configuration file
In-Reply-To: <OF7A5AEA39.D484F9D8-ON8025758C.0050926C-8025758C.0050A7C3@nominet.org.uk>
References: <A1E6C0DF-2C1D-4D74-B12F-F53F1D5168B1@kirei.se>	<OFA338B8E5.0E45316B-ON80257589.00429928-C1257589.0042B8A5@nominet.org.uk>
	<49D0B8BC.8040006@nlnetlabs.nl>	<46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se>
	<C9E5BE2C-DCCD-43EE-AEE5-95918A0CE338@kirei.se>	<49D1CB6F.8060009@NLnetLabs.nl>
	<C3D58609-747B-4AEF-A84F-E74EB13C22C0@kirei.se>
	<BA5F8B12-B3F4-4621-9B95-2512E3381EF5@NLnetLabs.nl>
	<OF7A5AEA39.D484F9D8-ON8025758C.0050926C-8025758C.0050A7C3@nominet.org.uk>
Message-ID: <E43E8159-5588-4FBC-8740-5FC4C1138DA6@kirei.se>

On 2 apr 2009, at 16.40, Ray.Bellis at nominet.org.uk wrote:

> > With XML you have the added benefit that for those that edit config
> > data with their favorite XML aware editor one gets a schema check  
> for
> > free.
>
> and those that do edit config data without such an editor get to do  
> it at least twice, every time ;-)

right, but I'd say that's true for YAML as well.

	jakob



From Ray.Bellis at nominet.org.uk  Thu Apr  2 15:07:52 2009
From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk)
Date: Thu, 2 Apr 2009 16:07:52 +0100
Subject: [Opendnssec-develop] common configuration file
In-Reply-To: <E43E8159-5588-4FBC-8740-5FC4C1138DA6@kirei.se>
References: <A1E6C0DF-2C1D-4D74-B12F-F53F1D5168B1@kirei.se>	<OFA338B8E5.0E45316B-ON80257589.00429928-C1257589.0042B8A5@nominet.org.uk>
	<49D0B8BC.8040006@nlnetlabs.nl>	<46B28EF5-E338-4ED4-82C1-E795D742FF9C@iis.se>
	<C9E5BE2C-DCCD-43EE-AEE5-95918A0CE338@kirei.se>	<49D1CB6F.8060009@NLnetLabs.nl>
	<C3D58609-747B-4AEF-A84F-E74EB13C22C0@kirei.se>	<BA5F8B12-B3F4-4621-9B95-2512E3381EF5@NLnetLabs.nl>
	<OF7A5AEA39.D484F9D8-ON8025758C.0050926C-8025758C.0050A7C3@nominet.org.uk>
	<E43E8159-5588-4FBC-8740-5FC4C1138DA6@kirei.se>
Message-ID: <OFD8F21B27.124201C2-ON8025758C.0052DEA2-8025758C.00531EBB@nominet.org.uk>

> right, but I'd say that's true for YAML as well.

Yes, that's very true :)

FWIW, I help admin a gaming system that uses XML configuration and it's a 
right pain in the backside, and when I wrote my own plugins I went to a 
.ini style format.  Configuration errors have dropped dramatically.

Regardless of which is chosen, it's probably useful to offer a 
"configuration check only" mode in the software which just tells you 
whether the config file parses correctly (as per Samba, Apache, etc).

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090402/ff20d287/attachment.htm>

From jad at jadickinson.co.uk  Mon Apr  6 13:55:32 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Mon, 6 Apr 2009 14:55:32 +0100
Subject: [Opendnssec-develop] I give up -- help!
Message-ID: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk>

Can anyone who knows more than me explain the following errors when I  
run aclocal on solaris in the trunk/enforcer/libksm/ dir?


aclocal
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id,  
must contain _cv_ to be cached
../../../autoconf-2.62/lib/autoconf/general.m4:1973: AC_CACHE_VAL is  
expanded from...
../../../autoconf-2.62/lib/autoconf/general.m4:1993: AC_CACHE_CHECK is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:632: AC_LIBTOOL_COMPILER_OPTION is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:4932: AC_LIBTOOL_PROG_COMPILER_PIC  
is expanded from...
/opt/csw/share/aclocal/libtool.m4:2700: _LT_AC_LANG_C_CONFIG is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:2699: AC_LIBTOOL_LANG_C_CONFIG is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded  
from...
/opt/csw/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded  
from...
/opt/csw/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded  
from...
configure.ac:11: the top level
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id,  
must contain _cv_ to be cached
/opt/csw/share/aclocal/libtool.m4:677: AC_LIBTOOL_LINKER_OPTION is  
expanded from...
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): suspicious cache- 
id, must contain _cv_ to be cached
/opt/csw/share/aclocal/libtool.m4:2781: _LT_AC_LANG_CXX_CONFIG is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:2780: AC_LIBTOOL_LANG_CXX_CONFIG is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:1825: _LT_AC_TAGCONFIG is expanded  
from...
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache- 
id, must contain _cv_ to be cached
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, ...): suspicious cache- 
id, must contain _cv_ to be cached
/opt/csw/share/aclocal/libtool.m4:4007: _LT_AC_LANG_F77_CONFIG is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:4006: AC_LIBTOOL_LANG_F77_CONFIG is  
expanded from...
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious cache- 
id, must contain _cv_ to be cached
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache- 
id, must contain _cv_ to be cached
/opt/csw/share/aclocal/libtool.m4:4116: _LT_AC_LANG_GCJ_CONFIG is  
expanded from...
/opt/csw/share/aclocal/libtool.m4:4115: AC_LIBTOOL_LANG_GCJ_CONFIG is  
expanded from...
configure.ac:11: warning:  
AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious cache- 
id, must contain _cv_ to be cached



---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jelte at NLnetLabs.nl  Mon Apr  6 14:15:27 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Mon, 06 Apr 2009 16:15:27 +0200
Subject: [Opendnssec-develop] I give up -- help!
In-Reply-To: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk>
References: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk>
Message-ID: <49DA0E7F.3000904@NLnetLabs.nl>

John Dickinson wrote:
> Can anyone who knows more than me explain the following errors when I
> run aclocal on solaris in the trunk/enforcer/libksm/ dir?
> 
> 

they're warnings, not errors ;)

i think libtool is out of sync with autoconf in terms of what macro's
there are defined (i see ldns spew the same garbage on kuriputo, but it
seems to compile fine, still my guess is that either libtool or autoconf
needs to be up or downgraded).


> aclocal
> configure.ac:11: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...):
> suspicious cache-id, must contain _cv_ to be cached
> ../../../autoconf-2.62/lib/autoconf/general.m4:1973: AC_CACHE_VAL is
> expanded from...
> ../../../autoconf-2.62/lib/autoconf/general.m4:1993: AC_CACHE_CHECK is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:632: AC_LIBTOOL_COMPILER_OPTION is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:4932: AC_LIBTOOL_PROG_COMPILER_PIC is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:2700: _LT_AC_LANG_C_CONFIG is expanded
> from...
> /opt/csw/share/aclocal/libtool.m4:2699: AC_LIBTOOL_LANG_C_CONFIG is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
> /opt/csw/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
> /opt/csw/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
> configure.ac:11: the top level
> configure.ac:11: warning: AC_CACHE_VAL(lt_prog_compiler_static_works,
> ...): suspicious cache-id, must contain _cv_ to be cached
> /opt/csw/share/aclocal/libtool.m4:677: AC_LIBTOOL_LINKER_OPTION is
> expanded from...
> configure.ac:11: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX,
> ...): suspicious cache-id, must contain _cv_ to be cached
> /opt/csw/share/aclocal/libtool.m4:2781: _LT_AC_LANG_CXX_CONFIG is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:2780: AC_LIBTOOL_LANG_CXX_CONFIG is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:1825: _LT_AC_TAGCONFIG is expanded
> from...
> configure.ac:11: warning:
> AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious
> cache-id, must contain _cv_ to be cached
> configure.ac:11: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77,
> ...): suspicious cache-id, must contain _cv_ to be cached
> /opt/csw/share/aclocal/libtool.m4:4007: _LT_AC_LANG_F77_CONFIG is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:4006: AC_LIBTOOL_LANG_F77_CONFIG is
> expanded from...
> configure.ac:11: warning:
> AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious
> cache-id, must contain _cv_ to be cached
> configure.ac:11: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ,
> ...): suspicious cache-id, must contain _cv_ to be cached
> /opt/csw/share/aclocal/libtool.m4:4116: _LT_AC_LANG_GCJ_CONFIG is
> expanded from...
> /opt/csw/share/aclocal/libtool.m4:4115: AC_LIBTOOL_LANG_GCJ_CONFIG is
> expanded from...
> configure.ac:11: warning:
> AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious
> cache-id, must contain _cv_ to be cached
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090406/00f25c7a/attachment.bin>

From matthijs at NLnetLabs.nl  Tue Apr  7 07:32:09 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Tue, 07 Apr 2009 09:32:09 +0200
Subject: [Opendnssec-develop] code reviewing
In-Reply-To: <49DA0E7F.3000904@NLnetLabs.nl>
References: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk>
	<49DA0E7F.3000904@NLnetLabs.nl>
Message-ID: <49DB0179.90609@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Rickard,

FYI

Yesterday, we had a meeting with Surfnet. They are willing to do code
review. We think this is useful, but Surfnet needs to be informed as
soon as possible in order to arrange a code reviewer. We could decide
this at the meeting next week (15th of April). I believe this is soon
enough for them to make such an arrangement.

They have special interest in reviewing code that interfaces with the HSM.

Regards,

Matthijs, Jelte, Roland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSdsBeQ8yVCPsQCW5AQIy/wf+KlpQIIiIhTAVQPjvO25pXC1JQz6JYl+G
MWUL1TuVfXRqZ8ySYo60Ek61tC5dk+3TAQ7AYPjUlr2CJinyLyXxBs+NxI3fEqn7
xSnnMaoF8zBH02r+i1hWPNe20ycAbRSR0CwDYBb87PLiWjEchIdWCEhmBLmC3aQD
zUoXjdbgRD21tNVtyRJnN1KuA+raow0Y3QWsE/599xIMtOKpiYU96IZcUs7278Hz
SPNWNCMZIsvIjcMA3/5Tmo7RaUOQm0dCCTEGJOhLEOlIz8gDSyMd0pK03GByjEW/
tPq4GJJWydiO3K2aAfW9f5vV9tlt6gyejk1vOlzSVnPCVTP84t0E1A==
=WBI2
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Tue Apr  7 07:40:13 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Tue, 7 Apr 2009 09:40:13 +0200
Subject: [Opendnssec-develop] code reviewing
In-Reply-To: <49DB0179.90609@nlnetlabs.nl>
References: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk><49DA0E7F.3000904@NLnetLabs.nl>
	<49DB0179.90609@nlnetlabs.nl>
Message-ID: <69830D4127201D4EBD146B904119971896D17E@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Yesterday, we had a meeting with Surfnet. They are willing to 
> do code review. We think this is useful, but Surfnet needs to 
> be informed as soon as possible in order to arrange a code 
> reviewer. We could decide this at the meeting next week (15th 
> of April). I believe this is soon enough for them to make 
> such an arrangement.

Great! Who should I contact? 

> They have special interest in reviewing code that interfaces 
> with the HSM.

Can always be arranged.



A question to the OpenDNSSEC group:

Who else is willing to do some code reviewing?

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSdsDXeCjgaNTdVjaAQjzMwf9G81wToLF+Z5AOu/W8c82OjVr/VNMIhtq
QVEQDf6XilhjIZXiPpKpfScJS3KaLVdpSXrlHA3BCgc+cOdXzcjX1lBLq7yY+DNn
xPz8SKu6ntFPjLlQScBXdkshZLhc5Z+Tud3QyJGdU3bMzGbqsmPOIyavCqH7GKWu
ChdIDV8oymx5hCdAVu1BVbr42Si0MVdretw1C4j2MSNxmBE9CapraN5fV9hXoVwk
fH75QEfEmKIkFY/ECPklRwu1n+Y4r9fFuXJPTwcx1LTPGOr/P/PQQCiLtWmtgb19
4H8C8mw+foVM1HzFFZaNenluBwyxtybawlGrgnh5l2+yuc0LvZA7Xw==
=OQFu
-----END PGP SIGNATURE-----


From matthijs at NLnetLabs.nl  Tue Apr  7 09:07:55 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Tue, 07 Apr 2009 11:07:55 +0200
Subject: [Opendnssec-develop] code reviewing
In-Reply-To: <69830D4127201D4EBD146B904119971896D17E@EXCHANGE.office.nic.se>
References: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk><49DA0E7F.3000904@NLnetLabs.nl>
	<49DB0179.90609@nlnetlabs.nl>
	<69830D4127201D4EBD146B904119971896D17E@EXCHANGE.office.nic.se>
Message-ID: <49DB17EB.9070008@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rickard Bondesson schreef:
> Great! Who should I contact? 

Roland van Rijswijk

> Who else is willing to do some code reviewing?

I am willing:)

Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSdsX6w8yVCPsQCW5AQJbcgf8CTt4P55NlFx/3uAoUkHJxf4ovqQZGNH6
ECKdFTmKG/Yl4e+XSgGPJIfRZsMj80/4aDGCenQZy5lONMFuqgucji6dBj3x+FxT
YOI6EX1lCmIM6Ei7eJwckjVeUoZeZ8BD0h+fLHiarNxWT+Iyn+uIrHHWIUWtBPaq
fcZspZinHHmmpeKWB47Om4co/ieSOyqCX26JNrqVZKeJj4XKEpLi17FT0u/sJqbr
C1dLBqJPFFcDA0bPecptSRsMw5l8OwWqx7ad5a+qgkFwdBAFSnr9zPw+ogp8h9xT
nzLzJu2YyL2OfWOSCh1MHUp48ghNMiJvvWKXB5C8ua05yu0ttjY5xA==
=HaZT
-----END PGP SIGNATURE-----


From jakob at kirei.se  Tue Apr  7 18:06:14 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Tue, 7 Apr 2009 20:06:14 +0200
Subject: [Opendnssec-develop] string handling
In-Reply-To: <20090407103715.43B3F6BDE0@mail.kirei.se>
References: <20090407103715.43B3F6BDE0@mail.kirei.se>
Message-ID: <3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>

On 7 apr 2009, at 12.37, Rickard Bondeson wrote:

> Author: rb
> Date: 2009-04-07 12:37:14 +0200 (Tue, 07 Apr 2009)
> New Revision: 394
>
> Modified:
>   trunk/softHSM/src/lib/SoftDatabase.cpp
> Log:
> We do not want to zero fill the token label.
>
>
> Modified: trunk/softHSM/src/lib/SoftDatabase.cpp
> ===================================================================
> --- trunk/softHSM/src/lib/SoftDatabase.cpp	2009-04-07 09:56:46 UTC  
> (rev 393)
> +++ trunk/softHSM/src/lib/SoftDatabase.cpp	2009-04-07 10:37:14 UTC  
> (rev 394)
> @@ -103,7 +103,12 @@
>
>   if(sqlite3_step(select_sql) == SQLITE_ROW) {
>     const char *tokenLabel = (const  
> char*)sqlite3_column_text(select_sql, 0);
> -    strncpy(retLabel, tokenLabel, 32);
> +
> +    int counter = 0;
> +    while(tokenLabel[counter] != '\0' && counter < 32) {
> +      retLabel[counter] = tokenLabel[counter];
> +      counter++;
> +    }
>   }
>
>   sqlite3_finalize(select_sql);
>

I'd just like to make a more public note regarding string handling in  
OpenDNSSEC; as long as possible we should should strlcpy(3) and  
strlcat(3) instead of home-brewn similar functions. if we need to  
support platforms that does not have those functions, we'll import  
compat-version from OpenSSH.

also, while we're at this specific example. static lengths (as 32  
above) should never be used - either #define them if a constant (like  
the size of a token label) or better use sizeof() when possible. I'll  
make a review of stuff like this, but it's better to get rid of them  
before that

so Rickard, please fix the stuff above and use strlcpy(3) and #define  
something like MAX_TOKEN_LABEL_LENGTH somewhere.


	jakob, senior buffer and string management officer



From roland.vanrijswijk at surfnet.nl  Wed Apr  8 06:52:12 2009
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Wed, 08 Apr 2009 08:52:12 +0200
Subject: [Opendnssec-develop] string handling
In-Reply-To: <3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>
References: <20090407103715.43B3F6BDE0@mail.kirei.se>
	<3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>
Message-ID: <49DC499C.3060808@surfnet.nl>

Hi Jakob, Rickard,

I'd like to bail Rickard out a bit here. PKCS #11 uses a lot of
fixed-length strings, one of which is token label. And to make matters
even more confusing: the fixed-length strings in the PKCS #11 spec are
not NULL-terminated...

Cheers,

Roland

Jakob Schlyter wrote:
> On 7 apr 2009, at 12.37, Rickard Bondeson wrote:
> 
>> Author: rb
>> Date: 2009-04-07 12:37:14 +0200 (Tue, 07 Apr 2009)
>> New Revision: 394
>>
>> Modified:
>>   trunk/softHSM/src/lib/SoftDatabase.cpp
>> Log:
>> We do not want to zero fill the token label.
>>
>>
>> Modified: trunk/softHSM/src/lib/SoftDatabase.cpp
>> ===================================================================
>> --- trunk/softHSM/src/lib/SoftDatabase.cpp    2009-04-07 09:56:46 UTC
>> (rev 393)
>> +++ trunk/softHSM/src/lib/SoftDatabase.cpp    2009-04-07 10:37:14 UTC
>> (rev 394)
>> @@ -103,7 +103,12 @@
>>
>>   if(sqlite3_step(select_sql) == SQLITE_ROW) {
>>     const char *tokenLabel = (const
>> char*)sqlite3_column_text(select_sql, 0);
>> -    strncpy(retLabel, tokenLabel, 32);
>> +
>> +    int counter = 0;
>> +    while(tokenLabel[counter] != '\0' && counter < 32) {
>> +      retLabel[counter] = tokenLabel[counter];
>> +      counter++;
>> +    }
>>   }
>>
>>   sqlite3_finalize(select_sql);
>>
> 
> I'd just like to make a more public note regarding string handling in
> OpenDNSSEC; as long as possible we should should strlcpy(3) and
> strlcat(3) instead of home-brewn similar functions. if we need to
> support platforms that does not have those functions, we'll import
> compat-version from OpenSSH.
> 
> also, while we're at this specific example. static lengths (as 32 above)
> should never be used - either #define them if a constant (like the size
> of a token label) or better use sizeof() when possible. I'll make a
> review of stuff like this, but it's better to get rid of them before that
> 
> so Rickard, please fix the stuff above and use strlcpy(3) and #define
> something like MAX_TOKEN_LABEL_LENGTH somewhere.
> 
> 
>     jakob, senior buffer and string management officer
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop


-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From jakob at kirei.se  Wed Apr  8 07:11:46 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 8 Apr 2009 09:11:46 +0200
Subject: [Opendnssec-develop] string handling
In-Reply-To: <49DC499C.3060808@surfnet.nl>
References: <20090407103715.43B3F6BDE0@mail.kirei.se>
	<3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>
	<49DC499C.3060808@surfnet.nl>
Message-ID: <51767AAD-7E1A-4476-8C44-403EE8037F14@kirei.se>

On 8 apr 2009, at 08.52, Roland van Rijswijk wrote:

> I'd like to bail Rickard out a bit here. PKCS #11 uses a lot of
> fixed-length strings, one of which is token label. And to make matters
> even more confusing: the fixed-length strings in the PKCS #11 spec are
> not NULL-terminated...

then we perhaps should write helper functions that translates PKCS#11  
fixed-length strings to/from null-terminated strings?

	jakob



From roland.vanrijswijk at surfnet.nl  Wed Apr  8 10:26:07 2009
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Wed, 08 Apr 2009 12:26:07 +0200
Subject: [Opendnssec-develop] string handling
In-Reply-To: <51767AAD-7E1A-4476-8C44-403EE8037F14@kirei.se>
References: <20090407103715.43B3F6BDE0@mail.kirei.se>
	<3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>
	<49DC499C.3060808@surfnet.nl>
	<51767AAD-7E1A-4476-8C44-403EE8037F14@kirei.se>
Message-ID: <49DC7BBF.1030609@surfnet.nl>

Hi Jakob,

Jakob Schlyter wrote:
> On 8 apr 2009, at 08.52, Roland van Rijswijk wrote:
> 
>> I'd like to bail Rickard out a bit here. PKCS #11 uses a lot of
>> fixed-length strings, one of which is token label. And to make matters
>> even more confusing: the fixed-length strings in the PKCS #11 spec are
>> not NULL-terminated...
> 
> then we perhaps should write helper functions that translates PKCS#11
> fixed-length strings to/from null-terminated strings?

Something like that could be helpful, to prevent buffer overflows.

Cheers,

Roland


-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From matthijs at NLnetLabs.nl  Wed Apr  8 13:02:22 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Wed, 08 Apr 2009 15:02:22 +0200
Subject: [Opendnssec-develop] Signer Testplan: first try
Message-ID: <49DCA05E.2040408@nlnetlabs.nl>

Hi,

Jelte and I have started to setup a test plan for the Signer Engine.
This is the first try, and is incomplete. But this gives a general idea
of the direction we are heading.

During writing some questions popped up, that we would like to bring to
the list.

1. Jitter
We did not have come to a final conclusion about what Jitter exactly means.
- Do we need to add jitter or subtract it from the expiration datetime?
Or is both accepted?
- Is random jitter acceptable? We could also make use of modular jitter.
This ensures a better spreading and give more predictable outcomes
(which can be useful for testing)

2. NSEC3PARAM TTL
Why do we need to configure the NSEC3PARAM TTL in signconf.xml? TTL for
NSEC3PARAM has no value because it is not used by resolvers or validators.

3. Software for component/system testing
Does anyone know good software to create component tests? At NLnet Labs,
we use our homebrew test tool, tpkg. But the issue with it is that it
has never been officially released.


Matthijs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testplan.pdf
Type: application/pdf
Size: 44683 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090408/b4b3a124/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 544 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090408/b4b3a124/attachment.bin>

From jakob at kirei.se  Wed Apr  8 14:58:29 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 8 Apr 2009 16:58:29 +0200
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <49DCA05E.2040408@nlnetlabs.nl>
References: <49DCA05E.2040408@nlnetlabs.nl>
Message-ID: <E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>

On 8 apr 2009, at 15.02, Matthijs Mekking wrote:

> 1. Jitter
> We did not have come to a final conclusion about what Jitter exactly  
> means.

nope :_)

> - Do we need to add jitter or subtract it from the expiration  
> datetime?
> Or is both accepted?

In my world, jitter is ABS(MAX(VARIANCE(signature expiration time))).

so something like:

   signature expiration = calculated expiration time - jitter +  
(random(jitter) * 2)

where random(x) is a function generating a random numberr such as 0 ?  
r ? x. this would generate a signature exception that can vary +/-  
some jitter number of seconds, right?

> - Is random jitter acceptable?

not only acceptable, it is required.

> 2. NSEC3PARAM TTL
> Why do we need to configure the NSEC3PARAM TTL in signconf.xml? TTL  
> for
> NSEC3PARAM has no value because it is not used by resolvers or  
> validators.

but it does need a TTL no? or do we always set it to X? if so, what is  
X?


	jakob



From matthijs at NLnetLabs.nl  Wed Apr  8 15:06:28 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Wed, 08 Apr 2009 17:06:28 +0200
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>
References: <49DCA05E.2040408@nlnetlabs.nl>
	<E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>
Message-ID: <49DCBD74.5050004@nlnetlabs.nl>

Jakob Schlyter wrote:
> In my world, jitter is ABS(MAX(VARIANCE(signature expiration time))).
> 
> so something like:
> 
>   signature expiration = calculated expiration time - jitter +
> (random(jitter) * 2)
> 
> where random(x) is a function generating a random numberr such as 0 ? r
> ? x. this would generate a signature exception that can vary +/- some
> jitter number of seconds, right?

You just make it a whole lot more complex ;)

>> - Is random jitter acceptable?
> 
> not only acceptable, it is required.

Is it? Where is that defined? Doing it modular instead of random gives
you a nicer expiration datetime spreading, imho.

>> 2. NSEC3PARAM TTL
>> Why do we need to configure the NSEC3PARAM TTL in signconf.xml? TTL for
>> NSEC3PARAM has no value because it is not used by resolvers or
>> validators.
> 
> but it does need a TTL no? or do we always set it to X? if so, what is X?

Although it doesn't matter, I think TTL=0 makes sense (since caching is
not involved). Or SOA MIN, like with NSEC(3).

However, I think to configure something that does not matter, doesn't
make sense.

Matthijs



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 544 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090408/2ded1e2b/attachment.bin>

From jakob at kirei.se  Wed Apr  8 15:20:26 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 8 Apr 2009 17:20:26 +0200
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <49DCBD74.5050004@nlnetlabs.nl>
References: <49DCA05E.2040408@nlnetlabs.nl>
	<E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>
	<49DCBD74.5050004@nlnetlabs.nl>
Message-ID: <D54144DC-E8CC-475F-B4BE-B59F6A45BD30@kirei.se>


On 8 apr 2009, at 17.06, Matthijs Mekking wrote:

> Jakob Schlyter wrote:
>> In my world, jitter is ABS(MAX(VARIANCE(signature expiration time))).
>>
>> so something like:
>>
>>  signature expiration = calculated expiration time - jitter +
>> (random(jitter) * 2)
>>
>> where random(x) is a function generating a random numberr such as 0  
>> ? r
>> ? x. this would generate a signature exception that can vary +/-  
>> some
>> jitter number of seconds, right?
>
> You just make it a whole lot more complex ;)

is it? this is just how I implemented it in the BIND signer. almost,  
more exactly I just did - and not +, but it is been there for some  
time now.

> Is it? Where is that defined? Doing it modular instead of random gives
> you a nicer expiration datetime spreading, imho.

spreading is good so whatever gives us that is good I guess.

> Although it doesn't matter, I think TTL=0 makes sense (since caching  
> is
> not involved). Or SOA MIN, like with NSEC(3).
>
> However, I think to configure something that does not matter, doesn't
> make sense.

it's just if it makes sense to set a default. or we just do TTL=0 and  
be done with it and it that case it can be removed from the kasp +  
signconf.

	jakob



From jelte at NLnetLabs.nl  Wed Apr  8 15:53:08 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 08 Apr 2009 17:53:08 +0200
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <D54144DC-E8CC-475F-B4BE-B59F6A45BD30@kirei.se>
References: <49DCA05E.2040408@nlnetlabs.nl>	<E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>	<49DCBD74.5050004@nlnetlabs.nl>
	<D54144DC-E8CC-475F-B4BE-B59F6A45BD30@kirei.se>
Message-ID: <49DCC864.1060403@NLnetLabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakob Schlyter wrote:
>>>  signature expiration = calculated expiration time - jitter +
>>> (random(jitter) * 2)
>>>
>>> where random(x) is a function generating a random numberr such as 0 ? r
>>> ? x. this would generate a signature exception that can vary +/- some
>>> jitter number of seconds, right?
>>
>> You just make it a whole lot more complex ;)
> 
> is it? this is just how I implemented it in the BIND signer. almost,
> more exactly I just did - and not +, but it is been there for some time
> now.
> 

nah, it is slightly more complex than either exptime + rand(jitter) or exptime -
rand(jitter). But only very :)

>> Is it? Where is that defined? Doing it modular instead of random gives
>> you a nicer expiration datetime spreading, imho.
> 
> spreading is good so whatever gives us that is good I guess.
> 

http://content4.clipmarks.com/image_cache/xofxof/512/405B2A78-5499-474D-89B9-17F420F175C5.gif

Random is computationally more difficult than modular, but again only very
little (we are not going for 'true' random here, pseudorandom is more than
enough for jitter), and compared to other stuff here negligible. However, random
should give (given a decent generator) a better spread, since one does not have
to guess the steps between the different jittered values. Or one could base that
on both the jitter setting and the number of signatures to be created. Making it
way more difficult than 'just' random :) (then again, a 'bad' random function
would be worse).

>> Although it doesn't matter, I think TTL=0 makes sense (since caching is
>> not involved). Or SOA MIN, like with NSEC(3).
>>
>> However, I think to configure something that does not matter, doesn't
>> make sense.
> 
> it's just if it makes sense to set a default. or we just do TTL=0 and be
> done with it and it that case it can be removed from the kasp + signconf.
> 

yes please. It might even have the added benefit that people don't confuse it
with something that matters for anything but authoritative resolvers.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkncyGQACgkQ4nZCKsdOncUKYgCgiq02//7c1I1vsatA/GB3hk/T
18IAoI8OkSC73J1Q9GJBwiR9c51qwVbt
=YW3V
-----END PGP SIGNATURE-----


From rick at openfortress.nl  Wed Apr  8 20:09:40 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 8 Apr 2009 20:09:40 +0000
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>
References: <49DCA05E.2040408@nlnetlabs.nl>
	<E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>
Message-ID: <20090408200940.GA14380@phantom.vanrein.org>

Hello,

You woke up the tiny mathematician living inside my head!

> In my world, jitter is ABS(MAX(VARIANCE(signature expiration time))).

1. You must mean MAX(ABS(...)) and not ABS(MAX(...))

2. I don't think you intended to use VARIANCE as a consolidation function,
   which is how statistics defines it; I think your intention is to calculate
   a difference with a mean value and have the consolidation done by MAX?

3. Instead of VARIANCE (which is a square of the (standard) deviation from
   the mean value) you probably mean the deviation.

I think I would capture your intentions in formulae as follows:

M = Average_i (sigexptime_i)
Jitter = Max_i (Abs (sigexptime_i - M))

Average_i and Max_i are consolidation functions ranging over i,
and sigexptime_i is the time of the i'th signature expiration.

>   signature expiration = calculated expiration time - jitter +  
> (random(jitter) * 2)
> 
> where random(x) is a function generating a random numberr such as 0 ?  
> r ? x. this would generate a signature exception that can vary +/-  
> some jitter number of seconds, right?

OK.

> >- Is random jitter acceptable?
> 
> not only acceptable, it is required.

I missed the background of jitter, perhaps we can clear it up?

Is Jitter a feature (a way of spreading signatures over time if a lot
of work would otherwise come in at once) or a bug (the result of the
non-ideal OS and such)?

I cannot help but feel that we are re-inventing realtime scheduling here.


Hope this helps,

-Rick


From rick at openfortress.nl  Wed Apr  8 20:23:02 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 8 Apr 2009 20:23:02 +0000
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <49DCA05E.2040408@nlnetlabs.nl>
References: <49DCA05E.2040408@nlnetlabs.nl>
Message-ID: <20090408202302.GB14380@phantom.vanrein.org>

Hello Matthijs and Jelte,

Thank you for this testing document.  Here are some remarks I have.

Tests 7 and 20:
	Textual only: These numbers occur more than once.
	You may want to check out \newcounter, \addtocounter, \usecounter

Tests 3 and 7#2:
	I don't like the idea of being liberal where semantics are
	concerned.  If you are proposing to tolerate semantical mistakes,
	I would be tempted to vote against that.  Maybe I just need to know
	what semantics you would be willing to interpret, and inhowfar.
	As a general rule, the security implications of systems that
	interpret my intentions "oh you MUST have meant to say X" gives
	me the creeps.  I'd much rather have a clear error message and a
	total bail-out.

Test 8:
	Language only: The words resign and re-sign have different meaning
	in the English language.  You meant to say re-sign, I think.

Test 12:
	If I got the informal drift of what jitter means, I think this test
	is overlooking slave duplication times and cache keeping times.
	It is a matter of discussion whether this suffices for the first
	version.  If OpenDNSSEC is to actually become a product, it should
	allow for the time for the signed data to go live, meaning that
	the slave and cache delays should be taken into account in this
	calculation.

Test 13:
	I don't understand what this is about.


I hope this is useful,

Cheers,
 -Rick


From jakob at kirei.se  Wed Apr  8 20:31:27 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 8 Apr 2009 22:31:27 +0200
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <20090408200940.GA14380@phantom.vanrein.org>
References: <49DCA05E.2040408@nlnetlabs.nl>
	<E3B9B7D0-07E8-4FB5-81D9-5B8289F21689@kirei.se>
	<20090408200940.GA14380@phantom.vanrein.org>
Message-ID: <8D29299B-F566-4FC7-A05D-C9ED48953DDD@kirei.se>

On 8 apr 2009, at 22.09, Rick van Rein wrote:

> Is Jitter a feature (a way of spreading signatures over time if a lot
> of work would otherwise come in at once) or a bug (the result of the
> non-ideal OS and such)?

it is a feature that you'd like so that your signatures do no expire  
at once, as that would give you a penalty in your incremental zone  
transfers. scheduling of the actual signing is another issue.

	jakob



From matthijs at NLnetLabs.nl  Thu Apr  9 08:10:44 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Thu, 09 Apr 2009 10:10:44 +0200
Subject: [Opendnssec-develop] Signer Testplan: first try
In-Reply-To: <20090408202302.GB14380@phantom.vanrein.org>
References: <49DCA05E.2040408@nlnetlabs.nl>
	<20090408202302.GB14380@phantom.vanrein.org>
Message-ID: <49DDAD84.8060401@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Rick,

Thanks for the comments. Notice that the document is a first set up only.

Rick van Rein schreef:
> Hello Matthijs and Jelte,
> 
> Thank you for this testing document.  Here are some remarks I have.
> 
> Tests 7 and 20:
> 	Textual only: These numbers occur more than once.
> 	You may want to check out \newcounter, \addtocounter, \usecounter

Indeed.

> Tests 3 and 7#2:
> 	I don't like the idea of being liberal where semantics are
> 	concerned.  If you are proposing to tolerate semantical mistakes,
> 	I would be tempted to vote against that.  Maybe I just need to know
> 	what semantics you would be willing to interpret, and inhowfar.
> 	As a general rule, the security implications of systems that
> 	interpret my intentions "oh you MUST have meant to say X" gives
> 	me the creeps.  I'd much rather have a clear error message and a
> 	total bail-out.

This is not a proposal, more up for discussion. The thing is, some
semantics are easy to detect and some are more difficult. The NSEC3
<Algorithm> for example can only be a few valid algorithm identifiers.

The <Locator> element however depends on the reachability of the HSM,
the availability of the key. These things you might not want to check
while reading the configuration, but rather take for granted.

Or we can perform all semantic checks on the signconf.xml before
accepting it.

> Test 8:
> 	Language only: The words resign and re-sign have different meaning
> 	in the English language.  You meant to say re-sign, I think.

I mean the one where new signatures may need to be created ;)

> Test 12:
> 	If I got the informal drift of what jitter means, I think this test
> 	is overlooking slave duplication times and cache keeping times.
> 	It is a matter of discussion whether this suffices for the first
> 	version.  If OpenDNSSEC is to actually become a product, it should
> 	allow for the time for the signed data to go live, meaning that
> 	the slave and cache delays should be taken into account in this
> 	calculation.

It is merely to enforce partial zone re-signing.

> Test 13:
> 	I don't understand what this is about.

Inception offset (previously called clockskew) is used when you are
uncomfortable with setting the signature inception datetime to NOW. With
Inception offset you can create signatures that are valid from 1hr ago,
1day ago, or something like.



Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSd2thA8yVCPsQCW5AQL56wgA0aVMHKflxVw2woY9aDJNbQtw0U/WmlpG
9za3oBzSoEnnAFnCo0Xf/x7EU4M7XHaFcjWN7KF6TL7o6QHQob6IKnm/o+o4jwjR
25vN33p5UnedpaEfQUmbzv3uPJ5f6wjSdgloSFd7D/0zSewKbpHnKBOyfP9gQpos
TSJSavASLtgHO97BqOe8N+vgqgfPkJZ5s0ZGFZePEY1r7kgBPrXuYyIR1eF8zv0m
gnPlpcxeupewoOyHs1vEmsSxsEsPsn2NGjK/tpFGPyIm38+EldeaNHRYy0cAMcWM
69x8Am5bZqMH+R2VZcwgeI87F70BI8LkiLDArhorEdthJrB4/jm+Dg==
=OkJF
-----END PGP SIGNATURE-----


From Stephen.Morris at nominet.org.uk  Thu Apr  9 09:27:18 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Thu, 9 Apr 2009 10:27:18 +0100
Subject: [Opendnssec-develop] string handling
In-Reply-To: <3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>
Message-ID: <OF53F41AC7.D9118D82-ON80257593.0032573E-80257593.0033EFC2@nominet.org.uk>

Jakob Schlyter <jakob at kirei.se> wrote on 07/04/2009 19:06:14:

> On 7 apr 2009, at 12.37, Rickard Bondeson wrote:
>
> :
> 
> I'd just like to make a more public note regarding string handling in 
> OpenDNSSEC; as long as possible we should should strlcpy(3) and 
> strlcat(3) instead of home-brewn similar functions. if we need to 
> support platforms that does not have those functions, we'll import 
> compat-version from OpenSSH.

I note a reservation in the Wikipedia article on the subject:

> > Red Hat developers Ulrich Drepper and James Antill are critics of 
> > the strlcpy and strlcat functions.[2] Antill notes that they are 
> > non-standard and that there are implementation differences between 
> > the BSD and Solaris implementations (the return value of strlcat 
> > when there is no nul in the destination buffer).[3] Antill also 
> > expressed concern regarding the risks of truncation when using any 
> > string function involving static allocation.[4] Drepper argues that 
> > strlcpy and strlcat make truncation errors easier for a programmer 
> > to ignore and thus can introduce more bugs than they remove;[2] 
> > consequently, these functions have not been added to the GNU C 
Library.

If true, the things that concern me are:

a) The implementation differences between BSD and Solaris
b) The fact that these are not in the GNU C library.

(I'm not worried by the truncation argument.  If you are using fixed-
length buffers as destinations, you should expect truncation.  That
is a lesser evil than a buffer overflow.)

As the functions are so trivial, why not write our own (OpenDNSSEC-wide)
versions and avoid any problems with them?


Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090409/fae37a5e/attachment.htm>

From jakob at kirei.se  Thu Apr  9 09:33:06 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 9 Apr 2009 11:33:06 +0200
Subject: [Opendnssec-develop] string handling
In-Reply-To: <OF53F41AC7.D9118D82-ON80257593.0032573E-80257593.0033EFC2@nominet.org.uk>
References: <OF53F41AC7.D9118D82-ON80257593.0032573E-80257593.0033EFC2@nominet.org.uk>
Message-ID: <58A574E1-8117-4D1A-94E2-74F4D5D510B6@kirei.se>

On 9 apr 2009, at 11.27, Stephen.Morris at nominet.org.uk wrote:

>
> If true, the things that concern me are:
>
> a) The implementation differences between BSD and Solaris
> b) The fact that these are not in the GNU C library.
>
> (I'm not worried by the truncation argument.  If you are using fixed-
> length buffers as destinations, you should expect truncation.  That
> is a lesser evil than a buffer overflow.)
>
> As the functions are so trivial, why not write our own (OpenDNSSEC- 
> wide)
> versions and avoid any problems with them?

I've seen the issues brough up by redhat, but still there is no better  
alternative.

instead of writing our own stuff, I strongly suggest we use the compat  
functions provided as part of OpenSSH (and thus very widely used on  
may platforms).

  - http://anoncvs.mindrot.org/index.cgi/openssh/openbsd-compat/
  - http://anoncvs.mindrot.org/index.cgi/openssh/openbsd-compat/strlcpy.c?view=log
  - http://anoncvs.mindrot.org/index.cgi/openssh/openbsd-compat/strlcat.c?view=log

	jakob



From jad at jadickinson.co.uk  Thu Apr  9 09:44:53 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 9 Apr 2009 10:44:53 +0100
Subject: [Opendnssec-develop] string handling
In-Reply-To: <58A574E1-8117-4D1A-94E2-74F4D5D510B6@kirei.se>
References: <OF53F41AC7.D9118D82-ON80257593.0032573E-80257593.0033EFC2@nominet.org.uk>
	<58A574E1-8117-4D1A-94E2-74F4D5D510B6@kirei.se>
Message-ID: <44DCA6F4-59D2-438B-8CA1-F06402DD781B@jadickinson.co.uk>


On 9 Apr 2009, at 10:33, Jakob Schlyter wrote:

> On 9 apr 2009, at 11.27, Stephen.Morris at nominet.org.uk wrote:
>
>>
>> If true, the things that concern me are:
>>
>> a) The implementation differences between BSD and Solaris
>> b) The fact that these are not in the GNU C library.
>>
>> (I'm not worried by the truncation argument.  If you are using fixed-
>> length buffers as destinations, you should expect truncation.  That
>> is a lesser evil than a buffer overflow.)
>>
>> As the functions are so trivial, why not write our own (OpenDNSSEC- 
>> wide)
>> versions and avoid any problems with them?
>
> I've seen the issues brough up by redhat, but still there is no  
> better alternative.
>
> instead of writing our own stuff, I strongly suggest we use the  
> compat functions provided as part of OpenSSH (and thus very widely  
> used on may platforms).
>
> - http://anoncvs.mindrot.org/index.cgi/openssh/openbsd-compat/
> - http://anoncvs.mindrot.org/index.cgi/openssh/openbsd-compat/strlcpy.c?view=log
> - http://anoncvs.mindrot.org/index.cgi/openssh/openbsd-compat/strlcat.c?view=log


This is what NSD does. All the necessary code/configure.ac stuff is  
written and we can just borrow it. Thanks Wouter :)

John
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From rick at openfortress.nl  Thu Apr  9 11:50:16 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Thu, 9 Apr 2009 11:50:16 +0000
Subject: [Opendnssec-develop] string handling
In-Reply-To: <OF53F41AC7.D9118D82-ON80257593.0032573E-80257593.0033EFC2@nominet.org.uk>
References: <3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>
	<OF53F41AC7.D9118D82-ON80257593.0032573E-80257593.0033EFC2@nominet.org.uk>
Message-ID: <20090409115016.GA8211@phantom.vanrein.org>

Hey all,

I like strlcat/strlcpy more than strncat/strncpy, but there's one worry
as far as I'm concerned.  Their spec has an exceptional case if the size
argument is 0.  I if had designed the function I would have exited on
those grounds, or at least raise a signal that could be caught.

Why?  Because that would eradicate the exceptional (and unpractical)
situation that must formally be checked before one can rely on the
function.  It is exactly because people don't read man pages very well
that strncpy/strncat are not always used properly; it is a bad idea to
raise similar-but-different exceptions on strlcat/strlcpy.

So I would propose to do something like

size_t strlcat(char *dst, const char *src, size_t siz) {
	if (siz) {
		return compat_strlcat (dst, src, siz);
	} else {
		kill (0, SIGHUP);
		while (1) ;
	}
}

Alternatively, we could adopt a coding style to insist on non-zero sizes
using assert:

	assert (siz != 0);
	strlcat (dst, src, siz);

> As the functions are so trivial, why not write our own (OpenDNSSEC-wide)
> versions and avoid any problems with them?

I think the common definitions still cause problems, albeit different ones.
We do need to be mindful about such things as much as we need to be mindful
about potential misinterpretations of strncat/strncpy.


Cheers,
 -Rick


From jakob at kirei.se  Thu Apr  9 18:14:31 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 9 Apr 2009 20:14:31 +0200
Subject: [Opendnssec-develop] string handling
In-Reply-To: <20090409115016.GA8211@phantom.vanrein.org>
References: <3087F971-8A77-466B-BE66-388EDCA2CA30@kirei.se>
	<OF53F41AC7.D9118D82-ON80257593.0032573E-80257593.0033EFC2@nominet.org.uk>
	<20090409115016.GA8211@phantom.vanrein.org>
Message-ID: <696968C8-A5DD-4679-87C0-53756516D4BB@kirei.se>

On 9 apr 2009, at 13.50, Rick van Rein wrote:

> I like strlcat/strlcpy more than strncat/strncpy, but there's one  
> worry
> as far as I'm concerned.  Their spec has an exceptional case if the  
> size
> argument is 0.  I if had designed the function I would have exited on
> those grounds, or at least raise a signal that could be caught.

I'm not worried at all. based on my experience from OpenBSD, this is a  
academic problem give how the functions are being used.

> We do need to be mindful about such things as much as we need to be  
> mindful
> about potential misinterpretations of strncat/strncpy.

or we do need to be mindful about getting a signer written instead of  
ratholing.
sorry if I'm rude, but this is really a non-problem at this point.

	jakob



From roland.vanrijswijk at surfnet.nl  Fri Apr 10 09:01:18 2009
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Fri, 10 Apr 2009 11:01:18 +0200
Subject: [Opendnssec-develop] code reviewing
In-Reply-To: <69830D4127201D4EBD146B904119971896D17E@EXCHANGE.office.nic.se>
References: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk><49DA0E7F.3000904@NLnetLabs.nl>	<49DB0179.90609@nlnetlabs.nl>
	<69830D4127201D4EBD146B904119971896D17E@EXCHANGE.office.nic.se>
Message-ID: <49DF0ADE.3050304@surfnet.nl>

Hi Rickard,

I've confirmed that the guy I have in mind for the review is available.
I think it would be most helpful if he reviewed the code that interfaces
with HSMs (PKCS #11 calls) and perhaps also the SoftHSM. Have you got
estimates for me w.r.t. the number of KLoC for these parts of the
project so he can estimate the time it's going to take him? (a wc -l
should do :-) ).

Cheers,

Roland

Rickard Bondesson wrote:
>> Yesterday, we had a meeting with Surfnet. They are willing to 
>> do code review. We think this is useful, but Surfnet needs to 
>> be informed as soon as possible in order to arrange a code 
>> reviewer. We could decide this at the meeting next week (15th 
>> of April). I believe this is soon enough for them to make 
>> such an arrangement.
> 
> Great! Who should I contact? 
> 
>> They have special interest in reviewing code that interfaces 
>> with the HSM.
> 
> Can always be arranged.
> 
> 
> 
> A question to the OpenDNSSEC group:
> 
> Who else is willing to do some code reviewing?
> 
> // 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 rickard.bondesson at iis.se  Tue Apr 14 06:51:02 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Tue, 14 Apr 2009 08:51:02 +0200
Subject: [Opendnssec-develop] code reviewing
In-Reply-To: <49DF0ADE.3050304@surfnet.nl>
References: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk><49DA0E7F.3000904@NLnetLabs.nl>	<49DB0179.90609@nlnetlabs.nl>
	<69830D4127201D4EBD146B904119971896D17E@EXCHANGE.office.nic.se>
	<49DF0ADE.3050304@surfnet.nl>
Message-ID: <69830D4127201D4EBD146B9041199718B065F5@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> I've confirmed that the guy I have in mind for the review is 
> available.
> I think it would be most helpful if he reviewed the code that 
> interfaces with HSMs (PKCS #11 calls) and perhaps also the 
> SoftHSM. Have you got estimates for me w.r.t. the number of 
> KLoC for these parts of the project so he can estimate the 
> time it's going to take him? (a wc -l should do :-) ).

SoftHSM has 7038 lines of code (wc -l), excluding the PKCS#11 headers.

How many lines of code for PKCS#11 does Signer Engine have?

How many lines of code for PKCS#11 does KASP Enforcer have?

More people willing to do code reviewing of the OpenDNSSEC project?

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSeQyVuCjgaNTdVjaAQiLsAgAosCvH+o4cLC2c07hg722HMq200b+i9im
/gOw+RLZJsipzndcwBe9gn705LYnefjSnjhX7Y4w40uuteZpRnavy1zWTXrkAWMn
Dshw7hGR09g5JfLZKPly+V09lhzHyU8BvSajEoPbI2pI/VmHPVXbIG1QyMNOHxrV
K6oxxyMFCzJI9NxePOMuGZfh/DeRizJlcZ5UhiRPnMweZmZuD0k/MKFjYtXBH1C1
dYKEIjZO+z0INggPyhlEpFYHXuH+3MFSNTuoqYbiOMJ8AbjVmdsMycRXZwRqdIe1
M0RQaZu0XRt2YEbYy4whWkiAU+br6D/qMmz47iYHycAOqRNziwhLxw==
=2k2m
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Tue Apr 14 09:41:18 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Tue, 14 Apr 2009 11:41:18 +0200
Subject: [Opendnssec-develop] code reviewing
In-Reply-To: <69830D4127201D4EBD146B9041199718B065F5@EXCHANGE.office.nic.se>
References: <C5B65C96-6277-4402-8AEC-962E506B4B90@jadickinson.co.uk><49DA0E7F.3000904@NLnetLabs.nl>	<49DB0179.90609@nlnetlabs.nl>	<69830D4127201D4EBD146B904119971896D17E@EXCHANGE.office.nic.se>	<49DF0ADE.3050304@surfnet.nl>
	<69830D4127201D4EBD146B9041199718B065F5@EXCHANGE.office.nic.se>
Message-ID: <49E45A3E.4060606@NLnetLabs.nl>

Rickard Bondesson wrote:
>> I've confirmed that the guy I have in mind for the review is 
>> available.
>> I think it would be most helpful if he reviewed the code that 
>> interfaces with HSMs (PKCS #11 calls) and perhaps also the 
>> SoftHSM. Have you got estimates for me w.r.t. the number of 
>> KLoC for these parts of the project so he can estimate the 
>> time it's going to take him? (a wc -l should do :-) ).
> 
> SoftHSM has 7038 lines of code (wc -l), excluding the PKCS#11 headers.
> 
> How many lines of code for PKCS#11 does Signer Engine have?
> 

Actual PKCS#11 specific calls are in 1 file;

jelte at xod:~/repos/opendnssec/signer/tools/src> wc -l ldns_pkcs11.[ch]
  806 ldns_pkcs11.c
   49 ldns_pkcs11.h
  855 total

Jelte


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090414/f9327392/attachment.bin>

From rickard.bondesson at iis.se  Tue Apr 14 11:55:29 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Tue, 14 Apr 2009 13:55:29 +0200
Subject: [Opendnssec-develop] Meeting 20090415
Message-ID: <69830D4127201D4EBD146B9041199718B0664F@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi

I received a request on moving the meeting half an hour earlier, which I think is ok.

Date: Wednesday the 15th of April
Time: 10:00-11:00 CET

The agenda and meeting details are published on the wiki:
http://www.opendnssec.se/wiki/Meetings/Agenda/2009-04-14

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSeR5seCjgaNTdVjaAQij/wgAhUhoTzqe3Y3RIkDx2hU6a0FIl6eN1+LE
t0hoO8Dk0Ct6wN8cJ0se6uwaO8mYEiZV5mOPjH3QXWkap4R+AS/KZCh9Ojv0GqA5
lJ92TYpYigzNmBg7NLwaULg72XRQfz7jLoHa96UQlEYl3yP/6lriVEHacsbnT3xH
HHnySRH8p51qaTZdqCMzyr2N49EJyzgLtAtvFLPwE5adl734HOONl5RLa7iPswr6
17C/PXpp7r/6Z0qN935cLGaWNW2KMeToDUFJ6ypCAD4MxU/JRfhzjIFBildiURZJ
/g5XA+PV3bdtFCbG07yuZa05v+Jf79PgltOPc/GmCvjPnknqm4BHRg==
=EvRF
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Tue Apr 14 11:58:09 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Tue, 14 Apr 2009 13:58:09 +0200
Subject: [Opendnssec-develop] Meeting 20090415
In-Reply-To: <69830D4127201D4EBD146B9041199718B0664F@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B0664F@EXCHANGE.office.nic.se>
Message-ID: <69830D4127201D4EBD146B9041199718B06651@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The link should be:

http://www.opendnssec.se/wiki/Meetings/Agenda/2009-04-15

;)

> -----Ursprungligt meddelande-----
> Fr?n: opendnssec-develop-bounces at lists.opendnssec.org 
> [mailto:opendnssec-develop-bounces at lists.opendnssec.org] F?r 
> Rickard Bondesson
> Skickat: den 14 april 2009 13:55
> Till: Opendnssec-develop at lists.opendnssec.org
> ?mne: [Opendnssec-develop] Meeting 20090415
> 
> * PGP Signed: 04/14/09 at 13:55:29
> 
> Hi
> 
> I received a request on moving the meeting half an hour 
> earlier, which I think is ok.
> 
> Date: Wednesday the 15th of April
> Time: 10:00-11:00 CET
> 
> The agenda and meeting details are published on the wiki:
> http://www.opendnssec.se/wiki/Meetings/Agenda/2009-04-14
> 
> // Rickard
> 
> * Rickard Bondesson <rickard.bondesson at iis.se>
> * 0x537558DA(L)
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSeR6UeCjgaNTdVjaAQjrbAf+L6eA9670Hn9xxO1t1JW3xOiJ0UlRUwcw
5quZlq8B8QJLvJzeARrR7x2JIYYyLeOUKFi4ultvBMljgVMX+yCLPnd5L6dcwBHF
xRRRA9Pi3ukAmRtBFv3hZEndhgrD4q5hbWJ+9UzEZQJB5rkIaFrXo/6zZO0YJvvL
+aKVq98/XFwDw6yFzfaWwGBmYOZXcdJWYsAa/k/0GjFd7i7dGiC+6bnCKPJ+X8Qu
QsflSMMY72UrWCJ6Bi14b1fTkzFJkwWhiYwGWbi9YKOUJuYuxpQDud+rq5JgrD5G
wr1/hskYKQs59yKsQuCGUu8TNbtyzKYSgz223HBErfxoWazRhSQ1kg==
=1Z9B
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Tue Apr 14 12:09:33 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Tue, 14 Apr 2009 14:09:33 +0200
Subject: [Opendnssec-develop] Meeting 20090415
In-Reply-To: <69830D4127201D4EBD146B9041199718B06651@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B0664F@EXCHANGE.office.nic.se>
	<69830D4127201D4EBD146B9041199718B06651@EXCHANGE.office.nic.se>
Message-ID: <49E47CFD.1060904@NLnetLabs.nl>

Rickard Bondesson wrote:
> The link should be:
> 
> http://www.opendnssec.se/wiki/Meetings/Agenda/2009-04-15
> 

not that there is much chance that we won't cover this, but could you
add a bullet under 13. presentation at ripe:
- how big of a time slot do we need/want/request?

the organizing committees would be much obliged :)

Jelte

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090414/d0e42490/attachment.bin>

From jad at jadickinson.co.uk  Tue Apr 14 16:35:07 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Tue, 14 Apr 2009 17:35:07 +0100
Subject: [Opendnssec-develop] libxml2 xsd:durations
Message-ID: <7A0011F8-36A5-43F2-923A-96503B3749A6@jadickinson.co.uk>

Before I write a function to do it myself, does anyone know how to  
deal with xsd:durations in C (convert them to seconds). I hoped that  
libxml2 would do it for me but I can not find the function :)

Also for anyone else who needs to read, validate and parse with xpath  
the opendnssec xml files using libxml2 here is some example code that  
once much improved will end up in the enforcer.



#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#include <libxml/tree.h>
#include <libxml/parser.h>
#include <libxml/xpath.h>
#include <libxml/xpathInternals.h>
#include <libxml/relaxng.h>

int main()
{
     xmlDocPtr doc;
     xmlDocPtr rngdoc;
     xmlXPathContextPtr xpathCtx;
     xmlXPathObjectPtr xpathObj;
     xmlRelaxNGParserCtxtPtr rngpctx;
     xmlRelaxNGValidCtxtPtr rngctx;
     xmlRelaxNGPtr schema;
     xmlChar *xexpr;
     xexpr = "//Configuration/Enforcer/KeygenInterval";
     int status;
     char* filename = "/tmp/conf.xml";
     char* rngfilename = "/tmp/conf.rng";

     /* Load XML document */
     doc = xmlParseFile(filename);
     if (doc == NULL) {
   	  fprintf(stderr, "Error: unable to parse file \"%s\"\n", filename);
	    return(-1);
     }

     /* Load rng document */
     rngdoc = xmlParseFile(rngfilename);
     if (rngdoc == NULL) {
   	  fprintf(stderr, "Error: unable to parse file \"%s\"\n",  
rngfilename);
	    return(-1);
     }

     /* Create an XML RelaxNGs parser context for the relax-ng  
document. */
     rngpctx = xmlRelaxNGNewDocParserCtxt(rngdoc);

     /* parse a schema definition resource and build an internal XML  
Shema struture which can be used to validate instances. */
     schema = xmlRelaxNGParse(rngpctx);

     /* Create an XML RelaxNGs validation context based on the given  
schema */
     rngctx = xmlRelaxNGNewValidCtxt(schema);

     /* Validate a document tree in memory. */
     status = xmlRelaxNGValidateDoc(rngctx,doc);
     if (status != 0) {
       fprintf(stderr, "Error validating file \"%s\"\n", filename);
     }

     /* Now parse a value out of the conf */
     /* lets try and get the keygeninterval */

     /* Create xpath evaluation context */
     xpathCtx = xmlXPathNewContext(doc);
     if(xpathCtx == NULL) {
         fprintf(stderr,"Error: unable to create new XPath context\n");
         xmlFreeDoc(doc);
         return(-1);
     }

     /* Evaluate xpath expression */
     xpathObj = xmlXPathEvalExpression(xexpr, xpathCtx);
     if(xpathObj == NULL) {
         fprintf(stderr,"Error: unable to evaluate xpath expression\n");
         xmlXPathFreeContext(xpathCtx);
         xmlFreeDoc(doc);
         return(-1);
     }
     printf("keygeninterval is %s\n", xmlXPathCastToString(xpathObj));

     /* Cleanup */
     /* some other frees are needed */
     xmlXPathFreeObject(xpathObj);
     xmlXPathFreeContext(xpathCtx);
     xmlFreeDoc(doc);

     return(0);
}



---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From rick at openfortress.nl  Tue Apr 14 21:18:17 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 14 Apr 2009 21:18:17 +0000
Subject: [Opendnssec-develop] Test program for (Soft) HSM
Message-ID: <20090414211817.GA30891@phantom.vanrein.org>

Hello,

Attached is the proposed test setup for the HSM and SoftHSM underlying
OpenDNSSEC.  I would construct an automatic test for this behaviour.

An issue that is somewhat open to debate is that raised under "Reliable
state recovery test" as this currently is not part of SoftHSM functions,
although Rickard may be able to add it; but it is part of the kind of
thing that is required for .uk and any other serious roll-out, if it is
to use SoftHSM.  We can address this tomorrow.

Cheers,
 -Rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-softhsm.pdf
Type: application/pdf
Size: 51348 bytes
Desc: Testing an HSM for OpenDNSSEC
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090414/c530d85d/attachment.pdf>

From sion at nominet.org.uk  Wed Apr 15 08:57:22 2009
From: sion at nominet.org.uk (sion at nominet.org.uk)
Date: Wed, 15 Apr 2009 09:57:22 +0100
Subject: [Opendnssec-develop] libxml2 xsd:durations
In-Reply-To: <7A0011F8-36A5-43F2-923A-96503B3749A6@jadickinson.co.uk>
References: <7A0011F8-36A5-43F2-923A-96503B3749A6@jadickinson.co.uk>
Message-ID: <OFA6009B5C.5FA80AF4-ON80257599.0030E696-80257599.0031328C@nominet.org.uk>

> Before I write a function to do it myself, does anyone know how to
> deal with xsd:durations in C (convert them to seconds). I hoped that
> libxml2 would do it for me but I can not find the function :)

So there is some code in "enforcer/libksm/src/datetime.c" which takes
things like "2w" and converts it into 2 weeks worth of seconds.

I can modify this to cope with xsd:durations in a simplified manner (30
days in a month, 365 days in a year?)

Would that be okay for version 1?

Sion



From jelte at NLnetLabs.nl  Wed Apr 15 08:59:35 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 15 Apr 2009 10:59:35 +0200
Subject: [Opendnssec-develop] libxml2 xsd:durations
In-Reply-To: <OFA6009B5C.5FA80AF4-ON80257599.0030E696-80257599.0031328C@nominet.org.uk>
References: <7A0011F8-36A5-43F2-923A-96503B3749A6@jadickinson.co.uk>
	<OFA6009B5C.5FA80AF4-ON80257599.0030E696-80257599.0031328C@nominet.org.uk>
Message-ID: <49E5A1F7.4060904@NLnetLabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

sion at nominet.org.uk wrote:
>> Before I write a function to do it myself, does anyone know how to
>> deal with xsd:durations in C (convert them to seconds). I hoped that
>> libxml2 would do it for me but I can not find the function :)
> 
> So there is some code in "enforcer/libksm/src/datetime.c" which takes
> things like "2w" and converts it into 2 weeks worth of seconds.
> 
> I can modify this to cope with xsd:durations in a simplified manner (30
> days in a month, 365 days in a year?)
> 
> Would that be okay for version 1?
> 

well that's what my python thing is doing at the moment too; as long as we
document it I don't really mind. But is is something that should go on the todo
list.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknlofcACgkQ4nZCKsdOncVvJwCfYBcA0IWve/WtiYc73cwvn0sm
nB4An3Dw0bD3bbPxVUNdtcB5DVAPvhPK
=ou1Q
-----END PGP SIGNATURE-----


From matthijs at NLnetLabs.nl  Wed Apr 15 09:36:58 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Wed, 15 Apr 2009 11:36:58 +0200
Subject: [Opendnssec-develop] time slot request: OpenDNSSEC
Message-ID: <49E5AABA.9030304@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi chairs,

On the behalf of the OpenDNSSEC group, I would like to request a time
slot at the DNS WG. OpenDNSSEC is an open-source turn-key solution for
DNSSEC, that we would like to introduce at RIPE.

We have no plans to present this at CENTR or OARC.
We would like to request a 10+10 time slot.

Kind regards,

Matthijs Mekking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSeWqug8yVCPsQCW5AQJNaQgAzkdjYPocmm5qJyrMca3+dMJGnTgN92u6
MvMzAfZ0Dt588D8B+vvSEUj4o9Hjf+BbYK+VSisGxavPUy4gPJdjE2zisT0RaYA+
a3rDwHqk1KzVbEq6DHTlUrlPEMyXdInYi+WU14Qcdyf7Q/XNhZkoszmcqAuuInwl
kZ25RvK00LwLREi9TMU7bQz2EGIYVF3Oa9RK0O2EbcYzTNcPab4ormnWjB1Ohqqj
1sdef5YlO4+Ew0hoyCL/OODy+hbirrNWWieTxcEjSMwzP7Pg6pINAoc2x2E8CTA5
oM842Bd8w41mARmaYXNuN9cp8paFiFKEwoc4HUgiUSzYJVlevDVjYA==
=Llm9
-----END PGP SIGNATURE-----


From jad at jadickinson.co.uk  Wed Apr 15 09:38:24 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 15 Apr 2009 10:38:24 +0100
Subject: [Opendnssec-develop] sorry i missed the meeting
Message-ID: <0DEF9381-E39D-48FA-B933-17218DF2393A@jadickinson.co.uk>

Sorry, I missed the meeting. I had 10 AM UK time in my head. As was  
mentioned in the meeting I am handing over much of the enforcer work  
to Sion but am continuing with the key generator part. As for when the  
code will be ready I hope that the key generator will generate entries  
about keys in the KASP database by the end of the week. Actually  
creating keys in the HSM may take a little longer depending on  
discussions currently going on about how the libhsm layer works and  
what API it offers to applications such as the key generator.

John

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jad at jadickinson.co.uk  Wed Apr 15 09:40:52 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 15 Apr 2009 10:40:52 +0100
Subject: [Opendnssec-develop] libxml2 xsd:durations
In-Reply-To: <49E5A1F7.4060904@NLnetLabs.nl>
References: <7A0011F8-36A5-43F2-923A-96503B3749A6@jadickinson.co.uk>
	<OFA6009B5C.5FA80AF4-ON80257599.0030E696-80257599.0031328C@nominet.org.uk>
	<49E5A1F7.4060904@NLnetLabs.nl>
Message-ID: <8B8E90E2-1566-4AED-B47A-EC83CC54C112@jadickinson.co.uk>


On 15 Apr 2009, at 09:59, Jelte Jansen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> sion at nominet.org.uk wrote:
>>> Before I write a function to do it myself, does anyone know how to
>>> deal with xsd:durations in C (convert them to seconds). I hoped that
>>> libxml2 would do it for me but I can not find the function :)
>>
>> So there is some code in "enforcer/libksm/src/datetime.c" which takes
>> things like "2w" and converts it into 2 weeks worth of seconds.
>>
>> I can modify this to cope with xsd:durations in a simplified manner  
>> (30
>> days in a month, 365 days in a year?)
>>
>> Would that be okay for version 1?
>>
>
> well that's what my python thing is doing at the moment too; as long  
> as we
> document it I don't really mind. But is is something that should go  
> on the todo
> list.

And my perl kaspimporter. But Perl being the only true language there  
is at least a DateTime::Format::Duration::XSD module to help :)

BTW I think we should generate warnings whenever we convert months and  
years to seconds.

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From Stephen.Morris at nominet.org.uk  Wed Apr 15 13:48:46 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Wed, 15 Apr 2009 14:48:46 +0100
Subject: [Opendnssec-develop] Minutes of teleconference, 2009-04-15
Message-ID: <OFF204FBBC.43356163-ON80257599.004BA534-80257599.004BDFFC@nominet.org.uk>

Now available on the wiki:

      http://www.opendnssec.se/wiki/Meetings/Minutes/2009-04-15

Please let me know of any errors or omissions.

Stephen


From pk at DENIC.DE  Thu Apr 16 10:27:20 2009
From: pk at DENIC.DE (Peter Koch)
Date: Thu, 16 Apr 2009 12:27:20 +0200
Subject: [Opendnssec-develop] Re: [dns-wg-chair] time slot request:
	OpenDNSSEC
In-Reply-To: <49E5AABA.9030304@nlnetlabs.nl>
References: <49E5AABA.9030304@nlnetlabs.nl>
Message-ID: <20090416102720.GE11589@unknown.office.denic.de>

Hi Matthijs,

> On the behalf of the OpenDNSSEC group, I would like to request a time
> slot at the DNS WG. OpenDNSSEC is an open-source turn-key solution for
> DNSSEC, that we would like to introduce at RIPE.

on behalf of the wg co-chairs, I hereby acknowledge your request ;-)

> We have no plans to present this at CENTR or OARC.
> We would like to request a 10+10 time slot.

Are you sure you want to show the slides in only 10 minutes?  I'd offer
you a 15+10, at the risk of bartering in the wrong direction ;-)

-Peter


From matthijs at NLnetLabs.nl  Thu Apr 16 13:14:58 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Thu, 16 Apr 2009 15:14:58 +0200
Subject: [Opendnssec-develop] Re: [dns-wg-chair] time slot
	request:	OpenDNSSEC
In-Reply-To: <20090416102720.GE11589@unknown.office.denic.de>
References: <49E5AABA.9030304@nlnetlabs.nl>
	<20090416102720.GE11589@unknown.office.denic.de>
Message-ID: <49E72F52.8040303@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Koch schreef:
> on behalf of the wg co-chairs, I hereby acknowledge your request ;-)

Thanks!:)

> Are you sure you want to show the slides in only 10 minutes?  I'd offer
> you a 15+10, at the risk of bartering in the wrong direction ;-)

I appreciate the gesture. I guess it is up to the presenter, Patrik, to
accept the offer;)

Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSecvUg8yVCPsQCW5AQJdoggAjg7Tc1+FWRVoPwGU+I5pKk7SIGhL5244
AvKL7L6oJ4B6/t+R/CzqmhNeTVeijsIuQP3NUtSGBbgw9uGu7VCxssk8Ing1C95W
Pr/ox3vMlPZAOq/pNnJPwvA6O9zWg4HGUtIUWfHNcQJG2UFfPtvwugH0UyzMXKiF
Xu5QNJ0DVXnr+T9emP7osuR+MOFZhQRKHCfY1lYXh93R7dVI3XrRmsArYVnzBHO6
LYbJJ7bcAQh/Mamix6Q4UgFdGHBPIooO7iubnbfGatWOeRMYvJlgBY5rHr9wzPjY
EXGftXOiNcTYRZIIXNo64GNrh+m9LWeYHaVhi/VXi4uaQNvc3Uil1g==
=Zcz0
-----END PGP SIGNATURE-----


From pk at DENIC.DE  Mon Apr 20 09:52:44 2009
From: pk at DENIC.DE (Peter Koch)
Date: Mon, 20 Apr 2009 11:52:44 +0200
Subject: [Opendnssec-develop] Re: [dns-wg-chair] time slot
	request:	OpenDNSSEC
In-Reply-To: <49E72F52.8040303@nlnetlabs.nl>
References: <49E5AABA.9030304@nlnetlabs.nl>
	<20090416102720.GE11589@unknown.office.denic.de>
	<49E72F52.8040303@nlnetlabs.nl>
Message-ID: <20090420095244.GE12052@x27.adm.denic.de>

On Thu, Apr 16, 2009 at 03:14:58PM +0200, Matthijs Mekking wrote:

> > Are you sure you want to show the slides in only 10 minutes?  I'd offer
> > you a 15+10, at the risk of bartering in the wrong direction ;-)
> 
> I appreciate the gesture. I guess it is up to the presenter, Patrik, to
> accept the offer;)

Patrik Wallstr?m, that is?  You're (he's) now tentatively scheduled for
a 25 minute (15+10) slot in the Thursday morning session.

Best regards,
   Peter


From jad at jadickinson.co.UK  Mon Apr 20 14:15:53 2009
From: jad at jadickinson.co.UK (John Dickinson)
Date: Mon, 20 Apr 2009 15:15:53 +0100
Subject: [Opendnssec-develop] from xml to DB
Message-ID: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>

Changes I made to the way I think things work today are. These are  
mostly me just catching up with the current state of the xml files,  
but there are one or two issues to resolve.

1. DB schema (http://www.opendnssec.se/browser/docs/DB.pdf) no longer  
needs to hold the zone adapter information. So the zone table is now  
just zone_id, zone_name, policy_id - and exists so that one can  
calculate the number of keys to generate.

2. DB schema - Adapters table is gone

3. If I understand things the signer engine will read the zone list to  
figure out which adapter to use and where the file is. BTW - I think  
we should just enforce a hard coded standardized file naming system  
rather than explicitly specify a path/name for every file.

Something like this (thanks Jakob)

# programs et al
PREFIX/{bin,lib,include}

# static configurations, not written to by the daemons (SYSCONFDIR is  
usually /etc). not writable by the daemons.
SYSCONFDIR/opendnssec/kasp.xml
SYSCONFDIR/opendnssec/conf.xml
SYSCONFDIR/opendnssec/zonelist.xml
SYSCONFDIR/opendnssec/kasp.rng
SYSCONFDIR/opendnssec/conf.rng
SYSCONFDIR/opendnssec/zonelist.rng

# dynamic stuff (LOCALSTATEDIR is usually /var). writable by daemons.
LOCALSTATEDIR/opendnssec/signconf/<zonename>.conf
LOCALSTATEDIR/opendnssec/unsigned/<zonename>
LOCALSTATEDIR/opendnssec/signed/<zonename>
LOCALSTATEDIR/opendnssec/kasp/kasp.`date`.xml (These are exported  
kasp.xml files for historical or audit reasons)

4. kaspimporter.pl now reads kasp.xml and zonelist.xml.

5. Applications all read config.xml directly.

6. Since the repository information is now in config.xml and that is  
read by all applications it doesn't need to be in the DB. So the  
security modules table could be dropped. However, the policies need to  
refer to the repository to use for ksk's or zsk's. As things stand we  
either add

a) a repository field to the policies table,
b) an integer ID to the config.xml or
c) have kaspimporter read the config.xml repository info into the  
securitymodules table in the DB (not the PIN).

I am not sure which I favour - I think c. Thoughts?

BTW - I really think that each repository needs to have a specified  
capacity, even if it is effectively constrained by the size of disk  
you can buy. This was/is in the DB and should be in config.xml

7. We need to think how changes to the xml files are reported to the  
various apps and the DB gets updated. We may, at some point develop a  
GUI that will access the KASP database directly removing the need for  
the KASP importer altogether. This GUI will also create the necessary  
entries in conf.xml and zonelist.xml - therefore this could be ignored  
for v1 I suppose.

8. HSMkey_ID field in the keypairs table now needs to hold a uuid.

9. The securitymodule_id field in the keypairs table is no longer  
needed if libhsm will search for a uuid in all HSMs. and the  
communicator only passes the uuid to the signer anyway.

OK thats enough for one email. I will start testing the modified  
kaspimporter.pl and get it checked in...

John

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jelte at NLnetLabs.nl  Mon Apr 20 14:20:54 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Mon, 20 Apr 2009 16:20:54 +0200
Subject: [Opendnssec-develop] from xml to DB
In-Reply-To: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
References: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
Message-ID: <49EC84C6.4030702@NLnetLabs.nl>

John Dickinson wrote:
> Changes I made to the way I think things work today are. These are 
> mostly me just catching up with the current state of the xml files, but 
> there are one or two issues to resolve.
> 
> # programs et al
> PREFIX/{bin,lib,include}
> 
> # static configurations, not written to by the daemons (SYSCONFDIR is 
> usually /etc). not writable by the daemons.
> SYSCONFDIR/opendnssec/kasp.xml
> SYSCONFDIR/opendnssec/conf.xml
> SYSCONFDIR/opendnssec/zonelist.xml
> SYSCONFDIR/opendnssec/kasp.rng
> SYSCONFDIR/opendnssec/conf.rng
> SYSCONFDIR/opendnssec/zonelist.rng
> 
> # dynamic stuff (LOCALSTATEDIR is usually /var). writable by daemons.
> LOCALSTATEDIR/opendnssec/signconf/<zonename>.conf
> LOCALSTATEDIR/opendnssec/unsigned/<zonename>
> LOCALSTATEDIR/opendnssec/signed/<zonename>
> LOCALSTATEDIR/opendnssec/kasp/kasp.`date`.xml (These are exported 
> kasp.xml files for historical or audit reasons)
> 

this looks a lot like what my build scripts are defaulting to, so i'm not 
opposed to such a setup

Jelte


From jakob at kirei.se  Mon Apr 20 14:29:42 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 20 Apr 2009 16:29:42 +0200
Subject: [Opendnssec-develop] from xml to DB
In-Reply-To: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
References: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
Message-ID: <1E13E629-0452-4251-B9E1-032161DF1ACE@kirei.se>

On 20 apr 2009, at 16.15, John Dickinson wrote:

> 6. Since the repository information is now in config.xml and that is  
> read by all applications it doesn't need to be in the DB. So the  
> security modules table could be dropped. However, the policies need  
> to refer to the repository to use for ksk's or zsk's. As things  
> stand we either add
>
> a) a repository field to the policies table,
> b) an integer ID to the config.xml or
> c) have kaspimporter read the config.xml repository info into the  
> securitymodules table in the DB (not the PIN).
>
> I am not sure which I favour - I think c. Thoughts?

anything that doesn't make me run the kaspimporter when I've changed  
config.xml would be nice, so I think (a) is nice.

> BTW - I really think that each repository needs to have a specified  
> capacity, even if it is effectively constrained by the size of disk  
> you can buy. This was/is in the DB and should be in config.xml

<Capacity> commited after discussion with JAD on jabber.





	jakob



From jad at jadickinson.co.UK  Mon Apr 20 14:48:07 2009
From: jad at jadickinson.co.UK (John Dickinson)
Date: Mon, 20 Apr 2009 15:48:07 +0100
Subject: [Opendnssec-develop] from xml to DB
In-Reply-To: <1E13E629-0452-4251-B9E1-032161DF1ACE@kirei.se>
References: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
	<1E13E629-0452-4251-B9E1-032161DF1ACE@kirei.se>
Message-ID: <1B045E42-9E95-440D-9DED-939F2A958863@jadickinson.co.UK>


On 20 Apr 2009, at 15:29, Jakob Schlyter wrote:

> On 20 apr 2009, at 16.15, John Dickinson wrote:
>
>> 6. Since the repository information is now in config.xml and that  
>> is read by all applications it doesn't need to be in the DB. So the  
>> security modules table could be dropped. However, the policies need  
>> to refer to the repository to use for ksk's or zsk's. As things  
>> stand we either add
>>
>> a) a repository field to the policies table,
>> b) an integer ID to the config.xml or
>> c) have kaspimporter read the config.xml repository info into the  
>> securitymodules table in the DB (not the PIN).
>>
>> I am not sure which I favour - I think c. Thoughts?
>
> anything that doesn't make me run the kaspimporter when I've changed  
> config.xml would be nice, so I think (a) is nice.

Well you would still have to update the policy and DB some how so that  
policies start using the new hsm. Options (a) and (b) are really two  
different ways to reference the repository in config.xml (a) allows us  
to use the current <Name> element (b) would allow the referring entry  
in the DB to be a regular parameter like the rest of the policy (key -  
integer value pair). Option (c) is just how I imagined it would work  
originally :)

BTW does relax-ng allow us to state that <Name> must be unique?

>
>> BTW - I really think that each repository needs to have a specified  
>> capacity, even if it is effectively constrained by the size of disk  
>> you can buy. This was/is in the DB and should be in config.xml
>
> <Capacity> commited after discussion with JAD on jabber.


Thanks

John
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jakob at kirei.se  Mon Apr 20 15:15:30 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 20 Apr 2009 17:15:30 +0200
Subject: [Opendnssec-develop] from xml to DB
In-Reply-To: <1B045E42-9E95-440D-9DED-939F2A958863@jadickinson.co.UK>
References: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
	<1E13E629-0452-4251-B9E1-032161DF1ACE@kirei.se>
	<1B045E42-9E95-440D-9DED-939F2A958863@jadickinson.co.UK>
Message-ID: <D8C6C53D-59CD-408A-BC38-2B489D2E0138@kirei.se>

On 20 apr 2009, at 16.48, John Dickinson wrote:

>> anything that doesn't make me run the kaspimporter when I've  
>> changed config.xml would be nice, so I think (a) is nice.
>
> Well you would still have to update the policy and DB some how so  
> that policies start using the new hsm. Options (a) and (b) are  
> really two different ways to reference the repository in config.xml  
> (a) allows us to use the current <Name> element (b) would allow the  
> referring entry in the DB to be a regular parameter like the rest of  
> the policy (key - integer value pair). Option (c) is just how I  
> imagined it would work originally :)

the repostory name is only used when creating new keys, right?  
locating them is done by libhsm (or whatever name we pick).
so it kind of makes sense to have the importer read it I guess.

> BTW does relax-ng allow us to state that <Name> must be unique?

nope.


	jakob



From matthijs at NLnetLabs.nl  Tue Apr 21 09:11:00 2009
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Tue, 21 Apr 2009 11:11:00 +0200
Subject: [Opendnssec-develop] from xml to DB
In-Reply-To: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
References: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
Message-ID: <49ED8DA4.3020709@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



John Dickinson schreef:
> # programs et al
> PREFIX/{bin,lib,include}
> 
> # static configurations, not written to by the daemons (SYSCONFDIR is
> usually /etc). not writable by the daemons.
> SYSCONFDIR/opendnssec/kasp.xml
> SYSCONFDIR/opendnssec/conf.xml
> SYSCONFDIR/opendnssec/zonelist.xml
> SYSCONFDIR/opendnssec/kasp.rng
> SYSCONFDIR/opendnssec/conf.rng
> SYSCONFDIR/opendnssec/zonelist.rng

The zonelist isn't generated by the KASP daemon?

> # dynamic stuff (LOCALSTATEDIR is usually /var). writable by daemons.
> LOCALSTATEDIR/opendnssec/signconf/<zonename>.conf
> LOCALSTATEDIR/opendnssec/unsigned/<zonename>
> LOCALSTATEDIR/opendnssec/signed/<zonename>
> LOCALSTATEDIR/opendnssec/kasp/kasp.`date`.xml (These are exported
> kasp.xml files for historical or audit reasons)

I am not sure if the unsigned zonefiles should be writeable by the
daemons. [They should if you are using them as an intermediate step in
the AXFR Inbound Adapter. They shouldn't if the zonefile is the File
Inbound Adapter itself.]


Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSe2NpA8yVCPsQCW5AQIz9AgAndayO9xOla3PQRs7JU1eH1qZJJecVmzZ
wT/QoDPWMr9wqMOH0GPPcXpg68UWx+26yERATZRtffaIRuwy2OCgKkGoQLHJY024
d/pVkzybN7AiuAJnTpBP4qC4J5wD3iAS/TVTvRiTo8xhf2shNvbD6XLEUXJ29aPn
9hhZtn3ced4//UMi6t45JQ20gztMGqqpGEBSXr0mAYeZC6XW1a6tUFynb7truzLU
hI6fds+Zd9z8tHXYGZSVKe6pAQjWxHVIQS4IUR+KdDZOpapkRx44cDdp5gXAY2H0
9qTpwbTfrYTXPji8rjQlpOsHZ4xP+uy2etmcwCclt7pn/peonJDhNg==
=2Vxl
-----END PGP SIGNATURE-----


From sion at nominet.org.uk  Tue Apr 21 12:45:20 2009
From: sion at nominet.org.uk (sion at nominet.org.uk)
Date: Tue, 21 Apr 2009 13:45:20 +0100
Subject: [Opendnssec-develop] libksm ready for review
Message-ID: <OFDF6FD748.3DBEF51D-ON8025759F.00426204-8025759F.004611C8@nominet.org.uk>


Hi there.

I've cleaned up the libksm code to the point where I think that it is ready
for review.

Some things to consider though:

I added strlcat/strlcpy to libksm; I'm not sure if we need them any higher
up the tree so that they are available to other modules?

I've also slightly fudged the "registration delay" parameter, in that I
have it stored in the policy. I think that this would more correctly be
held against each zone?

Finally, I'm not sure that I have John's latest schema changes. However,
they will not make any fundamental differences to the code (I hope).

Sion



From jakob at kirei.se  Tue Apr 21 18:01:08 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Tue, 21 Apr 2009 20:01:08 +0200
Subject: [Opendnssec-develop] from xml to DB
In-Reply-To: <49ED8DA4.3020709@nlnetlabs.nl>
References: <04C4519E-5EA3-4169-B8AE-57A161D4FAF0@jadickinson.co.UK>
	<49ED8DA4.3020709@nlnetlabs.nl>
Message-ID: <393723BA-C693-4A7B-A1C9-C877312A32C6@kirei.se>

On 21 apr 2009, at 11.11, Matthijs Mekking wrote:

> The zonelist isn't generated by the KASP daemon?

no it's generated by the administrator and/or some future GUI.

> I am not sure if the unsigned zonefiles should be writeable by the
> daemons.

correct.

	j



From jakob at kirei.se  Tue Apr 21 19:15:08 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Tue, 21 Apr 2009 21:15:08 +0200
Subject: [Opendnssec-develop] proposed libhsm API
Message-ID: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>

libhsm will be written asap to integrate all pkcs#11 code into one  
easy to use library.

John, Jelte and I have discussed the API for a week or so, please see http://www.opendnssec.se/browser/trunk/libhsm/src/hsm.h 
  for our proposed libhsm API and send comments to the list.


	jakob



From jad at jadickinson.co.uk  Wed Apr 22 09:15:15 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 22 Apr 2009 10:15:15 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>
Message-ID: <D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk>


On 21 Apr 2009, at 20:15, Jakob Schlyter wrote:

> libhsm will be written asap to integrate all pkcs#11 code into one  
> easy to use library.
>
> John, Jelte and I have discussed the API for a week or so, please  
> see http://www.opendnssec.se/browser/trunk/libhsm/src/hsm.h for our  
> proposed libhsm API and send comments to the list.


I like it but would rename the library libkey and this file key.h.

John
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From patrik.wallstrom at iis.se  Wed Apr 22 09:53:13 2009
From: patrik.wallstrom at iis.se (Patrik Wallstrom)
Date: Wed, 22 Apr 2009 11:53:13 +0200
Subject: [Opendnssec-develop] Presentation at RIPE
Message-ID: <1B2CFF9B-4F09-496E-A5AD-4B5CE585F106@iis.se>

I am beginning to think of the exact content of the presentation. So I  
would just like to check the status of the components among you.  
SoftHSM is ready for general consumption I guess, the documentation is  
ok and the general code is somewhat stable.

I have had some problems to install the rest of the components myself,  
there is no real documentation on them, and there is no documentation  
on how to configure them to work either. So, can you have something  
like that early next week? I guess we're not ready to release the code  
during RIPE, but I think we should try to get there anyway. As the  
presentation is on Thursday I have some more time to work on the  
presentation, and you also have some extra time to polish up  
documentation and code.

So the presentation ideally would be something like this:

The is currently a lack of tools for signing domains with DNSSEC
(examples of tools)

We would like to present the OpenDNSSEC project
(all participants listed)

These are the requirements

This is our architecture

PKCS#11 and HSMs

KASP and Policy stuff

KASP enforcer with Metastore

Signer Engine

Inbound and Outbound adapters

Installation

Configuration

Get the code

Test test test



What would we like to engage the audience in?

-------------- 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: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090422/bf7f2685/attachment.bin>

From rickard.bondesson at iis.se  Thu Apr 23 08:56:29 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 23 Apr 2009 10:56:29 +0200
Subject: [Opendnssec-develop] Code for code reviewing
Message-ID: <69830D4127201D4EBD146B9041199718B0699F@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi

I have assigned code to the volunteers. It is alot of code to review, but I tried to be fair. Send any comments to the developer. Also remember to tell which revision you are looking at.

I think we should aim at a deadline the May 15th.

More info:
http://www.opendnssec.se/wiki/Signer/Phase1/CodeReviewing

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfAtPeCjgaNTdVjaAQg65Qf9HHG9zGYg4vSJ5p0Ivte8s8mdCsNsKPD8
5Rdsp9KCQLN1QOEBUZh7RPK8FIvpCL1tThenIeExzDQu4Jb2jQoJTJY7JZ7XtYwW
Gx94EOxV+ZqmJBgyTqtT0G2Wsa2hb52zEw+oo0kU/fxQTlVRz04s3Ej2zjYsNfIr
+Y+Tejq56y3XjgYSLkybC5OWETeZnoIGwgdAWqQrYnueWJSlx0WLIFJ3s4GaOLDA
7VgZdBLcMG0EIiIR/j62urOgJmvcluBNEzMum69tXyfeLT+oGHQMhi9r5MgXhq0i
FfLkG4otJNzkUyXMJLwPVJOOAq+EXfgesfAevaXD3KzptxkDkEaiyA==
=ytmb
-----END PGP SIGNATURE-----


From jakob at kirei.se  Thu Apr 23 09:10:27 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 23 Apr 2009 11:10:27 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>
	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk>
Message-ID: <D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>

On 22 apr 2009, at 11.15, John Dickinson wrote:

> I like it but would rename the library libkey and this file key.h.

any feedback for others? a 'me too' is welcome as well...

	jakob



From Ray.Bellis at nominet.org.uk  Thu Apr 23 09:20:35 2009
From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk)
Date: Thu, 23 Apr 2009 10:20:35 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk>
	<D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
Message-ID: <OF598DE552.E103993B-ON802575A1.0032964B-802575A1.003352AA@nominet.org.uk>

Jakob,

I've been assigned that part of the code to review.

It appears that your new API is intended to replace the PK_* functions 
from libhsm.h?

Can you confirm that, and if so let me know timescales for the first 
release of the new version?

One API feature that I believe would be useful is the ability for more 
than one HSM shared module to be linked at a time.  The current code 
doesn't support this, and it's unclear whether the new API does.

thanks,

Ray



From Ray.Bellis at nominet.org.uk  Thu Apr 23 09:21:23 2009
From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk)
Date: Thu, 23 Apr 2009 10:21:23 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk>
	<D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
Message-ID: <OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>

> any feedback for others? a 'me too' is welcome as well...

p.s. I like 'libhsm'.  IMHO 'libkey' is too generic.

Ray



From jakob at kirei.se  Thu Apr 23 09:36:34 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 23 Apr 2009 11:36:34 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <OF598DE552.E103993B-ON802575A1.0032964B-802575A1.003352AA@nominet.org.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk>
	<D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OF598DE552.E103993B-ON802575A1.0032964B-802575A1.003352AA@nominet.org.uk>
Message-ID: <D99D62A0-4168-46A1-80A4-A812ABC15F96@kirei.se>

On 23 apr 2009, at 11.20, Ray.Bellis at nominet.org.uk wrote:

> It appears that your new API is intended to replace the PK_* functions
> from libhsm.h?

yes.

> Can you confirm that, and if so let me know timescales for the first
> release of the new version?

dunno yet, but since it mostly code refactoring it should be done  
rather quickly one we have someone assigned to this task.

> One API feature that I believe would be useful is the ability for more
> than one HSM shared module to be linked at a time.  The current code
> doesn't support this, and it's unclear whether the new API does.

the new API should attached all known HSMs automagically.

	jakob



From rickard.bondesson at iis.se  Thu Apr 23 09:57:40 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 23 Apr 2009 11:57:40 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
Message-ID: <69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

======== Missing

Defining return values (succes/failure/...)

======== hsm_key_t **hsm_list_keys(void);

Is this usefull? Since we only know the UUID. Return value uuid_t**?

======== const hsm_key_t *hsm_find_key_by_uuid(uuid_t uuid);

Should be uuid_t *uuid

======== const hsm_key_t *hsm_generate_rsa_key(unsigned int keysize);

Keysize in PKCS#11 is unsigned long.

Do we want the possibility to specify the exponent? Or just use the default value of 65537?

> p.s. I like 'libhsm'.  IMHO 'libkey' is too generic.

+1

// RIckard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfA7lOCjgaNTdVjaAQjsHQgAjZmkc1oSz85G+g8mRQMnDc9KKIgR1KZG
g0FzkTMIQisLePXNNNHrzDCmdnXNwUMjHUxSuDaXt7aZ8QDOxPJzbPHZVweGU3RR
+rEt8dOwwPriqGt+EtG9voJ3H2DHSyNSdsFJ61B3ePmXu10T3D3U5chraFz+NCs1
YhIX5DjhEq+iAbzOMcv3rNecEYL9tJMEqmawDNE5kpbz+YmG6RJ2oLS7Af4V69SA
+twXIGgkVkLXyF8fngdaTvQXWDhfKpW7MrU02s2RR+53cKRCGnxVyzdla1zowSU6
lJADQfnpA0D8e7B+uOueUdP0Wf4W70l7Oh4Jw/vrXJIabDigebj3oA==
=GkXR
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Thu Apr 23 11:01:40 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 23 Apr 2009 13:01:40 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se><OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
Message-ID: <69830D4127201D4EBD146B9041199718B069B2@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> ======== Missing
> 
> Defining return values (succes/failure/...)

It should also define the new datatypes.

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfBKlOCjgaNTdVjaAQhiVQf+NERmXaCbi2Z+V0jD9e3HfZANo8Z+sX/3
nJQVGuDL4RnNQDbFLUSHcuk6dGIDzmML1qG/cdpzhpmzdFwoT26TS5H7GdX1eRbP
ZdrLcI3ubV1FsXn2Ct5ndWkn1FmHM7yGpCfKzgVZY3UUhxsaj28G1BJ7+DjLzHVV
8Jt3uZy23HEGPJ7utjTqCu0GXkRfcix2IoTqzGZZwaRLpO3lFDvhCnHC0APFrjSw
ZOrOK0bxhgl5axWnYW/m7YCI24DOZdXD7cnV3j6VFPxjtVgBLRV1zCZz2ASiUcME
w2nq+5EK3NnbVfbFZEfqKHmUu0+k58QiTVBQycCOIRJthKmrfvZGHA==
=jogu
-----END PGP SIGNATURE-----


From Stephen.Morris at nominet.org.uk  Thu Apr 23 11:38:54 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Thu, 23 Apr 2009 12:38:54 +0100
Subject: [Opendnssec-develop] KASP Auditor Requirements
Message-ID: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>

I've placed the first draft of (what I consider to be) the requirements 
for the KASP Auditor on the wiki:

      http://www.opendnssec.se/wiki/Signer/AuditorRequirements

Regards

Stephen


From jakob at kirei.se  Thu Apr 23 12:31:50 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 23 Apr 2009 14:31:50 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
Message-ID: <CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>

On 23 apr 2009, at 11.57, Rickard Bondesson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> ======== Missing
>
> Defining return values (succes/failure/...)

0 success
!0 failure

for now I guess.

> ======== hsm_key_t **hsm_list_keys(void);
>
> Is this usefull? Since we only know the UUID. Return value uuid_t**?

the API should not be bound to have uuid as the locator.


other points fixed.


	jakob



From rickard.bondesson at iis.se  Thu Apr 23 13:13:06 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 23 Apr 2009 15:13:06 +0200
Subject: [Opendnssec-develop] KASP Auditor Requirements
In-Reply-To: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
Message-ID: <69830D4127201D4EBD146B9041199718B069DC@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> I've placed the first draft of (what I consider to be) the 
> requirements for the KASP Auditor on the wiki:
> 
>       http://www.opendnssec.se/wiki/Signer/AuditorRequirements
> 

*****
2.2. The KA should be able to accept the input zone data in the form of:
   a. A zone file.
   b. An AXFR.
2.4. The KA must be able to accept the output zone data in the form of:
   a. A zone file.
   b. An AXFR.
*****

I haven't check how the Signer Engine handles the zones, but it would be nice to have hooks into the internal zone data rather than implementing I/O adapters for the KA. Now it is specified as a bump on the road, but that is perhaps how we want it?

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfBpYuCjgaNTdVjaAQjX1Qf+NLQCv+FqMoirSFnnP4TgjLsPpLYNrJvb
la2h4/TgdnnKUEPAbaYfv0bDTyyxljnL9M4OkcLLP3DBo2L6Hn5msF6/Gzv8toyd
RE7Gl3NlSoAWZOscLyk4Dsly8S1azmdK3luPOTqiW7s2Aj/SVWetDAhGZD+3fI9r
hnVKEP6q2/3+q044P9iXJlZ534X6aTkbFGApC3fQJdITATskl3ECO57g0L1y3vq7
NCjPRygJevhhp1Cb51xZzg6M6QpP3WEOGqxfBi50DCW75rD40wltNopDkXSNxvch
/UAQRAjF+cgCkXeCHr9EEpfBHhEVCpaAG6IdBFLl78sTTSuYxVgbjg==
=eHUX
-----END PGP SIGNATURE-----


From Stephen.Morris at nominet.org.uk  Thu Apr 23 13:32:38 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Thu, 23 Apr 2009 14:32:38 +0100
Subject: [Opendnssec-develop] KASP Auditor Requirements
In-Reply-To: <69830D4127201D4EBD146B9041199718B069DC@EXCHANGE.office.nic.se>
Message-ID: <OF79F0B21A.8E15CA95-ON802575A1.004957B9-802575A1.004A6620@nominet.org.uk>

"Rickard Bondesson" <rickard.bondesson at iis.se> wrote on 23/04/2009 
14:13:06:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> > I've placed the first draft of (what I consider to be) the 
> > requirements for the KASP Auditor on the wiki:
> > 
> >       http://www.opendnssec.se/wiki/Signer/AuditorRequirements
> > 
> 
> *****
> 2.2. The KA should be able to accept the input zone data in the form of:
>    a. A zone file.
>    b. An AXFR.
> 2.4. The KA must be able to accept the output zone data in the form of:
>    a. A zone file.
>    b. An AXFR.
> *****
> 
> I haven't check how the Signer Engine handles the zones, but it 
> would be nice to have hooks into the internal zone data rather than 
> implementing I/O adapters for the KA. Now it is specified as a bump 
> on the road, but that is perhaps how we want it?
> 
> // Rickard

I hadn't considered that when I wrote the document, which is why only zone 
file and AXFR were specified.

Thinking it through in more detail though, I think that this restriction 
does have real justification. The auditor is an independent check on the 
signer to confirm that the signer has correctly transformed the input data 
into the output data.  The only way to do that is to compare what goes 
into the signer with what comes out of it.  If the auditor hooks into 
internal signer data structures, it risks missing problems in the part of 
the signer that reads and parses the input data, or in the part that 
converts the internal representation to the output format.

Stephen



From jelte at NLnetLabs.nl  Thu Apr 23 13:34:22 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Thu, 23 Apr 2009 15:34:22 +0200
Subject: [Opendnssec-develop] KASP Auditor Requirements
In-Reply-To: <69830D4127201D4EBD146B9041199718B069DC@EXCHANGE.office.nic.se>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069DC@EXCHANGE.office.nic.se>
Message-ID: <49F06E5E.90905@NLnetLabs.nl>

Rickard Bondesson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> *****
> 2.2. The KA should be able to accept the input zone data in the form of:
>    a. A zone file.
>    b. An AXFR.
> 2.4. The KA must be able to accept the output zone data in the form of:
>    a. A zone file.
>    b. An AXFR.
> *****
> 
> I haven't check how the Signer Engine handles the zones, but it would be nice to have hooks into the internal zone data rather than implementing I/O adapters for the KA. Now it is specified as a bump on the road, but that is perhaps how we want it?
> 

at the moment, it doesn't have a representation of the zone, only an input file 
name, an output file name, and a zone name. Zone content handling is done by the 
tools, which use text-in-text-out. Technically the originial idea was to 
directly pipe from the input file all the way to the output file, but for 
efficiency reasons (call it a cache), intermediate sorted and signed zone files 
are also stored.

(of course this is all for the first version)

one way i could easily sneak in AXFR (both in and out) is to still use those 
files, and write two little mini-daemons that 'do' the axfr from/to those files.

Jelte


From jakob at kirei.se  Thu Apr 23 14:30:28 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 23 Apr 2009 16:30:28 +0200
Subject: [Opendnssec-develop] KASP Auditor Requirements
In-Reply-To: <49F06E5E.90905@NLnetLabs.nl>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069DC@EXCHANGE.office.nic.se>
	<49F06E5E.90905@NLnetLabs.nl>
Message-ID: <46CC3263-4276-4C2A-90B1-2A4D4ED1C070@kirei.se>

I believe the KA should be able to read the policy and zonelist XML  
blobs, right?

	jakob



From rickard.bondesson at iis.se  Thu Apr 23 14:38:10 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 23 Apr 2009 16:38:10 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
Message-ID: <69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

(Sending again, but to the list (reply to all))

I believe that we have to crack a big nut here.

How should we handle the sessions?

We want to allow signing with multiple threads. This needs one session per thread. If we connect the session with the HSM, then we can only use on thread per HSM. If we connect the session with the key, then the threads can not sign with the same key.

In other words we either need to keep track of the thread or give out session ids via the libhsm interface. A session id which needs to be translated to the session id within the HSM.

Then we also would need some interface to open and close sessions... and then we are almost creating a new PKCS#11 interface.

Suggestions?

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfB9UuCjgaNTdVjaAQjbIgf/fEqOOfQXotg55oSNR1GFdA3uNYM6BSei
INT658p1kAeSsXaITAydfXyLROigD1b1nqRIgObry+ZJTyd6F11qsRsnrD6//Eno
WluL/wdre4Hue08x+dknWWNPfnCq30KPSWSgBj/fdnNzOgbEtb07AfEhXd3/n+5H
7kmiUEKl4ZF5eyXUUs0kXuGadTGMdFpkISepGjlnxCD8vgZ5AeHrVFiCUY01ayVE
xQ/OsVURxBYISf49qc5I9L6PWqSkHgVRsGFkIbv2IPjHBpmWGRCp1zT2GpY7k3z5
Dcihb14ZSttgxORUbpOfenjrBk37s1oMSFH3f1LKfuSfGcgFEjWdAA==
=at9y
-----END PGP SIGNATURE-----


From jakob at kirei.se  Thu Apr 23 14:46:29 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 23 Apr 2009 16:46:29 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
	<69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>
Message-ID: <5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>

On 23 apr 2009, at 16.27, Rickard Bondesson wrote:

> How should we handle the sessions?

internally, without exposing to the user of libhsm.

> We want to allow signing with multiple threads. This needs one  
> session per thread. If we connect the session with the HSM, then we  
> can only use on thread per HSM. If we connect the session with the  
> key, then the threads can not sign with the same key.

it would be nice if we can have the library allocate a bunch of  
session and use them when needed, right?

> In other words we either need to keep track of the thread or give  
> out session ids via the libhsm interface. A session id which needs  
> to be translated to the session id within the HSM.

we could let libhsm return a hsm_context and pass that context around  
for each operation, makes sense?

do you pass credentionals to pkcs11 per session? if so, we probably  
need to create all sessions for a given library at attach time, but at  
that point we don't know about each token? do we require all tokens  
accessible with the same library to have shared credentials?

> Then we also would need some interface to open and close sessions...  
> and then we are almost creating a new PKCS#11 interface.

I'd say better since we do operations against all HSMs.

	j



From jad at jadickinson.co.uk  Thu Apr 23 14:56:21 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 23 Apr 2009 15:56:21 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
	<69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>
	<5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>
Message-ID: <C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>


On 23 Apr 2009, at 15:46, Jakob Schlyter wrote:

> On 23 apr 2009, at 16.27, Rickard Bondesson wrote:
>
>> How should we handle the sessions?
>
> internally, without exposing to the user of libhsm.
>
>> We want to allow signing with multiple threads. This needs one  
>> session per thread. If we connect the session with the HSM, then we  
>> can only use on thread per HSM. If we connect the session with the  
>> key, then the threads can not sign with the same key.
>
> it would be nice if we can have the library allocate a bunch of  
> session and use them when needed, right?
>
>> In other words we either need to keep track of the thread or give  
>> out session ids via the libhsm interface. A session id which needs  
>> to be translated to the session id within the HSM.
>

Forgive my naivety but the only thing that needs to be threaded ever is

ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t  
*key);

so how about

ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t  
*key, int thread_id);

when hsm_sign_rrset sees a new thread_id it opens a new session.

Isn't this kind of what is done in the speed tester except an array of  
sessions is created in advance of launching the threads.
John

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jakob at kirei.se  Thu Apr 23 15:17:11 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 23 Apr 2009 17:17:11 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
	<69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>
	<5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>
	<C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
Message-ID: <E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>

On 23 apr 2009, at 16.56, John Dickinson wrote:

> Forgive my naivety but the only thing that needs to be threaded ever  
> is
>
> ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t  
> *key);
>
> so how about
>
> ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t  
> *key, int thread_id);
>
> when hsm_sign_rrset sees a new thread_id it opens a new session.

do you need to login in when you create the thread?

	jakob



From Ray.Bellis at nominet.org.uk  Thu Apr 23 15:23:36 2009
From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk)
Date: Thu, 23 Apr 2009 16:23:36 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
	<69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>	<5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>
	<C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
	<E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
Message-ID: <OF66A48495.2AFE3684-ON802575A1.00547ADE-802575A1.00548F11@nominet.org.uk>

BTW:

   int hsm_attach(const char *name, const char *path, const char *pin);

who (if anybody) is responsible for erasing the contents of *pin once it 
has been used?

Ray



From rickard.bondesson at iis.se  Thu Apr 23 15:22:49 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 23 Apr 2009 17:22:49 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se><OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk><69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se><CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se><69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se><5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se><C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
	<E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
Message-ID: <69830D4127201D4EBD146B9041199718B06A03@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> do you need to login in when you create the thread?

Login can be performed as long there is a session open . The login state will be kept as long as there is a session open. More sessions can be added. But the user will be logged out if all sessions are closed with the token.

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfCHyeCjgaNTdVjaAQiugwf+KHyScVYEFUB5Zs0y00lDUowdlzMqktXR
bOX5GkM35VklM/+1PuXZhGZ7cuxM2B+Ybi6kqrsO4pHpwLoQHu9ZMwj1yFHrQDMo
ZtlZqz+lUpc7h081TUgHhMyPVhPNPnDxt8AzFmJHIlRGzHod64GQIJP7t5k2ByHq
36iDZdKUBaDK5ahfKyDzqJzp+zy31TmD0XsZxWGPkAT4BpnNhMsMBRc/oQ2BIgsB
IvELH2j17YPFFdI7HiKZI+quOVryN+0UrRadI7cr6Tfv1aKrYjeciRYU9s6PwgM0
KKndd51mE6c+VABukXjp4eZbHkijxyrCFN70A20Urw5qRxwF2gRH5A==
=GJiP
-----END PGP SIGNATURE-----


From jad at jadickinson.co.uk  Thu Apr 23 15:31:21 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 23 Apr 2009 16:31:21 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>
	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
	<69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>
	<5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>
	<C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
	<E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
Message-ID: <EE51880E-D7A6-4182-A84D-7F2CBAB332BD@jadickinson.co.uk>


On 23 Apr 2009, at 16:17, Jakob Schlyter wrote:

> On 23 apr 2009, at 16.56, John Dickinson wrote:
>
>> Forgive my naivety but the only thing that needs to be threaded  
>> ever is
>>
>> ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t  
>> *key);
>>
>> so how about
>>
>> ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t  
>> *key, int thread_id);
>>
>> when hsm_sign_rrset sees a new thread_id it opens a new session.
>
> do you need to login in when you create the thread?


Roy would know but from the comments in the speed tester it appears  
you just log in to one session and they all become user sessions.

John
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jad at jadickinson.co.uk  Thu Apr 23 15:39:57 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 23 Apr 2009 16:39:57 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <OF66A48495.2AFE3684-ON802575A1.00547ADE-802575A1.00548F11@nominet.org.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>
	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>
	<69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>	<5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>
	<C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
	<E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
	<OF66A48495.2AFE3684-ON802575A1.00547ADE-802575A1.00548F11@nominet.org.uk>
Message-ID: <D0904768-9D47-4387-9101-00F6AFFE2305@jadickinson.co.uk>


On 23 Apr 2009, at 16:23, Ray.Bellis at nominet.org.uk wrote:

> BTW:
>
>   int hsm_attach(const char *name, const char *path, const char *pin);
>
> who (if anybody) is responsible for erasing the contents of *pin  
> once it
> has been used?


libhsm is the only thing that ever prompts for, caches or erases PINs  
unless the admin decideds to store them in conf.xml.

John
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From Stephen.Morris at nominet.org.uk  Fri Apr 24 10:20:57 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Fri, 24 Apr 2009 11:20:57 +0100
Subject: [Opendnssec-develop] KASP Auditor Requirements
In-Reply-To: <46CC3263-4276-4C2A-90B1-2A4D4ED1C070@kirei.se>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B069DC@EXCHANGE.office.nic.se>	<49F06E5E.90905@NLnetLabs.nl>
	<46CC3263-4276-4C2A-90B1-2A4D4ED1C070@kirei.se>
Message-ID: <OF44D772F3.EC8A9875-ON802575A2.00371B98-802575A2.0038D95B@nominet.org.uk>

Jakob Schlyter <jakob at kirei.se> wrote on 23/04/2009 15:30:28:


> I believe the KA should be able to read the policy and zonelist XML 
> blobs, right?

I wasn't quite certain how these were specified so I merely stated that 
"It must be possible to specify the zone or zones for which the KA is to 
perform checks" and 'It must be possible to specify the policy information 
used to sign the data".

Of course, it retrieves this information from the XML passed to the 
signer, the auditor is only checking the signer.  If it retrieves the 
information from the original policy source, it is checking the entire 
system.  I am guessing that the former will be easier to do, although the 
latter is preferable.

Stephen


From Ray.Bellis at nominet.org.uk  Fri Apr 24 11:39:49 2009
From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk)
Date: Fri, 24 Apr 2009 12:39:49 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <69830D4127201D4EBD146B9041199718B06A03@EXCHANGE.office.nic.se>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se><OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk><69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se><CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se><69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se><5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se><C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
	<E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
	<69830D4127201D4EBD146B9041199718B06A03@EXCHANGE.office.nic.se>
Message-ID: <OF862DB315.DF3936C1-ON802575A2.003FE59B-802575A2.00401245@nominet.org.uk>

re:

  const hsm_key_t *hsm_generate_rsa_key(unsigned long keysize);

Do we need a parameter to say _which_ HSM the key will be generated on. 
For instance, when adding a second HSM to an existing system (so that the 
old can be eventually decommissioned) we might need to specify that all 
news keys are created on the new HSM and not on the old one.

(unless that's part of the automagic .xml configuration ?)

Ray
 


From jad at jadickinson.co.uk  Fri Apr 24 12:02:05 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Fri, 24 Apr 2009 13:02:05 +0100
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <OF862DB315.DF3936C1-ON802575A2.003FE59B-802575A2.00401245@nominet.org.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se><OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk><69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se><CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se><69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se><5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se><C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
	<E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
	<69830D4127201D4EBD146B9041199718B06A03@EXCHANGE.office.nic.se>
	<OF862DB315.DF3936C1-ON802575A2.003FE59B-802575A2.00401245@nominet.org.uk>
Message-ID: <7534E357-5178-4721-84C8-16C6DD121FE2@jadickinson.co.uk>


On 24 Apr 2009, at 12:39, Ray.Bellis at nominet.org.uk wrote:

> re:
>
>  const hsm_key_t *hsm_generate_rsa_key(unsigned long keysize);
>
> Do we need a parameter to say _which_ HSM the key will be generated  
> on.
> For instance, when adding a second HSM to an existing system (so  
> that the
> old can be eventually decommissioned) we might need to specify that  
> all
> news keys are created on the new HSM and not on the old one.


Yes. and maybe a few other things like exponent size.
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jad at jadickinson.co.uk  Fri Apr 24 12:18:51 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Fri, 24 Apr 2009 13:18:51 +0100
Subject: [Opendnssec-develop] xml files
Message-ID: <B278B920-5050-4EC8-96D1-1EA47679BF31@jadickinson.co.uk>

I am trying to make sure that the enforcer components all install in a  
sensible way and can find each other and their config files.

I suggest that at least for now libksm installs an example conf.xml,  
kasp.xml and zonelist.xml along with their relanx-ng schemas. At the  
moment they are copies of the ones in the docs/xml directory. I would  
like to suggest that they now move from docs/xml directory to be part  
of libksm and that libksm will make the .rng files from the .rnc  
sources as part of the standard build.

Are people OK with that?

John
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jakob at kirei.se  Fri Apr 24 12:23:24 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 24 Apr 2009 14:23:24 +0200
Subject: [Opendnssec-develop] xml files
In-Reply-To: <B278B920-5050-4EC8-96D1-1EA47679BF31@jadickinson.co.uk>
References: <B278B920-5050-4EC8-96D1-1EA47679BF31@jadickinson.co.uk>
Message-ID: <BC84CB13-2DFC-4EB4-A252-DFAB2417A17D@kirei.se>

On 24 apr 2009, at 14.18, John Dickinson wrote:

> I am trying to make sure that the enforcer components all install in  
> a sensible way and can find each other and their config files.
>
> I suggest that at least for now libksm installs an example conf.xml,  
> kasp.xml and zonelist.xml along with their relanx-ng schemas. At the  
> moment they are copies of the ones in the docs/xml directory. I  
> would like to suggest that they now move from docs/xml directory to  
> be part of libksm and that libksm will make the .rng files from  
> the .rnc sources as part of the standard build.
>
> Are people OK with that?

for the examples I agree, but IMHO we should move the rng/rnc into a  
more stable location like http://svn.opendnssec.se/xml/1.0/conf.xml ?

	j



From jakob at kirei.se  Fri Apr 24 12:26:07 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 24 Apr 2009 14:26:07 +0200
Subject: [Opendnssec-develop] xml files
In-Reply-To: <BC84CB13-2DFC-4EB4-A252-DFAB2417A17D@kirei.se>
References: <B278B920-5050-4EC8-96D1-1EA47679BF31@jadickinson.co.uk>
	<BC84CB13-2DFC-4EB4-A252-DFAB2417A17D@kirei.se>
Message-ID: <16841DC1-C969-4E3F-BCC3-44180F77C07C@kirei.se>

On 24 apr 2009, at 14.23, Jakob Schlyter wrote:

> On 24 apr 2009, at 14.18, John Dickinson wrote:
>
>> I am trying to make sure that the enforcer components all install  
>> in a sensible way and can find each other and their config files.
>>
>> I suggest that at least for now libksm installs an example  
>> conf.xml, kasp.xml and zonelist.xml along with their relanx-ng  
>> schemas. At the moment they are copies of the ones in the docs/xml  
>> directory. I would like to suggest that they now move from docs/xml  
>> directory to be part of libksm and that libksm will make the .rng  
>> files from the .rnc sources as part of the standard build.
>>
>> Are people OK with that?
>
> for the examples I agree, but IMHO we should move the rng/rnc into a  
> more stable location like http://svn.opendnssec.se/xml/1.0/conf.xml ?

but we could also just move them into source and make the stable  
location a redirect/rewrite, perhaps that's better?

	jakob



From jakob at kirei.se  Fri Apr 24 12:27:07 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 24 Apr 2009 14:27:07 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <OF862DB315.DF3936C1-ON802575A2.003FE59B-802575A2.00401245@nominet.org.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se><OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk><69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se><CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se><69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se><5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se><C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
	<E8663892-9929-4869-AD1E-4C568EBA7746@kirei.se>
	<69830D4127201D4EBD146B9041199718B06A03@EXCHANGE.office.nic.se>
	<OF862DB315.DF3936C1-ON802575A2.003FE59B-802575A2.00401245@nominet.org.uk>
Message-ID: <E43F69D3-6BA6-47F4-80C6-C3A3D6FF8E2E@kirei.se>

On 24 apr 2009, at 13.39, Ray.Bellis at nominet.org.uk wrote:

>  const hsm_key_t *hsm_generate_rsa_key(unsigned long keysize);
>
> Do we need a parameter to say _which_ HSM the key will be generated  
> on.
> For instance, when adding a second HSM to an existing system (so  
> that the
> old can be eventually decommissioned) we might need to specify that  
> all
> news keys are created on the new HSM and not on the old one.

yes.

> (unless that's part of the automagic .xml configuration ?)

no, it isn't as the repository name for new keys is configured using  
the KASP.

	jakob



From jad at jadickinson.co.uk  Fri Apr 24 12:34:41 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Fri, 24 Apr 2009 13:34:41 +0100
Subject: [Opendnssec-develop] xml files
In-Reply-To: <16841DC1-C969-4E3F-BCC3-44180F77C07C@kirei.se>
References: <B278B920-5050-4EC8-96D1-1EA47679BF31@jadickinson.co.uk>
	<BC84CB13-2DFC-4EB4-A252-DFAB2417A17D@kirei.se>
	<16841DC1-C969-4E3F-BCC3-44180F77C07C@kirei.se>
Message-ID: <85C148FF-B5CC-4BFE-81D6-CCE642C80832@jadickinson.co.uk>


On 24 Apr 2009, at 13:26, Jakob Schlyter wrote:

> On 24 apr 2009, at 14.23, Jakob Schlyter wrote:
>
>> On 24 apr 2009, at 14.18, John Dickinson wrote:
>>
>>> I am trying to make sure that the enforcer components all install  
>>> in a sensible way and can find each other and their config files.
>>>
>>> I suggest that at least for now libksm installs an example  
>>> conf.xml, kasp.xml and zonelist.xml along with their relanx-ng  
>>> schemas. At the moment they are copies of the ones in the docs/xml  
>>> directory. I would like to suggest that they now move from docs/ 
>>> xml directory to be part of libksm and that libksm will make  
>>> the .rng files from the .rnc sources as part of the standard build.
>>>

Reading my message again I realize it wasn't really what I meant :).  
Lets try again...

We need to be able to install an example conf.xml, kasp.xml and  
zonelist.xml along with their relanx-ng schemas. Should this be done  
by the make && make install of any existing component of OpenDNSSEC or  
should they stand alone?

Thinking more about it I think they should stand alone in a better  
place than docs/xml/. How about we move them to trunk/xml. I can write  
a quick configure.ac and Makefile.am to to build the .rng files from  
the .rnc sources and install them in SYSCONFDIR/opendnssec/

John


>>> Are people OK with that?
>>
>> for the examples I agree, but IMHO we should move the rng/rnc into  
>> a more stable location like http://svn.opendnssec.se/xml/1.0/ 
>> conf.xml ?
>
> but we could also just move them into source and make the stable  
> location a redirect/rewrite, perhaps that's better?
>
> 	jakob
>

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From jakob at kirei.se  Fri Apr 24 12:37:27 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 24 Apr 2009 14:37:27 +0200
Subject: [Opendnssec-develop] xml files
In-Reply-To: <85C148FF-B5CC-4BFE-81D6-CCE642C80832@jadickinson.co.uk>
References: <B278B920-5050-4EC8-96D1-1EA47679BF31@jadickinson.co.uk>
	<BC84CB13-2DFC-4EB4-A252-DFAB2417A17D@kirei.se>
	<16841DC1-C969-4E3F-BCC3-44180F77C07C@kirei.se>
	<85C148FF-B5CC-4BFE-81D6-CCE642C80832@jadickinson.co.uk>
Message-ID: <17C6777E-7AD4-44D3-9CD8-42C08998C97E@kirei.se>

On 24 apr 2009, at 14.34, John Dickinson wrote:

> Thinking more about it I think they should stand alone in a better  
> place than docs/xml/. How about we move them to trunk/xml. I can  
> write a quick configure.ac and Makefile.am to to build the .rng  
> files from the .rnc sources and install them in SYSCONFDIR/opendnssec/

makes sense. please do.

	jakob



From rick at openfortress.nl  Fri Apr 24 12:52:34 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Fri, 24 Apr 2009 12:52:34 +0000
Subject: [Opendnssec-develop] Which CKM_xxx methods are needed from PKSC #11?
Message-ID: <20090424125234.GA21817@phantom.vanrein.org>

Hello,

I am writing HSM test code, and making sure not to look
at any code to stay independent of that.

Which CKM_xxx methods are required for OpenDNSSEC?

I am specifically looking for methods for key pair
generation and for signing.  Please name all methods
that you would consider using (which may be more than
you are actually using in your code).

Thanks,
 -Rick


From rickard.bondesson at iis.se  Fri Apr 24 13:14:20 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Fri, 24 Apr 2009 15:14:20 +0200
Subject: [Opendnssec-develop] Which CKM_xxx methods are needed from PKSC #11?
In-Reply-To: <20090424125234.GA21817@phantom.vanrein.org>
References: <20090424125234.GA21817@phantom.vanrein.org>
Message-ID: <69830D4127201D4EBD146B9041199718B06A4E@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Which CKM_xxx methods are required for OpenDNSSEC?

For generating the key:
  CKM_RSA_PKCS_KEY_PAIR_GEN

For signatures:
  CKM_SHA1_RSA_PKCS
  CKM_SHA256_RSA_PKCS (for future use, draft-ietf-dnsext-dnssec-rsasha256-12)
  CKM_SHA512_RSA_PKCS (for future use, draft-ietf-dnsext-dnssec-rsasha256-12)

For digesting:
  CKM_SHA_1
  CKM_SHA256
  CKM_SHA512 (for future use???)

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfG7LOCjgaNTdVjaAQi/6wf/eyK1BXEXf7HdhpCDAVebnZbAyLiVjlbY
1OL6BU8cY8ghL0Al5l97tnRslPOQCC3dZCkAp63noYbUUUsK+yXrUTsIhvOzij/r
ijkL1D8z9WDHlivDepgfnqsNu32JixZleFW7DPXPj5x8FPCTPWvdC/lP+QLM+3kZ
lTrbGb+JLgPOFYfBolU42sjn7QN14/NdJBfl8BSUAbpoOy+6wBAL7ljap6AD1NT/
FB3WcKb/JNbjzmx51wXQSmNyoRts+rJny4X1PWxHPMoHHQSo12/b84Jpq2q8c8SG
2/TA1zqWD104e1wYyNocBYhKTbl/Lmf5QRKJcIZ6cY6aHg2HJ7HlRw==
=T62F
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Fri Apr 24 13:21:45 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Fri, 24 Apr 2009 15:21:45 +0200
Subject: [Opendnssec-develop] xml files
In-Reply-To: <85C148FF-B5CC-4BFE-81D6-CCE642C80832@jadickinson.co.uk>
References: <B278B920-5050-4EC8-96D1-1EA47679BF31@jadickinson.co.uk>	<BC84CB13-2DFC-4EB4-A252-DFAB2417A17D@kirei.se>	<16841DC1-C969-4E3F-BCC3-44180F77C07C@kirei.se>
	<85C148FF-B5CC-4BFE-81D6-CCE642C80832@jadickinson.co.uk>
Message-ID: <49F1BCE9.30508@NLnetLabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Dickinson wrote:
> 
> Reading my message again I realize it wasn't really what I meant :).
> Lets try again...
> 
> We need to be able to install an example conf.xml, kasp.xml and
> zonelist.xml along with their relanx-ng schemas. Should this be done by
> the make && make install of any existing component of OpenDNSSEC or
> should they stand alone?
> 
> Thinking more about it I think they should stand alone in a better place
> than docs/xml/. How about we move them to trunk/xml. I can write a quick
> configure.ac and Makefile.am to to build the .rng files from the .rnc
> sources and install them in SYSCONFDIR/opendnssec/
> 


because it wasn't there, the signer engine also installs a conf.xml.sample,
based on an conf.xml.sample.in file so a few default paths are filled in with
configure values. If you haven't written it yet you could take that one. The
place to put this in the end imo is the 'big' configure/install script for the
whole project (which doesn't exist yet).

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknxvOYACgkQ4nZCKsdOncWilwCgz0jpsMJN9oyStJMEKPyJbr7d
kF4An3H4taUSb2MUKipdjAyPtGSCuF9/
=QbsF
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Fri Apr 24 13:42:26 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Fri, 24 Apr 2009 15:42:26 +0200
Subject: [Opendnssec-develop] Call for meeting topics 20090427
Message-ID: <69830D4127201D4EBD146B9041199718B06A56@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi

I am requesting meeting topics besides the ones that are in our backlog.

Meeting:
Monday 27 April 2009
11:00-12:00 CEST

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfHBwuCjgaNTdVjaAQh6DAf/blF8a+VXvM/OHwphBJQ4wudxPHpDIx6e
CbMTyZOOrkSA8YPFYBD6DEN+sJ2qMW5QOgKe3teAU8g4YfQpvsr+AXYFPq7/mh46
6mwdrA+Pp3JFiXBPscwFf1sa1QOGGlwlK9XYPgycjt0niuGqeTh7GQMG+qpfEi7X
KrYBC98mFvvahx0OeTuYqRJKSS19c7UqpijK6Xxw9VwzmdrjWpwJZSFJBgPaD7QG
6wC6U7iBKlE9sFJHNkHwLlyscTCnN+j7fIanpT2lWEZS5jRcyApsnAASek8GScQM
THRXEfIzeH/Vtp0itwPD3K9a9TAft+QfAmljaZcVQBoNG7N8Og8KEA==
=VYCe
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Fri Apr 24 14:39:51 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Fri, 24 Apr 2009 16:39:51 +0200
Subject: [Opendnssec-develop] running the signer engine
Message-ID: <49F1CF37.1010800@NLnetLabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

I've added a description on how to run the signer engine manually (i.e. without
the KASP), so if anyone wants to try it out, be my guest. Since you're going to
have to provide a few files that are normally generated by the kasp, it may be a
bit of typing XML though.

It's in <repos>/signer/README

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknxzzcACgkQ4nZCKsdOncWXoACePH+J7p+o7UXD+zBfe7FGaF1d
g8UAoL9+rcZKrv8JpZqpOhSkCVWT5UAj
=ksOQ
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Mon Apr 27 07:46:06 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Mon, 27 Apr 2009 09:46:06 +0200
Subject: [Opendnssec-develop] Meeting agenda 20090427
Message-ID: <69830D4127201D4EBD146B9041199718B06A84@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The meeting agenda is posted to the wiki:

http://www.opendnssec.se/wiki/Meetings/Agenda/2009-04-27

See you at 11 CEST.

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfVivuCjgaNTdVjaAQj1OQf9E2Otd7+OlCCr0sb/GXkp0k3M5TzTjfAe
QlQHtKRqz+/vPrFmN/4+81G3d21Q3b3mRVyz2wozwKUQuet5FjbevuYeMRkA+I3P
ZplVS0/Furd2jdBfhGIc3pQ3SO/OEsEoBauesRu/M6JIF6o2DxO7g8pMHuIwnbOI
tX9LEPk95wr5lkZQRKrISVjNfVX4maD5FgIOnbCsTTMp16JLuxk+Fxf3iTVbydsa
fWwm3D533ZqYwSZGqUt9a/QC86ZiW0eOu9UkdQvuf76KDOLioDUnEuU2bYMd5hec
tVz/8RldlA5clmjxcASwthLKryY7f07AKGqIbeL+CBF/BpmzCQ8XPQ==
=W/38
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Mon Apr 27 07:58:45 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Mon, 27 Apr 2009 09:58:45 +0200
Subject: [Opendnssec-develop] proposed libhsm API
In-Reply-To: <C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
References: <803202D0-70B8-4276-8A72-A99A22C5A38A@kirei.se>	<D9DB6E9B-3910-4560-B38B-1A980E3E1EA4@jadickinson.co.uk><D1658F64-272B-4D6A-A73E-59E7BB0F5628@kirei.se>	<OFF7C2DF70.18F3A1B6-ON802575A1.00335AB6-802575A1.0033656A@nominet.org.uk>	<69830D4127201D4EBD146B9041199718B069AB@EXCHANGE.office.nic.se>	<CB902CE1-029C-4C4E-849B-B4DDBA571B62@kirei.se>	<69830D4127201D4EBD146B9041199718B069FA@EXCHANGE.office.nic.se>	<5FE6F374-B016-492A-9C1B-6C1DD6B71ABD@kirei.se>
	<C8E0749D-1B3B-404F-916A-834027FEE2BB@jadickinson.co.uk>
Message-ID: <49F565B5.7010302@NLnetLabs.nl>

John Dickinson wrote:
> 
>>> In other words we either need to keep track of the thread or give out 
>>> session ids via the libhsm interface. A session id which needs to be 
>>> translated to the session id within the HSM.
>>
> 
> Forgive my naivety but the only thing that needs to be threaded ever is
> 
> ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t *key);
> 
> so how about
> 
> ldns_rr* hsm_sign_rrset(const ldns_rr_list* rrset, const hsm_key_t *key, 
> int thread_id);
> 

why not define a hsm_ctx, have that one be returned by what is currently
hsm_autoconf(), and pass it around to all other functions? Then we don't need 
global variables, and if someone wants to do multithreading with one ctx he can 
lock that himself.

Jelte


From Stephen.Morris at nominet.org.uk  Mon Apr 27 17:18:38 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Mon, 27 Apr 2009 18:18:38 +0100
Subject: [Opendnssec-develop] Minutes of teleconference, 2009-04-27
Message-ID: <OF275E1377.D5B8416E-ON802575A5.005ED5E9-802575A5.005F1743@nominet.org.uk>

Notes from today's meeting can be found on the Wiki:

     http://www.opendnssec.se/wiki/Meetings/Minutes/2009-04-27

As always, please let me know of any errors or omissions.

Stephen


From jad at jadickinson.co.uk  Wed Apr 29 13:09:31 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 29 Apr 2009 14:09:31 +0100
Subject: [Opendnssec-develop] Minutes of teleconference, 2009-04-27
In-Reply-To: <OF275E1377.D5B8416E-ON802575A5.005ED5E9-802575A5.005F1743@nominet.org.uk>
References: <OF275E1377.D5B8416E-ON802575A5.005ED5E9-802575A5.005F1743@nominet.org.uk>
Message-ID: <19DC2982-F86B-4F0F-9FF8-0FD652F8EF3C@jadickinson.co.uk>


On 27 Apr 2009, at 18:18, Stephen.Morris at nominet.org.uk wrote:

> Notes from today's meeting can be found on the Wiki:
>
>     http://www.opendnssec.se/wiki/Meetings/Minutes/2009-04-27


Sorry for being unable to make the meeting - here is what I would have  
said....

"libhsm

KASP - not sure - need feedback from John Dickinson here. However, we  
shouldn't need it for the alpha release providing that we can fill up  
the pool of keys using a shell script."

At the moment the key generator just calls a dummy uuid creator and  
adds an entry to the KASP DB. I could make create actual keys by using  
Roy's existing libhsm code by altering PK_GenerateObject(long keysize)  
to return the uuid if the real libhsm is going to be a while.

"Key Generation: uncertain as to the state of this (John Dickinson is  
writing it)."

It compiles, installs finds the default xml files and creates keys in  
the DB, then goes to sleep for keygeninterval. All the complexity of  
calculating how many keys are needed is actually done by libksm.

I have a script that checks out, builds and installs all the enforcer  
components and then runs them. It is customized to my environment,  
however, I will check this in as it may be useful to others. How about  
using the location /trunk/testing/enforcer/

This is my todo list
4. set up some end to end tests for key generation
5. code review and fix up the function to read conf.xml in the key  
generator then make a version of it for the communicator.
6. contribute to discussions on libhsm
7. check that docs and code are in sync.
8. Sort out signal handling in the communicator and key-generator.  
There is a signal handling function but it sets no  flags yet.
9. look at what common code is in the key generator and communicator  
and try to make it common.
10. compile on OS X, Linux, FreeBSD, Solaris and fix issues with build
11. run it all through valgrind
12. once likhsm exists replace the stub in the key-generator with the  
libhsm calls.

For 4 I suggest that we write a set of xml files for each test and a  
document that based on the kasp draft describes what should happen as  
a result of each test.

John

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From rickard.bondesson at iis.se  Wed Apr 29 13:48:13 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 29 Apr 2009 15:48:13 +0200
Subject: [Opendnssec-develop] VB: [keihatsu.kirei.se/svn/dnssec] r548 - in
	trunk/softHSM: checks src/bin src/lib
Message-ID: <69830D4127201D4EBD146B9041199718B06C5A@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This last change to the SoftHSM will store key information in another way than before. If you use SoftHSM live, you will have to perform a key rollover to the new library. The new library can not read the old database.

The previous SoftHSM could not make a new key visible to a second application running the library at the same time.

// Rickard.

> Moved the object handling to the database layer. Now can two 
> applications create and access each others objects, if they 
> have the correct 
> permissions. Live checks against the database is needed to be 
> able to have fresh information.

-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSfhaneCjgaNTdVjaAQgLiQgAkbBpIYJj64aN6d1i46DBlAJ4NrZQfiQu
ulVrOIkVnFTEpaERPBH8pdofUe0BIg9QqQsyF2a0fwlh5hbFfGe22e8MRzIuGTXx
WZbdJU39L3EGgniEGRl6ACajHtkTkALAVnWl3nGt6JYo7bm2K0rphHwcRssN8BPj
GdMdUmIMw0GV0KXYEVbycXHaO3ou+2IrXoQ82BTwhrEE6rIrDYgMG4dKnwIHeHK7
EIKEoYQ1vVhiBpQDg8WHovLqQl3Cb2gcW1fQy64rFotU/nHC6kx7P7EpJ8z1Echk
fukhQf4yUfDE/8T4J/3m86H5f7a9Ff5CIrgHkH1eWwZMyUI7Qz+WjA==
=RCjD
-----END PGP SIGNATURE-----


From Stephen.Morris at nominet.org.uk  Thu Apr 30 12:09:15 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Thu, 30 Apr 2009 13:09:15 +0100
Subject: [Opendnssec-develop] OpenDNSSEC and Backups
Message-ID: <OF297B3CA7.CBD5E216-ON802575A8.003F8E27-802575A8.0042C398@nominet.org.uk>

Whilst going through the requirements, a couple of issues concerning 
backups of the OpenDNSSEC system occurred to me:


1. Backing up DNSSEC key information
As presently envisaged, DNSSEC keys are created on demand.  There is a 
(configurable) interval after creation during which the keys are not used 
and a backup is assumed to take place.  After that, the keys are available 
for use.

It seems to me that the flaw here is that backups are only assumed to take 
place - the system does not know that they actually have been done. If 
some problem causes the backup to fail, the system could end up in a 
position where a public key is being used but there is only a single copy 
of the private key.  A failure of the hardware at that point could be 
catastrophic.

It would be safer to require a positive action on behalf of the user to 
confirm that a backup has been taken before the system uses those keys. 
The sort of thing I have in mind is adding a command to ksm that will 
record the time of the latest backup.  Only keys whose creation time (the 
"generate" time) is earlier than this are available for use.  It is up to 
the operator how this is used, e.g. embedding it in the backup script or 
running a job after their backup has finished.


2. Integrity of Key Information
When backing up the files on disk, how do we guarantee that we have a 
coherent copy of the file if the OpenDNSSEC software is running at the 
time?  Since the OpenDNSSEC software is run as daemon processes triggered 
by timers, is there a chance that one or more of the files (including the 
key store for hardware HSMs) could be being written by OpenDNSSEC at the 
time it is backed up?


Thoughts?


Stephen


From jad at jadickinson.co.uk  Thu Apr 30 12:30:27 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 30 Apr 2009 13:30:27 +0100
Subject: [Opendnssec-develop] OpenDNSSEC and Backups
In-Reply-To: <OF297B3CA7.CBD5E216-ON802575A8.003F8E27-802575A8.0042C398@nominet.org.uk>
References: <OF297B3CA7.CBD5E216-ON802575A8.003F8E27-802575A8.0042C398@nominet.org.uk>
Message-ID: <9D762A9F-14B6-4253-B4C7-F39F4CD006A4@jadickinson.co.uk>


On 30 Apr 2009, at 13:09, Stephen.Morris at nominet.org.uk wrote:

> Whilst going through the requirements, a couple of issues concerning
> backups of the OpenDNSSEC system occurred to me:
>
>
> 1. Backing up DNSSEC key information
> As presently envisaged, DNSSEC keys are created on demand.  There is a
> (configurable) interval after creation during which the keys are not  
> used
> and a backup is assumed to take place.  After that, the keys are  
> available
> for use.
>
> It seems to me that the flaw here is that backups are only assumed  
> to take
> place - the system does not know that they actually have been done. If
> some problem causes the backup to fail, the system could end up in a
> position where a public key is being used but there is only a single  
> copy
> of the private key.  A failure of the hardware at that point could be
> catastrophic.
>
> It would be safer to require a positive action on behalf of the user  
> to
> confirm that a backup has been taken before the system uses those  
> keys.
> The sort of thing I have in mind is adding a command to ksm that will
> record the time of the latest backup.  Only keys whose creation time  
> (the
> "generate" time) is earlier than this are available for use.  It is  
> up to
> the operator how this is used, e.g. embedding it in the backup  
> script or
> running a job after their backup has finished.

Sounds good

>
>
> 2. Integrity of Key Information
> When backing up the files on disk, how do we guarantee that we have a
> coherent copy of the file if the OpenDNSSEC software is running at the
> time?  Since the OpenDNSSEC software is run as daemon processes  
> triggered
> by timers, is there a chance that one or more of the files  
> (including the
> key store for hardware HSMs) could be being written by OpenDNSSEC at  
> the
> time it is backed up?
>

What do we actually need to back up? I hope, but need to think about  
it, that we just need to back up the database. We should be able to  
get a consistent view of that. The backup interval above should cover  
the keystore.

If we lost the machine would recovering the DB and running the  
communicator be sufficient to get the signer going again without  
risking going insecure?

John


>
> Thoughts?
>
>
> Stephen
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From Stephen.Morris at nominet.org.uk  Thu Apr 30 14:46:58 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Thu, 30 Apr 2009 15:46:58 +0100
Subject: [Opendnssec-develop] OpenDNSSEC and Backups
In-Reply-To: <9D762A9F-14B6-4253-B4C7-F39F4CD006A4@jadickinson.co.uk>
References: <OF297B3CA7.CBD5E216-ON802575A8.003F8E27-802575A8.0042C398@nominet.org.uk>
	<9D762A9F-14B6-4253-B4C7-F39F4CD006A4@jadickinson.co.uk>
Message-ID: <OF986BEE87.77538A48-ON802575A8.004EEF60-802575A8.00513407@nominet.org.uk>

John Dickinson <jadsab at googlemail.com> wrote on 30/04/2009 13:30:27:

> > 2. Integrity of Key Information
> > When backing up the files on disk, how do we guarantee that we have a
> > coherent copy of the file if the OpenDNSSEC software is running at the
> > time?  Since the OpenDNSSEC software is run as daemon processes 
> > triggered
> > by timers, is there a chance that one or more of the files 
> > (including the
> > key store for hardware HSMs) could be being written by OpenDNSSEC at 
> > the
> > time it is backed up?
> >
> 
> What do we actually need to back up? I hope, but need to think about 
> it, that we just need to back up the database. We should be able to 
> get a consistent view of that. The backup interval above should cover 
> the keystore.

I think that we would need to backup the contents of the database, the key 
stores and, while we are at it, all configuration files.

My question was really about the contents of the HSMs though; for example, 
the SCA6000 stores its keys in an encrypted file on disk.  As we have no 
control over how HSMs operate, the possibility exists that backing them up 
while they are being used could lead to the backup being inconsistent. 
Admittedly, this possibility is small and perhaps would only occur if the 
keys were being generated (and the file being written to) when the backup 
took place.  Nevertheless, it could exist and might lead to a backup that 
could not be recovered.

One solution would be for OpenDNSSEC itself to make a consistent copy of 
the data and for the end user to back up that copy.  An advantage of such 
a scheme would be that if KASP were using a database such as MySql or 
Oracle, KASP could export the data to one or more files, and the operator 
would only have to worry about backup up those files; they would not have 
to be concerned with backing up a database whilst it is running.

However, this only complicates the software and perhaps the risk is not 
worth worrying about?


> If we lost the machine would recovering the DB and running the 
> communicator be sufficient to get the signer going again without 
> risking going insecure?

I think so, although you would need to recover the keystore as well.


Stephen


From jad at jadickinson.co.uk  Thu Apr 30 15:05:40 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 30 Apr 2009 16:05:40 +0100
Subject: [Opendnssec-develop] OpenDNSSEC and Backups
In-Reply-To: <OF986BEE87.77538A48-ON802575A8.004EEF60-802575A8.00513407@nominet.org.uk>
References: <OF297B3CA7.CBD5E216-ON802575A8.003F8E27-802575A8.0042C398@nominet.org.uk>
	<9D762A9F-14B6-4253-B4C7-F39F4CD006A4@jadickinson.co.uk>
	<OF986BEE87.77538A48-ON802575A8.004EEF60-802575A8.00513407@nominet.org.uk>
Message-ID: <1A1FBD0C-FE24-4D21-BEA1-558C0A48BFBF@jadickinson.co.uk>


On 30 Apr 2009, at 15:46, Stephen.Morris at nominet.org.uk wrote:

> John Dickinson <jadsab at googlemail.com> wrote on 30/04/2009 13:30:27:
>
>>> 2. Integrity of Key Information
>>> When backing up the files on disk, how do we guarantee that we  
>>> have a
>>> coherent copy of the file if the OpenDNSSEC software is running at  
>>> the
>>> time?  Since the OpenDNSSEC software is run as daemon processes
>>> triggered
>>> by timers, is there a chance that one or more of the files
>>> (including the
>>> key store for hardware HSMs) could be being written by OpenDNSSEC at
>>> the
>>> time it is backed up?
>>>
>>
>> What do we actually need to back up? I hope, but need to think about
>> it, that we just need to back up the database. We should be able to
>> get a consistent view of that. The backup interval above should cover
>> the keystore.
>
> I think that we would need to backup the contents of the database,  
> the key
> stores and, while we are at it, all configuration files.
>
> My question was really about the contents of the HSMs though; for  
> example,
> the SCA6000 stores its keys in an encrypted file on disk.  As we  
> have no
> control over how HSMs operate, the possibility exists that backing  
> them up
> while they are being used could lead to the backup being inconsistent.

Backing up the HSM should be done according to the HSM manufacturers  
specified method. Having the ability to make consistent backups should  
be a feature of the HSM. In the case of a SCA6000 see http://docs.sun.com/source/820-4144-11/3_admin.html#50552899_pgfId-1009280

> Admittedly, this possibility is small and perhaps would only occur  
> if the
> keys were being generated (and the file being written to) when the  
> backup
> took place.  Nevertheless, it could exist and might lead to a backup  
> that
> could not be recovered.
>
> One solution would be for OpenDNSSEC itself to make a consistent  
> copy of
> the data and for the end user to back up that copy.

OpenDNSSEC can not get the private keys.

>  An advantage of such
> a scheme would be that if KASP were using a database such as MySql or
> Oracle, KASP could export the data to one or more files, and the  
> operator
> would only have to worry about backup up those files; they would not  
> have
> to be concerned with backing up a database whilst it is running.
>
> However, this only complicates the software and perhaps the risk is  
> not
> worth worrying about?
>
>
>> If we lost the machine would recovering the DB and running the
>> communicator be sufficient to get the signer going again without
>> risking going insecure?
>
> I think so, although you would need to recover the keystore as well.

Yes.

John

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009





From Stephen.Morris at nominet.org.uk  Thu Apr 30 17:07:23 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Thu, 30 Apr 2009 18:07:23 +0100
Subject: [Opendnssec-develop] OpenDNSSEC and Backups
In-Reply-To: <1A1FBD0C-FE24-4D21-BEA1-558C0A48BFBF@jadickinson.co.uk>
References: <OF297B3CA7.CBD5E216-ON802575A8.003F8E27-802575A8.0042C398@nominet.org.uk>
	<9D762A9F-14B6-4253-B4C7-F39F4CD006A4@jadickinson.co.uk>
	<OF986BEE87.77538A48-ON802575A8.004EEF60-802575A8.00513407@nominet.org.uk>
	<1A1FBD0C-FE24-4D21-BEA1-558C0A48BFBF@jadickinson.co.uk>
Message-ID: <OF6DD708FF.CF227824-ON802575A8.005C999B-802575A8.005E0F00@nominet.org.uk>

John Dickinson <jadsab at googlemail.com> wrote on 30/04/2009 16:05:40:

> :
> Backing up the HSM should be done according to the HSM manufacturers 
> specified method. Having the ability to make consistent backups should 
> be a feature of the HSM. In the case of a SCA6000 see http://
> docs.sun.com/source/820-4144-11/3_admin.html#50552899_pgfId-1009280

This is seeming to argue for OpenDNSSEC making a copy of the data (if 
possible) and backing that up.  Otherwise in the worse case backup could 
require logging into an HSM and exporting the data, backing up the KASP 
database according to the appropriate instructions, and copying the 
configuration files.

> 
> > Admittedly, this possibility is small and perhaps would only occur 
> > if the
> > keys were being generated (and the file being written to) when the 
> > backup
> > took place.  Nevertheless, it could exist and might lead to a backup 
> > that
> > could not be recovered.
> >
> > One solution would be for OpenDNSSEC itself to make a consistent 
> > copy of
> > the data and for the end user to back up that copy.
> 
> OpenDNSSEC can not get the private keys.

Accepted.  What I was meaning was being able to take a copy of the HSM 
data (stored as a encrypted file on disk), sure in the knowledge that the 
file is not being accessed and is therefore consistent.


Stephen