On Fri, Sep 5, 2014 at 2:43 AM, Gervase Markham <[email protected]> wrote: > On 05/09/14 00:06, Brian Smith wrote: >> Precisely defining a short-lived certificate is a prerequisite for a >> proper discussion of policy for short-lived certificates. It seems >> likely to me that short-lived certificates will be defined as >> certificates that would expire before the longest-acceptable-life OCSP >> response for that certificate would expire. Then it would be easy to >> understand the security properties of short-lived certificates, given >> that we understand the security properties of OCSP. > > I strongly want to avoid ratholing on this discussion; if I say "OK, > let's say for the sake of argument that short-lived is the same as the > max OCSP lifetime", then someone else will say "but that's still too > long!" and so on.
I agree, because the maximum allowed OCSP *is* too long, regardless of whether you want to do short-lived certificates or not. >> Previously, we decided it was important that we have evidence that the >> OCSP responder know about all certificates that were issued by the CA, >> so we made it a requirement that OCSP responders must return not >> return "Good" for certificates that they do not know about. But, >> accepting short-lived certificates is equivalent to an OCSP responder >> returning "Good" for all certificates, whether it knows about them or >> not. > > Is that actually true? I am assuming that if a cert is mis-issued, for a > few minutes at least the CA will stand by their issuance, and that the > attacker can obtain a good OCSP response for it with a lifetime of X, > and staple that response during their attack. So the security properties > of that are about the same as those for a cert with lifetime X. Then what was the value in adding requirement that an OCSP responder cannot return "Good" for an unknown cert to the BRs? We added that requirement specifically in response to Diginotar. Note that this requirement has caused Firefox more trouble than anybody, because Firefox is the only browser that tries to enforce this in a useful way. Consequently, site stop working (only) in Firefox when the website replaces their cert from a CA (in particular, StartSSL) that does not keep their OCSP responder in sync with their cert issuance. (Search Twitter for "sec_error_ocsp_unknown_cert"). > Hmm... is there some mileage in saying that OCSP responses for certs > during their first week of existence must have a max lifetime of > significantly less than for the rest of their lives? That wouldn't > increase OCSP server load much, but would perhaps mitigate this issue if > the CA were to discover the misissuance soon after it happened. There are also reasons for shortening the max lifetime of an OCSP response well past the initial issuance time. In particular, a server getting its private key stolen is almost definitely more common than a CA mis-issuing a certificate, and a stolen private key also requires a quick response time. Cheers, Brian _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
