Hi Jake, Thanks for the write up! I do have a few additional pointers.
nit: Subject line should be about enforcers I suppose. > I believed the initial run of 'ods-enforcerd' was what > decided which key(s) would be picked first. For OpenDNSSEC 2 this will be the case. The database doesn't get populated with keys by an external program (ksmutil) anymore. Though it can still pre generate keys. > I wish ods-enforcerd, on initial run, would first check > the HSM for available keys instead of checking 'keypairs', finding it > empty, and then generating a new key. I'm not sure it would be a good idea to let OpenDNSSEC use key material it happens to find and doesn't know about. Could be from old keys. Perhaps once used with a different algorithm. Best to let them untouched. It is a feature we could think about though. Yet, the HSM also doesn't come with guarantees regarding the order of keys as far as I know. > èThis behaviour would be especially bad in situations where someone is > using multiple AEP Keypers in remote locations, as it would take a trip > and smart cards to get the newly generated key on to the secondary HSM. > (Unless using AEP load balancer, I guess) OpenDNSSEC supports importing of keys from the HSM. But that might not be applicable here. Not sure it can import as 'unused'. //Yuri
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
