I am quite familiar with the ROC but am not a QSA.
PCI definition of strong cryptography make references to choosing your own standard and follow that, for example; if I followed NIST i.e. TLS as specified by Special Publication 800-57 Part 1 section 5.6.2 and I don't choose RSA and only use Diffie-Hellman key exchanges then keys smaller than 2048 bits do not meet the PCI DSS requirements?
That is an interpretation narrowly focused on weak public key bits, what about all of the other aspects of a TLS connection that may be considered problematic? Just look at the SSL Labs reports for an example of how long this list may be.
Also what about using mTLS, is not using mTLS for TLS connections where both endpoints are within your control considered problematic? I would assume it is.
And then there's the nuance related to client certificates; how should client certificate issuers be determined, which trust anchor should be used (device trust stores are for determining trust anchors of the server certificate chain), do clients need to adhere to the server's indication/list of acceptable client certificate subjects (some issuer subject's have no CN e.g. Amazon ACM so shouldn't issuer matching be based on Issuer SKI == Cert AKI??), shouldn't the client be skeptical of the server endpoint authenticity also and validate the security posture/expectations of the server handshake?
These are only 4 client certificate thoughts off the top of my head, there are plenty more I'm sure of it.
My question to be concise is; is there any authoritative source, specifically a framework/standard that meets the PCI requirement of something that can be followed for your implementation, of all the TLS security considerations and the secure configurations for both client and server endpoints?
I've searched NIST and found some useful scattered references, OWASP has limited also scattered hints, SAFECode and CIS are sparse in this area, ISF is completely useless (and costs way too much for it's value). I'm not sure where else to look.