Re: 825 days success and future progress!

2018-04-05 Thread Jakob Bohm via dev-security-policy 

On 04/04/2018 04:16, Matt Palmer wrote:

On Tue, Apr 03, 2018 at 03:16:53AM +0200, Jakob Bohm via dev-security-policy 
wrote:

On 03/04/2018 02:35, Kurt Roeckx wrote:

On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy 
wrote:

seems
to be mostly justified as a poor workaround for the browsers and
certificate libraries not properly implementing reliable revocation
checks.


The problem is not in the libraries, or even the applications
making use of them, it's that actually trying to check them is not
reliable. There are just too many cases where trying to check it
results in an error.

OCSP stapling should at least help with this. We should really
encourage people to use this, and have software enable this by
default. According to ssl-pulse 31% of the sites enable it.

There might also be library or application bugs. At least firefox
for me is annoying that if it for whatever reasons fails, it says
it's an internal server error (which as far as I know is never the
case), and then even doesn't seem to retry it and just give that
same error again.


Most of the remaining 69% of servers run software libraries that don't
include a good enough OCSP stapling implementation.  This includes the
omnipresent OpenSSL 1.0.2.

Automatically scheduled CRL downloads, though currently bandwidth
inefficient, would be much more reliable, as they are done and retried
in advance, with typically at least a day to recover from server
glitches.  Also, CRL download servers are much more reliable than OCSP
servers as they don't need to run special software with high CPU
capacity and a secure private key, any basic redundant HTTP server can
do the job.

Delta CRLs, with some systematic enhancements, could further speedup CRL
downloads to a viable bandwidth level.


Bandwidth, whilst a big problem (not everyone has phat pipes, nor even
*always connected* pipes), isn't the only problem with CRLs.  You also need
to be able to store them all, and generate and store the indexes to make
searching them sufficiently fast.  Oh, and because CRL distribution points
aren't embedded in the root certificates, you're still going to stumble
across certs that you don't have the CRL for, which kills the "oh you'll
definitely have all the CRLs in advance" argument, bringing us back to the
same problem we've already got, that of "what do you do when you can't
access timely revocation information?" while *also* having all the other
problems of CRLs.



But the problem of a never-before or not-recently seen CRL will be a lot
rarer than the problem of a not-recently queried OCSP status, thus
representing a much smaller risk of either maliciously blocked checking
causing a fail open or unexpected damage from failing closed.

As for indexing, some requirements above and beyond the current RFCs
could make that a lot easier, for example:

- CRLs must be sorted by certificate serial number (DER sorting rules),
 alternatively security libraries (like NSS) could create an index file
 for each cached CRL.

- A combination of issuing CA and actual certificate signing algorithm
 must have exactly one CRL, no sharding etc. allowed.

- Delta CRLs must contain enough data to allow the client to
 deterministically reconstruct the latest CRL without actually
 downloading it.

- CRL URLs must be listed in CCADB allowing participating browsers to
 distribute an initial preload list, further reducing the frequency of
 needing an uncached CRL.  Alternatively define some other way for
 clients to enumerate relevant CRLs.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 825 days success and future progress!

2018-04-03 Thread Matt Palmer via dev-security-policy 
On Tue, Apr 03, 2018 at 03:16:53AM +0200, Jakob Bohm via dev-security-policy 
wrote:
> On 03/04/2018 02:35, Kurt Roeckx wrote:
> > On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via 
> > dev-security-policy wrote:
> > > seems
> > > to be mostly justified as a poor workaround for the browsers and
> > > certificate libraries not properly implementing reliable revocation
> > > checks.
> > 
> > The problem is not in the libraries, or even the applications
> > making use of them, it's that actually trying to check them is not
> > reliable. There are just too many cases where trying to check it
> > results in an error.
> > 
> > OCSP stapling should at least help with this. We should really
> > encourage people to use this, and have software enable this by
> > default. According to ssl-pulse 31% of the sites enable it.
> > 
> > There might also be library or application bugs. At least firefox
> > for me is annoying that if it for whatever reasons fails, it says
> > it's an internal server error (which as far as I know is never the
> > case), and then even doesn't seem to retry it and just give that
> > same error again.
> 
> Most of the remaining 69% of servers run software libraries that don't
> include a good enough OCSP stapling implementation.  This includes the
> omnipresent OpenSSL 1.0.2.
> 
> Automatically scheduled CRL downloads, though currently bandwidth
> inefficient, would be much more reliable, as they are done and retried
> in advance, with typically at least a day to recover from server
> glitches.  Also, CRL download servers are much more reliable than OCSP
> servers as they don't need to run special software with high CPU
> capacity and a secure private key, any basic redundant HTTP server can
> do the job.
> 
> Delta CRLs, with some systematic enhancements, could further speedup CRL
> downloads to a viable bandwidth level.

