From jad at jadickinson.co.uk  Fri May  1 08:33:20 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Fri, 1 May 2009 09:33:20 +0100
Subject: [Opendnssec-develop] OpenDNSSEC and Backups
In-Reply-To: <OF6DD708FF.CF227824-ON802575A8.005C999B-802575A8.005E0F00@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>
	<1A1FBD0C-FE24-4D21-BEA1-558C0A48BFBF@jadickinson.co.uk>
	<OF6DD708FF.CF227824-ON802575A8.005C999B-802575A8.005E0F00@nominet.org.uk>
Message-ID: <6404D25B-6E17-4BC9-B3F7-3147C1FEAFB4@jadickinson.co.uk>


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

> 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.

Sorry, I don't understand. What if the HSM doesn't store its keys in a  
file on disk but has some completely out of band backup system? This  
is a process issue that should not be solved by OpenDNSSEC.

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 May  1 10:16:48 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Fri, 1 May 2009 11:16:48 +0100
Subject: [Opendnssec-develop] OpenDNSSEC and Backups
In-Reply-To: <6404D25B-6E17-4BC9-B3F7-3147C1FEAFB4@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>
	<OF6DD708FF.CF227824-ON802575A8.005C999B-802575A8.005E0F00@nominet.org.uk>
	<6404D25B-6E17-4BC9-B3F7-3147C1FEAFB4@jadickinson.co.uk>
Message-ID: <OFC87A9065.FB10780C-ON802575A9.0032A239-802575A9.00387837@nominet.org.uk>

John Dickinson <jadsab at googlemail.com> wrote on 01/05/2009 09:33:20:

> On 30 Apr 2009, at 18:07, Stephen.Morris at nominet.org.uk wrote:
> 
> > 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.
> 
> Sorry, I don't understand. What if the HSM doesn't store its keys in a 
> file on disk but has some completely out of band backup system? This 
> is a process issue that should not be solved by OpenDNSSEC.

In that case, you would need to follow the HSM backup instructions.

Maybe it is not part of the remit of OpenDNSSEC.  But we're writing the 
software to make it easier to operate signed zones: as backing up the data 
is an essential part of operations, I think we should try to make getting 
a consistent backup as easy as possible as well.

Stephen


From jakob at kirei.se  Mon May  4 07:31:54 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 4 May 2009 09:31:54 +0200
Subject: [Opendnssec-develop] OpenDNSSEC license terms
Message-ID: <CF8379DE-E157-4A2E-B58C-4C8AC345CBC2@kirei.se>

good morning! this is a transmission from the opendnssec legal and  
licensing department.

based on discussions very early in the project, I want to remind  
eveyrone that this is the license (pure 2-clause BSD license) that  
applies to all OpenDNSSEC software. I want to stress that no other  
licenses may be used, except when we decide to include code from  
others. in such cases we need to discuss license first and import  
later, not the other way around.

for now, the copyright holder is the organization of the principal  
author, like:

- NLNet Labs
- .SE (The Internet Infrastructure Foundation)
- Nominet UK
- Kirei AB
- John Dickinson

we might decide to change this to "OpenDNSSEC" later, but since there  
is no such formal organization that might be difficult.

note: no other licenses may be used.


==> I will apply this license to all code this week unless promptly  
stopped.

	jakob


#
# $Id$
#
# Copyright (c) YYYY XXX. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the  
distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
# GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
# IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
# IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#



From olaf at NLnetLabs.nl  Mon May  4 11:17:57 2009
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Mon, 4 May 2009 13:17:57 +0200
Subject: [Opendnssec-develop] OpenDNSSEC license terms
In-Reply-To: <CF8379DE-E157-4A2E-B58C-4C8AC345CBC2@kirei.se>
References: <CF8379DE-E157-4A2E-B58C-4C8AC345CBC2@kirei.se>
Message-ID: <6C6912FF-C535-4C2F-B027-587A5AE8AA18@NLnetLabs.nl>


On 4 mei 2009, at 09:31, Jakob Schlyter wrote:

> good morning! this is a transmission from the opendnssec legal and  
> licensing department.
>
> based on discussions very early in the project, I want to remind  
> eveyrone that this is the license (pure 2-clause BSD license) that  
> applies to all OpenDNSSEC software. I want to stress that no other  
> licenses may be used, except when we decide to include code from  
> others. in such cases we need to discuss license first and import  
> later, not the other way around.
>
> for now, the copyright holder is the organization of the principal  
> author, like:
>
> - NLNet Labs
> - .SE (The Internet Infrastructure Foundation)
> - Nominet UK
> - Kirei AB
> - John Dickinson
>
> we might decide to change this to "OpenDNSSEC" later, but since  
> there is no such formal organization that might be difficult.
>
> note: no other licenses may be used.


I wholeheartedly agree.

--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/20090504/d45aae77/attachment.bin>

From jakob at kirei.se  Mon May  4 15:53:39 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 4 May 2009 17:53:39 +0200
Subject: [Opendnssec-develop] where to install scripts
Message-ID: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>

most of the signer engine is written as a collection of python  
scripts. where do we install them?
currently, they are installed in PREFIX/lib/opendnssec/signer/, but  
they are not libraries.

the executable tools are put in PREFIX/libexec/opendnssec, which makes  
more sense. but scripts?

please advice.

	jakob



From rickard.bondesson at iis.se  Tue May  5 07:33:40 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Tue, 5 May 2009 09:33:40 +0200
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>
Message-ID: <69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>

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

> most of the signer engine is written as a collection of 
> python scripts. where do we install them?
> currently, they are installed in 
> PREFIX/lib/opendnssec/signer/, but they are not libraries.
> 
> the executable tools are put in PREFIX/libexec/opendnssec, 
> which makes more sense. but scripts?
> 
> please advice.

I think that the tools and the scripts should be installed under

PREFIX/bin/opendnssec/signer/

The tools are executables and the scripts almost.

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

wsBVAwUBSf/r1OCjgaNTdVjaAQig6gf8DfW0WUtatYtQ7yco7drXnkdG0aX6fd4Z
ZOCOwGfDa+lunKE3/0Wtgwdlrrk1Lvmsb+ergAL4bBZERoUUr2bLtt2DU2oeleLc
C1o4IxC4gbyugaCNH+6UJwF+yDiCM6q4ucDpTMcn3D9oq+xrtA/6GESVPHmqKlFw
jwgvxkJxHjMe235V1u54jcyoXK6u/03LbsrKTMCeL9swOLZnZh+pw+/5+y7DahXU
xH+PCLgKSKZQqpRI989ihdRw/G8proJKwt0VvyR3YqvRrbVi1yS/rh84FLq9vuT/
W8UYZYEEu3SEFpzxZ+/GzvO7XX+6DRU1PZwd5s14llKbnWHSv7SeJw==
=wsX0
-----END PGP SIGNATURE-----


From jakob at kirei.se  Tue May  5 08:06:44 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Tue, 5 May 2009 10:06:44 +0200
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>
	<69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>
Message-ID: <2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>

On 5 maj 2009, at 09.33, Rickard Bondesson wrote:

> I think that the tools and the scripts should be installed under
>
> PREFIX/bin/opendnssec/signer/
>
> The tools are executables and the scripts almost.

no, that location is not kosher - bin/ never has subdirectories. the  
choices we basically have are:

	- PREFIX/lib/opendnssec/
	- PREFIX/libexec/opendnssec/
	- PREFIX/libdata/opendnssec/
	- PREFIX/share/opendnssec/

when looking at other software packages I find PREFIX/lib/opendnssec  
the best path; most python scripts live somewhere there.

	jakob



From jad at jadickinson.co.uk  Tue May  5 09:30:54 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Tue, 5 May 2009 10:30:54 +0100
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>
	<69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>
	<2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>
Message-ID: <1B0986E0-294F-48BC-A0F9-03727B4BA472@jadickinson.co.uk>


On 5 May 2009, at 09:06, Jakob Schlyter wrote:

> On 5 maj 2009, at 09.33, Rickard Bondesson wrote:
>
>> I think that the tools and the scripts should be installed under
>>
>> PREFIX/bin/opendnssec/signer/
>>
>> The tools are executables and the scripts almost.
>
> no, that location is not kosher - bin/ never has subdirectories. the  
> choices we basically have are:
>
> 	- PREFIX/lib/opendnssec/
> 	- PREFIX/libexec/opendnssec/
> 	- PREFIX/libdata/opendnssec/
> 	- PREFIX/share/opendnssec/
>
> when looking at other software packages I find PREFIX/lib/opendnssec  
> the best path; most python scripts live somewhere there.

What is wrong with PREFIX/bin/

John



From jakob at kirei.se  Tue May  5 09:32:24 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Tue, 5 May 2009 11:32:24 +0200
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <1B0986E0-294F-48BC-A0F9-03727B4BA472@jadickinson.co.uk>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>
	<69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>
	<2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>
	<1B0986E0-294F-48BC-A0F9-03727B4BA472@jadickinson.co.uk>
Message-ID: <1B089140-FA8A-45B9-9D13-B9BF3F517E48@kirei.se>

On 5 maj 2009, at 11.30, John Dickinson wrote:

> What is wrong with PREFIX/bin/

this is stuff like Engine.py, i.e. python components for the signer  
engine. after some more though we'll stick to PREFIX/lib/opendnssec/ 
signer for now unless someone has a really good reason not to.

	jakob



From rick at openfortress.nl  Tue May  5 09:41:42 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 5 May 2009 09:41:42 +0000
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <1B089140-FA8A-45B9-9D13-B9BF3F517E48@kirei.se>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>
	<69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>
	<2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>
	<1B0986E0-294F-48BC-A0F9-03727B4BA472@jadickinson.co.uk>
	<1B089140-FA8A-45B9-9D13-B9BF3F517E48@kirei.se>
Message-ID: <20090505094142.GE5629@phantom.vanrein.org>

Hi,

> this is stuff like Engine.py, i.e. python components for the signer  
> engine. after some more though we'll stick to PREFIX/lib/opendnssec/ 
> signer for now unless someone has a really good reason not to.

Isn't it better to use the Python habits for Python code?

Python has directories PREFIX/lib/pythonX.Y/site-packages/ for that
purpose.  It contains a README that specifies it is intended for
third-party add-ons:

> This directory exists so that 3rd party packages can be installed
> here.  Read the source for site.py for more details.

Running `pydoc site` shows that these 3rd party add-ons will be included
at startup.  It also warns that it adds a PREFIX=/usr/local/ only for
Debian.


Cheers,
 -Rick


From Stephen.Morris at nominet.org.uk  Tue May  5 14:56:21 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Tue, 5 May 2009 16:56:21 +0200
Subject: [Opendnssec-develop] OpenDNSSEC Requirements Updated
Message-ID: <OFF3BD490D.3970709E-ON802575AD.0050D691-C12575AD.00521061@nominet.org.uk>

As a prelude for writing the test plan, I have updated the requirements 
for OpenDNSSEC - see 
http://www.opendnssec.se/wiki/ProjectPlan/Requirements

I have incorporated the original requirements, as well as requirements 
from Nominet and .SE.

Comments?

Stephen


From jelte at NLnetLabs.nl  Tue May  5 15:10:34 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Tue, 05 May 2009 17:10:34 +0200
Subject: [Opendnssec-develop] OpenDNSSEC Requirements Updated
In-Reply-To: <OFF3BD490D.3970709E-ON802575AD.0050D691-C12575AD.00521061@nominet.org.uk>
References: <OFF3BD490D.3970709E-ON802575AD.0050D691-C12575AD.00521061@nominet.org.uk>
Message-ID: <4A0056EA.5060709@NLnetLabs.nl>

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

Stephen.Morris at nominet.org.uk wrote:
> As a prelude for writing the test plan, I have updated the requirements 
> for OpenDNSSEC - see 
> http://www.opendnssec.se/wiki/ProjectPlan/Requirements
> 
> I have incorporated the original requirements, as well as requirements 
> from Nominet and .SE.
> 
> Comments?
> 

just a few at a quick glance;

I'm seeing a few things that it currently does not do (signatures on first
input, but i think i can add that without much trouble), or probably can't
handle in any decent timerange (sorting might take a while for millions of records)

RSA support is mentioned, but not RSAwithSHA1 and/or RSAwithMD5 (not that I know
of anyone actually using that, but it might be good to at least make the
distinction, and we will know where to put SHA2 if that draft ever reaches
publication)

