To set up the problem to solve. Asking for points that are missed. (Purposefully omitting the trailing dot, not talking about 'root' because that could get confusing.)
Trust anchor for "one/17" (i.e., key_id=17) Trust anchor for "two.one/145" Received data for "three.two.one" signed by "two.one/9342" What would cause "two.one/9342" to be signed by "one/17" and not by "two.one/145"? (I think this captures the question of interest.) 1. "two.one/145" is in the MISSING state from STD 69. 2. "two.one/145" was revoked but the validator didn't remove it. 3. "two.one/145" is stale, as the validator is not using STD 69. 4. "two.one" was re-delegated, the previous holder still uses "two.one/145" 5. (open for more scenarios of "why") What should the validator do with the response? For cases 1,2,3, the chain ought to be accepted. For case 4, although the appropriate DNS response (according to the DNS protocol) was received, the application calling it might not want to take action based on the response (action such as open a connection and/or flow data). Is there a way, within the DNS, to differentiate amongst the reasons why the response is signed up to "one" and not "two.one"? Is there a way the application can tell? With DANE as "an application" in mind: When it comes to DANE, what bothers me is this, in "DNS-Based Authentication for TLS", the section "The Certificate Usage Field" (that is RFC 6698, section 2.1.1), for value "3 -- Certificate usage 3". For that value, this is stated: "PKIX validation is not tested for certificate usage 3". My reading of this is that the "problem" with PKIX certificate authorities has just been shifted over to DNS hosting services (in this case for "one"), concerns about the DNS hoster are on par with concerns regarding the certificate authorities. (In essence, either could re-delegate a name.) (Yes, this is a tangential off-shoot, anticipating questions about how DANE plays with this.) In essence, usage 3 removes the benefit of pinning, which the application could use to detect a re-delegation.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
