On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi <r...@sleevi.com> wrote:
> As Andrew Ayer points out, currently, CAs are required to ensure TCSCs > comply with the BRs. Non-compliance is misissuance. Does Mozilla share > that view? And is Mozilla willing to surrender the ability to detect > misissuance, in favor of something which clearly doesn't address the > use cases for redaction identified in the CA/Browser Forum and in the > IETF? > I don't agree that a third-party TCSC failing to conform to the BRs should be considered misissuance in every case, when the technical constrain is name constraints. Let's run with an example where I am Example Corp, I own example.com, I want to get a name-constrained CA certificate for example.com and *. example.com. Let's say I screw up something and accidentally issue a certificate from my sub-CA for google.com or addons.mozilla.org. Because of the name constraints, this is a non-issue and shouldn't result in any sanctions on the original root CA or Example Corp. (Note that this means that relying parties need to implement name constraints, as Mozilla products do, and so this should be listed as a prerequisite for using Mozilla's trust anchor list in any non-Mozilla product.) Let's say I issue a SHA-1-signed certificate for credit-card-readers.example.com. Again, that's 100% OK, if unfortunate, because after 2017-1-1 one shouldn't be using Mozilla's trust store in a web browser or similar consumer product if they accept SHA-1-signed certificates. Let's say that the private key for https://www.example.com gets compromised, but I didn't create any revocation structure so I can't revoke the certificate for that key. That's really, really, unfortunate, and that highlights a significant problem with the definition of name-constrained TCSCs now. In particular, it should be required that the name-constrained intermediate be marked using this mechanism https://tools.ietf.org/html/rfc7633#section-4.2.2 in order to be considered technically-constrained. Let's say I issue a malformed certificate that is rejected from my name-constrained intermediate. Again, IMO, we simply shouldn't care too much. The important thing is that implementations don't implement workarounds to accomodate such broken certificates. Let's say I issue a SHA-2 certificate that is valid for 20 years from my name-constrained certificate. Again, that is not good, but it won't matter as long as clients are rejecting certificates that are valid for too long, for whatever definition of "too long" is decided. Why is it so important to be lenient like this for name-constrained TCSC's? One big reason is that HPKP is dangerous to use now. Key pinning is really important, so we should fix it by making it less dangerous. The clearest way to make it safer is to use only pin the public keys of multiple TCSCs, where each public key is in an intermediate issued by multiple CAs. But, basically no CAs are even offering TCSCs using name constraints as the technical constraint, which means that websites can't do this, and so for the most part can't safely use key pinning. Absolving CAs from having to babysit their customers' use of their certificates will make it more practical for them to make this possible. Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
