[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

[Dimitris Zacharopoulos]

On 10/2/2017 11:50 πμ, Gervase Markham via Public wrote:
> On 09/02/17 17:31, Christian Heutger via Public wrote:
>> 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.
> 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?
>
>> As I understood the discussion, 1 year is the first step on a road to
>> months or weeks.
> Well, if you still haven't sorted out automation by the time someone
> proposes months or weeks, you can oppose it then :-)
>
>>> I'm sure there are plenty of CAs, big and small, who would assert
>>> their automation solutions are secure. :-)
>> 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.
> 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.

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.

Since we are talking about the Baseline Requirements, IMHO the 27 months 
proposed in the recent Google S/MIME policy 
<https://support.google.com/a/answer/7300887> (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).


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/edb7b3f9/attachment-0003.html>