It all started with a product that I work on, needing dbghelp.dll so it can give its own functionality using dbghelp functions. Since all binaries released were required to be signed, and dbghelp.dll in use was not signed by Microsoft, there rose a question as to whether it is ok (legally) to sign Microsoft’s dbghelp.dll with the company certificate even though we did not write all that code. It is kind of strange to sign a redistributed dll with a certificate issued for code-signing in that sense but the reasons for some kind of signature in this case were three fold
(a) End user or administrator or software can verify whether the file has been changed after installation. Presumably the change is with malicious intent.
(b) End user or administrator or software can establish, without guarantee, the origin of the file on the system.
(c) All binaries from the product installer have a signature – which is a good requirement to meet.
However the intent is not to indicate that the code is from the signing company which presumably would be illegal. The intent also is not to endorse that code meets certain quality requirements (like WHQL certifications for example). So looking at it from technical/end-user standpoint, it is obvious how signing of this nature can be easily misconstrued unless the purpose of signing is somehow further differentiated and clearly highlighted in a signature, into separate categories such as
1. this is code written by us and we are signing it to prove it to ourselves and others that it is from us. This is the most prevalent use of code signing certificates.
2. this is redistributed code we need and trust to be good because we have tested with it and therefore we are signing or resigning it so a self-trust can be established between components.
3. this is redistributed code we are signing (resigning) to establish that we are the source of redistribution and because the original source did not (did) sign the code.
May be X.509 has a solution to this problem that I am not aware of but I had to run it by our ISV Architect Evangelist at Microsoft and after couple of email exchanges it was clear that license.txt and redist.txt found at the root of Debugging Tools For Windows installation directory conferred redistribution rights but limited modification of binary. Technically signing a binary with the signature embedded in the binary, could be considered modification because the binary file is modified after all. Signing a binary could also be argued to be no modification because signature bytes added are not really part of the binary because if it was, then signing a binary changes it and therefore it would be a catch-22. Also if signature is a modification, re-signing will invalidate the first signature.
Thankfully 6.8.4.0 dbghelp.dll in the latest Debugging Tools For Windows is signed by Microsoft so we simply switched to that version and put the immediate issue to rest. But if we were not lucky and Microsoft did not have a signed version, would it be completely left to lawyers to figure this one out or are there any generally accepted legal guidelines about signing and/or re-signing redistributed binaries that we as software engineers are supposed to be aware of ?
