When attempting to access an HTTPS site with an expired cert on Firefox
32, you'll see a "This Connection is Untrusted" page that lets you add
an exception and proceed.
But when attempting to access an HTTPS site with a revoked cert, you'll
see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.
Would it make sense to treat expired certs in the same way as revoked
certs? (And if not, why not?)
On 04/09/14 12:52, Hubert Kario wrote:
----- Original Message -----
From: "Gervase Markham" <g...@mozilla.org>
To: mozilla-dev-security-pol...@lists.mozilla.org
Sent: Thursday, September 4, 2014 12:21:50 PM
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).
It all depends on the exact definition of "short-lived". If the definition
is basically the same as for OCSP responses or shorter, then yes, they
provide the same security as regular certs with hard fail for OCSP
querying/stapling.
I'm not sure what gives us the removal of revocation info from certificate.
I mean, if the recommendation for PKIX is to not check revocation info
for certificates that have total validity period of less than, say 2 days,
then inclusion or exclusion of AIA extension is secondary.
There's also the must-staple extension in the works, which can be part of
the plan: you either get short lived certs or you get a long lived with
must-staple. They would provide the same security guarantees.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
