Sign me as an Intermediate CA for my Domain with Name Constraint?

[ecdsa-chacha20]

Thanks for your answers.

@pfg

One of the problems with name constraints today is that they're not supported across all platforms, for example on Apple devices.

Sure. If I’d go for that path I’d have to live with this hopefully time-limited limitation. Any news on Apple’s progress on supporting that feature?

@pfg

This leads to the following problem: In order to protect all platforms against misissued certificates from name constrained intermediates, the name constraint extension would have to be marked critical. This would tell TLS clients that do not implement this extension to fail.

Yes, I pointed that limitation to a critical extension in my opening post. Anything else is obviously dangerous.

@tialaramex

By the way even with the name constraint the parent CA will probably feel (and may even legally be) obliged to check you're behaving properly, and they typically do that by requiring all the infrastructure for your CA lives in their data centres not yours, so they can run their own audit trail and do their own logging. That's another reason Let's Encrypt wouldn't want to get into this game - it will be expensive to do it.

What’s the reason for this step? If my CA issues bad certificates for whichever reason, they can only be for my own domain, so that should be solely my problem, shouldn’t it?

@pfg

I believe CAs that offer constrained intermediate certificates to their customers usually keep the private key, unless they're cross-sign for another CA (such as IdenTrust signing Let's Encrypt's intermediate certificate). I'm not quite sure if the Baseline Requirements allow for this kind of setup without obligating you to essentially run your own CA (as in: get audited, etc.) The existing contracts with IdenTrust might also prevent this from happening (at least with regards to the IdenTrust cross-signed intermediate; this would not affect the ISRG root).

So it’s just a contractual/legal topic then? For which reason? I can already issue certificates for random domains, they are just not valid for one or the other reason, so nobody should trust them. If I’d be allowed to create certificates for my domain, why should that require more scrutiny if I can only shoot myself into the foot?

Are there other technical topics than the Apple etc. feature support topic? Perhaps browser developers planning to enforce certificates must be on a CT chain which might not want to trust my –non-audited– Signing CA’s chain update posts?

Furthermore, this feature could be combined with other features, namely OCSP Must Staple RFC 7633 - X.509v3 Transport Layer Security (TLS) Feature Extension for the Signing CA certificate: Just as with disclosed keys for host certificates, OCSP Stapling could manage to get rid of detected misuse in relatively short time.

So, other than ‘no sufficient support for it in browsers’ and rules that have not been updated to reflect the possibilities of the freedom if correctly used, and perhaps business topics of even more angry CAs losing money, I only see benefits of this approach: I would have full freedom of my domain by creating certificates as I like, would stop eating up public Signing CA resources for each certificate, and if something goes wrong it’s just my fault.