[Opendnssec-user] Some glitches in OpenDNSSEC

[Ondřej Surý]

On Fri, Jul 2, 2010 at 09:17, Rickard Bellgrim <rickard.bellgrim at iis.se> wrote:
>
> On 25 jun 2010, at 11.41, Ondřej Surý wrote:
>
>> - No way how to get rid of a imported key or change a state of already
>> imported key
>
> Once the key is imported, it is supposed that the enforcer updated the state.

Yes, but suppose you imported wrong key and want to get rid of it.

>> - If I delete zone and re-add it later, the keys are lost, but you
>> cannot re-import keys with same CKA_ID.
>
> Removal of a zone does not remove the keys.
>
>> - No way how to remove "lost" keys (see previous remark).
>
> ods-hsmutil remove <id>

In fact:

ods-ksmutil key purge -p all

is needed. Because when I just remove the keys with ods-hsmutil:

# ods-ksmutil zone delete -z foobar.cz
# ods-hsmutil remove 99cfd17644c8987f8ea709feb3c6e09ee26b12eb54e4dbd50768733d
Key remove successful.
# ods-hsmutil remove a34f6f2cc51c5ee968cd4e1508fd90e1198f4c5a11e2796c30de592a
Key remove successful.

then key import fails:

ods-ksmutil key import --cka_id
99cfd17644c8987f8ea709feb3c6e09ee26b12eb54e4dbd50768733d --repository
SoftHSM --zone foobar.cz --bits 1024 --algorithm 5 --keystate active
--keytype ZSK --time 201007021105
Error: key with CKA_ID
"99cfd17644c8987f8ea709feb3c6e09ee26b12eb54e4dbd50768733d" already
exists in database

ods-ksmutil key import --cka_id
a34f6f2cc51c5ee968cd4e1508fd90e1198f4c5a11e2796c30de592a --repository
SoftHSM --zone foobar.cz --bits 2048 --algorithm 5 --keystate active
--keytype KSK --time 201007021105
Error: key with CKA_ID
"a34f6f2cc51c5ee968cd4e1508fd90e1198f4c5a11e2796c30de592a" already
exists in database

So my original comment is still valid. You cannot remove individual
keys from KASP database.

>> - Algorithm rollover is missing? And it's not in the roadmap yet?
>
> It is planned for 1.3, but the roadmap is not update. Will do that next week.

Thanks.

> Algorithm rollover is essentially like going from unsigned to signed with the new algorithm. Then at one point you decide to go unsigned with the old algorithm. The Enforcer should be able to handle multiple sets of algorithms, and also that the kasp.xml must be expanded (so that you can have multiple ksk and zsk fields)

Nope, unfortunatelly it's much more complicated. Olafur and I had a
talk about that and you need to pre-publish the signatures before you
publish DNSKEYs with new algorithm. Also at each time you need to have
signatures for all RRSets with DNSKEY for each algorithm in apex. Then
you have to be careful with DS as well (same rule applies).

Expect some mail in dnsop/dnsext soon on this topic.

Ondrej
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/