> On 5 Sep 2014, at 13:11, Phillip Hallam-Baker <[email protected]> wrote: > >> On Fri, Sep 5, 2014 at 5:30 AM, Gervase Markham <[email protected]> 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. > > Which means that expired short lived certs probably need to be treated > differently. > > We probably need to mark them in some way as being intended to be > short lived.
Isn't a short lived cert categorised simply by its short validity? If the platform will do something different based on a decision about the validity then that's already built in and needs no other indicator/OID/cert bytes. ;-) > And we certainly need to fix the problem of getting them > renewed efficiently. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
