On Apr 19, 2013, at 11:28 AM, Joe Abley <[email protected]> wrote:
>
> On 2013-04-19, at 11:21, Wes Hardaker <[email protected]> wrote:
>
>> Joe Abley <[email protected]> writes:
>>
>>> By this thinking, a signed apex DS RRSet with the meaning discussed
>>> for CDS could be deployed today, with no need for code point
>>> assignment. What am I missing?
>>
>> Besides the other two comments: DS records are signed with the ZSK, and
>> the CDS document explains why it needs to be signed with the KSK instead
>> (also).
>
> I'm not sure I fully understand the logic of that, actually.
>
> Surely the important thing is that the apex CDS RRSet in the child zone can
> be verified to be authentic. Whether that means that CDS has an RRSIG created
> by a KSK or a ZSK should make no difference, so long as the chain of trust
> from the parent zone is intact.
>
> Why is it not sufficient to specify that the authenticity of the CDS RRSet in
> the child zone should be able to be verified using DNSSEC, or else that the
> CDS RRSet should be ignored?
Flippant answer: in the case where same entity operates both KSK and ZSK keys,
just use singe key in both roles.
Serious answer: CDS becomes part of the Trust Anchor authentication chain, in
RFC5011 Trust Anchor Maintainers only accept new trust anchors that
are signed by the old Trust Anchor, and CDS copied that requirement.
Olafur
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
