+1
Short lifetime certs don't solve every problem with revocation. But they
allow us to drastically reduce the problem space. That makes applying other
mechanisms viable.
The end goal has to be to reduce the time window of vulnerability to the
time it takes people to respond to phishing sites and
Hi Gerv, you've been busy! The cases Jeremy identified (thanks, Jeremy!) are all good problems to address and while I'm not unsympathetic I don't necessarily find them all that compelling. The situations involving network meddling by someone in power is especially troubling and goes beyond what I'm
Maybe an ad-hoc pre-approval process would work.
-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, September 4, 2014 1:07 PM
To: Ben Wilson
Cc: Gervase Markham; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Short-lived certs
On Thu, Sep 4, 2014 a
- Original Message -
> From: "Phillip Hallam-Baker"
> To: "Gervase Markham"
> Cc: "Rob Stradling" ,
> mozilla-dev-security-pol...@lists.mozilla.org, "Hubert Kario"
>
> Sent: Friday, September 5, 2014 2:11:09 PM
> Subject: Re: Short-lived certs
>
> We probably need to mark them in some
> On 5 Sep 2014, at 13:11, Phillip Hallam-Baker wrote:
>
>> On Fri, Sep 5, 2014 at 5:30 AM, 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 tha
On Fri, Sep 5, 2014 at 5:30 AM, 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 attempti
On 05/09/14 10:55, Gervase Markham wrote:
On 05/09/14 10:47, Rob Stradling wrote:
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,
shor
On 05/09/14 10:47, Rob Stradling wrote:
> Unless the recently expired cert is found to be revoked, in which case
> you'd show "Secure Connection Failed" I presume?
Yes :-)
>> but after that we switch to "Secure Connection Failed". What do you think
>> of that idea?
>
> If the false positive rate
On 04/09/14 19:32, fhw...@gmail.com wrote:
> Could you (or anyone) elaborate a bit on the use cases where short
> lived certs are desirable?
See other messages in this thread - it saves a significant amount of
setup time not to have to wait for a response from the OCSP server.
> I'm also wonderin
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
On 05/09/14 01:32, Phillip Hallam-Baker wrote:
> The point I am trying to get across here is that there are very few
> good reasons for an end user sticking to an obsolete browser and
> almost all would upgrade given the choice. This is not the case for
> servers and there are lots of folk who will
On 05/09/14 00:06, Brian Smith wrote:
> Precisely defining a short-lived certificate is a prerequisite for a
> proper discussion of policy for short-lived certificates. It seems
> likely to me that short-lived certificates will be defined as
> certificates that would expire before the longest-accep
On 04/09/14 19:20, Phillip Hallam-Baker wrote:
> 1) Any new scheme has to work equally well with legacy browsers and
> enabled browsers.
Yes; I think short-lived certs meet that criterion.
> 2) Ditto for legacy servers and this is actually a harder problem as
> upgrading a server can force a comp
On 04/09/14 18:36, David E. Ross wrote:
> Spammers change their E-mail addresses quite frequently, using the same
> address for only a day or two. Hackers also frequently change their
> "residence" so as to prevent tracing them. The same is true of
> distributors of malware.
>
> If short-lived c
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 "
On 04/09/14 14:18, Rob Stradling wrote:
> Today, if an end-entity cert contains no AIA->OCSP URL and the server
> sends no stapled OCSP response, it's a violation of the BRs. I wonder
> if any clients out there would reject the cert in this situation? (I
> suspect not, but it's something to watch
On 04/09/14 14:14, Hubert Kario wrote:
>>From what I heard (and my limited personal experience matches), is that
> the vast majority of clients not only completely ignore failures in OCSP
> retrieval (soft-fail) but completely lack any mechanism for revocation
> checking
> (be it OCSP or CRL).
I
17 matches
Mail list logo
