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.
