[cabfpub] FW: FW: CAB Forum Policy Change request

[Rick Andrews]

Reposting to the public list with permission.

-----Original Message-----
From: WILEMON, ANDREA A [mailto:aw8139 at att.com] 
Sent: Friday, October 02, 2015 1:00 PM
To: Sigbjørn Vik ; public at cabforum.org
Cc: Rick Andrews; Shannon Ortiz; Mark Kelly; MCROBERTS, JOHN M; GALLAGHER,
TIM; THOMPSON, TIMOTHY R
Subject: RE: [cabfpub] FW: CAB Forum Policy Change request

Sigbjørn,

While storing certificate key pairs in secure USB drives in a locked safe is
a good solution for smaller companies, manually managing and distributing
large volumes of certificates within one year is not feasible in a large
enterprise environment for the following reasons: 

-	We have almost 10,000 SHA-1 certificates due for conversion to
SHA-256 by January 1, 2017.  These certificates are spread across many sites
within the United States and international. 
-	Our security policies don't allow sensitive data, the private keys
in this case, to be stored on portable drives such as USB, including secure
hardware versions.
-	Password protected Zip files are not approved in our secure crypto
tool suite for protecting sensitive data which in this case is the private
keys.
-	We could deploy the proposed option but it would be an deemed an
insecure solution within our enterprise and places our private keys at risk
for compromise. 
-	A secure deployment will require additional resources to build-out
and manage across our many locations for a short-term temporary solution.  

Each certificate has a unique thumbprint, serial number and is time stamped
by the CA at issuance.  This proposal will require the contacts for each
SHA-1 certificate to create the private key, enroll the CSR, install the
certificate to create the key pair and copy the new key pair to another
location for storage.  We do not allow applications to copy private keys
from the server home key stores to reduce risk of extending a compromise to
multiple servers.

Your interpretation of our request is correct.  We are asking for an
exception to the SHA-1 certificate issuance deadline to support applications
requiring new SHA-1 certificates for a short time frame in 2016 while
completing migrations to SHA-256.  We are not asking for an extension past
the CAB Forum SHA-1 deprecation deadline of December 31, 2016.  If the goal
is to reduce SHA-1 certificate use in 2016 by halting issuance now, we will
still have the same number of SHA-1 server certificates in use next year
regardless of whether we issue them now or in 2016 with less-than-one year
validity.  

We do not advocate use of vulnerable browser products.  Our internal
standard is Internet Explorer v11 with the current security patches.  

Andrea
 
Andrea A. Wilemon, CISSP
Principle-Technology Security

Rethink Possible® 

Chief Security Office, Mobility, Cloud & Enterprise Security AT&T Services,
Inc.

P: 248-424-4115
aw8139 at att.com

Send #X before you drive to pause the
conversation until you arrive. 
Take the pledge... It Can Wait.

This e-mail and any files transmitted with it are the property of AT&T, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed. If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at 248-424-4115 and delete this
message immediately from your computer. Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited."

-----Original Message-----
From: Sigbjørn Vik [mailto:sigbjorn at opera.com]
Sent: Thursday, September 17, 2015 8:24 AM
To: public at cabforum.org
Cc: WILEMON, ANDREA A
Subject: Re: [cabfpub] FW: CAB Forum Policy Change request

On 16-Sep-15 00:44, WILEMON, ANDREA A wrote:

> 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.

Here is a solution which doesn't require any time to build:
Order your certificates, and store them all in an encrypted .zip file on a
USB drive.
Store the drive in a safe.
Make sure that no one person has the both the code to the safe and the .zip
password. Any access to the .zip file thus requires at least two people
present, and you may add more policies as wanted.
Any requests for certificates are routed to these people.
(A backup drive in a different safe is optional, so is the use of secure USB
HW.)

> We can't issue generic certificates and update them later with the 
> Subject Distinguished Name (DN) values

You would need one certificate for each subject name. This is the same
whether they are issued now, or next year.

> We are not asking to extend the SHA-1 deprecation deadline.

You are asking to extend the SHA-1 issuance deadline.

> those browsers that do not support SHA-1 certificates through 2016 
> will quickly be retired from our environment.

Two points:
* I read what you wrote as "If some browsers tighten their security, we will
retire them", which I interpret as "If CABForum supports our use case, we
will use the most insecure browser available". That sounds like a very good
reason not to support the use case.
* If you are able to control the environment and retire browsers, you are
also able to install custom roots, in which case you may consider that as a
solution instead.

--
Sigbjørn Vik
Opera Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5749 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151002/5efb5470/attachment.bin