5 ms·

While I admit I don't know all the rules that govern CAs, can you name one that would be at issue here? I would presume that, at the time you're issuing the nam

While I admit I don't know all the rules that govern CAs, can you name one that would be at issue here? I would presume that, at the time you're issuing the name-constrained CA certificate, you would issue a challenge to prove ownership of the domain, much as you would for a non-CA cert. Why would that not suffice?

tialaramex 8y ago
The "proof of ownership" needs to be fresh enough for each leaf issuance. It's not permitted to just check you have example.com in 2015 and then keep issuing you certificates for the next ten years for names under example.com But that's not a huge obstacle, account based issuance exists today in the corporate space, some tech person proves control every so often and as long as they keep that up to date all other account users get certs whenever they want. It's the other rules that we don't trust you to enforce once given your own subCA. 1. Lifetime is an easy example. Having checked you own example.com the maximum longevity for a leaf certificate is 825 days. A subCA that itself only lasts 825 days would be kind of annoying (you'd need to replace it say once per year, then swap all your issuance to the new one each time), so presumably you're going to want it to last longer, whereupon nothing prevents you using it to issue yourself leaf certs that last longer even though that's forbidden. 2. Key checks are another rule for lead certificates that the root CA is supposed to check but if you have physical control how can they? If you ask Let's Encrypt for a certificate for your Debian weak key because you forgot that the archaic Debian system you were trying to certify has a broken OpenSSL install out of the box it will just refuse. That key is no good. But how can the root be sure you run such checks every time on your own subCA ? 3. Or how about compatibility. The trust stores and the Baseline Requirements both say only to issue specific types of certificates, e.g. no SHA1 for security reason, but also no SHA3 because their software doesn't grok that yet. Or equally No putting arbitrary EKUs in certificates without explaining why. Rules like this also can't be enforced on the subCA.
- deathanatos 8y ago
  Interesting, and thanks for taking the time to detail all that; I agree now that it is not exactly straight-forward. Regarding 1: that's interesting. I guess I figure that part of validation should be to check that the expiry of a cert is within the expiry of the issuing CA certificate. But if this is an issue… what prevents CAs from doing this today, and if it's just "good behavior", why not codify this in the validation rules? (That is, any certificate can't expiry after the expiry of the certificate above it in the chain?) Regarding 2 & 3… is not saying "it's the responsibility of the domain owner" not sufficient? Issuing poor keys only hurts them (and perhaps those who want to communicate with them, which that might be an issue). (I agree that this isn't a great response, and it would be better for the world as a whole if we got these checked, but is it really our job to force domain owners to do this? Also, IDK if I really trust that major CAs are doing a good job of checking these sorts of things given all the other issues we see with them.) SHA1 is going to be ignored by user agents soon (already?), so a subCA won't issue those solely b/c they won't work. What's wrong with a subCA adopting SHA3 sooner than major CAs? (Given how long the switch off of SHA1 took … that seems like a plus?)
  - tialaramex 8y ago
    You seem very focused on the approach of just putting all the work in clients to detect things that are a problem and reject/ ignore them. But we do not like this because it's only ever one mistake away from no prevention at all and you can't tell by looking. Better then to reject this whole "Let's give subCAs to random people to save them some work" approach altogether. Can you trust that major CAs are doing a good job? Well, if you suspect that they aren't all the data is there to go look for yourself, please report anything untoward that you find to m.d.s.policy and/or the issuer. For the final point - the problem is compatibility. We do not want to create myriad non-interoperable systems, that's why "the Internet" won in the first place. If not for the grave security problems with SHA1 (demonstrated collision for a relatively affordable sum of money) we'd be using that forever, even though newer hashes are nicer. SHA3 in particular might never go anywhere. Its design (a sponge not another Merkle–Damgård construction like MD4, MD5, SHA1 and SHA2) has appealing properties such as preventing length extension attacks, but you can get many similar benefits from things like SHA512/256 (run SHA-512 but throw away bits to keep only 256 of them). https://www.imperialviolet.org/2017/05/31/skipsha3.html https://www.imperialviolet.org/2017/05/31/skipsha3.html

tialaramex 8y ago

The "proof of ownership" needs to be fresh enough for each leaf issuance. It's not permitted to just check you have example.com in 2015 and then keep issuing you certificates for the next ten years for names under example.com But that's not a huge obstacle, account based issuance exists today in the corporate space, some tech person proves control every so often and as long as they keep that up to date all other account users get certs whenever they want. It's the other rules that we don't trust you to enforce once given your own subCA. 1. Lifetime is an easy example. Having checked you own example.com the maximum longevity for a leaf certificate is 825 days. A subCA that itself only lasts 825 days would be kind of annoying (you'd need to replace it say once per year, then swap all your issuance to the new one each time), so presumably you're going to want it to last longer, whereupon nothing prevents you using it to issue yourself leaf certs that last longer even though that's forbidden. 2. Key checks are another rule for lead certificates that the root CA is supposed to check but if you have physical control how can they? If you ask Let's Encrypt for a certificate for your Debian weak key because you forgot that the archaic Debian system you were trying to certify has a broken OpenSSL install out of the box it will just refuse. That key is no good. But how can the root be sure you run such checks every time on your own subCA ? 3. Or how about compatibility. The trust stores and the Baseline Requirements both say only to issue specific types of certificates, e.g. no SHA1 for security reason, but also no SHA3 because their software doesn't grok that yet. Or equally No putting arbitrary EKUs in certificates without explaining why. Rules like this also can't be enforced on the subCA.

deathanatos 8y ago
Interesting, and thanks for taking the time to detail all that; I agree now that it is not exactly straight-forward. Regarding 1: that's interesting. I guess I figure that part of validation should be to check that the expiry of a cert is within the expiry of the issuing CA certificate. But if this is an issue… what prevents CAs from doing this today, and if it's just "good behavior", why not codify this in the validation rules? (That is, any certificate can't expiry after the expiry of the certificate above it in the chain?) Regarding 2 & 3… is not saying "it's the responsibility of the domain owner" not sufficient? Issuing poor keys only hurts them (and perhaps those who want to communicate with them, which that might be an issue). (I agree that this isn't a great response, and it would be better for the world as a whole if we got these checked, but is it really our job to force domain owners to do this? Also, IDK if I really trust that major CAs are doing a good job of checking these sorts of things given all the other issues we see with them.) SHA1 is going to be ignored by user agents soon (already?), so a subCA won't issue those solely b/c they won't work. What's wrong with a subCA adopting SHA3 sooner than major CAs? (Given how long the switch off of SHA1 took … that seems like a plus?)
- tialaramex 8y ago
  You seem very focused on the approach of just putting all the work in clients to detect things that are a problem and reject/ ignore them. But we do not like this because it's only ever one mistake away from no prevention at all and you can't tell by looking. Better then to reject this whole "Let's give subCAs to random people to save them some work" approach altogether. Can you trust that major CAs are doing a good job? Well, if you suspect that they aren't all the data is there to go look for yourself, please report anything untoward that you find to m.d.s.policy and/or the issuer. For the final point - the problem is compatibility. We do not want to create myriad non-interoperable systems, that's why "the Internet" won in the first place. If not for the grave security problems with SHA1 (demonstrated collision for a relatively affordable sum of money) we'd be using that forever, even though newer hashes are nicer. SHA3 in particular might never go anywhere. Its design (a sponge not another Merkle–Damgård construction like MD4, MD5, SHA1 and SHA2) has appealing properties such as preventing length extension attacks, but you can get many similar benefits from things like SHA512/256 (run SHA-512 but throw away bits to keep only 256 of them). https://www.imperialviolet.org/2017/05/31/skipsha3.html https://www.imperialviolet.org/2017/05/31/skipsha3.html