ETA on smaller stick penalty for CA Violations? (paging bsmith)
(please send follow-ups to mozilla.dev.tech.crypto) Brian has in the past discussed proposed updates to NSS that would allow us to penalize bad CA behavior by removing trust of all certs from a given CA that were issued after a given date (or even for X amount of time after a given date). The theory is that this would allow real penalties and user protection for bad CA behavior without breaking the internet. From a moz.dev.sec.policy perspective, this would be a nice tool to have in our belt. However, if we're not going to have it in the relative near term, we need to be taking other policy steps. I've tried to track down Brian's past discussions of this, to no avail. I believe that he talked about it at our panel at USENIX Security last year, but all of the video/audio links from that event seem to be crapping out: http://static.usenix.org/events/sec11/ Brian, any thoughts on this? Is this something we should be holding out for, or should we look to other approaches? Steve -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ETA on smaller stick penalty for CA Violations? (paging bsmith)
On 19/02/12 04:30, Jan Schejbal wrote: A different interesting approach for a punishment could be removal of the ability to create Sub-CAs. This would not put a CA out of business like other solutions, but hurt it and most importantly, remove an extremely risky ability. This could probably be done by removing the root and adding a new, modified cert that has a length constraint (possibly adding all still-allowed CA-owned sub-CAs if they issued Sub-CAs directly from their root). I don't think this would be terribly practical. If the length constraint was 1, then the CA would need to issue all subscriber certs directly off the root - which is a strongly discouraged practice. If the length constraint was 2, then the CA could still issue subordinates. The only way around this would be to add all the CA's existing subordinates to NSS with length constraint 1. However, this would put a significant crimp in the CA's day-to-day operations; creating new subordinates is, as I understand it, something that happens reasonably often (every few months, perhaps), for a diverse number of reasons. If Firefox embeds all the intermediates, the CA suddenly has a ubiquity problem, because if they issued a new one, we could not easily update all older Firefoxes with it, particularly those which are no longer supported. You may say well, giving the CA pain is the point, but it's worth noting that your proposed course of action has significant side-effects. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ETA on smaller stick penalty for CA Violations? (paging bsmith)
On 2/18/12 11:30 PM, Jan Schejbal wrote: Am 2012-02-19 02:46, schrieb Stephen Schultze: Brian, any thoughts on this? Is this something we should be holding out for, or should we look to other approaches? A different interesting approach for a punishment could be removal of the ability to create Sub-CAs. This would not put a CA out of business like other solutions, but hurt it and most importantly, remove an extremely risky ability. This could probably be done by removing the root and adding a new, modified cert that has a length constraint (possibly adding all still-allowed CA-owned sub-CAs if they issued Sub-CAs directly from their root). Yes, but it would also break all existing certs issued by that CA that are in the wild, which is one of the reasons that Mozilla has been so resistant to removing roots in the first place. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ETA on smaller stick penalty for CA Violations? (paging bsmith)
Am 2012-02-20 12:59, schrieb Gervase Markham: I don't think this would be terribly practical. If the length constraint was 1, then the CA would need to issue all subscriber certs directly off the root - which is a strongly discouraged practice. If the length constraint was 2, then the CA could still issue subordinates. I assumed that intermediates change less often than they do, so the legnth constraint approach won't work. The best solution to achieve this would probably be an agreement with the CA that they will not issue any new Sub-CAs at all or that they will issue them only from a specific intermediate that can be blacklisted in Mozilla. If the CA does not want to agree to that (or violates the agreement), the root would have to be removed. Sub-CAs issued before the agreement was made would need to be disclosed (at least by certificate fingerprint/serial) and blacklisted, unless they are supposed to stay valid. This should be doable, as I doubt that a CA issues thousand of Sub-CAs. Kind regards, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention FROM NG in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ETA on smaller stick penalty for CA Violations? (paging bsmith)
On 19.02.2012 02:46, Stephen Schultze wrote: Brian has in the past discussed proposed updates to NSS that would allow us to penalize bad CA behavior by removing trust of all certs from a given CA that were issued after a given date (or even for X amount of time after a given date). Someone needs to implement this idea in NSS, before it can be used. https://bugzilla.mozilla.org/show_bug.cgi?id=643982 Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ETA on smaller stick penalty for CA Violations? (paging bsmith)
On Sat, Feb 18, 2012 at 5:46 PM, Stephen Schultze sjschultze.use...@gmail.com wrote: Brian has in the past discussed proposed updates to NSS that would allow us to penalize bad CA behavior by removing trust of all certs from a given CA that were issued after a given date (or even for X amount of time after a given date). The theory is that this would allow real penalties and user protection for bad CA behavior without breaking the internet. There is a problem here, in that any CA can simply roll back the notBefore time to bypass it. Unless we can get timestamps from a different CA in the same structure, it can't work. Unless we can fit timestamps into the Certificate that is presented, it can't work. From a moz.dev.sec.policy perspective, this would be a nice tool to have in our belt. However, if we're not going to have it in the relative near term, we need to be taking other policy steps. We do indeed. Most of the other steps involve reducing the dependence on the Single CA. Of course, this would require *gasp* changing the security model to something that can support multiple CAs, multiple timestamps, and multiple OCSP responses in a single data structure to put into the Certificate field. This sounds like a job for the Envelope. I'm actively working on this, but the basic idea is: 1) Generate a single new keypair, add the public key to a Pot. 2) Add all the certificates in the (1+) certificate chains you want to assert into the Pot. (This should include several chains from multiple authoritative CAs, plus zero or more chains from local CAs.) 3) Sign the Pot with all of the private keys you own (including the new private key generated for step 1). [This proves that all end-entity authorites (private key holders) chose to bind all of their certificate chains and the new keypair together.] 4) Obtain all the authoritative OCSP responses for all certificates in all certificate chains you want to assert. [This proves that the certificates were acceptable at the Timestamped moment.] 5) Obtain timestamps (more than 1 timestamp, more than 1 digest algorithm, more than 1 authority) of the multiple-signed Pot [This proves that the Pot existed before the timestamps were generated.] 6) Add the SignedPot, the Timestamps, and the OCSP responses to a DER sequence. Add that DER sequence to an Extension, which goes into a new X.509 TBSCertificate structure. 7) Self-sign the TBSCertificate, and install both the self-signed certificate and its private key. The evaluation is set up so that any one (or maybe two) of the certificate chains must correctly verify. In particular, it's set up so that if any one of the trust anchors for any of the chains is distrusted, the remainder will continue to work. This would give an extra bit of extra leeway so that we could effectively shut down the trust of a given CA for a given time period without inconveniencing its pre-existing customers too much, and without forcing those customers to go through another validation process with another CA at an inconvenient moment when they're not thinking of risk management. The evaluation requires either that the evaluator recursively calls itself for the embedded certificate chains, or that PSM pulls the self-signed cert extension apart and calls back to the validator. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ETA on smaller stick penalty for CA Violations? (paging bsmith)
Am 2012-02-19 02:46, schrieb Stephen Schultze: Brian, any thoughts on this? Is this something we should be holding out for, or should we look to other approaches? A different interesting approach for a punishment could be removal of the ability to create Sub-CAs. This would not put a CA out of business like other solutions, but hurt it and most importantly, remove an extremely risky ability. This could probably be done by removing the root and adding a new, modified cert that has a length constraint (possibly adding all still-allowed CA-owned sub-CAs if they issued Sub-CAs directly from their root). Kind regards, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention FROM NG in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ETA on smaller stick penalty for CA Violations? (paging bsmith)
Am 2012-02-19 06:00, schrieb Stephen Schultze: Yes, but it would also break all existing certs issued by that CA that are in the wild, which is one of the reasons that Mozilla has been so resistant to removing roots in the first place. Why? The point was only breaking the certs signed by sub-CAs, which probably aren't that many. Existing certs would chain up to the new cert that is a copy of the old one only with a length constraint added (or to one of the intermediates, which would also be added with a length constraint). In case NSM does check the signature on installed CA certs (which I didn't think it did), this would have to be changed or the certs would need to be signed with a key generated just for this purpose (which, if needed, could be certified and added). Just to make it clear, I do support the original suggestion, this is just an additional one. Kind regards, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention FROM NG in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
