During the years, we've had discussions about adding support for offline keys to OpenDNSSEC. There are at least two scenarios where you might want to use offline keys and OpenDNSSEC should try to support both. This feature is tracked in issue OPENDNSSEC-251.
Open source code is available at : https://github.com/icann/dnssec-keytools
Jakob can create example KSR/SKSR files
Output of ksk signing: http://data.iana.org/ksk-ceremony/15/
Offline Key Repositories
The keys are stored in an offline HSM connected to the OpenDNSSEC system and can be put online for key management if required. Once online, the enforcer can create the required keys. Some part of OpenDNSSEC also need to prepare some number of future DNSKEY RRset (including signatures) to be used until the HSM is connected the next time.
Distributed Key Management
All key signing keys are managed and stored elsewhere. Public zone signing keys needs to be exported from OpenDNSSEC and the signed keys, together with public KSKs, needs to be imported back.
This setup is very similar to the process set up for the root zone, where Verisign maintain the ZSKs and sends a set of future keys – the Key Signing Request (KSR) – to IANA for signing. Once IANA has signed the keys (four times a year) – producing a Signed Key Response (SKR) – Verisign will import back the signatures and include them in the signed root zone. The KSR/SKR scheme has been in production since 2010 and has been proven to work very well.
Support for offline keys is limited to offline Key Signing Keys (KSK) – offline Zone Signing Keys (ZSK) is out of scope.
What parts of OpenDNSSEC are affected by offline keys?
The KASP Enforcer needs key repositories to be available for key generation, although one can configure for manual key generate. Once the keys has been generated, the Enforcer actually don't need to access the keys as only key identifiers are communicated to the signer engine as part of the signer configuration.
The enforcer needs to be aware that another entity manage the KSKs. With distributed key management this also effect timing parameters, as KSK signature lifetimes, TTL etc. is managed by the KSK manager.
The signer engine expects all key repositories referenced in the signer configuration to be available for signing.
The signer engine needs to allow for already signed RRsets (i.e., a DNSKEY RRset signed with all active offline keys) to be automatically imported into the zone. Functionality is need to determine what pre-signed RRsets (as produced by the KSK manager) to include at what time. Imported DNSKEY RRset may not be altered by the signer engine as the signatures would go bogus if altered. Hence, any conflicting signer configuration (e.g. what keys to publish) must be ignored by the signer engine.