On 28/03/2017 16:13, Ryan Sleevi wrote:
On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
In principle any source of information could change just one minute
later. A domain could be sold, a company could declare bankruptcy, a
personal domain owner could die.
Yup. And we balance the usability tradeoff.
For smaller organizations (i.e. not Google), requesting and deploying
new certificates every few years is a real hassle,
And that's a bug and needs to change. Plain and simple, that doesn't work
for security. But perhaps we're getting further off-topic, other than I
think the crux of your objection is that "Replacing certificates is hard",
when the reality is we should be striving to replace certificate every 90
days or less, and work to address the systemic and organizational issues
that prevent this.
and often a
non-trivial expense. Forcing the paid, carefully validated
certificates to be repurchased and reinstalled a lot more often imposes
a real burden on real websites and real e-mail accounts.
The previous CAB/F rule of 3 years max seemed to be a useful
compromise, only slightly more difficult than the old 5 year offering
from some CAs, and well within reason as to handling the frequency of
ordinary changes in domain and company ownership/status that occur in
the real world.
Unfortunately, that's long been held as undesirably long by browser
members, based on the surveys for several years. Unfortunately, CAs have
not been terribly interested in aligning this.
The somewhat sudden (to outsiders) tendency to force frequent
certificate replacements for those not using "Let's encrypt" seems
arbitrary, harmful and mostly pointless.
Right, I think this philosophical difference - one in which I very much
think is actively harmful to security, even though I think it's a totally
understandable and reasonable position for you to hold - is perhaps the
crux of the objection on validating information. And that's useful to
acknowledge up front, and since we've arguably beat this horse to death,
acknowledge that it's merely a position statement being provided, and the
philosophical differences mean it's unlikely for everyone to be happy.
Just because you happen to disagree doesn't make it an invalid point to
make when someone explicitly asks if it would be a good idea to lower
the max to 1 year *before* the "bug" of certificate deployment being
hard has been fixed.
While some parts of the "bug" are about tools and instructions (I have
posted some suggestions to help in that area), there are fundamental
intractable parts:
1. Strong validation *by necessity* must involve interacting with high
ranking humans in ways that are sufficiently non-trivial to avoid
being faked by phishing attacks.
2. Securely generating and deploying private keys for new certificates,
and securely ensuring the right private key is used in a non-ACME
certificate request (of any form), *necessarily* involves non-trivial
security procedures on the part of the certificate holder.
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
