Hi Thomas, On 2025-10-16 16:51 +02, Peter Thomassen <[email protected]> wrote: > Hi Florian, > > This is pretty cool! I think it would make perfect sense as an informational > RFC. > > I actually this this document is quite mature already, and could perhaps be > done quickly. >
thank you! > Some suggestions: > - Section 4.1, second paragraph: This is under the assumption that > keys for both algorithms are inoperable, correct? If one is, one > doesn't need to add two keys. (In general, I'd think that one needs to > add only one key per algorithm for which there is at least one > inoperable key.) Correct. I've created an issue on github. (As a side node, we want to keep the procedures as simple and straightforward as possible. I.e. trade simplicity for unnecessary work. We had considered to write a whole section on algorithm rolls with all the possible cases that might arise, but that results in a quadratic explosion of cases. For the case you point out I think it is easy enough to sneak a sentence in that says: Only introduce new keys for algorithms where the old key is inoperable. That will not increase complexity.) > - Also, consider switch sections 4.2 and 4.3. Could you elaborate why? We chose to use this order because - it's the same order as in 7583 - the zsk case is arguably the easier one, so get that one out of the way first ;) - 4.3 references 4.2 I had considered dealing with the KSK case first because that's probably the one people run into most of the time. I'm curious to hear why you would like to switch the order. Thanks, Florian > > Best, > Peter > > > On 10/12/25 18:05, Florian Obser wrote: >> Hi there, >> we put a draft together on what to do when losing the private key >> for >> signing a zone. >> Spoiler: One can still do a key-rollover. >> Any comments are very welcome. >> Is this something the WG would be interested in? >> Thanks, >> Florian >> ---------- Forwarded message --------- >> From: <[email protected]> >> Date: Sun, 12 Oct 2025 at 12:42 >> Subject: New Version Notification for >> draft-fobser-dnsop-dnssec-keyrestore-00.txt >> To: Florian Obser <[email protected]>, Martin Pels <[email protected]> >> A new version of Internet-Draft >> draft-fobser-dnsop-dnssec-keyrestore-00.txt >> has been successfully submitted by Florian Obser and posted to the >> IETF repository. >> Name: draft-fobser-dnsop-dnssec-keyrestore >> Revision: 00 >> Title: DNSSEC Key Restore >> Date: 2025-10-12 >> Group: Individual Submission >> Pages: 11 >> URL: >> https://www.ietf.org/archive/id/draft-fobser-dnsop-dnssec-keyrestore-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-fobser-dnsop-dnssec-keyrestore/ >> HTML: >> https://www.ietf.org/archive/id/draft-fobser-dnsop-dnssec-keyrestore-00.html >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-fobser-dnsop-dnssec-keyrestore >> Abstract: >> This document describes the issues surrounding the handling of >> DNSSEC >> private keys in a DNSSEC signer. It presents operational guidance in >> case a DNSSEC private key becoming inoperable. >> -------------------- End of forwarded message -------------------- >> > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Möckernstraße 74 > 10965 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- In my defence, I have been left unsupervised. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
