[Opendnssec-develop] Minutes 2009-02-23 (phone meeting)

[Rick van Rein]

Hello,

Here are the notes of this afternoon's phone discussion.
Any comments, please let me know before I put them on the
Wiki.

Cheers,
 -Rick

    ------- 8< ------- 8< ------- 8< ------- 8< ------- 8< -------


Notes of the OpenDNSSEC phone meeting on 2009-02-23
===================================================


Present: Jakob, Jelte, John, Rick, Rickard.
Not present with notification: Matthijs, Olaf, Roland, Roy.


1. Who will write minutes?

Rick will.


2. Use cases

Stephen updated the Use Cases and published them on the Wiki.
These cover only phase 1, and he is asking whether to go ahead
with phase 2 as well.  We decide to focus on phase 1 for now and
do the work towards phase 2 later.


3. Updates on the API between the Enforcer and Signer Engine

There is good progress in the XML specifications that define the interface
between these two components.  Issues covered include

* import data into the KASP, and getting it into the database
* a text format for the strings that identify keys in the repository
* utilities that enable the Signer Engine to scan through the key set

The designers believe that they have covered all the issues that enable
the coding at both ends to commence.

Jakob offered to formalise the schema using RelaxNG.  He explains that
this would formalise the syntax only; what RelaxNG adds with respect
to DTD or XML Schema is that it is readable to humans.


4. Discussion about each component

KASP and KASP Enforcer:
        The internal database is moving from an old to a new schema, and
that is currently taking some effort.  Support for XML has been started
on.  An internal component called KSM is the one that will do the key
rollover; a document including the algorithms for such key rollover has
been posted, and the authors are actively seeking feedback on it.
Stephen and John will add their time estimates to the Wiki.

Signing Engine:
        Jelte is working on v1, while Matthijs prepares for v2.  The
engine has been updated to a queue-based architecture, which is intended
to make it scale up without bounds.  It won't sign 5000 zones a minute,
but it can keep 5000 zones signed at a normal pace.  Jelte estimates
that this work will be finished in about 2 weeks, to a level where it
is ready for integration.

SoftHSM:
        Rickard has made internal changes: slots can now be configures
out-of-band, as discussed during the previous meeting, and each slot
contains one token for one user.  The speed of the system is not impaired
by this change; it creates 6158 signatures a second, compared to 8300
for OpenSSL on the same 64-bit configuration.  Rickard wants to take
some time to overlook the design, run test cases and have it reviewed.
This will easily be done before phase 1 is complete, so it should not
introduce any locking problems.


5. DNSSEC Signer

We agree that it is ideal if we can test components in isolation,
challenging them with "funny" usage patterns, so that the integration
should not introduce many novel problems.  This ought to be possible
because all component interfaces are known (PKCS #11, an XML format)
and so are the interaction patterns.

Stephen requests that someone draw up a diagram similar to a UML
package diagram to work out the architecture in a bit more detail.
Rickard volunteers.

Rickard will also set up guidelines that detail all the thiings that
are needed for phase 1.


6. Project requirements

Stephen and Rick are working on these; Rick hasn't done much because
he was ill since last meeting, but Stephen has written an initial
document, for which he actively requests feedback.  The requirements
(also from last meeting) will be brought onto the Wiki by Stephen
and Rick, and the intention is to make them suitable for deriving
tests from.


7. HSM-buyers guide

Without Roland present at the meeting, we cannot come to conclusions
on this point.


8. Transport trust-anchor/secure-entry-point to the parent

There are no standards for transporting new signing keys to the parent;
the KASP Enforcer will log it over syslog.

We discuss a few other mechanisms (email, syslog NG, shell script,
HTTP POST) and Jelte envisions an adapter into which an admin's
favourite could be plugged.  We will defer this disucssion until
v2 or later.


8.1/2. Other parties (extra topic)

Afilias has recently contacted NLnet Labs about OpenDNSSEC.  They may
have something to contribute, and say that they have special
requirements.  NLnet Labs will see them, and gather requirements
that may influence our thinking about the project.  We are not
looking for extra partners at this time, and will not promise them
anything more than using their requirements as an inspiration that
we may choose to add.  The rationale behind this is that we do not
want to slow down the project with late requirement entries.

ISC is interested in OpenDNSSEC as well, and for bind 9.7 they are
looking into something similar to the KASP.  We see no harm in
sharing our work with them, but at the same time we would not
mind if two independent DNSSEC signers would co-exist in the
open source realm; this can be a great asset in times when one
of these fails.

Secure64 also shows interest in OpenDNSSEC, but this may be due
to an interest in alternatives moving on the DNSSEC market.


9. Next meeting

We will meet on the phone again in 2 weeks from now, on Monday
the 9th of March, 14:00 to 15:00 CET.