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
