On 4/3/2015 3:39 PM, Dave Botsch wrote: > Hi, Jeff. > > The updates are very very much appreciated. Certainly, these changes > will make life interesting in the future. > > A couple of followup questions, if you know the answers... > > When MS implements the new signing changes, whenever that is, is it > expected that existing installations of the AFS client will break? Or > is it expected that those will break? Or that clients up to a certain > version, even if not yet installed, will work?
I understand that the situation is very complex and confusing. You can be rest assured that any system you have today that is running a driver that Your File System signed up to this point will continue to function in the future. Including if you upgrade such a Windows 7 system to Windows 10 with the driver installed. The problems are going to begin once Windows 10 is released to manufacturing because drivers signed after that point must be signed using the new process if they are going to continue to function after a system is upgraded to Windows 10. > Also, do you have to wait until MS "flips the switch" to be able to > submit the client for the certification/review process? Or will you be > able to do that earlier and get feedback with some sort of lead time? As I wrote yesterday one of the complications is that there is no well defined certification process for file systems. If there was a "Certified for Windows" logo that I could easily obtain for the AFS redirector drivers I would have done so years ago. Now there is a Catch-22. Drivers "must be certified in order to install on Windows Server" but "no certification process for file systems". There is no certification for file systems because the semantics of file systems vary so much. Just think about the varying capabilities of FAT vs NTFS vs ReFS vs CDFS vs CIFS vs AFS vs AuriStor vs NFS3 vs NFS4. It would not be possible to define a single set of tests that could cover all of them. The first step is going to be working with Microsoft to define a set of tests that must be passed and required features that must be implemented in order to be certified. The second step is going to be implementing the tests and any new code or architectural changes that will be needed. Finally, the certification submission will consist of the execution test results plus the drivers and any other supporting documentation. This certification will be required for each new revision of the driver to be signed by Microsoft. To clarify, certification is not a process by which a driver and its source code are given to a third party for analysis. For example you might be familiar with the FIPS 140-2 validation procedure for cryptographic libraries. This process is not like that. For most driver classes there exists a well defined set of tests and a functional requirement list. The tests are performed by the developer and the results are submitted to Microsoft along with the driver for review. Prior to signing a driver I suspect that Microsoft will also analyze the driver to ensure the apis it is calling are sane, that the driver is not self modifying, that it implements stack randomization, and other code hardening features. If I were Microsoft I would also examine the diffs between drivers with the same name to ensure that the code is similar to the prior submission. If it isn't I would ask for additional details before issuing a signature. This isn't an answer to your question but I hope it explains the current situation. > Finally, does the certification process itself cost $$? I think you are asking if there is a check that needs to be written to Microsoft for each request to certify and sign a driver. The answer to that is "no". However, there are many costs associated with getting to the point where you can submit a driver to be certified and signed. > I'm, of course, wondering if this change will be implemented with some > sort of update we can block. So far, the only publicity w.r.t. signing > I've heard from MS has been on web certs. So, I'm really surprised this > very major change hasn't been more publicized, yet. Regarding publicity. NIST deprecated SHA-1 for use in code signing certificates at the end of 2013. Microsoft announced on 14 November 2013 that SHA-1 would not longer be accepted for code signing after 31 December 2015. As I mentioned on 28 March the Microsoft pushed the most recent update to Windows 7 and Server 2008 R2 that adds support for SHA-256 as part of the March 2015 Windows Update. Blocking this update will only prevent a driver signed with a SHA-256 certificate from validating. While Your File System is currently signing with a SHA-1 certificate the new EV certificate we are receiving is SHA-256. One question I have to decide is whether it is worth the effort once the new signature program is in place for Your File System to issue two versions of each installer package: * one signed with the SHA-1 certificate for older systems * one signed with the EV SHA-256 certificate for everything else Once we reach 2016 there will not be a choice because it will not be possible to obtain or renew a SHA-256 Authenticode certificate. > Again, thanks so much for the heads up. I should also point out that there is no guarantee that Microsoft will be willing to certify OpenAFS because it might not be possible for OpenAFS to satisfy the agreed upon requirements. One example of a potential requirement is support for UNC Hardening. UNC Hardening was introduced by MS15-011 in February 2015. It is an architectural change to how file systems work to prevent man in the middle attacks against the Group Policy Service but is also relevant for protecting roaming profiles and redirected folders. It would be perfectly reasonable for Microsoft to require any network file system that supports roaming profiles and redirected folders to also support UNC Hardening. But there is no point in implementing UNC hardening for OpenAFS because the hardening guarantees cannot be enforced by AFS. The reason I attend Microsoft's IFS PlugFests is be aware of the requirements for new OS releases and to build the personal relationships necessary to jump hurdles such as this one. I have begun a conversation. It is going to be some time before I know where it will end. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
