Ed Lewis wrote: And to make this work really well, we have to figure out how I'd get a DS record for an unpublished DNSKEY into a zone like .NL (Antoin's - well, not his personally) that wants keys to work on, not DS records. To hark back to Wes, I don't have answer for that, I don't want to propose a solution - like, hey Antoin, you're wrong, use DS instead - that would prevent Antoin from operating under his model. I can see having CDS be used to indicate what DNSKEY Antoin would have to pull - if the key is in the DNS.
Okay, here's an open question (as in, if anyone knows, please chime in): Is it possible/feasible/easy, to use DNSKEYs as public/private crypto tools' keys, generally? E.g. If I have a public key (from a DNSKEY), say for my zone's parent-zone's ZSK, could I encrypt something (like a public DNSKEY value, which has not been published), and have the parent-zone's operator decrypt it (with their private key(s), either offline, online, or using an HSM which performs decryption without exposing the private keys)? This would avoid the act of publishing the DNSKEY, while still having the general mechanism of using DNS to publish CDS data. The DNSKEY is transferrable only to the parent, presuming no leakage of private keys on the parent's side, so the DNSKEY remains "unpublished", yet Antoin's model should still work (albeit with the addition of "encrypt" to the web-form). If so, then I think this may be a feasible solution: Have support for encrypted DNSKEY data, with fields indicating signer name (parent zone apex), key tag and algorithm. NB – the parent's DNSKEY used for encrypting the child's DNSKEY, might possibly be used ONLY for encrypting/decrypting CDS data, I.e. be yet another member of the DNSKEY set, but be neither a ZSK nor a KSK. Maybe we could have another bit assigned to signal this particular use/purpose? Thoughts? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
