I want trusted SMIME certificates for 3rd parties. Is this a reasonable configuration?

Question

I want to send out SMIME certificates with my emails, and want to deploy the following PKI

Root01  (All EKU, All Constrants, No Restrictions)

PolicyInt01 (Internal applications, not trusted by 3rd parties...)
PolicyExt01 (Name constraints = domain.com, EKU=Message signing) 

IssueExt01 (Issues certificates for PolicyExt01)

My intent is to ask external parties to trust PolicyExt01 and add that to the trusted root store. Since it is constrained, and limited in use, I think that most intelligent 3rd parties wouldn't have an issue with this.

Question

• Is this an acceptable configuration for deploying trusted SMIME certs outside our organisation?

• What changes would you make in order for you, yourself as a security admin, to this process?

• Is there any risk of this certificate pkipolext01 cross-signing/chaining another certificate, causing unexpected escalation of rights? (name constraints/EKU)

Answer 1

I would recommend using a completely separate root for the external and internal certificates, to prevent any information leak about internal hosts or users, through Root01, but also prevent any implicit trust by broken software. By using 2 separate root for external and internal use, theres no possible for any trust to leak from External to Internal certificates, regardless how broken the software is.

Normally, if we have certification paths that looks like this:

Root01 --> SubCA01 -> Cert01
Root01 --> SubCA02 -> Cert02

And SubCA02 is imported as trusted. In a valid PKI implementation, Cert01 should not be trusted. But as you know with lazy coding, broken software, and hacky parsing of certificates, theres is possible for trust to leak over from subCA02 to Root01 and thus leaking over causing Cert01 to be trusted by someone that shouldn't trust that cert, if the PKI implementation is very broken and, for example assumes any higher cert as trusted automatically. Yes its far fetched, but better account for any broken software by using completely separate roots instead.

I would also add a PathLength=0 Basic constraint, preventing the CA certificate from being used to sign other CA certificates, in addition to the name constraint.

As you might know, there is lots of broken software out there, and a privilegie escalation attack (as you call it when someone manages to sign a certificate in violation with the constraints) can happen, for example if the said PolicyExt01 certificate is used to sign a subordinate CA, that in turn is signing a S/MIME certificate.

Some broken software only checks for example naming constraints "1 level Deep", and adding a Pathlength constraint would then cause longer chains to fail instead of being accepted as trusted.

So I would do like this:

Root01 (Name constraints = Email=@domain.com, PathlenConstraint=0, EKU=Message signing)
Root02 (Internal applications, not trusted by 3rd parties...)

And then sharing Root01 cert with those third parties that should trust it, while installing both Root01 and Root02 in all Company-internal computers.

Both Root01 and Root02 is then self-signed root CA certificates.

When using Namingconstraint, I would only put a Email=@domain.com Naming constraint, and then put every other naming constraints (IP, DNS, UPN, URI) as wildcard excluded, to prevent a certificate from being used as for example a website SSL certificate, if a broken browser or SSL implementation would be unable to parse the key usage flags.

A good idea is also to test your setup, preferable by exporting the root CA certificate and private key to a secure offline computer, and then attempt to sign "invalid" certificates with this. Then test the "invalid" certificates with common client software to ensure the constraints are kicking in and marking the certificate as untrusted.

---

I do not personally know any explicit configuration that would cause such a "privilege escalation" attack, but as you know, theres lots of broken SSL implementations and PKI software out there, so better be safe than sorry and restrict the certificates as much as possible, and also use separate roots to prevent any trust leak between the certificates by VERY broken software.

Answer 2

The purpose of S/MIME certificates is to sign and encrypt email messages. Given your use case, what you are proposing is not appropriate. For email you want recipients to be able to verify email messages without having to download and install your organization's root key. So for email, you really want to use certs issued by a globally recognized S/MIME certificate provider, such as Comodo, VeriSign, or StartCom. You can issue these certificates on-site if you purchase the appropriate system from these providers.

If your relying parties have removed all of their certificates from their root stores, then you can, of course, provide them with your own root certificate and scope it as you have described. However, once again, there is no need to have a separate PKI for internal and external use. It will be nearly impossible to manage, and there is no added security in doing so. Just use a single root.