3 ms·

Yes, this has been done a few times in the past. It's unfortunate that "distrust after X date" and "distrust now" are the only penalties that currently exist b

by wolrah 2y ago

Yes, this has been done a few times in the past. It's unfortunate that "distrust after X date" and "distrust now" are the only penalties that currently exist but that's the reality of the current PKI world. There are a lot of efforts to get name constraints widely supported, so a given CA can only issue for certain TLDs or even domains, but it's still not there. That could be a viable punishment for misbehaving CAs in the future, or even an intentionally chosen restriction for CAs that want less strict requirements. Government CAs could be a very useful application, if a CA cert could be name constrained to only issue for .gov.cctld at that point we could basically just let them do whatever they want without concern. Likewise for any small regional CAs, if they could be limited to only regional TLDs their blast radius is reduced which also could mean less strict requirements than those applied to CAs able to sign for .com.

thayne 2y ago
It would also be really useful if I could add a "root" CA for my employer's private CA to sign certificates for say .internal or .example.com, but not allow them to sign certs for any arbitrary domain. There's decent support for constraints on intermediate certs, but then you have to trust the root won't ever be used to sign unconstrained intermediates. It would also be useful for localhost. Create a private CA that is constrained to localhost and *.local, and you don't have to worry about it being used to MitM other sites if it gets compromised.
- wolrah 2y ago
  I 100% agree, and I also think it'd be a better solution than wildcard certs in most cases where they're used. I would love to be able to have a personal CA cert that was name constrained to mydomain.tld for the duration of my registration of that domain which I could then use to issue certs for subdomain.mydomain.tld for individual services instead of having to have one *.mydomain.tld which hypothetically might allow a single compromised service to be turned in to the ability to impersonate any of my services. Obviously having a glut of new private CAs would cause scalability issues for CT logs that are already having issues keeping up with current uses, perhaps CT requirements could be reduced for such single-domain CAs in combination with limited lifetimes.

by wolrah 2y ago

thayne 2y ago

It would also be really useful if I could add a "root" CA for my employer's private CA to sign certificates for say .internal or .example.com, but not allow them to sign certs for any arbitrary domain. There's decent support for constraints on intermediate certs, but then you have to trust the root won't ever be used to sign unconstrained intermediates. It would also be useful for localhost. Create a private CA that is constrained to localhost and *.local, and you don't have to worry about it being used to MitM other sites if it gets compromised.

wolrah 2y ago
I 100% agree, and I also think it'd be a better solution than wildcard certs in most cases where they're used. I would love to be able to have a personal CA cert that was name constrained to mydomain.tld for the duration of my registration of that domain which I could then use to issue certs for subdomain.mydomain.tld for individual services instead of having to have one *.mydomain.tld which hypothetically might allow a single compromised service to be turned in to the ability to impersonate any of my services. Obviously having a glut of new private CAs would cause scalability issues for CT logs that are already having issues keeping up with current uses, perhaps CT requirements could be reduced for such single-domain CAs in combination with limited lifetimes.