I don't know in which category it would fall, but the SOA SERIAL that is used
could be very important for some people, I've heard of at least one instance
where they have the requirement that it is not changed by the signer. This will
have very serious consequences on when and how to do resigning operations (one
would have to 'sneak' them into normal updates, which of course have to happen
regularly then, but i guess this is more appropriate for the second version; so
it could actually be an explicit non-requirement.

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

iEYEARECAAYFAkoAVuoACgkQ4nZCKsdOncUc4QCgpwzQag1O60w2aqEg3fxIiB0I
xp4An3KhlBFU9I5OyYl+BStemJmHXyAD
=79NR
-----END PGP SIGNATURE-----


From rick at openfortress.nl  Tue May  5 20:17:36 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 5 May 2009 20:17:36 +0000
Subject: [Opendnssec-develop] HSM test program -> develop against SoftHSM?
Message-ID: <20090505201736.GB12913@phantom.vanrein.org>

Hello Rickard, Stephen and Roland,

I am working on the HSM testing program, and wondering how to test the
test program, other than sticking to the PKCS #11 specification as
tightly as possible.

One approach would be to absolutely ignore the SoftHSM and test on another
device.  But whichever way I turn it, it will always be a test against
something concrete, not against a generic thing like the spec, which it
would ideally be.

I am now thinking that I could test against the SoftHSM, and "wrestle"
with Rickard over who is right/wrong when differences pop up.  Since
the HSM Test code was written in total ignorance of the SoftHSM code,
and since I will continue to discuss with Rickard instead of his code,
we would actually end up testing to see if the specs are properly
implemented on either end.

If either of you (or the Cc'd list) sees a formal problem with such testing
against the SoftHSM then please speak now or otherwise I shall proceed.


Cheers,
 -Rick


From jakob at kirei.se  Tue May  5 20:20:41 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Tue, 5 May 2009 22:20:41 +0200
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <20090505094142.GE5629@phantom.vanrein.org>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>
	<69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>
	<2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>
	<1B0986E0-294F-48BC-A0F9-03727B4BA472@jadickinson.co.uk>
	<1B089140-FA8A-45B9-9D13-B9BF3F517E48@kirei.se>
	<20090505094142.GE5629@phantom.vanrein.org>
Message-ID: <2373E162-DA75-466B-8C90-7FB23338F8B8@kirei.se>

On 5 maj 2009, at 11.41, Rick van Rein wrote:

> Isn't it better to use the Python habits for Python code?
>
> Python has directories PREFIX/lib/pythonX.Y/site-packages/ for that
> purpose.  It contains a README that specifies it is intended for
> third-party add-ons:

sure, we can do that, but is this really normal python package? jelte?

	j



From rickard.bondesson at iis.se  Wed May  6 06:30:09 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 6 May 2009 08:30:09 +0200
Subject: [Opendnssec-develop] HSM test program -> develop against SoftHSM?
In-Reply-To: <20090505201736.GB12913@phantom.vanrein.org>
References: <20090505201736.GB12913@phantom.vanrein.org>
Message-ID: <69830D4127201D4EBD146B9041199718B06DD5@EXCHANGE.office.nic.se>

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

> I am working on the HSM testing program, and wondering how to 
> test the test program, other than sticking to the PKCS #11 
> specification as tightly as possible.

I think that you should write the code as you think that PKCS#11 should work according to the API. The question is whether you should write a test program that allows some minor problems in some corner cases that won't do any bad, or tightly according to the API?

> One approach would be to absolutely ignore the SoftHSM and 
> test on another device.  But whichever way I turn it, it will 
> always be a test against something concrete, not against a 
> generic thing like the spec, which it would ideally be.

You have to test the real things (SCA6000, AEP Keyper, SoftHSM, ...) since RSA Labs do not have a soft implementation or otherwise we would not need SoftHSM.

> I am now thinking that I could test against the SoftHSM, and "wrestle"
> with Rickard over who is right/wrong when differences pop up. 
>  Since the HSM Test code was written in total ignorance of 
> the SoftHSM code, and since I will continue to discuss with 
> Rickard instead of his code, we would actually end up testing 
> to see if the specs are properly implemented on either end.

That is a good idea. Because I am trying to write a HSM according to the API and you are trying to test according to the API. Then we can have a common view. A potential problem might be that the other vendors might have another view, thus breaking the tests. But we can always discuss what might be the problem behind the failure.

> If either of you (or the Cc'd list) sees a formal problem 
> with such testing against the SoftHSM then please speak now 
> or otherwise I shall proceed.

+1

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

wsBVAwUBSgEuceCjgaNTdVjaAQgLtAf/ZuRzI2ZJSPaBlUXOC2pk2AZIWUjudT1F
cbQGo0iAr8LE3RX63DRVO1wxgC6ROCSG8HX8Nosr4b/DTLXVQRMod04zgJ6nHpWt
cOdVPZXX59Exn7o4hKKGlre7i+cWHGGjX3FjSoTBnZ14xV6dE7L6Z9cW65bJCD8I
RWDKcQ8C9zgtCiStwPVlHxYMXJPDX1ZcT+7ot5EAagk/AbFQrwEdY2zoLBC+5oXQ
ECwvyGHwZ3/RcelOq8q0FAcqH1GddzSxY5oHavxBRDHc8ziKUBImdeJPLdts2DH/
W/3dGeT6izqioLGFwNcYAnSEmDJC7zuF8cI0iP/lGgy2G3RlEsxuPA==
=+qjd
-----END PGP SIGNATURE-----


From rick at openfortress.nl  Wed May  6 06:47:57 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 6 May 2009 06:47:57 +0000
Subject: [Opendnssec-develop] Re: HSM test program -> develop against
	SoftHSM?
In-Reply-To: <69830D4127201D4EBD146B9041199718B06DD5@EXCHANGE.office.nic.se>
References: <20090505201736.GB12913@phantom.vanrein.org>
	<69830D4127201D4EBD146B9041199718B06DD5@EXCHANGE.office.nic.se>
Message-ID: <20090506064757.GB19257@phantom.vanrein.org>

Hi Rickard,

> A potential problem might be that the other vendors might have another
> view, thus breaking the tests.

I've dealt with this a lot, and have generally found PKCS #11 a very good
standard, in that it leaves little room for imagination.

-Rick


From jakob at kirei.se  Wed May  6 08:59:31 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 6 May 2009 10:59:31 +0200
Subject: [Opendnssec-develop] tree cleanup ahead
Message-ID: <BC9768FB-7C1A-4DD3-AEC7-34430147C788@kirei.se>

hi,

I've been doing some licensing cleanups and will continue tomorrow  
with some cleanup of the automake files, add common scripts for  
updating automake etc. personal build scripts that might disappear,  
but you can always resurrect them from the repo if you want a local  
copy.

if you find me intrusive, let me know and I'll might back off :-)

	jakob



From jelte at NLnetLabs.nl  Wed May  6 09:14:56 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 06 May 2009 11:14:56 +0200
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <2373E162-DA75-466B-8C90-7FB23338F8B8@kirei.se>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>	<69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>	<2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>	<1B0986E0-294F-48BC-A0F9-03727B4BA472@jadickinson.co.uk>	<1B089140-FA8A-45B9-9D13-B9BF3F517E48@kirei.se>	<20090505094142.GE5629@phantom.vanrein.org>
	<2373E162-DA75-466B-8C90-7FB23338F8B8@kirei.se>
Message-ID: <4A015510.207@NLnetLabs.nl>

Jakob Schlyter wrote:
> On 5 maj 2009, at 11.41, Rick van Rein wrote:
> 
>> Isn't it better to use the Python habits for Python code?
>>
>> Python has directories PREFIX/lib/pythonX.Y/site-packages/ for that
>> purpose.  It contains a README that specifies it is intended for
>> third-party add-ons:
> 
> sure, we can do that, but is this really normal python package? jelte?
> 

I'm not really sure whether there is a canonical path for python files; 
/usr/lib/python-X.Y/site-packages/$program seems to be used about as much as 
/usr/lib/$program/$optional_subdir on my systems.

Jelte


From jakob at kirei.se  Wed May  6 18:53:45 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 6 May 2009 20:53:45 +0200
Subject: [Opendnssec-develop] where to install scripts
In-Reply-To: <4A015510.207@NLnetLabs.nl>
References: <90710986-7F3F-4BE4-8FB3-ACC7428E866F@kirei.se>	<69830D4127201D4EBD146B9041199718B06D30@EXCHANGE.office.nic.se>	<2BDFAA7D-051C-4DAF-A55C-376FE20390A4@kirei.se>	<1B0986E0-294F-48BC-A0F9-03727B4BA472@jadickinson.co.uk>	<1B089140-FA8A-45B9-9D13-B9BF3F517E48@kirei.se>	<20090505094142.GE5629@phantom.vanrein.org>
	<2373E162-DA75-466B-8C90-7FB23338F8B8@kirei.se>
	<4A015510.207@NLnetLabs.nl>
Message-ID: <45404748-C541-4126-B287-4328A353BD64@kirei.se>

On 6 maj 2009, at 11.14, Jelte Jansen wrote:

> I'm not really sure whether there is a canonical path for python  
> files; /usr/lib/python-X.Y/site-packages/$program seems to be used  
> about as much as /usr/lib/$program/$optional_subdir on my systems.

I agree, let's leave it in lib/opendnssec/signer for now.

	jakob




From jakob at kirei.se  Wed May  6 18:55:45 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 6 May 2009 20:55:45 +0200
Subject: [Opendnssec-develop] Re: HSM test program -> develop against
	SoftHSM?
In-Reply-To: <20090506064757.GB19257@phantom.vanrein.org>
References: <20090505201736.GB12913@phantom.vanrein.org>
	<69830D4127201D4EBD146B9041199718B06DD5@EXCHANGE.office.nic.se>
	<20090506064757.GB19257@phantom.vanrein.org>
Message-ID: <3966A903-5DD5-46BD-8855-FDBCE271B3E1@kirei.se>

On 6 maj 2009, at 08.47, Rick van Rein wrote:

> I've dealt with this a lot, and have generally found PKCS #11 a very  
> good
> standard, in that it leaves little room for imagination.

still vendors like Sun doesn't implement parts of it (which we found  
out when testing the signer earlier this week). I believe the HSM test  
program should exercise at least the stuff we use in libhsm (currently  
that code lives in the signer and in keygend), so that people can  
verify that the pkcs11 library they've given works with OpenDNSSEC.

	jakob



From rickard.bondesson at iis.se  Fri May  8 06:42:01 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Fri, 8 May 2009 08:42:01 +0200
Subject: [Opendnssec-develop] Plattform support
Message-ID: <69830D4127201D4EBD146B9041199718B06F07@EXCHANGE.office.nic.se>

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

Please fill in the plattforms that your components have compiled and works on (or not).

http://www.opendnssec.se/wiki/Signer/Phase1/PlatformSupport

Signer
Enforcer
libksm
libhsm
SoftHSM

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

wsBVAwUBSgPUOeCjgaNTdVjaAQivLwgAgQRqFqBgGgqkiF+plwFVMmj08iMe1muc
RimUkLVfEARc0xe6YJ86BYqQJxKHVlvLqi4khxHxWUabqYUi0os0+Ft0aVmzPEQb
lOH8svAfOWHFqneDNQ6PiTHwy53F92oZCbA8ql6hOa9Ud9muKCHVfvEb5mnWRW5+
W02+mJ8h/1VjiHBXIlG2cWXv0CI74KiaBnyHt+DA29Zsv+WYoTlBxEU5ks+0v33g
K2OkLSt9Ub43SfWNXHDjTw9YR9Gypnxg4JxIKcJ/s76SwE8RlnWahDFkg3lCoQGM
NP3AyWEqPGL/cgEimKfbaGDExFxJT/2KctT314fpNpazvMG5kfVLCg==
=Caxx
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Fri May  8 11:22:35 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Fri, 8 May 2009 13:22:35 +0200
Subject: [Opendnssec-develop] C Standard
Message-ID: <69830D4127201D4EBD146B9041199718B06F51@EXCHANGE.office.nic.se>

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

Which version of C are we writing/supporting?

C89/C90 or C99?

I get less warnings to fix with C99.

Any comments?

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

wsBVAwUBSgQV++CjgaNTdVjaAQiHGAf+OJaLP8nQY2JFQ2wu7hLARFBWi091d13C
WdvpkEj0Q+JtpLbFh/OeOrfxq5pJQ2gAwpu/MryBsm2qP9qFvYddfgEpSnoZzPVd
gBccOZGUfMzLh/VqWvqOn8YjBkE31+8N+M5XPzlHFe34V9znvw1+F+0gCJq51p0f
E+sWcJSUP1SNX+0D3ku//Q7xFLLEPfekysh67O0+W7ZAGZXNhpWEnNtpoaOp1FhZ
Fd6yEfdYpHF8U16kgjpaCZIdosXG5L+2XMyqnxqNc6D/RramUhkE7VbZCadrNSrA
MTjFcqmhDe7cKDD3/7140nTcN9+Z3Vu4as2oFWzPXmOR0AF3XlPg4A==
=Y7xQ
-----END PGP SIGNATURE-----


From jakob at kirei.se  Fri May  8 12:00:59 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 8 May 2009 14:00:59 +0200
Subject: [Opendnssec-develop] initial results for signing .se
Message-ID: <EEB3F435-BEC0-4C21-BBE4-E3C8DC941445@kirei.se>

gentlemen,

I've just signed .SE using Jeltes sorter, nseccer and signer!

  - 1,465,431 unsigned RRs in 6 minutes and 16 seconds giving  
2,709,724 RRs output.


wheee!


	jakob



From olaf at NLnetLabs.nl  Fri May  8 12:08:50 2009
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Fri, 8 May 2009 14:08:50 +0200
Subject: [Opendnssec-develop] initial results for signing .se
In-Reply-To: <EEB3F435-BEC0-4C21-BBE4-E3C8DC941445@kirei.se>
References: <EEB3F435-BEC0-4C21-BBE4-E3C8DC941445@kirei.se>
Message-ID: <F2F19F3D-842D-4B76-8420-C40315CE912D@NLnetLabs.nl>




Sorted or unsorted input?

-Olaf

On 8 mei 2009, at 14:00, Jakob Schlyter wrote:

> gentlemen,
>
> I've just signed .SE using Jeltes sorter, nseccer and signer!
>
> - 1,465,431 unsigned RRs in 6 minutes and 16 seconds giving  
> 2,709,724 RRs output.
>
>
> wheee!
>
>
> 	jakob
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 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/20090508/3cf5d762/attachment.bin>

From jakob at kirei.se  Fri May  8 12:10:32 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 8 May 2009 14:10:32 +0200
Subject: [Opendnssec-develop] initial results for signing .se
In-Reply-To: <F2F19F3D-842D-4B76-8420-C40315CE912D@NLnetLabs.nl>
References: <EEB3F435-BEC0-4C21-BBE4-E3C8DC941445@kirei.se>
	<F2F19F3D-842D-4B76-8420-C40315CE912D@NLnetLabs.nl>
Message-ID: <59127E69-B55B-43DE-B6BF-1CD14E551448@kirei.se>

On 8 maj 2009, at 14.08, Olaf Kolkman wrote:

> Sorted or unsorted input?

unsorted. we don't need to sort the output.

	j



From Stephen.Morris at nominet.org.uk  Fri May  8 12:11:36 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Fri, 8 May 2009 14:11:36 +0200
Subject: [Opendnssec-develop] C Standard
In-Reply-To: <69830D4127201D4EBD146B9041199718B06F51@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B06F51@EXCHANGE.office.nic.se>
Message-ID: <OF714E2231.EB58935D-ON802575B0.0042C7A0-C12575B0.0042FB49@nominet.org.uk>

"Rickard Bondesson" <rickard.bondesson at iis.se>  wrote on 08/05/2009 
13:22:35:

> Which version of C are we writing/supporting?
> 
> C89/C90 or C99?
> 
> I get less warnings to fix with C99.
> 
> Any comments?
> 
> // Rickard

Just out of interest, what warnings are missing from the C99 compilation?

Stephen


From rickard.bondesson at iis.se  Fri May  8 12:18:04 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Fri, 8 May 2009 14:18:04 +0200
Subject: [Opendnssec-develop] C Standard
In-Reply-To: <OF714E2231.EB58935D-ON802575B0.0042C7A0-C12575B0.0042FB49@nominet.org.uk>
References: <69830D4127201D4EBD146B9041199718B06F51@EXCHANGE.office.nic.se>
	<OF714E2231.EB58935D-ON802575B0.0042C7A0-C12575B0.0042FB49@nominet.org.uk>
Message-ID: <69830D4127201D4EBD146B9041199718B06F64@EXCHANGE.office.nic.se>

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

> Just out of interest, what warnings are missing from the C99 
> compilation?

C90 complains about comments like this:
 // A comment

All variables have to be declared in the beginning of a code block.

Fixed all of them, so now I am happy with C90 :)

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

wsBVAwUBSgQi/OCjgaNTdVjaAQhClQf+LkZlDk+meYiMeAvAvyZlsYAgth2Vs+Mz
WMvz10wzkrw4X/1ex9ZqPXAuz6jh1WFTxAVyWVaSk7qSP38btcKUWaZS983YPERp
SHGJgLWk9Ud/KDzQwx3lOFYv/OctYhQm5UI6ZZe3Z+/mX+aVw+BqWx2iKdFDwkFu
Vwadl7zbSGovgEM/eIDRKlCSv6k0lrAxEmPb1QMmyPWC1NDkPTOxWaolgJ1h8A98
UA1Ni5qJbsl5INZmf2Ll4fiWioFb4un0q9okhBUX1MxDDhGMwnlE10VMcZP8C1oT
FuZzS4M4RLfTXvOuFpplH0yWrZ+jmjhQeYdOmzAJoquF5f/k38VDJw==
=DyCX
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Fri May  8 14:17:21 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Fri, 08 May 2009 16:17:21 +0200
Subject: [Opendnssec-develop] C Standard
In-Reply-To: <69830D4127201D4EBD146B9041199718B06F64@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B06F51@EXCHANGE.office.nic.se>	<OF714E2231.EB58935D-ON802575B0.0042C7A0-C12575B0.0042FB49@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718B06F64@EXCHANGE.office.nic.se>
Message-ID: <4A043EF1.9060705@NLnetLabs.nl>

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

Rickard Bondesson wrote:
>> Just out of interest, what warnings are missing from the C99 
>> compilation?
> 
> C90 complains about comments like this:
>  // A comment
> 
> All variables have to be declared in the beginning of a code block.
> 
> Fixed all of them, so now I am happy with C90 :)
> 