Bandwidth, whilst a big problem (not everyone has phat pipes, nor even
*always connected* pipes), isn't the only problem with CRLs.  You also need
to be able to store them all, and generate and store the indexes to make
searching them sufficiently fast.  Oh, and because CRL distribution points
aren't embedded in the root certificates, you're still going to stumble
across certs that you don't have the CRL for, which kills the "oh you'll
definitely have all the CRLs in advance" argument, bringing us back to the
same problem we've already got, that of "what do you do when you can't
access timely revocation information?" while *also* having all the other
problems of CRLs.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 825 days success and future progress!

2018-04-02 Thread Jakob Bohm via dev-security-policy 

On 03/04/2018 02:35, Kurt Roeckx wrote:

On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy 
wrote:

seems
to be mostly justified as a poor workaround for the browsers and
certificate libraries not properly implementing reliable revocation
checks.


The problem is not in the libraries, or even the applications
making use of them, it's that actually trying to check them is not
reliable. There are just too many cases where trying to check it
results in an error.

OCSP stapling should at least help with this. We should really
encourage people to use this, and have software enable this by
default. According to ssl-pulse 31% of the sites enable it.

There might also be library or application bugs. At least firefox
for me is annoying that if it for whatever reasons fails, it says
it's an internal server error (which as far as I know is never the
case), and then even doesn't seem to retry it and just give that
same error again.



Most of the remaining 69% of servers run software libraries that don't
include a good enough OCSP stapling implementation.  This includes the
omnipresent OpenSSL 1.0.2.

Automatically scheduled CRL downloads, though currently bandwidth
inefficient, would be much more reliable, as they are done and retried
in advance, with typically at least a day to recover from server
glitches.  Also, CRL download servers are much more reliable than OCSP
servers as they don't need to run special software with high CPU
capacity and a secure private key, any basic redundant HTTP server can
do the job.

Delta CRLs, with some systematic enhancements, could further speedup CRL
downloads to a viable bandwidth level.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 825 days success and future progress!

2018-04-02 Thread Kurt Roeckx via dev-security-policy 
On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy 
wrote:
> seems
> to be mostly justified as a poor workaround for the browsers and
> certificate libraries not properly implementing reliable revocation
> checks.

The problem is not in the libraries, or even the applications
making use of them, it's that actually trying to check them is not
reliable. There are just too many cases where trying to check it
results in an error.

OCSP stapling should at least help with this. We should really
encourage people to use this, and have software enable this by
default. According to ssl-pulse 31% of the sites enable it.

There might also be library or application bugs. At least firefox
for me is annoying that if it for whatever reasons fails, it says
it's an internal server error (which as far as I know is never the
case), and then even doesn't seem to retry it and just give that
same error again.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 825 days success and future progress!

2018-04-02 Thread Jakob Bohm via dev-security-policy 


Furthermore in IT departments of smaller companies, setting up new
automations or upgrading otherwise functioning systems to ones that
include automation is much harder than it is for a mastodon like
Siemens.

The main arguing for ever shorter validity periods seems to come from
very few mega-companies with 100% automated computer systems, and seems
to be mostly justified as a poor workaround for the browsers and
certificate libraries not properly implementing reliable revocation
checks.

From a small IT depeartment perspective, a much more usable further plan
would be:

1. NO MORE REDUCTIONS IN MAX LIFETIME.

2. A rule that CAs periodically check for conflicting whois
  changes or other changes in underlying public records, and revoke
  affected certificates with a reasonable warning to the affected
  entities (just in case the detected change is erroneous and the
  certificate contents is still true).

3. A *requirement* that participating browsers implement fully working
  revocation checks for both OCSP and CRL cases.

4. Work to create improved (more efficient) privacy preserving
  revocation protocols, such as redundant delta CRLs over HTTPS.

5. Once revocation is actually working industry wide, work to
  reintroduce certificate lifetimes comparable to domain registration
  periods (1, 2, 3, 5 years).





On 02/04/2018 21:20, Buschart, Rufus wrote:

By practical means in an IT department of a large company, it is always easier 
to discuss about money, if such a plan is written down in a standard that can 
be referenced and shown (like the BRGs) than in the depths of the archive of a 
mailing list. So if there is a plan, I would like to suggest to add it to the 
standard.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife>
[www.siemens.com/ingenuityforlife]
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Montag, 2. April 2018 21:16
To: Buschart, Rufus (GS IT HR 7 4)
Cc: Alex Gaynor; Tim Hollebeek; MozPol
Subject: Re: 825 days success and future progress!

