On 2015-12-04 02:55, Jakob Bohm wrote:
How huge and unwieldy are CRLs really, especially if letting the
computer (NSS/Firefox) do the updating?
Individual CRLs are in the range of a few kB to a few MB. For the CA
that issues the subscriber certificates they have a maximum validity of
10
On 2015-12-04 15:21, Jakob Bohm wrote:
On 04/12/2015 11:19, Kurt Roeckx wrote:
On 2015-12-04 02:55, Jakob Bohm wrote:
How huge and unwieldy are CRLs really, especially if letting the
computer (NSS/Firefox) do the updating?
Individual CRLs are in the range of a few kB to a few MB. For the CA
On 30/11/15 22:37, Jakob Bohm wrote:
> 1.1. Certificates that are used on servers that don't implement
> OCSP stapling.
No-one is suggesting dropping support for non-stapling web servers. But
the revocation options will not be as good.
> 1.2. Certificates that are moved from a server software
On 03/12/2015 11:25, Gervase Markham wrote:
On 30/11/15 22:37, Jakob Bohm wrote:
1.1. Certificates that are used on servers that don't implement
OCSP stapling.
No-one is suggesting dropping support for non-stapling web servers. But
the revocation options will not be as good.
Good.
1.2.
On Thu, Dec 03, 2015 at 07:32:43PM +0100, Jakob Bohm wrote:
> On 03/12/2015 11:25, Gervase Markham wrote:
> >On 30/11/15 22:37, Jakob Bohm wrote:
> >>1.2. Certificates that are moved from a server software implementation
> >>that does do OCSP stapling to another that doesn't. In particular,
>
Having seen the current (as of a few hours ago) wiki page, I have two
major things to add:
1. Unfortunately, not all https servers seem capable of doing
OCSP stapling, thus any viable requirements and mechanisms must allow
for:
1.1. Certificates that are used on servers that don't implement
On 8/4/2014 10:16 AM, Erwann Abalea wrote:
I imagine you have access to more detailed information (OCSP URL,
date/time, user location, ...), could some of it be open?
All of our telemetry data is open as far as I know. Because of privacy
concerns we only collect aggregate stats from users,
* Richard Barnes rbar...@mozilla.com [2014-08-01 04:09]:
Hi all,
We in the Mozilla PKI team have been discussing ways to improve
revocation checking in our PKI stack, consolidating a bunch of ideas
from earlier work [1][2] and some maybe-new-ish ideas. I've just
pressed save on a new wiki
On Wed, August 6, 2014 11:14 pm, Sebastian Wiesinger wrote:
* Richard Barnes rbar...@mozilla.com [2014-08-01 04:09]:
Hi all,
We in the Mozilla PKI team have been discussing ways to improve
revocation checking in our PKI stack, consolidating a bunch of ideas
from earlier work [1][2] and
* Ryan Sleevi ryan-mozdevsecpol...@sleevi.com [2014-08-07 08:33]:
Hi Sebastian,
While you raise an important issue, the problem(s) OneCRL sets out to
solve are still problems that need solving, and we should not lose sight.
I agree with that. And I also agree that we should not lose sight.
Mozilla has (i.e. lawyers). There's probably an issue of time and staff
availability.
Original Message
From: Sebastian Wiesinger
Sent: Thursday, August 7, 2014 2:28 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: New wiki page on certificate revocation plans
* Ryan Sleevi ryan
http://dev.chromium.org/Home/chromium-security/crlsets says:
The limit of the CRLSet size is 250KB
Have Mozilla decided what the maximum OneCRL size will be?
On 01/08/14 03:07, Richard Barnes wrote:
Hi all,
We in the Mozilla PKI team have been discussing ways to improve revocation checking in
On Aug 7, 2014, at 9:47 AM, Rob Stradling rob.stradl...@comodo.com wrote:
http://dev.chromium.org/Home/chromium-security/crlsets says:
The limit of the CRLSet size is 250KB
Have Mozilla decided what the maximum OneCRL size will be?
No, we haven't.
The need for a limit largely depends on
-cry...@lists.mozilla.org;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New wiki page on certificate revocation plans
On Aug 7, 2014, at 9:47 AM, Rob Stradling rob.stradl...@comodo.com wrote:
http://dev.chromium.org/Home/chromium-security/crlsets says:
The limit of the CRLSet size
On 04/08/14 18:16, Erwann Abalea wrote:
I imagine you have access to more detailed information (OCSP URL,
date/time, user location, ...), could some of it be open?
Not necessarily; I suspect this data was gathered using Firefox
Telemetry, where we try very hard to avoid violating a user's
On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham g...@mozilla.org wrote:
On 04/08/14 18:16, Erwann Abalea wrote:
OCSP is painful and costly to optimize, x509labs shows great
availability and good performance for most CA/location combination,
but this is in contradiction with real user
Subject: Re: New wiki page on certificate revocation plans
On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham g...@mozilla.org wrote:
On 04/08/14 18:16, Erwann Abalea wrote:
OCSP is painful and costly to optimize, x509labs shows great
availability and good performance for most CA/location combination
Am 01.08.2014 12:11, schrieb simon.zer...@gmail.com:
Where is the evidence that OSCP hard fails and these
speed issues are actually a problem in the real world?
Try it on a site with an unknown issuer.
The handshake takes at least 30 seconds longer, because thats the time
you need to turn off
- Original Message -
From: David Huang linshunghu...@gmail.com
To: mozilla-dev-security-pol...@lists.mozilla.org
Sent: Saturday, August 2, 2014 1:21:58 AM
Subject: Re: New wiki page on certificate revocation plans
This is great news!
Regarding the max lifetime threshold of short
I am generally in favour of this plan - I think it's the right way to
go. I am not sure we will ever get to hard-fail for plain OCSP, but I am
very happy for that to be a data-driven decision somewhere down the line.
On 01/08/14 03:07, Richard Barnes wrote:
There's one major open issue
On 02/08/14 15:20, Jesper Kristensen wrote:
* Have you considered adding support for multiple ocsp staples to allow
stapeling of CA certs?
There is a proposed standard for multi-stapling but as far as I remember
it's not even finished yet, yet alone implemented and deployed. We
decided that we
On 04/08/14 14:16, Gervase Markham wrote:
On 02/08/14 15:20, Jesper Kristensen wrote:
* Have you considered adding support for multiple ocsp staples to allow
stapeling of CA certs?
There is a proposed standard for multi-stapling but as far as I remember
it's not even finished yet, yet alone
: Re: New wiki page on certificate revocation plans
Am 01.08.2014 12:11, schrieb simon.zer...@gmail.com:
Where is the evidence that OSCP hard fails and these speed issues are
actually a problem in the real world?
Try it on a site with an unknown issuer.
The handshake takes at least 30 seconds
, 2014 10:35 AM
To: Jeremy Rowley
Cc: Matthias Hunstock; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New wiki page on certificate revocation plans
Firefox 31 data:
on desktop the median successful OCSP validation took 261ms, and the 95th
percentile (looking at just the universe
Le lundi 4 août 2014 18:34:50 UTC+2, Patrick McManus a écrit :
Firefox 31 data:
on desktop the median successful OCSP validation took 261ms, and the 95th
percentile (looking at just the universe of successful ones) was over
1300ms. 9% of all OCSP requests on desktop timed out completely and
Den 04-08-2014 kl. 15:16 skrev Gervase Markham:
On 02/08/14 15:20, Jesper Kristensen wrote:
* Have you considered adding support for multiple ocsp staples to allow
stapeling of CA certs?
There is a proposed standard for multi-stapling but as far as I remember
it's not even finished yet, yet
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf Of Jesper Kristensen
Sent: Saturday, August 2, 2014 8:21 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New wiki page on certificate revocation plans
Hi
This sounds like a really great plan
This is great news!
Regarding the max lifetime threshold of short-lived certificates, we ran study
[1] a while back that indicated the average OCSP validity time was 4 days
(while 87.14% were equal to or less than 7 days). Thus, FWIW, we suggested a
certificate lifetime of 4 days in our paper
Hi
This sounds like a really great plan!
Some comments:
* Have you considered adding support for multiple ocsp staples to allow
stapeling of CA certs?
* Why not allow short-lived CA certs without revocation info, just like
EE certs?
* While must-staple and short-lived certificates seem
On Fri, August 1, 2014 3:11 am, simon.zer...@gmail.com wrote:
Hi,
I would really like to see some hard metrics on OSCP failures and SSL/TLS
setup speed issues.
I use FF a lot with OSCP hard fail enabled and I don't seem to see any
hard fails. In addition my SSL/TLS sessions seems to be
30 matches
Mail list logo
