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 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 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&minNotBefore=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.
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
