Options for trying this out might fit under an exception, if one were created, for "test, experimental, temporary, pilot, provisional, etc." certificate types.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On Behalf Of Gervase Markham Sent: Thursday, September 4, 2014 4:22 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Short-lived certs Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). I've just been reviewing discussions from July 2012 on the CAB Forum mailing lists about short-lived certs. There was some significant opposition to removing revocation information from short-lived certs at the time (although things may be different now, I don't know). I personally think much of that opposition was mistaken, but the discussion nevertheless did not result in consensus. How should we approach the issue of short-lived certs? It seems to me we can do the following: 0) Try and get a motion passed to change the BRs to allow short-lived certs to not have any revocation information. This would probably require us to review the original discussion and make a wiki page outlining our proposal and rebutting objections. We may still run into heavy weather. We could also discuss it at the face-to-face. 1) Write an exception in Mozilla's policy that short-lived certs don't have to have revocation info. This would likely have no effect, because CAs would want to continue issuing to the BRs. 2) Stop checking revocation information for short-lived certs unilaterally. This would result in reduced take-up of the idea, because there would be no advantage in other browsers, and one would still need to implement all the mechanisms, both at the CA and at the site, for frequent cert renewals and deployments. 3) Configure Firefox to not bother checking revocation information for any cert newer than N days. This way, you can "emulate" short-lived certs by just reissuing an X-year cert every N days or less. It also 'fixes' the clock-skew problem in one direction, because the certs will still work for users whose clocks are some way in the future (although their browsers would check revocation). 4) Something else? Gerv [0] https://wiki.mozilla.org/CA:RevocationPlan _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
