You poor souls. The DNSSEC monster is vast and complex. So much easier just to fix the problem instead of this endless gibberish. It's so complex it's funny when you consider a simple solution like DNSCURVE - http://dnscurve.org/ - and so much more secure. No man in the middle issues.
Oh well - sorry for the interruption - and carry on. cheers joe baptista On Wed, Mar 11, 2009 at 10:57 AM, Edward Lewis <ed.le...@neustar.biz> wrote: > At 8:19 +1100 3/11/09, Mark Andrews wrote: > >> In message <a06240804c5dc2ddef...@[10.31.200.116]>, Edward Lewis writes: >> > > record involves less typing than a DNSKEY, I'd want to work with a DS >>> record. >>> >> >> Has anyone on this list ever typed in a DNSKEY or DS as a >> trust anchor? I would presume that most (99.9999%) people >> > > "work with" != type in > > At 10:40 +1100 3/11/09, Mark Andrews wrote: > >> I have a new key I want to introduce. I add the DS to the >> parent zone at least the ttl(ds) before I start using that >> key in the zone. After the DS has been published for ttl(ds) >> I can then replace the DNSKEY referred to by the old DS >> with that of the new DS and re-sign the DNSKEY RRset. Once >> the ttl(dnskey) has expired I can remove the old DS from >> the parent zone. >> >> I wish to be able to do something similar with trust anchors. >> Publishing DS prevents me from doing so. >> > > There is more than one way to do a key supersession. I'll describe one > assuming DS records are installed as trust anchors. > > DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a > note that it should be installed "by the 15th." On the 15th, DNSKEY(KEY2) > is placed in the zone and KEY2 only is used to sign the keyset. With a 1 > week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed > from the set. At some point after that I can remove DS(KEY1) from my > validator. > > Perhaps the special case here is that the keyset is unique in that the > signatures for SEP/KSK's are "tied" to the where the key data is. I.e., if > you have something signed by KEY1, then you have KEY1 because that something > has to be the key set. > > If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is > triggered by signing the last RR set by KEY2 and then the TTL. > > The principle here is that there is no error if "for a DS record there is > no corresponding DNSKEY" and vice versa. All that is needed for validation > is one "chain of trust." Accepting dangling references is not optimal but > provides robustness. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Getting everything you want is easy if you don't want much. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
