Publish, ZSK, and KSK flags

Note: This information is only applicable for the signer and enforcer as of version 2.0

Since the Signer is smart about rollovers (i.e. provide gradual transition between two keys) and the Enforcer supports ludicrous rollovers, we must take extra care in how the two communicate.

The Enforcer has the following directives in the signconf:

1. Key Section. The key is mentioned in the configuration. Signatures with this key may be reused.
2. Publish Flag. If set, a key must have its DNSKEY record published.
3. KSK Flag. If set, DNSKEY set must be signed using this key.
4. ZSK Flag. If set, records must be signed using this key

ZSK Flag

This flag is problematic. In order to spread load, the signer keeps using signatures of old keys which are not yet expired before generating signatures with the new key. The Enforcer does not necessary performs a roll between 2 keys but rather N keys. Additionally a zone might be signed with multiple key of the same algorithm.

The challenge is for the signer to find out when new signatures must be generated and with which keys. The Figure below shows the decision tree Matthijs and I figured out.

The signer first of all loops through all RR sets, then over all keys. Each iteration the tree is consulted. We can define 4 different checks:

1. Active? The key has ZSK Flag.
2. Signature? This RR set already has a signature for this key.
3. Valid? Said signature is still valid.
4. Inactive key with valid Signature? There is a still valid signature, for an old key.

Behavior

This specification leads to the following behavior:

• Smooth rolling of ZSKs is still supported.
• When rolling from 1 ZSK to N, Any of those N will be used only after the old signatures expire.
• When signing with key A and then also signal to use key B. B's signatures will be introduced immediately.
• When signing with N keys, we can replace one of those in a smooth way.