I prefer C99, at least for the parts that use ldns, since the ldns api has some
c99 things as well.

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

iEYEARECAAYFAkoEPvAACgkQ4nZCKsdOncVdpQCcCf9H90Q/j9IPpiA9uxezjbdx
eIMAn3edLHXL+6R5oOXjp22qJOGSn4cu
=j4Qf
-----END PGP SIGNATURE-----


From Stephen.Morris at nominet.org.uk  Mon May 11 09:35:38 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Mon, 11 May 2009 10:35:38 +0100
Subject: [Opendnssec-develop] KASP Auditor Implementation
Message-ID: <OF01EAE0BA.3BD3F85F-ON802575B1.00335905-802575B3.0034B3D7@nominet.org.uk>

We now have the requirements for the KASP Auditor, but have not said 
anything about the implementation language.  What are the feelings about 
implementing it in Ruby, using the DNSRuby library (
http://rubyforge.org/projects/dnsruby)?

I ask because DNSRuby is a project that we have been running internally, 
and the developer is both available and interested in a project like this.

Stephen


From jakob at kirei.se  Mon May 11 09:40:30 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 11 May 2009 11:40:30 +0200
Subject: [Opendnssec-develop] KASP Auditor Implementation
In-Reply-To: <OF01EAE0BA.3BD3F85F-ON802575B1.00335905-802575B3.0034B3D7@nominet.org.uk>
References: <OF01EAE0BA.3BD3F85F-ON802575B1.00335905-802575B3.0034B3D7@nominet.org.uk>
Message-ID: <59AAB20F-397B-4F79-9D86-AAA816702006@kirei.se>

On 11 maj 2009, at 11.35, Stephen.Morris at nominet.org.uk wrote:

> We now have the requirements for the KASP Auditor, but have not said
> anything about the implementation language.  What are the feelings  
> about
> implementing it in Ruby, using the DNSRuby library (
> http://rubyforge.org/projects/dnsruby)?
>
> I ask because DNSRuby is a project that we have been running  
> internally,
> and the developer is both available and interested in a project like  
> this.

as the auditor is very different from the rest of the components, I  
think this seems like a doable idea. also, sharing (or borrowing :-)  
code from other parts of the project will not happen easily :-)

	jakob



From rickard.bondesson at iis.se  Tue May 12 07:03:46 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Tue, 12 May 2009 09:03:46 +0200
Subject: [Opendnssec-develop] KASP Auditor Implementation
In-Reply-To: <59AAB20F-397B-4F79-9D86-AAA816702006@kirei.se>
References: <OF01EAE0BA.3BD3F85F-ON802575B1.00335905-802575B3.0034B3D7@nominet.org.uk>
	<59AAB20F-397B-4F79-9D86-AAA816702006@kirei.se>
Message-ID: <69830D4127201D4EBD146B9041199718B070A2@EXCHANGE.office.nic.se>

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

> > We now have the requirements for the KASP Auditor, but have 
> not said 
> > anything about the implementation language.  What are the feelings 
> > about implementing it in Ruby, using the DNSRuby library ( 
> > http://rubyforge.org/projects/dnsruby)?
> >
> > I ask because DNSRuby is a project that we have been running 
> > internally, and the developer is both available and interested in a 
> > project like this.
> 
> as the auditor is very different from the rest of the 
> components, I think this seems like a doable idea. also, 
> sharing (or borrowing :-) code from other parts of the 
> project will not happen easily :-)

Sounds reasonable. What is your view concerning performance, reliability, and correctness in Ruby and DNSRuby? How much do you need to install to be able to run the KASP Auditor?

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

wsBVAwUBSgkfUuCjgaNTdVjaAQjq5wf+LSWWjeVoV98YzJJ2fMQ6Dy94lwKNA7wk
RHzebmHBdszwZKQHOgVeFJ/oUsSlkIRfRz+GxhzJ5mV6Zrd+QhNTyax2iHqqzV4G
7r63/FFKwIZUSHihyGAzFlOhg9ftZ9CCr5NA9sYrwfZpqBp74ZgYpMyGU/22TJVb
/pk0PzxSuQjlkeX3IBZGkqIfUdnzQWq3SJL/7whCv/YWNiRa144YPCesrXEIKBPR
X0eITA+rfH1dI6lsZ1+3b6s8kpcYXVS6uWzuAutw/oLrg93u7rAxKEkreAZAQmU0
xNjPgOgn30XlzmAfFMyPOuLOl5aH2A4/TMhQZgZzAKttl7z7YIjPZA==
=4Ohu
-----END PGP SIGNATURE-----


From Stephen.Morris at nominet.org.uk  Tue May 12 09:00:55 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Tue, 12 May 2009 10:00:55 +0100
Subject: [Opendnssec-develop] KASP Auditor Implementation
In-Reply-To: <69830D4127201D4EBD146B9041199718B070A2@EXCHANGE.office.nic.se>
References: <OF01EAE0BA.3BD3F85F-ON802575B1.00335905-802575B3.0034B3D7@nominet.org.uk>
	<59AAB20F-397B-4F79-9D86-AAA816702006@kirei.se>
	<69830D4127201D4EBD146B9041199718B070A2@EXCHANGE.office.nic.se>
Message-ID: <OFF7001796.BEF2D029-ON802575B4.00303F29-802575B4.0031865D@nominet.org.uk>

"Rickard Bondesson" <rickard.bondesson at iis.se> wrote on 12/05/2009 
08:03:46:

> Sounds reasonable. What is your view concerning performance, 
> reliability, and correctness in Ruby and DNSRuby? How much do you 
> need to install to be able to run the KASP Auditor?

I'm biased, but I think it is reliable. I believe that ISC are using it 
for the front-end to their DLV repository.

As to performance, we have not done any measurements so that is something 
that needs to be checked.  However, the requirements for the KASP auditor 
do allow for the auditor to check a sample of the records, so I guess that 
if performance is an issue, we tune the sample size to fit the available 
time.

Finally, Ruby is installed on many operating systems.  The DNSRuby package 
needs to be installed, but as that is available on Rubyforge, "gem" can be 
used to install it.  "gem" is the Ruby package manager and will be 
available Ruby; with it, installation of DNSRuby is nothing more than 
issuing the command "sudo gem install dnsruby".

Stephen


From Antoin.Verschuren at sidn.nl  Tue May 12 12:12:28 2009
From: Antoin.Verschuren at sidn.nl (Antoin Verschuren)
Date: Tue, 12 May 2009 14:12:28 +0200
Subject: [Opendnssec-develop] Review requirements
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
Message-ID: <850A39016FA57A4887C0AA3C8085F949C4FAD3@KAEVS1.SIDN.local>

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

Hi all,

I've taken some time to review the openDNSSEC requirements.
I came across 2 requirements on the website, one for the complete project (http://www.opendnssec.se/wiki/ProjectPlan/Requirements) and one only for the signer (http://www.opendnssec.se/wiki/Signer/AuditorRequirements)

I've taken the liberty to review http://www.opendnssec.se/wiki/ProjectPlan/Requirements, and I have some questions to discuss:

1. In 3.2.3 it says: "2. The signer MAY inspect input DNSSEC RRs associated with a zone and, if valid, output them instead of generating new ones.
Note: this behaviour SHOULD be a configurable option."
Can somebody explain why this should be a configurable option ? Or in other words, in what situations would you want to be able to mess with this ? 

2. I see in 2.4.3: "It MUST be possible to manually roll the KSK for a zone."
I don't know how far this goes, but does that mean that there should be a simple command or button to do an emergency key rollover ?
I think in case of a key compromise, I would like to have a simple button like that, so all other integrity checks are done automatically. Not only that I can manually generate a key, but all other keys and timers should be recalculated so that operation goes back to normal. An emergency key rollover without thinking what else needs to be done.

3. 2.4.3: "6. The production of a new KSK for a zone MAY be notified to the operator if such notifications are enabled."
I would like to have a configurable notification option as well where I am warned in advance that a KSK rollover will be necessary in a specific timeframe.
So f.e a notification that I need to generate new keys in the coming month. In cases of some higher security, f.e. when manual intervention for KSK generation is needed (offline signing).
Do we still find that applicable ? Is there still an opinion that ZSK rollovers are handled by the HSM/signer, but KSK rollovers can/should be done offline ?

4. Don't know if this is a nice to have or a requirement: I would like to have some state reporting to see how my signing is progressing.
A sort of oversight of all the zones with the versions of KSK and ZSK's used or ready to be used to monitor the signing process.

5. Parent interaction
How configurable will the KSK notifications be ? I'm thinking of parsing notifications directly to my parent. You'll have questions like do I need the DNSKEy, should I calculate the DS, can I follow the update process at the parent, in other words, what information and format do I need for KSK notification ?

6. There is a requirement for multiple HSM's to facilitate migration to new HSM's. I think another use case is that there are more zones/keys than fit in a single HSM, so you'll need extra HSM's to expand capacity. That use case should be provided too. I think it says that correctly in the requirements, but I want to make sure.

7. Integrity checking
We are used to do integrity checking before a zone is published. However, we can do a lot of integrity checking because we generate a complete new build of a zone. So we can compare the old zone with the new one and see if there is not a major change. I have 2 questions: Will integrity checking be done only on the DNSSEC data, or also on other parameters (What happens f.e. if the outputted zone is DNSSEC correct but has 90% less data). Or in other words do I still need integrity checking of the zone before and after I submit it to the signer.
And the second question is how configurable will this be ? I can imagine there are zone specific checks you want performed (this record should be in there). Or is this out of scope ?

8. Performance
I think this does indeed need more specification, and I think the current requirement is quite low.
I don't know how this will impact the one large zone versus lot's of small zones, or how that performance changes when increments are signed later, or do we think about that in a next stage ?
Shouldn't we have similar performance figures for integrity checking ? (The more you check, the longer it takes).

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E antoin.verschuren at sidn.nl
W http://www.sidn.nl/


> -----Original Message-----
> From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-
> develop-bounces at lists.opendnssec.org] On Behalf Of
> Stephen.Morris at nominet.org.uk
> Sent: Thursday, April 23, 2009 1:39 PM
> To: Opendnssec-develop at lists.opendnssec.org
> Subject: [Opendnssec-develop] KASP Auditor Requirements
> 
> 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
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSglnrDqHrM883AgnAQiwoQf9FgS4hQUgwL48aV8NaVoz0Z90Xz/DkqsD
7gkA4nLl2Bu48zaGYZLLUIKHK11a/CfLMwTsuwsXjI5TpG7J8hDKZ9If7X2V0qQA
msEq3+AACVHnn2rFgjdpshQFSU1WEdm9HTdgOMQ5lxot8OuxOEslPPVbGRWnGdz6
qlbwB1C9a0zyptUHax/rGgicREjjmzyihfNDDkbeId2IzFAPKMMf82/KueZK7UTr
XRudHIoSiZP4L5GuuVniOakRpKEDDOHPfX6B5vaYdM+pmRrPPJWpa5e8HFTsp7e8
8wLzcbzu2A/e+OY4pedwqQu9ENuY+SSDZB1vW4GKLCxoYX6Odd/dyg==
=E3kN
-----END PGP SIGNATURE-----


From jad at jadickinson.co.uk  Tue May 12 13:20:36 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Tue, 12 May 2009 14:20:36 +0100
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: <A7AD6648-4A74-44B7-B988-F3320DC0338C@jadickinson.co.uk>


On 23 Apr 2009, at 12:38, Stephen.Morris at nominet.org.uk wrote:

> 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


Some notes:
3.1 item 1: the signer should be able to change the TTL,  minimum  and  
serial numbers for the SOA. This is important so that the signer can  
"fix" a unsigned zone that does not contain values which are not  
consistent with the values specified in kasp.

3.1 item 2: using serial number arithmetic, of course.

3.2: item 2: the protocol field must equal 3
3.2: I don't agree the last two checks. Either the sep bit should be  
being used in a way consistent with RFC5011 or in a way consistent  
with the policy. It may be that the policy should be consistent with a  
BCP RFC like 4641bis.

3.3 s/domain/zone/

3.4 item 1: what if you are switching from nsec to nsec3? This does  
not have to be done in a single step.
3.4 item 4: should read: the nsec records form a single closed loop  
linking each owner name in canonical order.
3.4 item 5: should read: each nsec correctly identifies the set of RR  
types present at the  owner name.

3.5 item 1: what if you are switching from nsec3 to nsec? This does  
not have to be done in a single step.
3.5 item 2: if you are doing nsec3 then there must be a nsec3param.
3.5 item 2c:  there must be at least one complete chain of nsec3  
records present with the same set of nsec3 parameters.
3.5 item 3: should read: each nsec3  record has bits set to indicate  
the types of rr's  present at the owner name.
3.5 item 4: should read: the next hashed owner name field contains   
the next hashed owner name in hash order.

3.5: I think we should also say that all nsec3 records must either be  
opt in or opt out.


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  Tue May 12 21:11:07 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Tue, 12 May 2009 23:11:07 +0200
Subject: [Opendnssec-develop] Review requirements
In-Reply-To: <850A39016FA57A4887C0AA3C8085F949C4FAD3@KAEVS1.SIDN.local>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
	<850A39016FA57A4887C0AA3C8085F949C4FAD3@KAEVS1.SIDN.local>
Message-ID: <D70E9773-51E0-46F4-B9A3-E63279C3795A@kirei.se>

On 12 maj 2009, at 14.12, Antoin Verschuren wrote:

> 1. In 3.2.3 it says: "2. The signer MAY inspect input DNSSEC RRs  
> associated with a zone and, if valid, output them instead of  
> generating new ones.
> Note: this behaviour SHOULD be a configurable option."
> Can somebody explain why this should be a configurable option ? Or  
> in other words, in what situations would you want to be able to mess  
> with this ?

if you feed the opendnssec system an already signed zone, you may want  
to strip all dnssec information at ingress.

> 2. I see in 2.4.3: "It MUST be possible to manually roll the KSK for  
> a zone."
> I don't know how far this goes, but does that mean that there should  
> be a simple command or button to do an emergency key rollover ?

yes.

> I think in case of a key compromise, I would like to have a simple  
> button like that, so all other integrity checks are done  
> automatically. Not only that I can manually generate a key, but all  
> other keys and timers should be recalculated so that operation goes  
> back to normal. An emergency key rollover without thinking what else  
> needs to be done.

yes.

> 3. 2.4.3: "6. The production of a new KSK for a zone MAY be notified  
> to the operator if such notifications are enabled."
> I would like to have a configurable notification option as well  
> where I am warned in advance that a KSK rollover will be necessary  
> in a specific timeframe.

seems like resonable thing that one would like to ask the KASP enforcer.

> So f.e a notification that I need to generate new keys in the coming  
> month. In cases of some higher security, f.e. when manual  
> intervention for KSK generation is needed (offline signing).
> Do we still find that applicable ? Is there still an opinion that  
> ZSK rollovers are handled by the HSM/signer, but KSK rollovers can/ 
> should be done offline ?

currently, all key handling is done online. we've had discussion  
regarding operations that involves carbon life forms as well, but  
nothing is currently implemented as far as I know.

> 4. Don't know if this is a nice to have or a requirement: I would  
> like to have some state reporting to see how my signing is  
> progressing.
> A sort of oversight of all the zones with the versions of KSK and  
> ZSK's used or ready to be used to monitor the signing process.

yes that would be nice. please send code :-)  (sorry, I had to say that)

