ISRG root keys are in root store but it's only for valify TLS servers, so mail certificate signed by it won't be trusted.
and while that is using acme but protocal path is so different so it will use sapareate key/server instance even if LE choose to implement it.
I don't think this is correct. Looking at the roots @ Chain of Trust - Let's Encrypt it seems the roots don't have the "X509v3 Extended Key Usage" extension set, but the intermediates do.
Therefore, in theory, it would be possible to generate a specific intermediate from the ISRG root certificate(s) with the correct "X509v3 Extended Key Usage" extension specifically for S/MIME purposes.
Hm, interesting, I did not know that. Thanks for the correction!
Does this also apply for other root programs, such as Microsoft (Outlook)? And how easy would it be to change this? It might be easier to make such a change when it isn't necessary to actually modify the root certificate itself.
I bet it'd have to go through a process of ensuring that audits and what-not were all up-to-spec for the usage of email signing in addition to the existing usage of TLS server/client certificates. Kind of like how ISRG Root X2 is in the process of being added to roots, it's probably "easier" than the first time around of a new CA getting added but still needs to be scrutinized. Actually, probably best practice (my guess) would be to have a separate hierarchy entirely for S/MIME and TLS, so if Let's Encrypt wanted to get into doing this they might just make an entirely separate root for it.
I agree that Let's Encrypt offering free S/MIME would be great, but I don't know as it's something they'd be willing to add to their busy plates yet.
...priority is given to ... CAs whose certificates and certificate hierarchy are only used to issue TLS server certificates, and do not issue other forms of certificates.
Mozilla also has a similar recommendation, though not worded as strongly:
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).
Microsoft only has requirements on separate intermediates:
Issuing CA certificates that chain to a participating Root CA must separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. This means that a single Issuing CA must not combine server authentication with S/MIME, code signing or time stamping EKU. A separate intermediate must be used for each use case.