In past discussions, the proposal was 1 year to 2 years, and 1 year to 1 year 
after that. We're now at the midway point, so it seems appropriate to discuss 
how to get shorter.

On Mon, Apr 2, 2018 at 3:11 PM, Buschart, Rufus via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hi all!

 From the discussions we had in the last months internally at Siemens IT 
department about the 825 days rule, I can report that our server operators need 
a long term roadmap in this issue. The main point here is, that there are a 
hell lot of applications out there that don't (easily) support automated 
SSL/TLS certificate replacement (e.g. some SAP systems). To enable those 
systems to support automated certificate replacement a significant amount of 
money will need to be invested. To get approval for such an investment, one 
needs to calculate a business case. And this business case looks obviously much 
different, if a certificate on a system needs to be replaced every 825 days, 
731 days, 366 days or even 90 days. So I would like to propose not to start 
discuss about the next reduction step now, but agree on a clear (semi-)final 
goal (e.g. max life span of a certificate is 45 days in 2023 (five years from 
now)) and then agree on the intermediate steps to reach this goal.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com<mailto:rufus.busch...@siemens.com>

www.siemens.com/ingenuityforlife<http://www.siemens.com/ingenuityforlife>


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart<mailto:dev-security-policy-bounces%2Brufus.buschart>=siemens@lists.mozilla.org<mailto:siemens@lists.mozilla.org>]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Montag, 2. April 2018 20:51
To: Tim Hollebeek
Cc: MozPol
Subject: Re: 825 days success and future progress!

Hi Tim,

I'd have suggested an even shorter period, say 13 months, except I anticipated 
CAs would object that it was too great a change too suddenly, precisely as they 
did when this subject was last discussed!

While I appreciate that changing BRs can be difficult for customer 
communications, the fact that we are doing this in multiple steps instead of in 
one fell swoop is a result of CAs saying such a big leap was too disruptive. 
Frankly, you can't have it both ways.

Alex

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek 
<tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>>
wrote:


18 months is not significantly different from 825 days.   So there's really
no benefit.

People have to stop wanting to constantly

RE: 825 days success and future progress!

2018-04-02 Thread Buschart, Rufus via dev-security-policy 
By practical means in an IT department of a large company, it is always easier 
to discuss about money, if such a plan is written down in a standard that can 
be referenced and shown (like the BRGs) than in the depths of the archive of a 
mailing list. So if there is a plan, I would like to suggest to add it to the 
standard.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife>
[www.siemens.com/ingenuityforlife]
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Montag, 2. April 2018 21:16
To: Buschart, Rufus (GS IT HR 7 4)
Cc: Alex Gaynor; Tim Hollebeek; MozPol
Subject: Re: 825 days success and future progress!

In past discussions, the proposal was 1 year to 2 years, and 1 year to 1 year 
after that. We're now at the midway point, so it seems appropriate to discuss 
how to get shorter.

On Mon, Apr 2, 2018 at 3:11 PM, Buschart, Rufus via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hi all!

>From the discussions we had in the last months internally at Siemens IT 
>department about the 825 days rule, I can report that our server operators 
>need a long term roadmap in this issue. The main point here is, that there are 
>a hell lot of applications out there that don't (easily) support automated 
>SSL/TLS certificate replacement (e.g. some SAP systems). To enable those 
>systems to support automated certificate replacement a significant amount of 
>money will need to be invested. To get approval for such an investment, one 
>needs to calculate a business case. And this business case looks obviously 
>much different, if a certificate on a system needs to be replaced every 825 
>days, 731 days, 366 days or even 90 days. So I would like to propose not to 
>start discuss about the next reduction step now, but agree on a clear 
>(semi-)final goal (e.g. max life span of a certificate is 45 days in 2023 
>(five years from now)) and then agree on the intermediate steps to reach this 
>goal.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com<mailto:rufus.busch...@siemens.com>

www.siemens.com/ingenuityforlife<http://www.siemens.com/ingenuityforlife>


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart<mailto:dev-security-policy-bounces%2Brufus.buschart>=siemens@lists.mozilla.org<mailto:siemens@lists.mozilla.org>]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Montag, 2. April 2018 20:51
To: Tim Hollebeek
Cc: MozPol
Subject: Re: 825 days success and future progress!

Hi Tim,

I'd have suggested an even shorter period, say 13 months, except I anticipated 
CAs would object that it was too great a change too suddenly, precisely as they 
did when this subject was last discussed!

While I appreciate that changing BRs can be difficult for customer 
communications, the fact that we are doing this in multiple steps instead of in 
one fell swoop is a result of CAs saying such a big leap was too disruptive. 
Frankly, you can't have it both ways.