> 5. Parent interaction
> How configurable will the KSK notifications be ? I'm thinking of  
> parsing notifications directly to my parent. You'll have questions  
> like do I need the DNSKEy, should I calculate the DS, can I follow  
> the update process at the parent, in other words, what information  
> and format do I need for KSK notification ?

as far as I know, we have not discussed parent-child interaction yet.

> 6. There is a requirement for multiple HSM's to facilitate migration  
> to new HSM's. I think another use case is that there are more zones/ 
> keys than fit in a single HSM, so you'll need extra HSM's to expand  
> capacity. That use case should be provided too. I think it says that  
> correctly in the requirements, but I want to make sure.

we have a capacity value for each HSM so that should be possible.


> 7. Integrity checking
> We are used to do integrity checking before a zone is published.  
> However, we can do a lot of integrity checking because we generate a  
> complete new build of a zone. So we can compare the old zone with  
> the new one and see if there is not a major change. I have 2  
> questions: Will integrity checking be done only on the DNSSEC data,  
> or also on other parameters (What happens f.e. if the outputted zone  
> is DNSSEC correct but has 90% less data). Or in other words do I  
> still need integrity checking of the zone before and after I submit  
> it to the signer.

IMHO, the KASP auditor should only audit what the KASP states - so  
garbage in, garbage out.

> And the second question is how configurable will this be ? I can  
> imagine there are zone specific checks you want performed (this  
> record should be in there). Or is this out of scope ?

I think this is out of scope.

> 8. Performance
> I think this does indeed need more specification, and I think the  
> current requirement is quite low.
> I don't know how this will impact the one large zone versus lot's of  
> small zones, or how that performance changes when increments are  
> signed later, or do we think about that in a next stage ?

parts of the performance is depending on what HSM is used, but also  
how scheduling is done. I think we need to revisit this after the  
first version is released.

> Shouldn't we have similar performance figures for integrity  
> checking ? (The more you check, the longer it takes).

yes, probably.


	jakob

--
Jakob Schlyter
Kirei AB - www.kirei.se



From Stephen.Morris at nominet.org.uk  Wed May 13 14:52:06 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Wed, 13 May 2009 15:52:06 +0100
Subject: [Opendnssec-develop] Review requirements
In-Reply-To: <D70E9773-51E0-46F4-B9A3-E63279C3795A@kirei.se>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
	<850A39016FA57A4887C0AA3C8085F949C4FAD3@KAEVS1.SIDN.local>
	<D70E9773-51E0-46F4-B9A3-E63279C3795A@kirei.se>
Message-ID: <OF351269A7.0469DF99-ON802575B5.00432235-802575B5.0051AC94@nominet.org.uk>

Jakob Schlyter <jakob at kirei.se> wrote on 12/05/2009 22:11:07:

> > 2. I see in 2.4.3: "It MUST be possible to manually roll the KSK for 
> > a zone."
> > I don't know how far this goes, but does that mean that there should 
> > be a simple command or button to do an emergency key rollover ?
> 
> yes.
> 
> > I think in case of a key compromise, I would like to have a simple 
> > button like that, so all other integrity checks are done 
> > automatically. Not only that I can manually generate a key, but all 
> > other keys and timers should be recalculated so that operation goes 
> > back to normal. An emergency key rollover without thinking what else 
> > needs to be done.
> 
> yes.

Just to amplify this, although the exact way you will tell the system to 
perform an emergency rollover still has to be defined, the operation 
itself is quite simple: the retirement date of the active key is set to 
the current time and a normal rollover is initiated.



> > 3. 2.4.3: "6. The production of a new KSK for a zone MAY be notified 
> > to the operator if such notifications are enabled."
> > I would like to have a configurable notification option as well 
> > where I am warned in advance that a KSK rollover will be necessary 
> > in a specific timeframe.
> 
> seems like reasonable thing that one would like to ask the KASP 
enforcer.

I agree.



> > So f.e a notification that I need to generate new keys in the coming 
> > month. In cases of some higher security, f.e. when manual 
> > intervention for KSK generation is needed (offline signing).
> > Do we still find that applicable ? Is there still an opinion that 
> > ZSK rollovers are handled by the HSM/signer, but KSK rollovers can/ 
> > should be done offline ?
> 
> currently, all key handling is done online. we've had discussion 
> regarding operations that involves carbon life forms as well, but 
> nothing is currently implemented as far as I know.

This sounds like something we need to specify more closely.



> > 4. Don't know if this is a nice to have or a requirement: I would 
> > like to have some state reporting to see how my signing is 
> > progressing.
> > A sort of oversight of all the zones with the versions of KSK and 
> > ZSK's used or ready to be used to monitor the signing process.
> 
> yes that would be nice. please send code :-)  (sorry, I had to say that)

I'm not sure about the a status report when the signer is in operation 
(Jelte, how feasible is this?), but a status report showing all zones, 
what keys are in the zone, and when the keys are due for replacement 
should be obtainable from the KASP database.

In fact, looking through the requirements document I realise that it says 
nothing about reporting current status.  It mentions a GUI (to be defined) 
for configuration and use of syslog to report what has happened, but 
nothing to report what _is_ happening - status of signer, KASP, keys etc. 
What are people's thoughts here?



> > 5. Parent interaction
> > How configurable will the KSK notifications be ? I'm thinking of 
> > parsing notifications directly to my parent. You'll have questions 
> > like do I need the DNSKEy, should I calculate the DS, can I follow 
> > the update process at the parent, in other words, what information 
> > and format do I need for KSK notification ?
> 
> as far as I know, we have not discussed parent-child interaction yet.

I think we need to discuss this.



> > 6. There is a requirement for multiple HSM's to facilitate migration 
> > to new HSM's. I think another use case is that there are more zones/ 
> > keys than fit in a single HSM, so you'll need extra HSM's to expand 
> > capacity. That use case should be provided too. I think it says that 
> > correctly in the requirements, but I want to make sure.
> 
> we have a capacity value for each HSM so that should be possible.

I think that the note on requirement 2.4.2.3 should be moved to 
requirement 2.4.2.4.a to make this clearer.



> > 7. Integrity checking
> > We are used to do integrity checking before a zone is published. 
> > However, we can do a lot of integrity checking because we generate a 
> > complete new build of a zone. So we can compare the old zone with 
> > the new one and see if there is not a major change. I have 2 
> > questions: Will integrity checking be done only on the DNSSEC data, 
> > or also on other parameters (What happens f.e. if the outputted zone 
> > is DNSSEC correct but has 90% less data). Or in other words do I 
> > still need integrity checking of the zone before and after I submit 
> > it to the signer.
> 
> IMHO, the KASP auditor should only audit what the KASP states - so 
> garbage in, garbage out.

The requirements for the KASP auditor includes two requirements to check 
non-DNSSEC data as well:

 1. All non-DNSSEC data (i.e. all RRs except NSEC, NSEC3, NSEC3PARAM, 
DNSKEY and RRSIG) in the input zone must be identical to that in the 
output zone. The only exception is SOA, where it is permissible for the 
serial number to differ.
 2. The KA may retain the SOA serial number for a zone between runs and 
warn if the zone serial number has decreased. 

(KA = KASP Auditor)


 
> > And the second question is how configurable will this be ? I can 
> > imagine there are zone specific checks you want performed (this 
> > record should be in there). Or is this out of scope ?
> 
> I think this is out of scope.

I agree that adding specific checks to the contents of the zone is out of 
scope of the project, although allowing some way for a user-specified 
checking program to gain control at some point may not be.  However, being 
able to configure the supplied checks is certainly in scope.  The 
requirements suggest that the auditor be configured to run on the entire 
zone or just a sample of the zone.  But should we require each of the 
checks (non-DNSSEC data, DNSKEY, NSEC etc.) to be configurable, e.g. give 
options to check the entire zone, not run the check, or check only a 
sample?


 
> > 8. Performance
> > I think this does indeed need more specification, and I think the 
> > current requirement is quite low.
> > I don't know how this will impact the one large zone versus lot's of 
> > small zones, or how that performance changes when increments are 
> > signed later, or do we think about that in a next stage ?
> 
> parts of the performance is depending on what HSM is used, but also 
> how scheduling is done. I think we need to revisit this after the 
> first version is released.
> 
> > Shouldn't we have similar performance figures for integrity 
> > checking ? (The more you check, the longer it takes).
> 
> yes, probably.

... although if you allow the checking of a sample of a zone, you can tune 
the size of the sample to fit your checking window.



I think that there are a number of issues that would we worth further 
discussion; could we add them to the agenda for the next teleconference? I 
don't think that anything here should delay the alpha release, but there 
are a number of things that we should perhaps consider adding to the beta 
version.

Stephen



From rickard.bondesson at iis.se  Wed May 13 14:58:01 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 13 May 2009 16:58:01 +0200
Subject: [Opendnssec-develop] Review requirements
In-Reply-To: <OF351269A7.0469DF99-ON802575B5.00432235-802575B5.0051AC94@nominet.org.uk>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk><850A39016FA57A4887C0AA3C8085F949C4FAD3@KAEVS1.SIDN.local><D70E9773-51E0-46F4-B9A3-E63279C3795A@kirei.se>
	<OF351269A7.0469DF99-ON802575B5.00432235-802575B5.0051AC94@nominet.org.uk>
Message-ID: <69830D4127201D4EBD146B9041199718B0720B@EXCHANGE.office.nic.se>

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

> I think that there are a number of issues that would we worth further 
> discussion; could we add them to the agenda for the next 
> teleconference? I 
> don't think that anything here should delay the alpha 
> release, but there 
> are a number of things that we should perhaps consider adding 
> to the beta 
> version.

Will add them to the agenda. And I will send a request for comments tomorrow.

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

