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