Alex

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek 
<tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>>
wrote:

> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>
> People have to stop wanting to constantly change the max validity period.
> It's difficult enough to communicate these changes to consumers and
> customers, and it really drives them nuts.  I can only imagine what a
> non-integral number of years will do to various company's planning and
> budgeting processes.
>
> I would propose, instead, a minimum one year moratorium on proposals
> to change the max validity period after the previous change to the max
> validity period goes into effect.  That would make much more sense.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy 
> > [mailto:dev-security-policy-<mailto:dev-security-policy->
> > bounces+tim.hollebeek=digicert@lists.mozilla.org<mailto:digicert@lists.mozilla.org>]
> >  On Behalf Of
> > bounces+Alex
> > Gaynor via dev-security-policy
> > Sent: Monday, April 2, 2018 1:07 PM
> > To: MozPol 
> > <mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
> > Subject: 825 days success and future progress!
> >
> > Afternoon all!
> >
> > A month ago a new BR rule went into effect, putting a maximum
> > validity
> period
> > of 825 days on newly issued cert

Re: 825 days success and future progress!

2018-04-02 Thread Ryan Sleevi via dev-security-policy 
In past discussions, the proposal was 1 year to 2 years, and 1 year to 1
year after that. We're now at the midway point, so it seems appropriate to
discuss how to get shorter.

On Mon, Apr 2, 2018 at 3:11 PM, Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi all!
>
> From the discussions we had in the last months internally at Siemens IT
> department about the 825 days rule, I can report that our server operators
> need a long term roadmap in this issue. The main point here is, that there
> are a hell lot of applications out there that don't (easily) support
> automated SSL/TLS certificate replacement (e.g. some SAP systems). To
> enable those systems to support automated certificate replacement a
> significant amount of money will need to be invested. To get approval for
> such an investment, one needs to calculate a business case. And this
> business case looks obviously much different, if a certificate on a system
> needs to be replaced every 825 days, 731 days, 366 days or even 90 days. So
> I would like to propose not to start discuss about the next reduction step
> now, but agree on a clear (semi-)final goal (e.g. max life span of a
> certificate is 45 days in 2023 (five years from now)) and then agree on the
> intermediate steps to reach this goal.
>
> With best regards,
> Rufus Buschart
>
> Siemens AG
> GS IT HR 7 4
> Hugo-Junkers-Str. 9
> 90411 Nuernberg, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
>
> www.siemens.com/ingenuityforlife
>
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+rufus.buschart=siemens@lists.mozilla.org] On Behalf Of Alex
> Gaynor via dev-security-policy
> Sent: Montag, 2. April 2018 20:51
> To: Tim Hollebeek
> Cc: MozPol
> Subject: Re: 825 days success and future progress!
>
> Hi Tim,
>
> I'd have suggested an even shorter period, say 13 months, except I
> anticipated CAs would object that it was too great a change too suddenly,
> precisely as they did when this subject was last discussed!
>
> While I appreciate that changing BRs can be difficult for customer
> communications, the fact that we are doing this in multiple steps instead
> of in one fell swoop is a result of CAs saying such a big leap was too
> disruptive. Frankly, you can't have it both ways.
>
> Alex
>
> On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek <tim.holleb...@digicert.com>
> wrote:
>
> > 18 months is not significantly different from 825 days.   So there's
> really
> > no benefit.
> >
> > People have to stop wanting to constantly change the max validity period.
> > It's difficult enough to communicate these changes to consumers and
> > customers, and it really drives them nuts.  I can only imagine what a
> > non-integral number of years will do to various company's planning and
> > budgeting processes.
> >
> > I would propose, instead, a minimum one year moratorium on proposals
> > to change the max validity period after the previous change to the max
> > validity period goes into effect.  That would make much more sense.
> >
> > -Tim
> >
> > > -Original Message-
> > > From: dev-security-policy [mailto:dev-security-policy-
> > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
> > > bounces+Alex
> > > Gaynor via dev-security-policy
> > > Sent: Monday, April 2, 2018 1:07 PM
> > > To: MozPol <mozilla-dev-security-pol...@lists.mozilla.org>
> > > Subject: 825 days success and future progress!
> > >
> > > Afternoon all!
> > >
> > > A month ago a new BR rule went into effect, putting a maximum
> > > validity
> > period
> > > of 825 days on newly issued certificates.
> > >
> > > Truthfully, I was expecting tons of CAs to screw up, forget to
> > > implement
> > it, or
> > > have no technical controls, and there to be tons of miss-issuance.
> > > To me delight, the results have been pretty good:
> > > https://crt.sh/?zlint=1081=2018-03-01 the majority of
> > > violations have been from the US Government (whose PKI isn't
> > > remotely BR compliant, nor trusted by Mozilla).
> > >
> > > In light of this incredible success, I think it's time to begin a
> > discussion on what
> > > the next in this chain is. While obviously actually encoding this in
> > > the
> > BRs will
> > > be a function of the CABF, as mdsp is the premier public discussion
> > > forum
> > for
> > > the PKI, I wanted to start h

Re: 825 days success and future progress!

2018-04-02 Thread Ryan Sleevi via dev-security-policy 
Tim,

I think it's far more productive to help clarify misunderstandings. For
example, based on your statement, it sounds like you're actually opposed to
any change - and the objection that it's not "significantly different" is
simply a misleading objection. If that's not the case, then can you please
explain why you raise it as an objection and what constitutes a change that
would be "significantly different" such that you'd support.

On Mon, Apr 2, 2018 at 2:59 PM, Tim Hollebeek <tim.holleb...@digicert.com>
wrote:

> Ryan, I’ve warned you several times, do not put words in my mouth.  I
> support the status quo, for now.  We can talk about future changes in the
> future.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:r...@sleevi.com]
> *Sent:* Monday, April 2, 2018 2:58 PM
> *To:* Tim Hollebeek <tim.holleb...@digicert.com>
> *Cc:* Alex Gaynor <agay...@mozilla.com>; MozPol <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Re: 825 days success and future progress!
>
>
>
>
>
>
>
> On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>
>
>
> So it sounds like you're supportive of 13 months, then, so that we arrive
> at an effective and meaningful maximum.
>
>
>
> People have to stop wanting to constantly change the max validity period.
>
>
>
> This is an entirely unproductive line of reasoning. The only reason that
> we're at a point of discussing incremental approaches seems to be because
> CAs resisted making meaningful steps all at once, and instead preferred a
> phase-in, like SHA-1. Proposals were put forward to make it a significant
> and meaningful difference, and there appeared to be wide browser support in
> spirit - and the only question being about the timing of the phase in.
> Thus, it seems reasonable to begin discussing how to approach that - and it
> doesn't seem productive to suggest the community should not discuss this.
>
>
>
> It's difficult enough to communicate these changes to consumers and
> customers, and it really drives them nuts.  I can only imagine what a
> non-integral number of years will do to various company's planning
> and budgeting processes.
>
>
>
> So this argues in favor of 13 months, rather than 18 months. The
> communication difficulties are not expanded upon here, but it seems that if
> CAs spent more time investing in interoperable automation, these
> communication issues would evaporate, because they'd no longer be an issue.
>
>
>
> I would propose, instead, a minimum one year moratorium on proposals
> to change the max validity period after the previous change to the max
> validity period goes into effect.  That would make much more sense.
>
>
>
> I'm sure to a CA it makes sense, especially if the argument is that change
> is hard for them to do. Yet, at the same time, attempts to propose
> moratoriums on misissuance by CAs have consistently failed. A moratorium on
> discussions on how to reduce risk only seems valuable if would also imposed
> a moratorium on trust for those CAs that have issues. Since I'm sure that's
> not desirable for CAs, I hope we can agree that discussions of how to
> reduce the risk of such issues is highly relevant and necessary to resolve.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: 825 days success and future progress!

