On Sat, Oct 10, 2026 at 4:50 AM Jasper Spaans via mailop <[email protected]> wrote:
> I'm assuming Kurt was trying to find out whether "real" CAs are willing to > hand out CA certificates with a name constraint > (https://www.rfc-editor.org/info/rfc5280/#section-4.2.1.10 ) to third parties. > It would be very nice to have something like that. Maybe letsencrypt or a I'm pretty sure the answer no. Also Letsencrypt is a browser CA not a S/MIME CA. Each CA is made for a purpose. A code signing CA does not sign Browser/TLS server certs. A Browser CA does not sign client auth certificates. Etc. The web browser trusted root programs set rules that generally prevent their CAs signing authorities used to sign a chain that issue other kinds of certificates, and there's a lack of policies permitting name constraints as a substitute for individual confirmation of every end certificate. For the possibility to exist; you need not just the technical function to exist, but also the authorization or policies in the respective root programs granting approval to the scenario. A CA admitted to various root programs would likely not be allowed to have a CSP permitting that CA to sign a certificate granting certificatesigning authority using a secret key outside the exclusive control of that same CA. That same certificate authority would have to retain exclusive custody of any sub-CA's signing keys. At that point they could have an API granting signing access through a sub-CA controlled by the main CA after validation requirements are met, but it would be practically the same as issuing certificates from that CA's intermediates. A CA is responsible to make certain that proper authority over every subject name appearing on a trusted certificate is validated, and in addition, they have to account for every certificate issued and ensure that it gets logged with its validity dates. Maintaining the proper certificate issuance logging would be impossible if an external parties was granted signing keys for "their" sub-CA. Mozilla, etc, require regular independent security audits of CAs. If you could get a certificate signed without proper verification, then the CA would be in violation. The existence of a name constraint doesn't prevent a 3rd party from signing certificates that violate the constraint or attempting to craft unusual certs to attack software bugs that may exist within some implementations. What you can do is either use a private CA for S/MIME, or find a commercial S/MIME CA, and seek a plan from the certificate provider where they would include a pre-agreed number of certificates as part of a service plan... > Jasper -- -JA _______________________________________________ mailop mailing list -- [email protected] To unsubscribe send an email to [email protected]
