Doug Barton <[email protected]> writes: > ... thus creating a support problem when the customer checks their CDS > record, sees that it is "valid," and then doesn't understand why the > parent won't accept it.
Yes, but a CDS management tool wouldn't. It's a specific use case. The above is like saying "my MX record validates with DNSSEC so it must be valid", even though the label doesn't point to a real name. It is not the job of a validator to judge how the data itself will be used and guess at any additional constraints that may be placed on it. A CDS record, just like an MX record, can be valid but not usable. [and don't get me started on CNAME breakage in the wild] >> And to say that we don't have that elsewhere and this is new isn't >> correct either. 5011 has a number of similar semantics. Consider the >> revoke bit for the simplest and closest to this case. > > Perhaps you could elaborate? It's not clear to me how that case > applies in the child -> parent signalling direction. A revoke bit is only considered "actionable" (IE, revoke it from your trust storage) if it was signed by the same key that produced the key with the revoke bit turned on. IE, you can have a "valid" key with the revoke bit set, but you shouldn't actually act on it because it wasn't signed by the key itself. See RFC5011, section 2.1, last sentence for the quick summary. The key would still be considered valid by a validator but you shouldn't act on the knowledge of the data in the key. -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
