Enhanced zone signing. #418
Conversation
- FIX: Clear the signing buffer between uses. - Output signed DNSKEY RRs from sign().
…e unsigned delegation NSEC3 RRs in the output.
| /// If only one key has a supported algorithm and has the ZONE flag set | ||
| /// AND has the SEP flag set, it will be used as a CSK (i.e. both KSK and | ||
| /// ZSK). |
There was a problem hiding this comment.
This isn't quite true. At the moment, if only KSKs or only ZSKs are found, then they are all used as CSKs. If multiple KSKs or multiple ZSKs are found, they will all be used. Do you want to update the documentation or the code?
There was a problem hiding this comment.
Thanks. Note: None of this behaviour / interface is set in stone yet as I'm still working my way through the support needed for all of the ldns-signzone arguments and behaviours. Once I'm done with that I'll start reconsidering the API and then update comments to match.
| #[allow(clippy::type_complexity)] | ||
| pub fn sign<Octets, ConcreteSecretKey>( | ||
| &self, | ||
| apex: &FamilyName<N>, | ||
| expiration: Timestamp, | ||
| inception: Timestamp, | ||
| key: SigningKey<Octets, ConcreteSecretKey>, | ||
| ) -> Result<Vec<Record<N, Rrsig<Octets, N>>>, ErrorTypeToBeDetermined> | ||
| keys: &[SigningKey<Octets, ConcreteSecretKey>], |
There was a problem hiding this comment.
Better to take an iterator, maybe?
There was a problem hiding this comment.
There's a version of this code that takes an iterator and works with a domain ZoneTree, so yes changes to this API are intended at some point, but at the moment I'm just making stupid minimal changes to the API and will return to the topic of API design later.
This PR builds upon #416 to extend the signing support in
domainto support signing with multiple keys and key types using the new key management functionality in #406.