2018-04-02 Thread Buschart, Rufus via dev-security-policy 
Hi all!

>From the discussions we had in the last months internally at Siemens IT 
>department about the 825 days rule, I can report that our server operators 
>need a long term roadmap in this issue. The main point here is, that there are 
>a hell lot of applications out there that don't (easily) support automated 
>SSL/TLS certificate replacement (e.g. some SAP systems). To enable those 
>systems to support automated certificate replacement a significant amount of 
>money will need to be invested. To get approval for such an investment, one 
>needs to calculate a business case. And this business case looks obviously 
>much different, if a certificate on a system needs to be replaced every 825 
>days, 731 days, 366 days or even 90 days. So I would like to propose not to 
>start discuss about the next reduction step now, but agree on a clear 
>(semi-)final goal (e.g. max life span of a certificate is 45 days in 2023 
>(five years from now)) and then agree on the intermediate steps to reach this 
>goal.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Montag, 2. April 2018 20:51
To: Tim Hollebeek
Cc: MozPol
Subject: Re: 825 days success and future progress!

Hi Tim,

I'd have suggested an even shorter period, say 13 months, except I anticipated 
CAs would object that it was too great a change too suddenly, precisely as they 
did when this subject was last discussed!

While I appreciate that changing BRs can be difficult for customer 
communications, the fact that we are doing this in multiple steps instead of in 
one fell swoop is a result of CAs saying such a big leap was too disruptive. 
Frankly, you can't have it both ways.

