I received the following note from my code signing certificate provider (Symantec, used to be VeriSign):
---------------------------------------------------
We are writing to tell you about Secure Hash Algorithm 256 (SHA-256 or SHA-2) support on Symantec Code Signing for Individuals and Symantec Code Signing for Organizations. SHA-2 was developed by the National Institute of Standards and Technology (NIST) and
is the recommended cryptographic hash function to replace SHA-1 by the end of 2014.
SHA-2 support is available starting April 1st, 2013 for the following Symantec Code Signing products: Microsoft® Authenticode™, Java™, Adobe® Air® and Microsoft® Office Visual Basic® for Applications (VBA). You will be able to select the option for SHA-2 through
the ordering pages, reissue process and via the Application Programmatic Interface (API) for QuickOrder, QuickInvite and Reissue.
Please note that some older applications and operating systems do not support SHA-2, for example, Windows™ XP Service Pack 2 or lower does not support the use of SHA-2. Java SDK 1.4.2 or higher needs to be installed and used on the server for SHA-2 support
for Java server support.
If you are using a Windows environment, please refer to the following blog for SHA-2 deployment:
http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx.
--------------------------------------------------------------------------------------
OK, so what does this mean for click once?
Should I just ignore this because the NIST recommendation is just a recommendation?
Is the security problem big enough I should talk about upgrading all my downlevel clients (Windows XP SP 2 and Windows Server 2003). I've got 10k+ customers out there, this won't be simple.
Does Microsoft have any further guidance about how this related to click once?
So click once uses two manifests, an application manifest and a deployment manifest. I always get the names confused. My product allows assignment of different versions to different users, so one of these manifests (the one with all the build
files) is signed at the time the build was done, and the other is signed at the time the user first logs into the system. This could mean that since builds hang around for years, the manifest tied to the build would stay SHA-1, while the corresponding
manifest tied to the user will have a SHA-2 sign. Will windows accept this kind of a chain, and allow an install?
The question is similar to a certificate upgrade, but not quite...
Thanks,
Darwin
----------------------------------------------- "Cannot find reality.sys ... Universe Halted!"