it’s not only OCSP i’m afraid, CA providers publish CRL as well which UAs usually respect, and there are blacklisted certs distributed by OS vendor. i dont know how DC’s TLS implementation handles/ignores CRLs or blacklisted certs exactly but once i set up
https://autoconfig.<domain>, it must conform all TLS clients: DC, Thunderbird, and browsers too, since I can not distinguish clients before TLS handshake. (well, one can employ more https configs but at most 2: one for
autoconfig.<domain>/mail/… and one for
<domain>/.well-known/… – but this is a hack even at my standards ) . Cross-signed certs may help – thanks for the hint.
i’m a bit disagree: it is not neccessarily always first use - say you setup a@domain, then b@domain later on, then c@domain… in this case
<domain>'s cert (or the issuer’s cert) might be remembered. if this theoretical TLS-TOFU model would work on the OS level, then it’d be more protective (ie. you visit a website earlier on this domain). indeed, it’s less useful if each particular app does it on its own, rather than managing user-approved cert issuers system-wide.
on the other hand, i agree that compromised TLS-TOFU impacts more seriously than Autocrypt-TOFU.
config by DNS-SRV
good to see that there was an initiative for it. i agree that an extra “is-subdomain?” check would be overrestrictive.
sorry for the many off-topics, i’m happy to get involved in DC.