3 ms·

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

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

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