Could LE new Root allow eventual Name Restricted Sub issuance

I'm not sure how the adoption of Name Constraints has been, but does LE's new Root contribute anything towards a path to name constrained subordinates? Does it give LE complete control over chain length?
It's also been 2 years since the last post I could find about Permitted Subtrees with Name Constraints and 4 since the one that got a statement from LE, I'm curious if anything has changed since as far as BRs restrictions or Name Constraints adoption?

1 Like

You're referring to the Baseline Requirements here I'm guessing? That's something you could check yourself :slight_smile:

I don't think there's any difference between the current ISRG Root X1 (RSA) and the new ISRG Root X2 (ECDSA) when it comes to name constrained subordinates. Why would there?

I'm not familiair with any change, but you can check for yourself:


by the way how hard to run and manage Technically Restrained CA?(assume someone willing to sign one)?
self audit still needed, so it need 3% of certificates zlinted and check against its own CPS, so I guess it still need full size CA software like boulder or EJBCA? or things like CFSSL can make enough log for it? and does it use parent's CA for CAA record? are they need to publish it's leaf certificate to CT logger?


@Osiris, thanks! Google wasn't super helpful in directing me to relevant key words to research more on this.
I brought up the new root because I remember seeing someone mention that the old root was restricted to certain number of subordinates/chain length.

So to summarize what I think the latest spec said at 7.1.5, 8.1, and 8.7 a constrained subordinate CA still has to have at least 3% of its issued certificates manually audited quarterly by its issuing CA without there being any clear way to automate it. Unless there could be a way to automate it to the CABF's satisfaction.


that 3% audit applys to full-ca too, so I guess there is way to automate that, like here. there is no way ISRG hire people to look at 3% of certs