3 ms·

"[...] we will begin to also require disclosure of intermediate certificates that are capable of issuing websites (TLS/SSL) or email (S/MIME) certificates even

by pas 5y ago

"[...] we will begin to also require disclosure of intermediate certificates that are capable of issuing websites (TLS/SSL) or email (S/MIME) certificates even when they are technically constrained." tl;dr all interCAs have to be reported (right? or am I missing something?)

floatingatoll 5y ago
I haven’t researched this fully yet, but I believe that this is a nuance of x509 and certificate purposes. If the intermediate is granted the permission “issue website/email cert” at the lowest x509 level, then it apparently (TIL) used to be possible to layer in higher-level constraints in order to disable that so as not to disclose it — but when these rules take effect, that kind of exception will no longer be accepted, since intermediates that won’t be issuing web/email certificates shouldn’t be issued with x509 properties that say “I can issue web/email certificates” anyways.
tialaramex 5y ago
Previously, Mozilla's requirement to be informed of intermediate CAs explicitly did not include "technically constrained" CAs. "Technically constrained" refers to properties of the signed CA certificate which would cause a correct PKIX implementation to either reject the certificate (because they know they don't understand something important about it) or obey some restriction when trusting it, a constraint on how it can be used. In particular constraints are used to say things like "This intermediate must only issue for names ending in .famous.example" or "This intermediate may not issue for names ending in .different.example". In practice we also use the X.509 Extended Key Usage fields of CA certificates as constraints, even though probably we shouldn't that's settled practice and can't realistically be fixed now. So, if the intermediate's certificate has an EKU saying its key has "Any Use" the interpretation today is that it can be used to sign other certificates with any use. After the policy change, most intermediate CAs will need to be disclosed. But, an intermediate that can't be used to issue working certificates in the Web PKI or for S/MIME could still exist under these rules. For example if you have ended up with some legacy system that needs a CA primarily used in the Web PKI but you're doing SpecialThing with it, in principle a subCA under that CA constrained by an EKU saying only SpecialThing usage is allowed, would still not need to be disclosed since it can't cause harm: A "real" SpecialThing certificate isn't a TLS certificate, and bad guys who subvert the SpecialThing intermediate can't issue working TLS certificates either. Mozilla primarily cares about Firefox users, so, they don't need to care that in theory your badly designed TLS client might not check EKUs, Firefox does.

by pas 5y ago

floatingatoll 5y ago

I haven’t researched this fully yet, but I believe that this is a nuance of x509 and certificate purposes. If the intermediate is granted the permission “issue website/email cert” at the lowest x509 level, then it apparently (TIL) used to be possible to layer in higher-level constraints in order to disable that so as not to disclose it — but when these rules take effect, that kind of exception will no longer be accepted, since intermediates that won’t be issuing web/email certificates shouldn’t be issued with x509 properties that say “I can issue web/email certificates” anyways.

tialaramex 5y ago

Previously, Mozilla's requirement to be informed of intermediate CAs explicitly did not include "technically constrained" CAs. "Technically constrained" refers to properties of the signed CA certificate which would cause a correct PKIX implementation to either reject the certificate (because they know they don't understand something important about it) or obey some restriction when trusting it, a constraint on how it can be used. In particular constraints are used to say things like "This intermediate must only issue for names ending in .famous.example" or "This intermediate may not issue for names ending in .different.example". In practice we also use the X.509 Extended Key Usage fields of CA certificates as constraints, even though probably we shouldn't that's settled practice and can't realistically be fixed now. So, if the intermediate's certificate has an EKU saying its key has "Any Use" the interpretation today is that it can be used to sign other certificates with any use. After the policy change, most intermediate CAs will need to be disclosed. But, an intermediate that can't be used to issue working certificates in the Web PKI or for S/MIME could still exist under these rules. For example if you have ended up with some legacy system that needs a CA primarily used in the Web PKI but you're doing SpecialThing with it, in principle a subCA under that CA constrained by an EKU saying only SpecialThing usage is allowed, would still not need to be disclosed since it can't cause harm: A "real" SpecialThing certificate isn't a TLS certificate, and bad guys who subvert the SpecialThing intermediate can't issue working TLS certificates either. Mozilla primarily cares about Firefox users, so, they don't need to care that in theory your badly designed TLS client might not check EKUs, Firefox does.