On 9/8/2021 10:18 μ.μ., Ryan Sleevi wrote:
On Mon, Aug 9, 2021 at 1:25 PM Dimitris Zacharopoulos
<[email protected] <mailto:[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?
Not quite, we first ensured that the sending agent did not add the
cross-certificate in the certificate chain, which we knew it would make
it impossible for the receiving agent to successfully validate the
chain, and then "hoped" for AIA fetching to occur.
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.
We constructed the "(new leaf) <- (new intermediate) <- (new root) <-
(old root)".
The test here is:
- Sending agent sends certificate bundle that contains their cert,
intermediate, and new-signed-by-old
This is where the sending mail agents fail. As explained in the test, TB
and Outlook do not have a way to "inject" the cross-certificate in the
chain, therefore the default behavior is to only send (new leaf) <- (new
intermediate).
If the cross-certificate is included in the chain, the receiving agents
successfully validate the chain. In order to do that, the sender must
manually delete the (new root) from the local trust store so the sending
agent can build a path to the (old root), using the cross-certificate,
but that's not something we want to enourage.
I hope this makes things a bit clearer.
Thanks,
Dimitris.
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/c0928cfe-85e6-0e27-de96-1654349f8744%40it.auth.gr.
