On 2013-03-04, at 05:39, Antoin Verschuren <[email protected]> wrote:
> Op 01-03-13 16:50, Olafur Gudmundsson schreef: > > > One CDS's goals is to get the "Parent" out of the habit of > > calculating hash, just publish what the Child wants. > > I strongly disagree on this. > I don't think CDS goal should be to mandate registry policy. Contrarily, I don't think the goal should be for registry policy to dictate what DS records should be acceptable for a child. I think this should be the child's decision. > Let me get some real world data in there. > > The majority of DNSSEC delegations in TLD's today were set up by > sending DNSKEY to the registry and have the registry calculate the > hash it supports at the parent. Our registrars do it, and they have > absolutely no issue with it. By the number of DS records published in registry zones, you might be right. But as a counter data-point, I have signed domains delegated from CA, ORG, NET, COM and NZ and I have never supplied a DNSKEY RRSet to the parent; I have only ever supplied a DS RRSet. > DS is on the parent side of the zone cut. The child should not bother > to calculate DS, certainly not with algorithms the parent doesn't > support. If as a child I want to use an experimental or newly-standardised algorithm, I should be able to do so. The parent zone operator should care that the DS RRSets are well-formed and legal; they should not care what the RDATA is. The relying parties for my signatures in my zone might well not include the parent zone operator. Why should the choice of algorithms for those relying parties be restricted by what the parent zone operator thinks is acceptable? We're threatening the future development and use of new algorithms by institutionalising these restrictions. > The risk is that childs can deliberately choose algorithms > that will diminish the integrity of the parent zone. What is that risk? I don't see it. Joe
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
