On Fri, Dec 02, 2022 at 08:20:58PM +0000, Ollie wrote:
> That said, in reply to your points, I understand DANE to a level that I know
> PKIX isn't applicable to my original intention/query, so perhaps I haven't
> been clear with what I'm looking to achieve.
DANE has 4 certificate usages, and 2 of them PKIX-TA(0) and PKIX-EE(1)
are a combination of local trust-anchors (RFC 5280 PKIX) and DANE
certificate constraints (server-side DNS CA or EE certificate or public
key constraint).
The security of PKIX-EE(1) is at least as strong as DANE-EE
(self-signed), and already supports CT via the existing CAs. CT is
already a centralised model, so your allergic reaction to public CAs
while seeking mandatory CT is puzzling. Perhaps you can explain on
ACME, or perhaps the (mostly inactive) d...@ietf.org list.
With a PKIX-EE(1) server key "pin", no CA can unilaterally convince a
DANE-enabled client that a misissued certificate is valid. If the
client requires PKIX-EE(1) and does not support DANE-EE(3), then
just compromising DNSSEC is also ineffective.
Of course this is also the most operationally fragile model, offering
two ways to have an outage. I don't see it gaining much popularity,
but you can try to convince people otherwise.
Good luck.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