wsBVAwUBSgrf+eCjgaNTdVjaAQgUlwf/WoGDTK4ZFrGsfwxMK0N5PBil39ftEN5x
pZtXryXU4QOJHDtOJ+P4EFhxnKHo0aj3tUA5asaXxLG2aQ7nK8hAe8u44iC9294t
pFo/uzeCK2Fbu3CAxzJwjJXJToWQv+93sLi+F4YXTd2J1EUz7FpkdqCXs3pUyUH9
sBbT5SsYsL8D0C8X4+Qu5nNLOrYTmfUsGTAlMYjOMs9JZ5gLmxPxyOtn8KODq9U+
sTnupfyjmiDAncnYHdCJNZGl4OosqtnTlx+yTjMEKHBuR4eSiOMlDAm+YFclf99/
Cciz/f2L/6OJRB4NFtmElFh7sstJXPbuXku+AOVb7LqLP09qKAXghA==
=1q6S
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Wed May 13 15:26:14 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 13 May 2009 17:26:14 +0200
Subject: [Opendnssec-develop] Review requirements
In-Reply-To: <OF351269A7.0469DF99-ON802575B5.00432235-802575B5.0051AC94@nominet.org.uk>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>	<850A39016FA57A4887C0AA3C8085F949C4FAD3@KAEVS1.SIDN.local>	<D70E9773-51E0-46F4-B9A3-E63279C3795A@kirei.se>
	<OF351269A7.0469DF99-ON802575B5.00432235-802575B5.0051AC94@nominet.org.uk>
Message-ID: <4A0AE696.5070806@NLnetLabs.nl>

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

Stephen.Morris at nominet.org.uk wrote:
> 
> I'm not sure about the a status report when the signer is in operation 
> (Jelte, how feasible is this?), but a status report showing all zones, 
> what keys are in the zone, and when the keys are due for replacement 
> should be obtainable from the KASP database.
> 
> In fact, looking through the requirements document I realise that it says 
> nothing about reporting current status.  It mentions a GUI (to be defined) 
> for configuration and use of syslog to report what has happened, but 
> nothing to report what _is_ happening - status of signer, KASP, keys etc. 
> What are people's thoughts here?
> 

currently, you can ask the engine what is planning to do and when, but not what
it is doing at this exact moment; ie.

jelte at blackbox:~> signer_engine_cli queue
It is now: 2009-05-13 17:18:22
I have 6 tasks scheduled
At 2009-05-13 17:46:57 I will sign zone  openic.nl
At 2009-05-13 17:46:58 I will sign zone  dots.jelte.nlnetlabs.nl
At 2009-05-13 17:56:56 I will sign zone  nsec3.tjeb.nl
At 2009-05-13 19:20:19 I will sign zone  jelte.nlnetlabs.nl
At 2009-05-13 22:33:33 I will sign zone  tjeb.nl
At 2009-05-14 00:06:31 I will sign zone  sub.jelte.nlnetlabs.nl

though this is more of a debug option :)

The moment it starts signing it will disappear from the list, until it is done
signing, because it will automatically schedule a new resign operation.

I could extend this with the actions that are currently running, but in the way
it is done now it would not be able to tell how far it is; the actual signing
process doesn't know anything about zone sizes, it just gets rrsets and creates
signatures for them.

> 
> The requirements for the KASP auditor includes two requirements to check 
> non-DNSSEC data as well:
> 
>  1. All non-DNSSEC data (i.e. all RRs except NSEC, NSEC3, NSEC3PARAM, 
> DNSKEY and RRSIG) in the input zone must be identical to that in the 
> output zone. The only exception is SOA, where it is permissible for the 
> serial number to differ.

some other fields in the soa rr can be overwritten by the signer engine as well
(ttl and minimum), if so specified by the config

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

iEYEARECAAYFAkoK5pMACgkQ4nZCKsdOncXfrACfez5i+wo4k7b91H7yBMJ9HIdt
w4MAoJer4JzwJwN6McTQe77KKde+fhjm
=FX6h
-----END PGP SIGNATURE-----


From Stephen.Morris at nominet.org.uk  Wed May 13 16:07:11 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Wed, 13 May 2009 17:07:11 +0100
Subject: [Opendnssec-develop] KASP Auditor Requirements
In-Reply-To: <A7AD6648-4A74-44B7-B988-F3320DC0338C@jadickinson.co.uk>
References: <OF22A097D6.58CFD2A7-ON802575A1.003FC41B-802575A1.003FFCBD@nominet.org.uk>
	<A7AD6648-4A74-44B7-B988-F3320DC0338C@jadickinson.co.uk>
Message-ID: <OF8B7FCCA3.053A353B-ON802575B5.0052112A-802575B5.00588C18@nominet.org.uk>

John Dickinson <jadsab at googlemail.com> wrote on 12/05/2009 14:20:36:

> On 23 Apr 2009, at 12:38, Stephen.Morris at nominet.org.uk wrote:
> 
> > 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
> 
> 
> Some notes:
> 3.1 item 1: the signer should be able to change the TTL,  minimum  and 
> serial numbers for the SOA. This is important so that the signer can 
> "fix" a unsigned zone that does not contain values which are not 
> consistent with the values specified in kasp.

This raises an interesting question: ignoring the serial number, should 
the SOA values in the input zone file or in KASP be considered the 
definitive ones?  If the former, then either the values in KASP _must_ 
match the values in the zone file, or else KASP needs to read the zone 
file to determine them.  If the latter, this raises the possibility of 
what is set in the zone file is ignored by the signer, which could lead to 
confusion on the part of some users.



> 3.1 item 2: using serial number arithmetic, of course.

Good point.  But I think that the auditor should issue a warning message 
(as opposed to an error message) for this.



> 3.2: item 2: the protocol field must equal 3
> 3.2: I don't agree the last two checks. Either the sep bit should be 
> being used in a way consistent with RFC5011 or in a way consistent 
> with the policy. It may be that the policy should be consistent with a 
> BCP RFC like 4641bis.

Perhaps these checks should be optional then?



> 3.3 s/domain/zone/

"domain name" would be more accurate.  The idea is that if you have 
several million records, you may only decide to validate the records for a 
subset of all the names in the zone.



> 3.4 item 1: what if you are switching from nsec to nsec3? This does 
> not have to be done in a single step.

Good point.  Again, perhaps this should be configurable; most of the time 
you will use either NSEC or NSEC3 and you would want to ensure that only 
those type of next-secure records were in the zone, but during a 
transition you would want to ignore the check.



> 3.4 item 4: should read: the nsec records form a single closed loop 
> linking each owner name in canonical order.
> 3.4 item 5: should read: each nsec correctly identifies the set of RR 
> types present at the  owner name.

Accepted.



> 3.5 item 1: what if you are switching from nsec3 to nsec? This does 
> not have to be done in a single step.

Accepted, see above.



> 3.5 item 2: if you are doing nsec3 then there must be a nsec3param.
> 3.5 item 2c:  there must be at least one complete chain of nsec3 
> records present with the same set of nsec3 parameters.
> 3.5 item 3: should read: each nsec3  record has bits set to indicate 
> the types of rr's  present at the owner name.
> 3.5 item 4: should read: the next hashed owner name field contains 
> the next hashed owner name in hash order.

Accepted.



> 3.5: I think we should also say that all nsec3 records must either be 
> opt in or opt out.

Probably a good idea, but is this a requirement of the protocol?



I'll update both the requirements and auditor requirements documents after 
the teleconference next week.

Stephen



From Stephen.Morris at nominet.org.uk  Wed May 13 16:42:44 2009
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Wed, 13 May 2009 17:42:44 +0100
Subject: [Opendnssec-develop] OpenDNSSEC Requirements Updated
In-Reply-To: <4A0056EA.5060709@NLnetLabs.nl>
References: <OFF3BD490D.3970709E-ON802575AD.0050D691-C12575AD.00521061@nominet.org.uk>
	<4A0056EA.5060709@NLnetLabs.nl>
Message-ID: <OFFA45EC53.C0FC0FE4-ON802575AE.00376603-802575B5.005BCD35@nominet.org.uk>

Jelte Jansen <jelte at NLnetLabs.nl> wrote on 05/05/2009 17:10:34:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen.Morris at nominet.org.uk wrote:
> > As a prelude for writing the test plan, I have updated the 
requirements 
> > for OpenDNSSEC - see 
> > http://www.opendnssec.se/wiki/ProjectPlan/Requirements
> > 
> > I have incorporated the original requirements, as well as requirements 

> > from Nominet and .SE.
> > 
> > Comments?
> > 
> 
> just a few at a quick glance;

> I'm seeing a few things that it currently does not do (signatures on 
first
> input, but i think i can add that without much trouble), or probably 
can't
> handle in any decent timerange (sorting might take a while for 
> millions of records)

This is a first draft of the formal requirements, so there might be things 
that are impractical or not needed, in which case they should be removed.



> RSA support is mentioned, but not RSAwithSHA1 and/or RSAwithMD5 (not
> that I know
> of anyone actually using that, but it might be good to at least make the
> distinction, and we will know where to put SHA2 if that draft ever 
reaches
> publication)

I'm replying to this email a bit late (sorry!), so I'm not certain what 
version you refer to.  However, the current version does state (2.3.1.3.d) 
that RSA/SHA-1 MUST be supported and that RSA/SHA-256 SHOULD be supported 
if introduced as an RFC.  Do we need to bother with RSA/MD5?



> I don't know in which category it would fall, but the SOA SERIAL that is 
used
> could be very important for some people, I've heard of at least one 
instance
> where they have the requirement that it is not changed by the 
> signer. This will
> have very serious consequences on when and how to do resigning 
operations (one
> would have to 'sneak' them into normal updates, which of course haveto 
happen
> regularly then, but i guess this is more appropriate for the second 
> version; so
> it could actually be an explicit non-requirement.

We could add a requirement to "2.3.2 Signing Process" stating that the 
user should have the choice of leaving the SOA serial number unchanged, or 
having the system set it to Unix time format (number of seconds since 
1-Jan-1970).  But:

a) are there any other serial number formats that should be considered?
b) is it worth worrying about leap-seconds (where, theoretically, the time 
could go back by a second)?
c) is the year 2038 problem too far away to worry about now? (Remember 
what they said about the Y2K problem back in the 1960s.)

Stephen


From jelte at NLnetLabs.nl  Wed May 13 17:09:52 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 13 May 2009 19:09:52 +0200
Subject: [Opendnssec-develop] OpenDNSSEC Requirements Updated
In-Reply-To: <OFFA45EC53.C0FC0FE4-ON802575AE.00376603-802575B5.005BCD35@nominet.org.uk>
References: <OFF3BD490D.3970709E-ON802575AD.0050D691-C12575AD.00521061@nominet.org.uk>	<4A0056EA.5060709@NLnetLabs.nl>
	<OFFA45EC53.C0FC0FE4-ON802575AE.00376603-802575B5.005BCD35@nominet.org.uk>
Message-ID: <4A0AFEE0.9040504@NLnetLabs.nl>

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

Stephen.Morris at nominet.org.uk wrote:
> Jelte Jansen <jelte at NLnetLabs.nl> wrote on 05/05/2009 17:10:34:
> 
>> I'm seeing a few things that it currently does not do (signatures on 
> first
>> input, but i think i can add that without much trouble), or probably 
> can't
>> handle in any decent timerange (sorting might take a while for 
>> millions of records)
> 
> This is a first draft of the formal requirements, so there might be things 
> that are impractical or not needed, in which case they should be removed.
> 

actually it currently performs better than i myself expected (not nearly well
enough for something like .org, but good enough to be usable for, say, just to
name something, .se. Although any change in zone file would, as it is currently,
require the full six minutes :p)

> 
>> RSA support is mentioned, but not RSAwithSHA1 and/or RSAwithMD5 (not
>> that I know
>> of anyone actually using that, but it might be good to at least make the
>> distinction, and we will know where to put SHA2 if that draft ever 
> reaches
>> publication)
> 
> I'm replying to this email a bit late (sorry!), so I'm not certain what 
> version you refer to.  However, the current version does state (2.3.1.3.d) 
> that RSA/SHA-1 MUST be supported and that RSA/SHA-256 SHOULD be supported 
> if introduced as an RFC.  Do we need to bother with RSA/MD5?
> 

IIRC, the version i read only said RSA and nothing else, so my point is hereby
officially obsolete :)

> 
> We could add a requirement to "2.3.2 Signing Process" stating that the 
> user should have the choice of leaving the SOA serial number unchanged, or 
> having the system set it to Unix time format (number of seconds since 
> 1-Jan-1970).  But:
> 
> a) are there any other serial number formats that should be considered?

well, it shouldn't be hard to add them to the code if they come up later, but i
can't think of any at this time

> b) is it worth worrying about leap-seconds (where, theoretically, the time 
> could go back by a second)?

IMHO, no. Although if there is the slightest reason for this, i can add the same
logic to the timestamp-based format as i put in datecounter, ie.
if calculated_serial <= last_or_output_serial
then output_serial = last_output_serial + 1
(come to think of it, i might need to include the input serial in that check as
well)

> c) is the year 2038 problem too far away to worry about now? (Remember 
> what they said about the Y2K problem back in the 1960s.)
> 

that's one reason to use serial arithmetic, no? One corner case would then be if
someone would setup a zone with timestamp serials and a resign period of over 68
years btw :)

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

iEYEARECAAYFAkoK/uAACgkQ4nZCKsdOncVFgwCeLO16rNN3LgpoZ0Z81SRKbaga
gAkAoMHddzlM2Q1nDtTbh7pQH+jQpu4M
=KDBx
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Thu May 14 14:10:12 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 14 May 2009 16:10:12 +0200
Subject: [Opendnssec-develop] Meeting agenda 20090518
Message-ID: <69830D4127201D4EBD146B9041199718B072D9@EXCHANGE.office.nic.se>

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

Hi

I have added a draft to the wiki:

http://www.opendnssec.se/wiki/Meetings/Agenda/2009-05-18

If you have more discussion points, then please email me or update the wiki.

Next meeting:

