Thanks, I appreciate a response with some substance.
> name constraints with multiple prospective paths
Can you expand on this for me? Is this really a problem?
> longer-live[d] certificates than the CA/B guidelines permit
The iCA cert would only be valid for 90 days (or less, they could make it 30 or 15 days). Would a cert be valid if the iCA cert that issued it is expired?
> known insecure algorithm choices
Disallow bad algorithms by policy. Evidence of issuance using a bad algorithm gets the iCA revoked and the ACME account locked out. Many clients don't allow insecure algorithms by their own policy.
If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?
> Can you expand on this for me? Is this really a problem?
Sure, happy to: the issue here is that the user’s root might present multiple prospective validation paths, none of which have to agree on the total constructed set of permitted/denied name constraint subtrees. Path validation also doesn’t impose an order, meaning that two clients can (correctly!) disagree on the set of names that a validation path can issue.
Is it really a problem? Maybe: the various Web/Internet PKI standards aren’t clear about how to handle situations like this, and things that change the Web PKI to rely more heavily on correct extension handling have historically revealed lots of fragile/noncomplying clients.
> Would a cert be valid if the iCA cert that issued it is expired?
Nope, I made a mistake here: this wouldn’t be an issue, for the reason you’ve said.
(Having an ICA that expires every 90 days would impose other logistical challenges, however: you’d either need to include it in the server response along with the leaf, or lean heavily on an extension like AIA to retrieve the current ICA certificate.)
> If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?
Probably no worse for the private network scenario, although I think the proposed solution here ends up confounding the public and private cases: the certs issued under a NC’d ICA would also be valid on the public Internet, and may end up intentionally or unintentionally depending on this behavior.
If I had to TL;DR my opinion here, I think it would be: “all of these things are solvable or addressable at the policy level, but the Web PKI has historically been brittle to assumptions that currently standardized things are correctly respected by the client ecosystem” :-)
> name constraints with multiple prospective paths
Can you expand on this for me? Is this really a problem?
> longer-live[d] certificates than the CA/B guidelines permit
The iCA cert would only be valid for 90 days (or less, they could make it 30 or 15 days). Would a cert be valid if the iCA cert that issued it is expired?
> known insecure algorithm choices
Disallow bad algorithms by policy. Evidence of issuance using a bad algorithm gets the iCA revoked and the ACME account locked out. Many clients don't allow insecure algorithms by their own policy.
If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?