On 05/09/14 10:30, Gervase Markham wrote:
On 04/09/14 14:25, Rob Stradling wrote:
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?)
Logically, it does make sense. In practice, revocation has a near-zero
false-positive rate, whereas expired sadly has a much greater
false-positive rate. Which is why Firefox treats them differently.
Hi Gerv.
Yes, that is sad.
It might be good, in the future, to get CAs to guarantee to continue
providing revocation information for e.g. 3 months after expiry, and for
those 3 months, we treat as "Untrusted Connection",
Unless the recently expired cert is found to be revoked, in which case
you'd show "Secure Connection Failed" I presume?
but after that we switch to "Secure Connection Failed". What do you think
of that idea?
If the false positive rate drops to near-zero by 3 months after expiry,
then I think that could work. However, it would need to work equally
well for both long-lived certs and short-lived certs. Therefore,
short-lived certs would still need to provide revocation info, even if
the browser only uses that revocation info if it encounters the
short-lived cert after its expiry date.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
