<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/2/2017 11:50 πμ, Gervase Markham
via Public wrote:<br>
</div>
<blockquote
cite="mid:379665b7-4cce-4b31-694d-ad6a5c988e9d@mozilla.org"
type="cite">
<pre wrap="">On 09/02/17 17:31, Christian Heutger via Public wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I don’t believe, moving faster is required for normal situations. If
there are issues arising needing faster reaction, revocation and
reissue is still a possible way. For normal situations, enterprises
need to be able to react and they can’t move faster. Why are most
enterprises skipping one Windows version and roll out the next one?
As they are not able to move faster in controlled enterprise security
environments.
</pre>
</blockquote>
<pre wrap="">
If the effort of replacing a certificate is equivalent to the effort of
deploying a new version of Windows, then something is very wrong in that
environment.
We need to get to a place where replacing the security certificate in
_any_ server or appliance is a simple and easily-automatable job. How do
you propose we get there?
</pre>
<blockquote type="cite">
<pre wrap="">As I understood the discussion, 1 year is the first step on a road to
months or weeks.
</pre>
</blockquote>
<pre wrap="">
Well, if you still haven't sorted out automation by the time someone
proposes months or weeks, you can oppose it then :-)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I'm sure there are plenty of CAs, big and small, who would assert
their automation solutions are secure. :-)
</pre>
</blockquote>
<pre wrap="">
But as you know, there is nothing, which is 100% secure and if we
talk about certificates in their sense of encryption and(!) identity
assurance, such job shouldn’t be based on automatism.
</pre>
</blockquote>
<pre wrap="">
I suspect you will find that automated systems are, in fact, more
reliable and secure than manual ones. People doing things manually can
make mistakes. This is why sysadmins like automation.
</pre>
</blockquote>
<br>
SSL/TLS certificates are used for more than web services. In fact,
almost all server-side SSL/TLS implementations (FTPs, LDAPs, IMAPs,
POP3s, SMTP, etc) use publicly trusted SSL Certificates. Some of
these certificates belong in Federated Services which are also hard
to replace and usually require out-of-band communication. Replacing
these certificates manually (automation techniques are not mature
enough for these systems), requires significant work effort. This
additional effort has not been calculated for Subscribers and will
catch them by surprise, even if they have to deal with it by July
2018.<br>
<br>
Since we are talking about the Baseline Requirements, IMHO the 27
months proposed in the recent <a
href="https://support.google.com/a/answer/7300887">Google S/MIME
policy</a> (more or less, the same arguments apply for both
certificate types) is a reasonable number that will bring consensus
among all participants in the ecosystem (CAs, Subscribers, Browsers,
Relying Parties).<br>
<br>
<br>
Dimitris.<br>
</body>
</html>