Hi Ryan You seem to only focus on how the recipient email application will validate a certificate chain it receives. Do you disagree that it is important how the sending email application chooses what chain it will put in the message?
In TLS, most servers will send the chain exactly as you configured it, so it might be less relevant for TLS. Though the discussion here indicate that it can also be relevant for TLS: https://community.letsencrypt.org/t/potential-problem-with-r3-intermediates-on-windows-servers/157164 Den man. 9. aug. 2021 kl. 21.18 skrev Ryan Sleevi <[email protected]>: > > > On Mon, Aug 9, 2021 at 1:25 PM Dimitris Zacharopoulos <[email protected]> > wrote: > >> >> >> On 14/5/2021 2:58 π.μ., Ryan Sleevi wrote: >> >> >> >>> - >>> >>> Cross-certification adds another certificate to the chain, which is >>> sometimes difficult for customers to configure, and S/MIME clients do not >>> process cross certificates very well. >>> - >>> >>> Mozilla should distinguish between root CAs supporting serverAuth >>> certificates vs. S/MIME certificates, and Mozilla should keep the email >>> trust bit and remove the websites trust bit to help bridge the >>> transition. >>> >>> >> These are somewhat reasonable, although the statement about S/MIME >> clients is one that demands evidence, and is a little suspect based on the >> major implementations I've examined in the past. Supported with concrete >> data, it might be reasonable to treat a TLS transition independent of an >> S/MIME transition. >> >> >> We were able to reproduce and confirm past findings on this issue >> regarding the S/MIME agents not using cross-certificates in the chain. >> >> Our tests were performed using Thunderbird as sending agent and >> TB/Outlook as receiving agents. >> >> Sending agent trusted old and new Root and included the cross-certificate >> in local certificate store. >> >> The signed email contained only the Intermediate Certificate that chains >> to the new Root. There was no way to "dictate" TB to include the >> cross-certificate in the signature. >> >> The receiving agents trusted only the old Root. >> >> The receiving agents did not attempt to follow the AIA CAIssuers URI in >> order to get the cross-certificate, therefore the path validation failed >> and the signature was marked invalid. >> > > Thanks. This, at least, is a little more concrete as to what you meant by > "do not process well" - it seems what you were actually testing here is > whether or not AIA fetching occurs, correct? > > It's certainly not unexpected that Thunderbird does not do AIA chasing, > especially since Firefox does not. At a minimum, the Thunderbird behaviour > will be affected by what path builder it's using (which depends on which > NSS version as well as the build flags for your distribution - e.g. if it's > Mozilla-provided Thunderbird vs a distro-provided version), but even there, > I suspect Thunderbird-proper hasn't wired up AIA. It should, however, > properly handle the scenario where sender sends both, as well as paths that > chain to "new certified by old". > > It's unclear, however, from your description on your test methodology for > the certificate chain. It sounds like you did "(new leaf) <- (new > intermediate)" as the actual message contents, but it's unclear if you > constructed a chain "(new leaf) <- (new intermediate) <- (new root) <- (old > root)" or a chain of "(new leaf) <- (new intermediate) <- (new root), (new > leaf) <- (old intermediate) <- (old root)", the latter of which is expected > to be problematic. > > The test here is: > - Sending agent sends certificate bundle that contains their cert, > intermediate, and new-signed-by-old > > That should work. Outlook's calls through WinVerifyTrust/CAPI will handle > that, as should Thunderbird, provided the notBefore/notAfter dates are set > appropriately for (new root signed by old root). > > Maybe I'm further misunderstanding what you're meaning though by "do not > process cross certificates well", but it seems this was a test methodology > issue more than anything? > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHHpnzu2OWdPZ_9535Z0tiztgXMnn3%2BBqVKQA4fr%3DxqNng%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHHpnzu2OWdPZ_9535Z0tiztgXMnn3%2BBqVKQA4fr%3DxqNng%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACAF_Wj%3Df9BWS8QEjQXyd%2Boeu_U9NeL64bmzeW3Yq-mi7eMpag%40mail.gmail.com.
