[Opendnssec-develop] ZSK rollovers

Matthijs Mekking matthijs at NLnetLabs.nl
Wed May 5 13:20:53 UTC 2010


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

It may work. It does need changes in the signer though. And at the cost
of rollover knowledge in the signer engine:

The signer currently replaces signatures only if the keytag matches. For
example, in the current signer engine, Key 12345 will not replace old
signatures that were created with Key 67890.

If we want to solve it this way, I need to make this change in the
signer engine. I need to make it replace signatures per algorithm, not
on a key level. I think there are a couple of disadvantages here.

- - It works only for pre-published key rollover. For a double signature
(or double key rollover?), the new key must immediately be used for
signing (If I read the key-timing draft correctly). With the new
proposal, if there is a different signature present (created with a
different key) that is still fresh, we don't create a signature for the
new key. This means, we break the requirement that the new key is
immediately used for signing.

- - Thus, we need to make an exception for KSK.

- - Now we have introduced assumptions about what rollover scheme is used
into the signer engine. While it was explicitly designed *not* to know
about.


Best regards,

Matthijs


Stephen Morris wrote:
> On 05/05/2010 09:46, Sion Lloyd wrote:
> 
>> We had a discussion on the phone conference about ZSK rollovers and why
>> the signatures are all recreated...
>>
>> Rickard has just pointed out to me that the timing draft includes a term
>> Dsgn in the ZSK retire time.
>>
>> What this does is add in the time that a signature can be expected to
>> hang around in a zone for. I think that this is:
>>
>> (validity - refresh) + resign
>>
>> (I.e. assume the signature is created just before a key expires, then
>> add up the length of time that the signature will be left alone plus the
>> resign interval which is just the granularity of the system.)
>>
>> So if I add this to the length of time that the key is published in the
>> zone after it retires we can have the gradual switch between keys which
>> will look like:
>>
>> Sign with the old key until it retires, then use the _new_ key to
>> replace signatures as they reach the end of their lives. The old key
>> will be published for longer, until all signatures generated with it
>> have been replaced.
>>
>> This way we do not need to communicate any more information to the
>> signer.
>>
>> Does this work?
>>
>> Sion
> 
> That's the way I envisage it working.
> 
> AIUI, at the moment the signer is told what keys to publish in the zone
> and, of those keys, what key is the active one.  No change is needed to
> that for this scheme to work.
> 
> Stephen
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

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

iQEcBAEBAgAGBQJL4XCwAAoJEA8yVCPsQCW5yScH/RQ9H2MKlSCbYkHsFEyIDSV+
g1rnyI62hZH1A/XeQxyKnpI9JuOXn9m2ehQt7AvqU4czgR42twsCy0iKEeh9c2ho
iiHOn+iFilwOmkZJSMHVdykD/GmkV9ZHuePijBRgi0f8fGbB7JEDgq7st+kTXJP2
6DyOVNQstpJpQ/7UJIu6At/RbSOL496vx3O/Tn0UamelxDqhYMmBitNTt7xMc/nU
2MyRY1uWMA/n+Wwa9HRqG4g0M0oMwcQX7HOswrGYVqjsnE2J5UUxfS1Ig7aUJPQd
UJ/DCvmyEOJ5DergWxmNXbPInwFrLtbL3HqfJ5/JkZ//cFjaVLSJZdzj30W0v1g=
=Vdob
-----END PGP SIGNATURE-----



More information about the Opendnssec-develop mailing list