X.509 has a feature called constraints, where you say e.g. "This is a CA but it must only issue for names under .foo.example" or "This is a CA but it can only issue for S/MIME" and to make these effective you set a bitflag that means "If you are parsing this certificate and you don't understand this part, the certificate is invalid for you".
The consequence of that second element is that clients which don't understand the constraint (and thus wouldn't know which are or are not trustworthy leafs under the constrained intermediate) mustn't trust the intermediate at all. This means if you need those clients you cannot use the constraints they don't understand, because they'll reject your entire intermediate.
Mozilla defines constrained as it pertains to the problems they care about, so for example they do not consider a CA constrained if it lacks a constraint they require.
For your use-case there are two practical options:
1. Most suitable for commercial projects e.g. you're a startup selling a new IoT device. Talk to a commercial CA and work out a deal where you get what you need. Outfits like Sectigo strike deals like this all the time. They understand that you don't want to pay high prices per certificate for this problem, but on the other hand you may be able to guarantee minimum volume and that means it makes commercial sense compared to piecemeal orders.
2. For a hobby project talk to Let's Encrypt about getting an exemption to the rate limit for your specific application, or, if it fact the devices are owned by third parties, whether this should be on the Public Suffix List and thus exempt from rate limits anyway. (the PSL also means these devices can't share HTTP cookies among each other, which might well be exactly what you wanted anyway).
The consequence of that second element is that clients which don't understand the constraint (and thus wouldn't know which are or are not trustworthy leafs under the constrained intermediate) mustn't trust the intermediate at all. This means if you need those clients you cannot use the constraints they don't understand, because they'll reject your entire intermediate.
Mozilla defines constrained as it pertains to the problems they care about, so for example they do not consider a CA constrained if it lacks a constraint they require.
For your use-case there are two practical options:
1. Most suitable for commercial projects e.g. you're a startup selling a new IoT device. Talk to a commercial CA and work out a deal where you get what you need. Outfits like Sectigo strike deals like this all the time. They understand that you don't want to pay high prices per certificate for this problem, but on the other hand you may be able to guarantee minimum volume and that means it makes commercial sense compared to piecemeal orders.
2. For a hobby project talk to Let's Encrypt about getting an exemption to the rate limit for your specific application, or, if it fact the devices are owned by third parties, whether this should be on the Public Suffix List and thus exempt from rate limits anyway. (the PSL also means these devices can't share HTTP cookies among each other, which might well be exactly what you wanted anyway).