Date: Monday the 18th of May
Time: 11:00-12:00 CEST

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

wsBVAwUBSgwmROCjgaNTdVjaAQgmPAf/YNsbQdBaMg3G3hg3MbUCPEyh7sMMXbYI
73C6v3WXRpBaBf+Xbx97uW2R+dGvmY8OzvEfznGzsH6y7mAK13p3ezvEFyfIjAwJ
XVe48nYw+BQKlDKmImu1e1bK6d7pwdCKQhmLmrkz0s9fgz8AMwvzX+P/Rr4RXRoV
XPubD/wLmB+QqlwpCGH2znhy4bcwuGtXTEAfmDgByg2KjVNJL9Dd7/NAMmuIeP6a
WH/9JFaoAOT86ygZAjqNcjgrfg8JTjY/osgvxiLDNKtLkv80VYL4agQ9iYQPYV9X
cXsKb5hCpdvtv3jOXU+hAkak/pSWLv9uMpSrselvYQS3Kzegc9AZaQ==
=pNAq
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Mon May 18 13:56:22 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Mon, 18 May 2009 15:56:22 +0200
Subject: [Opendnssec-develop] Zone re-sign interval and SOA serial
Message-ID: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se>

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

If the re-sign interval is set to 4 hours and the signer receives a new zone file every second hour (with updated SOA serial), will the internal counter for the re-sign interval be reset when the updated zone is signed? And thus will new signatures newer be generated out-of-sync with the zone transfers? And no SOA serial is needed to be updated within the signer?

If we have add an option to the configuration xml that will prevent the system from updating the SOA serial, no new signatures can be pushed out from the system until a zone file with a new SOA serial is received?

E.g. element Serial { "counter" | "unixtime" | "datecounter" | "none" }

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

wsBVAwUBShFpBuCjgaNTdVjaAQhocgf/Y3EvKN+PReD6fxEXX6esABkUmRuH0CqW
0Z9gyzM0P3Ih32mHqDA0CtSxvha4AO3Az9XV9CUJfRpdm5p/SEjmEW0dxQhfvXwR
1EaEI2lcStfT00Q0HF7rpV0g2WmlARUw2ppaoj/wNMBmQ4tbHUNF47cibtxXAg1+
p19zzPom7I4MVAYG9GqAXMHC70FGMllpW+MQ2Ppqc7kDIDorVWU3HK+MpRaiGyA3
wFi0EEW+skKEBhVjLqlA4vhQVo+bhf6C2HUeKAbadTev9rN5X+dQhZtIjdL72KLI
oLMeaS2pO3LPQ6tz7eE32q+oEO1xcsW5LwJ/fYL/ksEG2ns3BUuJVQ==
=bmrY
-----END PGP SIGNATURE-----


From jakob at kirei.se  Mon May 18 14:39:17 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 18 May 2009 16:39:17 +0200
Subject: [Opendnssec-develop] Zone re-sign interval and SOA serial
In-Reply-To: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se>
Message-ID: <7DD2D57D-3AD1-4909-A34C-C09E747D35AC@kirei.se>

On 18 maj 2009, at 15.56, Rickard Bondesson wrote:

> If we have add an option to the configuration xml that will prevent  
> the system from updating the SOA serial, no new signatures can be  
> pushed out from the system until a zone file with a new SOA serial  
> is received?

correct, and we need to add logic not to try to sign unless a new  
version of the zone has arrived.

	jakob



From rickard.bondesson at iis.se  Wed May 20 06:41:01 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 20 May 2009 08:41:01 +0200
Subject: [Opendnssec-develop] Doodle: Telephone meeting in May/June
Message-ID: <69830D4127201D4EBD146B9041199718C68639@EXCHANGE.office.nic.se>

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

Hi

When can we have the next telephone meeting? 

27th May - 5th June

Please vote on this page: http://www.doodle.com/w9qrcxnr9ci7r95k

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

wsBVAwUBShOl/eCjgaNTdVjaAQjE6Af+IHkjNomWNWoi5hduYY01in69MVZtB8fd
vSNkL0A9TBEHhQEIbCZQ9n2lRCvkaXkY7rF56MflNiq8H2F4w1l/3zjovhS3x4YC
ZkodqRUglnLoLhRONXiIwJ9D1g241hl1lIUUOYLstoXOxn6g+j0Kqy9N909KNBFt
pk89jsw7oSZpDr2M0eYzUwQGMZEaNCORWN8KwfX3Ahlaz183ddpvdgYWzh2NwfRs
M2dfhibC55wp/Mp+QwA689XiwNjo04pO59TE0rzYEim8zp4kIPfB3unfQt5VIiBH
xs5sCUH+aQc+HF3VPNIW3/TC0zRXVV3uPUKKq9kTpeu9hxWB7T/8Uw==
=oWQ7
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Wed May 20 08:24:43 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 20 May 2009 10:24:43 +0200
Subject: [Opendnssec-develop] Zone re-sign interval and SOA serial
In-Reply-To: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se>
Message-ID: <69830D4127201D4EBD146B9041199718C6867A@EXCHANGE.office.nic.se>

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

> If the re-sign interval is set to 4 hours and the signer 
> receives a new zone file every second hour (with updated SOA 
> serial), will the internal counter for the re-sign interval 
> be reset when the updated zone is signed? And thus will new 
> signatures newer be generated out-of-sync with the zone 
> transfers? And no SOA serial is needed to be updated within 
> the signer?

Jelte do you have an answer for this? Will the Signer Engine reset the re-sign timer when a zone update arrives? Thus will the zone output always be in sync with the zone input in this scenario?

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

wsBVAwUBShO+S+CjgaNTdVjaAQgZVAf/aATfjXv1tGm4PB/9hRU5WNy3KMXUrc+d
qNfbgABY7wj4pgQG/7YSsGZGbTd0PQrUMqUhJx9YbJyXd37QkE/Y3qrFyBe/sATc
SDO7haqD9Nl5hijGB1wQ3V5yLxx5dyWbRQGDN5WrPjVzCxnlF/xEBrjZHgVC6RjZ
ree4O0NkeYiXLPAFhwXK5xrC5RdRrFsbNwgUiacHQdpmiaH3eMFMksATMxbt3Jz7
nn7fuA/8oEucQDlIDap3TeuHh6d4raZA854a6cnx0xp/sz/IkLXgOSwVl4i0ki1B
r0DlaaLp+9BSFIYoLRBZIPtXQ4aPLJdN0FTW/m6srb81PLpWi0KL3g==
=eQGp
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Wed May 20 08:31:42 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 20 May 2009 10:31:42 +0200
Subject: [Opendnssec-develop] Zone re-sign interval and SOA serial
In-Reply-To: <69830D4127201D4EBD146B9041199718C6867A@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se>
	<69830D4127201D4EBD146B9041199718C6867A@EXCHANGE.office.nic.se>
Message-ID: <4A13BFEE.60406@NLnetLabs.nl>

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

Rickard Bondesson wrote:
>> If the re-sign interval is set to 4 hours and the signer 
>> receives a new zone file every second hour (with updated SOA 
>> serial), will the internal counter for the re-sign interval 
>> be reset when the updated zone is signed? And thus will new 
>> signatures newer be generated out-of-sync with the zone 
>> transfers? And no SOA serial is needed to be updated within 
>> the signer?
> 
> Jelte do you have an answer for this? Will the Signer Engine reset the re-sign timer when a zone update arrives? Thus will the zone output always be in sync with the zone input in this scenario?
> 

Currently, when the engine gets the signal that zone input has changed, it will
restart the entire signing process, including recreating all signatures, so in
this scenario, it will never actually reach the resign process. So the soa
shouldn't need to be changed. This could be done way more efficiently, but that
would almost involve the incremental signing procedure planned for version 2. It
does have the upshot that this scenario works 'for free' ;)

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

iEYEARECAAYFAkoTv+sACgkQ4nZCKsdOncUg7QCgi4tpWOSFINBgmOR2tfMKVgwo
PrMAn0fF9MRUME3whJZemHnC2By7/jRQ
=u0dw
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Wed May 20 09:06:51 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 20 May 2009 11:06:51 +0200
Subject: [Opendnssec-develop] Zone re-sign interval and SOA serial
In-Reply-To: <4A13BFEE.60406@NLnetLabs.nl>
References: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se><69830D4127201D4EBD146B9041199718C6867A@EXCHANGE.office.nic.se>
	<4A13BFEE.60406@NLnetLabs.nl>
Message-ID: <69830D4127201D4EBD146B9041199718C68694@EXCHANGE.office.nic.se>

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

> Currently, when the engine gets the signal that zone input 
> has changed, it will restart the entire signing process, 
> including recreating all signatures, so in this scenario, it 
> will never actually reach the resign process. So the soa 
> shouldn't need to be changed. This could be done way more 
> efficiently, but that would almost involve the incremental 
> signing procedure planned for version 2. It does have the 
> upshot that this scenario works 'for free' ;)

This is a show-stopper for the deployment at .SE with the first version of OpenDNSSEC

Since this is how our current scenario looks like. And I do not think our slave server operators will be so happy when we send 2 x our zone (IXFR) every second hour from our distribution points.

Will it be possible to not drop the current state/signatures every time the zone gets updated? When a change happen, create a diff, and/remove signatures/nsec according to the diff, update old signatures?

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

wsBVAwUBShPIK+CjgaNTdVjaAQiDvQgAneKk2An0yZh4ccM3+gQuQoZE19AyMByf
dXW07TTnlVdcv9p2SEcLeZ0F/wBveqwx1QcBqp41rAcs5fGflDnkTPQARg3uAyCO
fTJxwoamsc9GAkQs0ZYl+28b2zJCja8JBr/hIFeEoNJRY72PI/RYtzN3RFK7YupZ
NzoidqV3TpXGdWQVJHl+myZl4oMMH0pFr4S9ZTOXorb55deBfSO1Yi4UR+2kuBRi
3D1+VVQt1DyTM1dz4tGi5gOroZPORQIJvEUNfcmrydYV9JCaTbMyCgPKWcJULTZX
NrfLXF5JfrOt7+ok1sJCk4w+smpanbQeqHQL/CDUGyIlYEyxI40M5w==
=Uotr
-----END PGP SIGNATURE-----


From jelte at NLnetLabs.nl  Wed May 20 09:09:41 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 20 May 2009 11:09:41 +0200
Subject: [Opendnssec-develop] Zone re-sign interval and SOA serial
In-Reply-To: <69830D4127201D4EBD146B9041199718C68694@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718B0751B@EXCHANGE.office.nic.se><69830D4127201D4EBD146B9041199718C6867A@EXCHANGE.office.nic.se>
	<4A13BFEE.60406@NLnetLabs.nl>
	<69830D4127201D4EBD146B9041199718C68694@EXCHANGE.office.nic.se>
Message-ID: <4A13C8D5.6000000@NLnetLabs.nl>

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

Rickard Bondesson wrote:
> 
> This is a show-stopper for the deployment at .SE with the first version of OpenDNSSEC
> 
> Since this is how our current scenario looks like. And I do not think our slave server operators will be so happy when we send 2 x our zone (IXFR) every second hour from our distribution points.
> 
> Will it be possible to not drop the current state/signatures every time the zone gets updated? When a change happen, create a diff, and/remove signatures/nsec according to the diff, update old signatures?
> 

i was thinking about a few trick to accomplish something like that, but haven't
had time to try them out yet

in short it would be running through the same sorting/nseccing process, but let
the signer accept an optional 'previous' file; if there is an RR in both files;
look in the second for a possibly-valid sig, and use that.

i'll try it out once libhsm is done enough to work with

Jelte

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

iEYEARECAAYFAkoTyNUACgkQ4nZCKsdOncVYfQCfXIoqP5UJNiybrQ43MofXSZCS
EGYAn2PikR4GScZk8MiiFsyNpE6XwTm5
=PBd+
-----END PGP SIGNATURE-----


From jakob at kirei.se  Wed May 20 09:42:50 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 20 May 2009 11:42:50 +0200
Subject: [Opendnssec-develop] libhsm: hsm_random() and friends
Message-ID: <085FCDFE-AE40-46EF-B4F1-BFA323B05C0D@kirei.se>

hi,

can someone remind me and why we want a hsm_random() function in  
libhsm? if not, we should remove it for now. for the jitter needed by  
the signer, it seems a bit overkill to use the HSM for that.

	jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090520/2c87ed18/attachment.bin>

From jakob at kirei.se  Wed May 20 09:55:05 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 20 May 2009 11:55:05 +0200
Subject: [Opendnssec-develop] non-automated HSM operations
Message-ID: <6F81819F-FAF5-460D-A132-CCDF1E7C9CB7@kirei.se>

hi,

while doing some design work for a large customer with high-risk  
zones, I'm starting to think that we should look into offline HSM  
operations (i.e. when the PIN is not known). to do this we need to  
address to things:

  - the signer will have to altert the security officer (SO) and ask  
for the PIN.
  - we most likely need a longer KSK signature time so one doesn't  
have to alert the SO more than needed (say once a month).
    it must be known in due time that the SO will be needed, since he  
or she might not be ready to rumble 24/7.


any thoughts regarding this?

	jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090520/e7b40200/attachment.bin>

From jad at jadickinson.co.uk  Wed May 20 10:00:30 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 20 May 2009 11:00:30 +0100
Subject: [Opendnssec-develop] libhsm: hsm_random() and friends
In-Reply-To: <085FCDFE-AE40-46EF-B4F1-BFA323B05C0D@kirei.se>
References: <085FCDFE-AE40-46EF-B4F1-BFA323B05C0D@kirei.se>
Message-ID: <8B3A735A-9926-497C-8A48-0EE4EF3A0022@jadickinson.co.uk>


On 20 May 2009, at 10:42, Jakob Schlyter wrote:

> hi,
>
> can someone remind me and why we want a hsm_random() function in  
> libhsm? if not, we should remove it for now. for the jitter needed  
> by the signer, it seems a bit overkill to use the HSM for that.


for the salt? Also the HSM is likely to be the best source of  
randomness in the system.

john


