In message <a06240800c5dd7e5f2...@[10.31.200.116]>, Edward Lewis writes:
> 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.
Ed, I'm aware there are multiple ways to do this. However
publishing DS records only precludes some methods. Publishing
DNSKEY records does not preclude any methods as one can
*ALWAYS* generate a DS from a DNSKEY. The reverse requires
you to look up a key which matches which means it must be
available to be available to be looked up.
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
