On Fri, Sep 20, 2013 at 06:10:48AM -0400, James Cloos wrote:
> VD> This usage requires the presence of a given CA (root or intermediate)
> VD> in the chain, but does not promote that CA to a trust anchor (as
> VD> with usage 2). So perhaps the original PKIX-CA is in fact better.
>
> On a ship with multiple anchors, each /is/ still an anchor. Even if
> the crew does not trust one at a time to hold the ship in place.
I look at this as a ship with an anchor, and a "golden link" in
the chain (O.K., gold is not stronger than iron, but we won't take
this metaphor too literally). Yes, the "golden link" can also be
a "golden anchor" when the TLSA record association data matches a
public root CA.
An interesting anomaly arises at a site that only explicitly trusts
an intermediate CA (via appropriate local software and configuration)
and is validating a chain that starts with an untrusted ancestor
CA that matches the TLSA RR:
TLSA-CA -> ... -> local PKIX-TA -> ... -> EE certificate
Should DANE admit this chain? Under the "2 anchors" analogy arguably
it should. I think it should not. The CA *constraint* in RFC 6698
was never intended to accept more certificate chains than one would
accept with PKIX alone, it is supposed to only be an additional check.
The PKIX trust anchor is primary and plays an assymetric role.
> The type 0/1 tlsa are anchors, but the admin lacks trust in either
> technology on its own and requires both technologies verify.
I think this is a radical departure from PKIX terminology.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