From jelte at NLnetLabs.nl  Wed May 20 10:07:38 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 20 May 2009 12:07:38 +0200
Subject: [Opendnssec-develop] libhsm: hsm_random() and friends
In-Reply-To: <8B3A735A-9926-497C-8A48-0EE4EF3A0022@jadickinson.co.uk>
References: <085FCDFE-AE40-46EF-B4F1-BFA323B05C0D@kirei.se>
	<8B3A735A-9926-497C-8A48-0EE4EF3A0022@jadickinson.co.uk>
Message-ID: <4A13D66A.1030303@NLnetLabs.nl>

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

John Dickinson wrote:
> 
> On 20 May 2009, at 10:42, Jakob Schlyter wrote:
> 
>> hi,
>>
>> can someone remind me and why we want a hsm_random() function in
>> libhsm? if not, we should remove it for now. for the jitter needed by
>> the signer, it seems a bit overkill to use the HSM for that.
> 
> 
> for the salt? Also the HSM is likely to be the best source of randomness
> in the system.
> 

turns out that implementing it was easier than discussing it, but i've done it
naively; if no tokens with rngs are attached, it will return an error (or the
not-so-random value 0).

talking about seeding; are hsm's with rngs guaranteed to be seeded? there is a
function S_SeedRandom but according to the docs this is only to add additional
seeding data. So i'm assuming that the hsm seeds itself (and that
C_GenerateRandom is a pseudo btw)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoT1moACgkQ4nZCKsdOncXc3gCdGWR/ebT51Y4v52vgHyTqIQNc
gYAAn00w4ymGuoUTCuOYUwc18HMor3eR
=4xST
-----END PGP SIGNATURE-----


From jakob at kirei.se  Wed May 20 10:10:42 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 20 May 2009 12:10:42 +0200
Subject: [Opendnssec-develop] libhsm: hsm_random() and friends
In-Reply-To: <8B3A735A-9926-497C-8A48-0EE4EF3A0022@jadickinson.co.uk>
References: <085FCDFE-AE40-46EF-B4F1-BFA323B05C0D@kirei.se>
	<8B3A735A-9926-497C-8A48-0EE4EF3A0022@jadickinson.co.uk>
Message-ID: <63AA6EA1-3B6C-4CF4-84B7-F852F830326E@kirei.se>

On 20 maj 2009, at 12.00, John Dickinson wrote:

>
> On 20 May 2009, at 10:42, Jakob Schlyter wrote:
>
>> hi,
>>
>> can someone remind me and why we want a hsm_random() function in  
>> libhsm? if not, we should remove it for now. for the jitter needed  
>> by the signer, it seems a bit overkill to use the HSM for that.
>
>
> for the salt? Also the HSM is likely to be the best source of  
> randomness in the system.

true. thanks for reminding me!

	j



From rickard.bondesson at iis.se  Wed May 20 11:09:41 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 20 May 2009 13:09:41 +0200
Subject: [Opendnssec-develop] libhsm: hsm_random() and friends
In-Reply-To: <4A13D66A.1030303@NLnetLabs.nl>
References: <085FCDFE-AE40-46EF-B4F1-BFA323B05C0D@kirei.se><8B3A735A-9926-497C-8A48-0EE4EF3A0022@jadickinson.co.uk>
	<4A13D66A.1030303@NLnetLabs.nl>
Message-ID: <69830D4127201D4EBD146B9041199718C686B2@EXCHANGE.office.nic.se>

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

> talking about seeding; are hsm's with rngs guaranteed to be 
> seeded? there is a function S_SeedRandom but according to the 
> docs this is only to add additional seeding data. So i'm 
> assuming that the hsm seeds itself (and that C_GenerateRandom 
> is a pseudo btw)

The API does not say anything about seeding, besides "C_SeedRandom mixes additional seed material into the token?s random number generator.". And there are no error code indicating that the RNG must seeded. So I would say that you just use the C_GenerateRandom without seeding.

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

wsBVAwUBShPk9eCjgaNTdVjaAQjLNAf/av31rC9lCUup5VDNHyDvuVbC+BV0ZbmK
+L3razt40V0pJxgr+QUPB9SFOgCQpMpISq3VunCjFibHb7LNCOH/6LHX8cx3DowI
TcELmnpNqbU7okO7Atgu+briomptCeOr9lUH4bgdNaBuWVPTwSWpRBquqomvouhp
R2Iz7gki0pCpGtXIgHS0R3d/WpfBH/fFhPmdgmF0iNoLJBSEMg0EaNRK0BomS5iw
qo5ba59+3JaVYzsTobWDyPJIou6uMjKSVsfw26lnpU1T7RTPVJKQsTGlZu6+K4+W
xd7ogKglIs2dEjprU21u/qY1cTWEQCstOOu6KtNSQdcRuwKk0QflOA==
=ZiET
-----END PGP SIGNATURE-----


From rickard.bondesson at iis.se  Wed May 20 12:07:10 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 20 May 2009 14:07:10 +0200
Subject: [Opendnssec-develop] CKF_TOKEN_INITIALIZED
Message-ID: <69830D4127201D4EBD146B9041199718C686BD@EXCHANGE.office.nic.se>

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

Hi

If you try to open a session with a token that is not initialized, what should you return?

There are no error code for token not initialized. Could CKR_TOKEN_NOT_RECOGNIZED work?

"CKR_TOKEN_NOT_RECOGNIZED: The Cryptoki library and/or slot does not
recognize the token in the slot."

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

wsBVAwUBShPybuCjgaNTdVjaAQgCsQgAlggXafgBLDNZ7WB3cYHmJ0NVdec9wvYJ
DMaPNMlomDoRyf4KK3Y2eVrisUZF5q9p+PPmj8eghHCw+p8oQaGis0bPMAxB1q4V
10EXnlqkRdQT8KeU5YpYiV+Jfmj+Fi0/6gIdXl+K1rNokATheDAR/CzaX63BGIlN
ts1RvbDrYpiBFOBbYBzQECQiaw7knMq8+orVhj9zoMEPnu6aPpQxLvBLOMqVSxX6
tkezwKktFe0WOMwPkvVndyeVkvU3Q33LP2/7e47XBTkkLgXAMNmKtFU+ylBKm91u
OWKBBRicXdA1GIg4sgLoLu3skawNu36xelixb7m52Mf89tSpvyeUdA==
=kACr
-----END PGP SIGNATURE-----


From rick at openfortress.nl  Wed May 20 12:11:45 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 20 May 2009 12:11:45 +0000
Subject: [Opendnssec-develop] CKF_TOKEN_INITIALIZED
In-Reply-To: <69830D4127201D4EBD146B9041199718C686BD@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718C686BD@EXCHANGE.office.nic.se>
Message-ID: <20090520121145.GA31340@phantom.vanrein.org>

Hi Rickard,

> There are no error code for token not initialized. Could CKR_TOKEN_NOT_RECOGNIZED work?

That seems like a decent choice to me.

-Rick


From rick at openfortress.nl  Wed May 20 18:48:50 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 20 May 2009 18:48:50 +0000
Subject: [Opendnssec-develop] Meeting notes 2009-05-18 are online
Message-ID: <20090520184850.GB3187@phantom.vanrein.org>

Hi,

I just placed the meeting notes online in the usual location,

http://www.opendnssec.se/wiki/Meetings/Minutes/2009-05-18?version=1

Let me know if there are any textual remarks.

Cheers,
 -Rick


From jelte at NLnetLabs.nl  Fri May 22 12:06:07 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Fri, 22 May 2009 14:06:07 +0200
Subject: [Opendnssec-develop] ldns, openssl and NSEC3 hashes
Message-ID: <4A16952F.7050909@NLnetLabs.nl>

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


Hi,

i've just cleaned up ldns for a --without-ssl configure option, but
unfortunately that means that everything that uses digests is also removed
(since those use the OpenSSL digest routines). Now normally this wouldn't be
much of a problem, since digests are mostly used in signing operations. However,
we also need them for NSEC3. So this would mean that the subprocesses sorter and
nsec3er also need to set up an hsm context and login etc., which seems a bit
overkill.

I think we have 3 options here:
- - Just set up the context whenever anything cryptoey is needed (i've just done
one example for this in the sorter)
- - Simply allow the dependency on OpenSSL for digests and let ldns handle them
- - Do them 'ourselves' (for instance through a c-wrapper for botan, on which we
have a dependency already), perhaps as an addition to libhsm)


any thoughts?

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

iEYEARECAAYFAkoWlS8ACgkQ4nZCKsdOncVxUACfQxKoEd8BTDn/RrBtl2Sq6i+J
oU0Anj8zOFhpSqpMzu0g39iMeTuiCp5e
=Cw7x
-----END PGP SIGNATURE-----


From jakob at kirei.se  Fri May 22 12:21:22 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Fri, 22 May 2009 14:21:22 +0200
Subject: [Opendnssec-develop] ldns, openssl and NSEC3 hashes
In-Reply-To: <4A16952F.7050909@NLnetLabs.nl>
References: <4A16952F.7050909@NLnetLabs.nl>
Message-ID: <915946F7-A1EB-47DA-88D8-B4DDD531AE47@kirei.se>

On 22 maj 2009, at 14.06, Jelte Jansen wrote:

> I think we have 3 options here:
> - - Just set up the context whenever anything cryptoey is needed  
> (i've just done
> one example for this in the sorter)

yuck.

> - - Simply allow the dependency on OpenSSL for digests and let ldns  
> handle them

please no.

> - - Do them 'ourselves' (for instance through a c-wrapper for botan,  
> on which we
> have a dependency already), perhaps as an addition to libhsm)

why not implement sha and friends directly in LDNS and get rid of  
OpenSSL for this case?

many operating systems has native SHA1(3) and for SHA2 you can use:

   http://www.ouah.org/ogay/sha2/
   http://www.aarongifford.com/computers/sha.html?sid=ef6t2k6ra202lqfn48vomkptjbhanoun

or some other fast free (BSD-licensed) SHA2 implementation and just  
add that code to LDNS directly.

or we'll put this in libhsm, but it seems wrong to do this there as it  
isn't hsm-stuff. but we can add it as a non-context-based utility  
function I'll guess. but I'd prefer LDNS if possible - feels better.

	jakob



From rick at openfortress.nl  Fri May 22 12:26:22 2009
From: rick at openfortress.nl (Rick van Rein)
Date: Fri, 22 May 2009 12:26:22 +0000
Subject: [Opendnssec-develop] ldns, openssl and NSEC3 hashes
In-Reply-To: <915946F7-A1EB-47DA-88D8-B4DDD531AE47@kirei.se>
References: <4A16952F.7050909@NLnetLabs.nl>
	<915946F7-A1EB-47DA-88D8-B4DDD531AE47@kirei.se>
Message-ID: <20090522122622.GA3988@phantom.vanrein.org>

Hi,

> why not implement sha and friends directly in LDNS and get rid of  
> OpenSSL for this case?

votes++

-Rick


From roy at nominet.org.uk  Fri May 22 12:37:30 2009
From: roy at nominet.org.uk (roy at nominet.org.uk)
Date: Fri, 22 May 2009 14:37:30 +0200
Subject: [Opendnssec-develop] ldns, openssl and NSEC3 hashes
In-Reply-To: <20090522122622.GA3988@phantom.vanrein.org>
References: <4A16952F.7050909@NLnetLabs.nl>	<915946F7-A1EB-47DA-88D8-B4DDD531AE47@kirei.se>
	<20090522122622.GA3988@phantom.vanrein.org>
Message-ID: <OF34335330.83FB60E4-ON802575BE.004544F7-C12575BE.00455A9B@nominet.org.uk>

Rick van Rein wrote on 05/22/2009 02:26:22 PM:

> Hi,
>
> > why not implement sha and friends directly in LDNS and get rid of
> > OpenSSL for this case?
>
> votes++

+1

Roy



From patrik.wallstrom at iis.se  Tue May 26 09:11:03 2009
From: patrik.wallstrom at iis.se (Patrik Wallstrom)
Date: Tue, 26 May 2009 11:11:03 +0200
Subject: [Opendnssec-develop] status of the enforcer?
Message-ID: <6FD0AEB0-D1A3-4217-B85C-CDBFFF64F34C@iis.se>

I am trying to get the enforcer running. There are two programs that  
need to work (except for kaspimport that I can run), keygend and  
communicated.

Both programs say that they accept the following command line options:

   -d          Debug.
   -u          Change effective uid to the specified user.
   -P pidfile  Specify the PID file to write.
   -v          Print version.
   -?          This help.

The README for the enforcer says this:

Once built the communicated binary takes the following options:
-n <NAME>       name of KASP DB user
-s <SCHEMA>     schema to use in the KASP DB (or DB file if using  
sqlite)
-p <PASS>       password for DB schema user
-h <HOST>       host machine of DB
-u <USER>       local user to suid as
-P <FILE>       pid file to use
-d              debug mode (do not daemonise)


I cannot pass the -s options to neither of the programs.

The KASP db file initiated by kaspimport (I am using sqlite3 now) -  
shouldn't this file (or MySQL user and db information) be stored in  
kasp.xml rather than as options to the different binaries?

With full understanding that this is work in progress of course.

-------------- 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/20090526/aaa7f958/attachment.bin>

From jelte at NLnetLabs.nl  Tue May 26 09:43:04 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Tue, 26 May 2009 11:43:04 +0200
Subject: [Opendnssec-develop] CKA_SENSITIVE and CKA_EXTRACTABLE
Message-ID: <4A1BB9A8.20409@NLnetLabs.nl>


Hi,

for the key generation in libhsm, i more or less copied the templates in 
hsm-toolkit. These had CKA_SENSITIVE=false and CKA_EXTRACTABLE=true.

However, as Rickard pointed out to me, these should probably be the other way 
around. I think he's right, but just wanted to conform this with the list.

Any objections?

Jelte


From jelte at NLnetLabs.nl  Tue May 26 09:43:41 2009
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Tue, 26 May 2009 11:43:41 +0200
Subject: [Opendnssec-develop] CKA_SENSITIVE and CKA_EXTRACTABLE
In-Reply-To: <4A1BB9A8.20409@NLnetLabs.nl>
References: <4A1BB9A8.20409@NLnetLabs.nl>
Message-ID: <4A1BB9CD.1090305@NLnetLabs.nl>

