That is completely antithetical to my understanding. For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI checks. For type 3 - I would agree that no PKI checks are to be done. That would include the name matching check.
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Viktor Dukhovni > Sent: Saturday, March 02, 2013 1:21 PM > To: [email protected] > Subject: Re: [dane] Certificate usages 1/3 and subject name checks > > On Sat, Mar 02, 2013 at 10:53:39AM +0200, Ilari Liusvaara wrote: > > > > However, I do believe that the same (subject name checking) policy > > > should apply for both certificate usage "3" and "1". > > > > I think you are mixing up usages 1 and 2 or something. > > I am quite sure I am not. > > In both usage 3 and usage 1 the TLSA RR specify the end-entity > (leaf) certificate deployed on the server. Once a particular certificate is > explicitly bound to the server via a TLSA RR, there is no point in comparing > the server name with the content of the certificate, we already have a > binding and name checks can only fail with no security gain (snatch defeat > from jaws of victory). > One simple design rule I try to adhere to is: "don't fail when success is an > option". > > I read the DANE certificate usage numbers as falling into a 2x2 feature matrix: > > TYPE: TA | EE > PKIX:/-----------\ > YES | 0 | 1 | > -----|-----------| > NO | 2 | 3 | > -----\-----------/ > > The TA usages specify a trust anchor while the EE usages specify an end- > entity certificate. The PKIX "YES" usages request trust-chain validation to an > existing CA root, while the "NO" usages do not. > > If we encode the certificate usage as a 2-bit number, the least significant bit > is the EE bit, and the most significant bit is the "CAs? We don't need no > stinkin' CAs!" bit (where by CAs one means the usual panoply of public root > CAs found in browser cert bundles, and not privately label trust-anchors is in > usage 2). > > Bottom line, the type of trust path validation is completely irrelevant when > deciding whether the client should check the SAN (or fallback CN) name > binding of the server certificate, given a DANE binding to an EE certificate, > whether we check the trust path or not, we're done with the name binding. > > Therefore, 1 and 3 should I believe be treated identically with respect to the > semantics of the certificate content (as distinct from its trust path). > > -- > Viktor. > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