Alex

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek <tim.holleb...@digicert.com>
wrote:

> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>
> People have to stop wanting to constantly change the max validity period.
> It's difficult enough to communicate these changes to consumers and 
> customers, and it really drives them nuts.  I can only imagine what a 
> non-integral number of years will do to various company's planning and 
> budgeting processes.
>
> I would propose, instead, a minimum one year moratorium on proposals 
> to change the max validity period after the previous change to the max 
> validity period goes into effect.  That would make much more sense.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of 
> > bounces+Alex
> > Gaynor via dev-security-policy
> > Sent: Monday, April 2, 2018 1:07 PM
> > To: MozPol <mozilla-dev-security-pol...@lists.mozilla.org>
> > Subject: 825 days success and future progress!
> >
> > Afternoon all!
> >
> > A month ago a new BR rule went into effect, putting a maximum 
> > validity
> period
> > of 825 days on newly issued certificates.
> >
> > Truthfully, I was expecting tons of CAs to screw up, forget to 
> > implement
> it, or
> > have no technical controls, and there to be tons of miss-issuance.
> > To me delight, the results have been pretty good:
> > https://crt.sh/?zlint=1081=2018-03-01 the majority of 
> > violations have been from the US Government (whose PKI isn't 
> > remotely BR compliant, nor trusted by Mozilla).
> >
> > In light of this incredible success, I think it's time to begin a
> discussion on what
> > the next in this chain is. While obviously actually encoding this in 
> > the
> BRs will
> > be a function of the CABF, as mdsp is the premier public discussion 
> > forum
> for
> > the PKI, I wanted to start here.
> >
> > I propose that our next target should be a max validity period of 18
> months
> > (~550 days), starting in ~6 months from now.
> >
> > The value of shorter-lived certificates has been discussed many 
> > times,
> but
> to
> > rehash: They afford the ecosystem significantly more agility, by 
> > allowing
> us to
> > remove mistakes in shorter periods of time without breaking valid
> certificates.
> > It also encourages subscribers to adopt more automation, which 
> > further
> helps
> > with agility.
> >
> > Alex
> > ___
> > dev-security-policy mailing list

RE: 825 days success and future progress!

2018-04-02 Thread Tim Hollebeek via dev-security-policy 
Ryan, I’ve warned you several times, do not put words in my mouth.  I support 
the status quo, for now.  We can talk about future changes in the future.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, April 2, 2018 2:58 PM
To: Tim Hollebeek <tim.holleb...@digicert.com>
Cc: Alex Gaynor <agay...@mozilla.com>; MozPol 
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: 825 days success and future progress!

 

 

 

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

18 months is not significantly different from 825 days.   So there's really
no benefit.

 

So it sounds like you're supportive of 13 months, then, so that we arrive at an 
effective and meaningful maximum.

 

People have to stop wanting to constantly change the max validity period.

 

This is an entirely unproductive line of reasoning. The only reason that we're 
at a point of discussing incremental approaches seems to be because CAs 
resisted making meaningful steps all at once, and instead preferred a phase-in, 
like SHA-1. Proposals were put forward to make it a significant and meaningful 
difference, and there appeared to be wide browser support in spirit - and the 
only question being about the timing of the phase in. Thus, it seems reasonable 
to begin discussing how to approach that - and it doesn't seem productive to 
suggest the community should not discuss this.

 

It's difficult enough to communicate these changes to consumers and
customers, and it really drives them nuts.  I can only imagine what a
non-integral number of years will do to various company's planning
and budgeting processes.

 

So this argues in favor of 13 months, rather than 18 months. The communication 
difficulties are not expanded upon here, but it seems that if CAs spent more 
time investing in interoperable automation, these communication issues would 
evaporate, because they'd no longer be an issue.

 

I would propose, instead, a minimum one year moratorium on proposals
to change the max validity period after the previous change to the max
validity period goes into effect.  That would make much more sense.

 

I'm sure to a CA it makes sense, especially if the argument is that change is 
hard for them to do. Yet, at the same time, attempts to propose moratoriums on 
misissuance by CAs have consistently failed. A moratorium on discussions on how 
to reduce risk only seems valuable if would also imposed a moratorium on trust 
for those CAs that have issues. Since I'm sure that's not desirable for CAs, I 
hope we can agree that discussions of how to reduce the risk of such issues is 
highly relevant and necessary to resolve.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 825 days success and future progress!

2018-04-02 Thread Ryan Sleevi via dev-security-policy 
On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>

So it sounds like you're supportive of 13 months, then, so that we arrive
at an effective and meaningful maximum.


> People have to stop wanting to constantly change the max validity period.
>