Jelte Jansen wrote:
> 
> Hi,
> 
> for the key generation in libhsm, i more or less copied the templates in 
> hsm-toolkit. These had CKA_SENSITIVE=false and CKA_EXTRACTABLE=true.
> 

(for private keys, of course)


From roland.vanrijswijk at surfnet.nl  Tue May 26 09:46:49 2009
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 26 May 2009 11:46:49 +0200
Subject: [Opendnssec-develop] CKA_SENSITIVE and CKA_EXTRACTABLE
In-Reply-To: <4A1BB9A8.20409@NLnetLabs.nl>
References: <4A1BB9A8.20409@NLnetLabs.nl>
Message-ID: <4A1BBA89.2020903@surfnet.nl>

Hi Jelte,

Yes, the other way around makes more sense :-)

Cheers,

Roland

Jelte Jansen wrote:
> 
> Hi,
> 
> for the key generation in libhsm, i more or less copied the templates in
> hsm-toolkit. These had CKA_SENSITIVE=false and CKA_EXTRACTABLE=true.
> 
> However, as Rickard pointed out to me, these should probably be the
> other way around. I think he's right, but just wanted to conform this
> with the list.
> 
> Any objections?
> 
> Jelte
> _______________________________________________
> 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 roy at nominet.org.uk  Tue May 26 10:02:10 2009
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 26 May 2009 12:02:10 +0200
Subject: [Opendnssec-develop] CKA_SENSITIVE and CKA_EXTRACTABLE
In-Reply-To: <4A1BB9A8.20409@NLnetLabs.nl>
References: <4A1BB9A8.20409@NLnetLabs.nl>
Message-ID: <OF870345C2.C0C5BF17-ON802575C2.0036727C-C12575C2.003721A9@nominet.org.uk>

Jelte Jansen wrote on 05/26/2009 11:43:04 AM:

> Hi,
> 
> for the key generation in libhsm, i more or less copied the templates in 

> hsm-toolkit. These had CKA_SENSITIVE=false and CKA_EXTRACTABLE=true.
> 
> However, as Rickard pointed out to me, these should probably be the 
other way 
> around. I think he's right, but just wanted to conform this with the 
list.
> 
> Any objections?

No objections.

Roy




From jad at jadickinson.co.uk  Tue May 26 10:35:54 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Tue, 26 May 2009 11:35:54 +0100
Subject: [Opendnssec-develop] status of the enforcer?
In-Reply-To: <6FD0AEB0-D1A3-4217-B85C-CDBFFF64F34C@iis.se>
References: <6FD0AEB0-D1A3-4217-B85C-CDBFFF64F34C@iis.se>
Message-ID: <43ACBA4A-D48E-440A-A0FF-1719F49A878D@jadickinson.co.uk>

the config is now in conf.xml and I clearly forgot to update the usage  
function. Sorry. See /trunk/testing/enforcer/* for some examples that  
build and run keygend.

On 26 May 2009, at 10:11, Patrik Wallstrom wrote:

> I am trying to get the enforcer running. There are two programs that  
> need to work (except for kaspimport that I can run), keygend and  
> communicated.
>
> Both programs say that they accept the following command line options:
>
>  -d          Debug.
>  -u          Change effective uid to the specified user.
>  -P pidfile  Specify the PID file to write.
>  -v          Print version.
>  -?          This help.
>
> The README for the enforcer says this:
>
> Once built the communicated binary takes the following options:
> -n <NAME>       name of KASP DB user
> -s <SCHEMA>     schema to use in the KASP DB (or DB file if using  
> sqlite)
> -p <PASS>       password for DB schema user
> -h <HOST>       host machine of DB
> -u <USER>       local user to suid as
> -P <FILE>       pid file to use
> -d              debug mode (do not daemonise)
>
>
> I cannot pass the -s options to neither of the programs.
>
> The KASP db file initiated by kaspimport (I am using sqlite3 now) -  
> shouldn't this file (or MySQL user and db information) be stored in  
> kasp.xml rather than as options to the different binaries?
>
> With full understanding that this is work in progress of course.
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From patrik.wallstrom at iis.se  Tue May 26 12:11:44 2009
From: patrik.wallstrom at iis.se (Patrik Wallstrom)
Date: Tue, 26 May 2009 14:11:44 +0200
Subject: [Opendnssec-develop] status of the enforcer?
In-Reply-To: <43ACBA4A-D48E-440A-A0FF-1719F49A878D@jadickinson.co.uk>
References: <6FD0AEB0-D1A3-4217-B85C-CDBFFF64F34C@iis.se>
	<43ACBA4A-D48E-440A-A0FF-1719F49A878D@jadickinson.co.uk>
Message-ID: <D80EA3CC-A175-4F7A-8036-39E52DA88ED9@iis.se>


On May 26, 2009, at 12:35 PM, John Dickinson wrote:

> the config is now in conf.xml and I clearly forgot to update the  
> usage function. Sorry. See /trunk/testing/enforcer/* for some  
> examples that build and run keygend.

Ok, got it.

There seems to be some problems with the configure build thingies, my  
prefix for the config files in the binaries seem strange, this is from  
keygend:

I/O warning : failed to load external entity "NONE/etc/opendnssec/ 
conf.xml"

I did not provide any prefix at configure. So the config files should  
be in /usr/local/etc/opendnssec/.

-------------- 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/20090526/606d896a/attachment.bin>

From jakob at kirei.se  Wed May 27 06:38:23 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Wed, 27 May 2009 08:38:23 +0200
Subject: [Opendnssec-develop] Fwd: [dnssec-deployment] DNSSHIM - DNSSEC for
	the masses made easy
References: <list-17684145@execdsl.com>
Message-ID: <5253E0B8-4369-4567-A570-ED8B264D3AA5@kirei.se>

the race is on! :-)


Begin forwarded message:

> From: Frederico A C Neves <fneves at registro.br>
> Date: ti 26 maj 2009 22.49.25 GMT+02:00
> To: "DNSSEC deployment" <dnssec-deployment at shinkuro.com>
> Subject: [dnssec-deployment] DNSSHIM - DNSSEC for the masses made easy
>
> This is the announcement of the first public [1] beta of DNSSHIM - DNS
> Secure Hidden Master. This is an open-source project to provide a
> DNS zone provisioning tool that does all DNSSEC provisioning and
> maintenance work behind the scenes.
>
> It provides an automated administrative interface, a poor man "HSM"
> for key management, a resigning schedule module, a DNS server
> interface with the main objective of providing notify,A|IXFR for
> authoritative delegated servers and a DNS configuration module for
> these servers.
>
> Our target users are hosting companies or any one administering a
> large amount of zones.
>
> Testing and comments are welcome,
>
> Regards,
> Frederico Neves
>
> [1] http://registro.br/dnsshim/index-EN.html
>    http://registro.br/dnsshim/download-EN.html
>
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/ 
> >
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>
>

--
Jakob Schlyter
Kirei AB - www.kirei.se





From rickard.bondesson at iis.se  Wed May 27 07:07:52 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Wed, 27 May 2009 09:07:52 +0200
Subject: [Opendnssec-develop] Next meeting: 2 June 2009
Message-ID: <69830D4127201D4EBD146B9041199718C68A26@EXCHANGE.office.nic.se>

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

Hi

The Doodle has spoken.

Next meeting will be held on 2 June 2009, 14-15 CEST.

The topics: Are we near an alpha version? What do we want to do next / implement?

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

wsBVAwUBShzmyOCjgaNTdVjaAQg+WAf/RUXs41fjPkeBOIzFeDNp/YigoNQi3xHr
+ZjBS/Bj3LOCIJy2/RkcW4Yszy/HE27A6kLZCMe2ILVPDJK07p/sUxb5y1+L2UR8
d2xl41Fw0X0YS9lAJ9rKBm3RxWu6ZR5A7F1biDuygBRX+Ww85Q42CHmdNLR0TU5E
tnZhZ57z/IEux7hj6boN6qGGs2g9/EKVsbmeveMNx39/Vm8QwnRcf/UctU4EPRYP
+zGpbQ/sx2cpxXJALUwiHK6VN6eE+i7sREC/7E3LqIvXIpw/qmDVKYZFvv5U4uMQ
Tlj4nKhGqbb3gPwP64f0XOfrIYuI7dqWTxaNDHpQwsG+xOWYEH1xjQ==
=SRBr
-----END PGP SIGNATURE-----


From jad at jadickinson.co.uk  Wed May 27 11:49:19 2009
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 27 May 2009 12:49:19 +0100
Subject: [Opendnssec-develop] status of the enforcer?
In-Reply-To: <D80EA3CC-A175-4F7A-8036-39E52DA88ED9@iis.se>
References: <6FD0AEB0-D1A3-4217-B85C-CDBFFF64F34C@iis.se>
	<43ACBA4A-D48E-440A-A0FF-1719F49A878D@jadickinson.co.uk>
	<D80EA3CC-A175-4F7A-8036-39E52DA88ED9@iis.se>
Message-ID: <4216C977-CF8A-433B-A6A2-C5C677FF61BA@jadickinson.co.uk>


On 26 May 2009, at 13:11, Patrik Wallstrom wrote:

>
> On May 26, 2009, at 12:35 PM, John Dickinson wrote:
>
>> the config is now in conf.xml and I clearly forgot to update the  
>> usage function. Sorry. See /trunk/testing/enforcer/* for some  
>> examples that build and run keygend.
>
> Ok, got it.
>
> There seems to be some problems with the configure build thingies,  
> my prefix for the config files in the binaries seem strange, this is  
> from keygend:
>
> I/O warning : failed to load external entity "NONE/etc/opendnssec/ 
> conf.xml"
>
> I did not provide any prefix at configure. So the config files  
> should be in /usr/local/etc/opendnssec/.

Fixed in r809. It appears that if you expand something like  
$sysconfdir in configure.ac you get $prefix/etc but then when that  
gets expanded $prefix = NONE unless specified on the configure command  
line. So you have to replace NONE with $ac_default_prefix.

Seems stupid to me but maybe one of you can explain it or suggest a  
more elegant solution.

Many thanks to the person who invented sed :)
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  Thu May 28 06:01:13 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 28 May 2009 08:01:13 +0200
Subject: [Opendnssec-develop] Looking at the XML
Message-ID: <69830D4127201D4EBD146B9041199718C68BF1@EXCHANGE.office.nic.se>

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

In the conf.xml example, do you really mean that keys should be generated every 3rd month?

<KeygenInterval>P3M</KeygenInterval>

Shouldn?t it be PT3M? So that you have minutes instead of months. Or am I confused?

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

wsBVAwUBSh4oqeCjgaNTdVjaAQizJAf7B2FdeILcbxoyy3Jw2BprXigmweLvcsFi
qloQWC3YippcTduJgEjkfdTzogcHxHz9UPJ8Mh7KCpxGsLZldc72uhEVANToIwXB
pIICqwlO0gvr78SE9wBh1BAxFohxA7p/NRFBETbr2M0MPpni6Ti052+tMVjP/n9l
jMgrXu1TUBu+uD1HMddHmqehuI9LTySTgwZliXLxgusIUyLtTSZecNqKwHX1LRdh
WgNOHNOv9qnvU94vjbP8N/gi8Gij3ubaL1SqGl7dKZtTNjU6/hswGZUVH7ofWhv5
7qci/jjpSXy4gBVrSoIDWBQKgsC3pACVO9IWx1i9+bI/4/jMQNYdgw==
=uBxG
-----END PGP SIGNATURE-----


From jakob at kirei.se  Thu May 28 12:49:08 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 28 May 2009 14:49:08 +0200
Subject: [Opendnssec-develop] FY: Configuration file summary
Message-ID: <6FCEC2FB-C7D4-4B13-97A0-E3530AD0C183@kirei.se>

FYI, I've added some text to the wiki describing what configuration  
files we have and what they do:
   http://www.opendnssec.se/wiki/Signer/Configuration


	jakob



From rickard.bondesson at iis.se  Thu May 28 14:26:38 2009
From: rickard.bondesson at iis.se (Rickard Bondesson)
Date: Thu, 28 May 2009 16:26:38 +0200
Subject: [Opendnssec-develop] Alpha version
Message-ID: <69830D4127201D4EBD146B9041199718C68D6F@EXCHANGE.office.nic.se>

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

Hi

Could everyone send to this thread what they think are left before their component or the project is ready for alpha release?

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

wsBVAwUBSh6fHuCjgaNTdVjaAQjq9Af8Clx2mGMoY+ytLCwyaAJrfhTCQO/QcRV6
53nJcQFET/PJD9ZtH4WRxwwamDb+30Ok/L+uneS2cGTY5meS3I6WR15Jf7jrdDWf
+EQwL8+rLP2Pic0pI9CTS+HxkuKB+Aqw2M4o5Kz7DGncIYz174gA9g8nt3JF/7MN
fK9JsOh4CJFEE2Cy4D1ylCewPkuLvm1QeYrU+ou0ZQ5zUhvijSTfAie2CV4Vvbx0
g7fO377WX88ebSwfz2A9Im1+B9wnjw3ENnG3Byse9achU8wuYFGtbVkifmwXX+9U
tsOZ+AAtrrt5FdO+0mILkHTJotgD/wU5Y5hMwEMY3pVJys1GX0GdWA==
=2wv7
-----END PGP SIGNATURE-----


From jakob at kirei.se  Thu May 28 14:30:52 2009
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 28 May 2009 16:30:52 +0200
Subject: [Opendnssec-develop] Invitations to PivotalTracker
Message-ID: <75E36898-56AD-4433-88F2-518B1F057B22@kirei.se>

Rickard and I are looking at using PivotalTracker (http://www.pivotaltracker.com/help#whatispivotaltracker 
) for tracking new features and bugs. some of you may have received  
some invitations - feel free to look around, but do not add any more  
stories just yet.

	jakob