Not Tony, but a partial reply from me: On 2/19/15, 6:19, "Mukund Sivaraman" <[email protected]> wrote: > >Is there a need for a DS RR to be dangling at the parent (i.e., not >pointing to any available DNSKEY at the child) during algorithm >rollovers?
“Need” isn’t the right question. However, there are some, even TLDs, that seem to have chosen to pre-publish DS records for DNSKEYs. These cases are same-algorithm though. >Matching DNSKEY in child for every DS algorithm type in parent is a MUST >requirement for auth servers (RFC 6840 sec. 5.11). It's just not a >validator requirement. Yes, or a client wouldn’t be able to determine whether someone stripped something out. If a client can trust (meaning has an implementation of the algorithm) used at the parent, they can trust what the child has - whether the client can deal with the child’s algorithm or not. So if the parent says the child has an algorithm the client can use but the child doesn’t have it - the client SERVFAILs. If the child can’t deal with any of the parent-reported child algorithms, the client can choose to downgrade to unsigned, downgrading ‘securely.’ Hope that’s clear enough, I haven’t had breakfast yet. (Empty stomach typing is always more hurried.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
