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
page with our initial plan:
https://wiki.mozilla.org/CA:Re
...@lists.mozilla.org;
mozilla-dev-tech-cry...@lists.mozilla.org
Subject: New wiki page on certificate revocation plans
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
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
> On Behalf Of Richard Barnes
> Sent: Thursday, July 31, 2014 8:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org;
> mozilla-dev-tech-cry...@lists.mozilla.org
> Subject: New wiki page on certificat
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 as quick to set up and
responsive as ever.
Where is the evidence th
-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf Of simon.zer...@gmail.com
Sent: Friday, August 1, 2014 4:12 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New wiki page on certificate revocation plans
Hi,
I
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
Hi Ryan,
Yes I do represent the real world. I am not fictional or in a test lab
somewhere with non production hardware or Internet connectivity :-)
I'm looking at that data now and from what it seems to be showing OCSP fails
are transitory and short lived. I will look at the numbers to see if t
- Original Message -
> From: "Simon Zerafa"
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Sent: Friday, 1 August, 2014 8:38:53 PM
> Subject: Re: New wiki page on certificate revocation plans
>
>
> I have asked lots of people who use OCSP hard fail
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 to
olicy
[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
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"
> 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
On Mon, Aug 4, 2014 at 12:12 AM, Jeremy Rowley
wrote:
> Why does OneCRL seem like a hack? Considering how infrequently intermediates
> and roots are revoked, OneCRL seems like a satisfactory way to provide this
> information long-term, provided that the certs are removed from OneCRL at
> some
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 highlight
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 im
-security-pol...@lists.mozilla.org
Subject: 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
ity-pol...@lists.mozilla.org
> Subject: 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 i
, 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 of
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
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 al
I agree that some of this performance data is concerning but I'm not ready to
give up on OCSP just yet because I don't see any choice in the matter: OCSP
hard fail has to be done.
The fact that end entity certs can not be revoked is a major gap in Internet
security right now. That gap should b
On 04/08/14 18:44, Jesper Kristensen wrote:
> I agree that it would not be relevant for the traditional intermediate
> CA certificates in the near future for this reason. I was thinking of
> name constrained sub-CAs, which on some aspects are more similar to EE
> certs than CA certs.
OK. Let's ass
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 priv
On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham 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 measurements. Why,
ozilla.org
Subject: Re: New wiki page on certificate revocation plans
On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham 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/loca
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, not
* Richard Barnes [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 page with ou
On Wed, August 6, 2014 11:14 pm, Sebastian Wiesinger wrote:
> * Richard Barnes [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 may
* Ryan Sleevi [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. The
difference seems to be wh
how much of an appetite the larger
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 r
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 i
On Aug 4, 2014, at 9:21 AM, Rob Stradling wrote:
> 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-staplin
On Aug 7, 2014, at 9:47 AM, Rob Stradling 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 whether we cover E
-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 wrote:
> http://dev.chromium.org/Home/chromium-security/crlsets says:
> "The limit of the CRLSet size is 250KB
Hey all,
Just to let you know: I've updated this wiki page and removed the {{draft}}
indication at the top. I'm considering this the plan of record for now.
https://wiki.mozilla.org/CA:RevocationPlan
The primary edit was with regard to OneCRL covering EE certificates. For now,
we're consideri
I took a hack at the blog post. I kept your outline, but ended up
text-editing a bunch of it. I think it's pretty good now.
On Thu, Jul 31, 2014 at 10:07 PM, Richard Barnes
wrote:
> Hi all,
>
> We in the Mozilla PKI team have been discussing ways to improve revocation
> checking in our PKI sta
Sorry, wrong thread. Expect to see a security blog post about revocation
soon, summarizing some recent work :)
On Sat, Nov 21, 2015 at 11:59 AM, Richard Barnes
wrote:
> I took a hack at the blog post. I kept your outline, but ended up
> text-editing a bunch of it. I think it's pretty good now
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
OCSP
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 imp
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. Ce
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,
> >>su
On 04/12/2015 02:20, Matt Palmer wrote:
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
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 days
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
that issues the subscriber certificates
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 04/12/2015 15:58, Kurt Roeckx wrote:
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 ra
48 matches
Mail list logo
