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

Reply via email to