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.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
