On Mon, Apr 14, 2014 at 11:10 AM, Warren Kumari <war...@kumari.net> wrote: > On Mon, Apr 14, 2014 at 9:17 AM, Tim Wicinski <tjw.i...@gmail.com> wrote: >> >> On 4/14/14, 8:50 AM, Patrik Fältström wrote: >>> >>> On 14 apr 2014, at 14:32, Antoin Verschuren <antoin.verschu...@sidn.nl> >>> wrote: >>> >>>> op 12-04-14 09:28, Patrik Fältström schreef: >>>>> >>>>> No, I want B. That CDS and CDNSKEY is staying in the zone. >>>> >>>> To keep it in the same thread, >>>> I want: >>>> >>>> C: The child MAY remove the CDS/CDNSKEY RR from the zone once the >>>> parent has published it, and this is how to do that safely. >>>> >>>> So I'm ok if they stay in, but we need a way to get them out for the >>>> ones that need that. >>> >>> I am fine with C. >>> >>> paf >>> >> >> Actually C helps me with some of the wording, as I spent some time >> yesterday with a red pen going over editorial issues. > > Hopefully you are reviewing the latest (-05) :-) > > Actually, I'm planning on incorporating C - chairs, please let me know > if this does not align with your view of consensus. >
... and I've just posted -06, incorporating option C. I have outlined the changes in the Change / Author Notes section -- they were primarily to ensure consistency and to remove duplicated text. One of the bits that is a larger change, and that I'd like some feedback on is: Section 6: I changed: "Regardless of how the Parental Agent detected changes to a CDS / CDNSKEY RR, the Parental Agent MUST use a DNSSEC validator to obtain a validated CDS / CDNSKEY RRset from the Child zone." to: "Regardless of how the Parental Agent detected changes to a CDS / CDNSKEY RR, the Parental Agent SHOULD use a DNSSEC validator to obtain a validated CDS / CDNSKEY RRset from the Child zone. The only exception to this is if the parent perfoms some additional validation on the data to confirm that it is the "correct" ket. This behavior is NOT RECOMMENDED." As Patrik (and others) have pointed out, a number of folk would like to use this for initial enrollment. How do folk feel about the above? Plan is that a user will publish a CDS in an (e.g) unsigned zone, and will then logon to the registrars web interface. They click "Fetch CDS/CDNSKEY" and the web interface displays the key. They user checks[0] that it is correct then click "LGTM". Now they are signed... I'm somewhat uncomfortable with the above, but, hey, whatever... W [0]: Yup, they really check it, and make sure the key matches. They don't, for example just blindly click OK :-P @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the DSA key sent by the remote host is e5:33:f0:e6:22:24:0c:ee:e2:ed:f2:d2:e7:a0:3f:a6. Please contact your system administrator. > W > > >> >> tim >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
