[Standards] Danish chains too short

Dave Cridland dave at cridland.net
Sun Jan 30 16:38:22 UTC 2022


Hi all,

XMPP servers typically do not include the trust anchor in the X.509 chains
they present to peers during TLS negotiation. This is broadly in line with
advice given in https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2,
where it notes that a certificate representing a trust anchor MAY be
omitted if it is known to the peer. In the typical PKIX world this is a
safe assumption - CAs are known to the peer, and if they're not, nothing
works anyway.

This does not, however, apply in the DANE-TA case (ie,
TrustAnchorAssertion). In this case, the trust anchor can be entirely
unknown to the peer except via the TLSA record (or, in Metre's case, a
synthetic record). Metre struggles even when the record includes the
FullCert data, which we could inject as a trust anchor prior to certificate
verification, but this would not be an option at all with matches based on
hashed or just the SubjectPublicKeyInfo.

Therefore, where servers construct the chain themselves (I'm thinking
ejabberd certainly, but possibly others), I think we should ensure the full
chain - including the trust anchor - is provided by default. This need not
be the case when the trust anchor is known to be known - for example, if
the peer is known to share the trust anchor, or if the trust anchor is
known to be a public CA (I'm thinking built-in ACME support).

But the default choice to maximize interop should be to include the trust
anchor.

1) Do people agree?

2) If so, where on earth should we specify this? (A Best Practice doc on
PKIX/DANE?)

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220130/ac71886e/attachment.html>


More information about the Standards mailing list