On Thu, 17 Nov 2016 09:28:43 -1000 Brian Smith <br...@briansmith.org> wrote:
> 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. I see the appeal of this. However, I'm concerned that allowing leniency with name-constrained TCSCs will make it hard for Mozilla to make security improvements to its certificate validation in the future. Improvements like rejecting SHA-1, 1024-bit RSA keys, and certificates valid for more than 39 months were only possible because CAs were first made to stop issuing these types of certificates. If policies are not enforced on the issuance of certificates from TCSCs, how will Mozilla make these types of changes in the future without causing massive breakage? Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
