[cabfpub] FW: CAB Forum Policy Change request

[Dean Coclin]

Re-posting to public list with permission


_____________________________________________
From: WILEMON, ANDREA A 
Sent: Tuesday, September 15, 2015 3:45 PM
To: Sigbjørn Vik
Subject: RE: [cabfpub] CAB Forum Policy Change request

Sigbjørn,

Our responses are below following your comments.

Andrea

Andrea A. Wilemon, CISSP
Principle-Technology Security
Chief Security Office, Mobility, Cloud & Enterprise Security
AT&T Services, Inc.

-----Original Message-----
From: Sigbjørn Vik 
Sent: Thursday, September 03, 2015 4:50 AM
To: public at cabforum.org
Cc: WILEMON, ANDREA A
Subject: Re: [cabfpub] CAB Forum Policy Change request

> This message is from the AT&T Services, Inc., Chief Security Office,
> Data Protection Team.

> 1) Symantec’s proposal involves changing thousands of SHA-1 certificates
> that will translate to a high volume of unplanned operations and
> workload churn.

Sigbjørn’s comment:
There is no need to replace certificates just because you got a new one.
I fail to see why the following wouldn't work: Get new certificates now,
and store them safely. Do not do anything with the existing
certificates. When you would otherwise replace a certificate with a new
one, instead of getting one issued, take a pre-issued one from your
secure storage and put that on your server.

Andrea's reply:
We considered this method.  This would be a good option except for the
volume of certificates that we have to manage.  The
secure-storage-until-needed-option presents many inventory management
difficulties in our environment:

*	A key escrow repository and inventory management system does not
exist, and there are not the resources or time left to build a temporary
solution.
		
*	Server certificates are different from software licenses in that
they are issued from our Symantec CA once with unique information per key
pair.  We can't issue generic certificates and update them later with the
Subject Distinguished Name (DN) values as PKI industry standards and the
technology require.  Each certificate owner has to enroll for new
certificates with unique Subject DN, Serial Number and Thumbprint values.
		
*	As mentioned above, there is no centralized secure repository for
the remaining SHA-1 certificates which are over 6,000 key pairs. The private
keys would be stored in many different locations by many different groups
which makes them difficult to track.
		
*	Without a secure repository system, the pending key pairs would most
likely be stored outside of properly secured containers which become a
security issue.  


> We request a policy change allowing Symantec to continue issuing
> less-than-one-year SHA-1 certificates after 12/31/2015 under their
> public trusted PKI hierarchy to support our remaining applications
> scheduled for SHA-256 adoption or retirement in 2016.

Sigbjørn’s comment:
The CABForum is working for a more secure web. This includes making
sunset periods for insecure methods. Whatever we decide to sunset, there
will always be someone struggling to meet the deadline, and a lot of
businesses moving at the last possible date. If we allow extensions of
the deadline, there will be even more problems next time, as businesses
will expect it to be moveable should they run into problems. When to
migrate is a business decision, by extending the deadline now, we reward
those making insecure decisions and punish those pushing the security of
the web forwards. Based on this, Opera is opposed to extending the deadline.

Andrea's reply: 
As mentioned before, we support the CAB Forum's work to increase Internet
security, as in this case to strengthen TLS encryption.   We are not asking
to extend the SHA-1 deprecation deadline. We are asking for access to
partial validity SHA-1 certificates in 2016.  Just to be clear, we are not
asking to extend the deadline for terminating use of SHA-1 certificates.
This will allow our remaining applications to complete their certificate
upgrades in 2016. 

Symantec notified customers about this change in 2014.  Our server
certificate migration path began in the second quarter of 2014 and the
majority of applications were upgraded to SHA-256 successfully.  However, we
have encountered roadblocks that delayed some applications from upgrading
from SHA-1 in 2015.  For example, hardware and software vendor support of
SHA-256 wasn’t available until as late as third quarter of 2015 in some
cases and required 2016 resource commitments for testing and implementation.



Sigbjørn’s comment:
Even if you get a CA to issue SHA-1 certificates in 2016, that doesn't
guarantee you that browsers would accept such certificates, browsers
will still only allow certificates they believe are in their user's
interest.

Andrea's reply:
We understand this point.  Internet Explorer (IE) is our standard and we
know IE will support SHA-1 certificates through December 31, 2016 which is
our deadline.  While other browsers are used in our environment, and others
may even be standards, those browsers that do not support SHA-1 certificates
through 2016 will quickly be retired from our environment.


-- 
Sigbjørn Vik
Opera Software


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150916/95753fb3/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150916/95753fb3/attachment-0001.p7s>