This is an entirely unproductive line of reasoning. The only reason that
we're at a point of discussing incremental approaches seems to be because
CAs resisted making meaningful steps all at once, and instead preferred a
phase-in, like SHA-1. Proposals were put forward to make it a significant
and meaningful difference, and there appeared to be wide browser support in
spirit - and the only question being about the timing of the phase in.
Thus, it seems reasonable to begin discussing how to approach that - and it
doesn't seem productive to suggest the community should not discuss this.


> It's difficult enough to communicate these changes to consumers and
> customers, and it really drives them nuts.  I can only imagine what a
> non-integral number of years will do to various company's planning
> and budgeting processes.
>

So this argues in favor of 13 months, rather than 18 months. The
communication difficulties are not expanded upon here, but it seems that if
CAs spent more time investing in interoperable automation, these
communication issues would evaporate, because they'd no longer be an issue.


> I would propose, instead, a minimum one year moratorium on proposals
> to change the max validity period after the previous change to the max
> validity period goes into effect.  That would make much more sense.
>

I'm sure to a CA it makes sense, especially if the argument is that change
is hard for them to do. Yet, at the same time, attempts to propose
moratoriums on misissuance by CAs have consistently failed. A moratorium on
discussions on how to reduce risk only seems valuable if would also imposed
a moratorium on trust for those CAs that have issues. Since I'm sure that's
not desirable for CAs, I hope we can agree that discussions of how to
reduce the risk of such issues is highly relevant and necessary to resolve.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: 825 days success and future progress!

2018-04-02 Thread Tim Hollebeek via dev-security-policy 
Yes, if we wanted to go to 13 months quickly, we would have gone directly 
there.  Getting to 13 months quickly is not a goal.  That’s not having it both 
ways, that having an understanding of how the ecosystem actually works.

 

The majority of the CAB forum, and not just CAs, but also many browsers, 
believe this sort of change so quickly after the most recent change, which came 
very quickly after the change before that, would be unnecessarily disruptive 
and unhelpful to the ecosystem.

 

-Tim

 

From: Alex Gaynor [mailto:agay...@mozilla.com] 
Sent: Monday, April 2, 2018 2:51 PM
To: Tim Hollebeek <tim.holleb...@digicert.com>
Cc: MozPol <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: 825 days success and future progress!

 

Hi Tim,

 

I'd have suggested an even shorter period, say 13 months, except I anticipated 
CAs would object that it was too great a change too suddenly, precisely as they 
did when this subject was last discussed!

 

While I appreciate that changing BRs can be difficult for customer 
communications, the fact that we are doing this in multiple steps instead of in 
one fell swoop is a result of CAs saying such a big leap was too disruptive. 
Frankly, you can't have it both ways.

 

Alex

 

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> > wrote:

18 months is not significantly different from 825 days.   So there's really
no benefit.

People have to stop wanting to constantly change the max validity period.
It's difficult enough to communicate these changes to consumers and
customers, and it really drives them nuts.  I can only imagine what a
non-integral number of years will do to various company's planning
and budgeting processes.

I would propose, instead, a minimum one year moratorium on proposals
to change the max validity period after the previous change to the max
validity period goes into effect.  That would make much more sense.

-Tim


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy- 
> <mailto:dev-security-policy-> 
> bounces+tim.hollebeek=digicert@lists.mozilla.org 
> <mailto:digicert@lists.mozilla.org> ] On Behalf Of Alex
> Gaynor via dev-security-policy
> Sent: Monday, April 2, 2018 1:07 PM
> To: MozPol <mozilla-dev-security-pol...@lists.mozilla.org 
> <mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
> Subject: 825 days success and future progress!
>
> Afternoon all!
>
> A month ago a new BR rule went into effect, putting a maximum validity
period
> of 825 days on newly issued certificates.
>
> Truthfully, I was expecting tons of CAs to screw up, forget to implement
it, or
> have no technical controls, and there to be tons of miss-issuance.
> To me delight, the results have been pretty good:
> https://crt.sh/?zlint=1081 
> <https://crt.sh/?zlint=1081=2018-03-01> =2018-03-01 
> the majority of
> violations have been from the US Government (whose PKI isn't remotely BR
> compliant, nor trusted by Mozilla).
>
> In light of this incredible success, I think it's time to begin a
discussion on what
> the next in this chain is. While obviously actually encoding this in the
BRs will
> be a function of the CABF, as mdsp is the premier public discussion forum
for
> the PKI, I wanted to start here.
>
> I propose that our next target should be a max validity period of 18
months
> (~550 days), starting in ~6 months from now.
>
> The value of shorter-lived certificates has been discussed many times, but
to
> rehash: They afford the ecosystem significantly more agility, by allowing
us to
> remove mistakes in shorter periods of time without breaking valid
certificates.
> It also encourages subscribers to adopt more automation, which further
helps
> with agility.
>
> Alex

> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org 
> <mailto:dev-security-policy@lists.mozilla.org> 
> https://lists.mozilla.org/listinfo/dev-security-policy

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 825 days success and future progress!

2018-04-02 Thread Alex Gaynor via dev-security-policy 
Hi Tim,

I'd have suggested an even shorter period, say 13 months, except I
anticipated CAs would object that it was too great a change too suddenly,
precisely as they did when this subject was last discussed!

While I appreciate that changing BRs can be difficult for customer
communications, the fact that we are doing this in multiple steps instead
of in one fell swoop is a result of CAs saying such a big leap was too
disruptive. Frankly, you can't have it both ways.

Alex

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek 
wrote:

> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>
> People have to stop wanting to constantly change the max validity period.
> It's difficult enough to communicate these changes to consumers and
> customers, and it really drives them nuts.  I can only imagine what a
> non-integral number of years will do to various company's planning
> and budgeting processes.
>
> I would propose, instead, a minimum one year moratorium on proposals
> to change the max validity period after the previous change to the max
> validity period goes into effect.  That would make much more sense.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Alex
> > Gaynor via dev-security-policy
> > Sent: Monday, April 2, 2018 1:07 PM
> > To: MozPol 
> > Subject: 825 days success and future progress!
> >
> > Afternoon all!
> >
> > A month ago a new BR rule went into effect, putting a maximum validity
> period
> > of 825 days on newly issued certificates.
> >
> > Truthfully, I was expecting tons of CAs to screw up, forget to implement
> it, or
> > have no technical controls, and there to be tons of miss-issuance.
> > To me delight, the results have been pretty good:
> > https://crt.sh/?zlint=1081=2018-03-01 the majority of
> > violations have been from the US Government (whose PKI isn't remotely BR
> > compliant, nor trusted by Mozilla).
> >
> > In light of this incredible success, I think it's time to begin a
> discussion on what
> > the next in this chain is. While obviously actually encoding this in the
> BRs will
> > be a function of the CABF, as mdsp is the premier public discussion forum
> for
> > the PKI, I wanted to start here.
> >
> > I propose that our next target should be a max validity period of 18
> months
> > (~550 days), starting in ~6 months from now.
> >
> > The value of shorter-lived certificates has been discussed many times,
> but
> to
> > rehash: They afford the ecosystem significantly more agility, by allowing
> us to
> > remove mistakes in shorter periods of time without breaking valid
> certificates.
> > It also encourages subscribers to adopt more automation, which further
> helps
> > with agility.
> >
> > Alex
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: 825 days success and future progress!

2018-04-02 Thread Tim Hollebeek via dev-security-policy 
18 months is not significantly different from 825 days.   So there's really
no benefit.

People have to stop wanting to constantly change the max validity period.
It's difficult enough to communicate these changes to consumers and
customers, and it really drives them nuts.  I can only imagine what a 
non-integral number of years will do to various company's planning 
and budgeting processes.

I would propose, instead, a minimum one year moratorium on proposals
to change the max validity period after the previous change to the max
validity period goes into effect.  That would make much more sense.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Alex
> Gaynor via dev-security-policy
> Sent: Monday, April 2, 2018 1:07 PM
> To: MozPol 
> Subject: 825 days success and future progress!
> 
> Afternoon all!
> 
> A month ago a new BR rule went into effect, putting a maximum validity
period
> of 825 days on newly issued certificates.
> 
> Truthfully, I was expecting tons of CAs to screw up, forget to implement
it, or
> have no technical controls, and there to be tons of miss-issuance.
> To me delight, the results have been pretty good:
> https://crt.sh/?zlint=1081=2018-03-01 the majority of
> violations have been from the US Government (whose PKI isn't remotely BR
> compliant, nor trusted by Mozilla).
> 
> In light of this incredible success, I think it's time to begin a
discussion on what
> the next in this chain is. While obviously actually encoding this in the
BRs will
> be a function of the CABF, as mdsp is the premier public discussion forum
for
> the PKI, I wanted to start here.
> 
> I propose that our next target should be a max validity period of 18
months
> (~550 days), starting in ~6 months from now.
> 
> The value of shorter-lived certificates has been discussed many times, but
to
> rehash: They afford the ecosystem significantly more agility, by allowing
us to
> remove mistakes in shorter periods of time without breaking valid
certificates.
> It also encourages subscribers to adopt more automation, which further
helps
> with agility.
> 
> Alex
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy