PKCS#11 stuff: "sign-only" vs "crypto-accelerator"

[Johan Ihren]

Hi Evan,

Sorry about the late reply... my mail server broke down while I was away on travel.

On 11 Feb 2010, at 02:27, Evan Hunt wrote:

>> Of course. So there needs to be meta data. Meta data per zone, not per key.
> 
> No, per key.  This stuff relates to the lifecycle of the individual key
> (created at time t1, published at t2, activated at t3, deactivated/revoked
> at t4, unpublished at t5, succeeded by key K...).

Well, that too, you're right. The point I was trying to make was in response to your observation:

> or else how does named know which HSM key to use?

In the end I think we can easily agree that there is metadata both per key and per zone. And as I am really sick and tired of all the K*-files I'd much prefer to hide it all in a per zone database of some sort.

> Per-key information could be stored in a single file rather than a
> directory (in a database file, or XML, or whatever).  But that's sort
> of semantic.

From my point of view this is the problem:

A. There is a zone. It has a well known name that has the good property of being static.

B. There are keys. A troublesome bunch. Changes over time. Different roles at different times. Need lots of metadata.

C. There is a tool (dnssec-signzone -S) that uses A + B to include the right keys and sign the zone.

The two things needed are:

1. A database for keys and metadata (be it a single text file for everything, a HSM for the keys and a file for the metadata or perhaps a sqlite3 database for all of it, or even K*-files). I can see situations where either choice makes sense.

2. Tweak the tool to be able to extract keys and metadata from the different types of databases. As dnssec-signzone already scans directories for keys I fail to see why it would be so difficult to scan a text file or look stuff up in a sqlite3 database.

And by all means keep the K*-files for the people who like them. Just don't make the K*-files the *only* mechanism for keys in the BIND release meant to be where DNSSEC became usable to the non-geeks.

>> I understand that it is too late for 9.7.0, but when(!) you change this
>> in a future release, please consider not locating it in K*.meta but
>> rather in a file per zone with a predictable name. Having to scan
>> directories is not a great idea.
> 
> In the meantime, I recommend using a different key-directory for each zone.

Ummm... no. That really doesn't make this any less ugly.

Johan