Assembly signing and certificate

Question

I find out the following scheme to protect the parts of the enterprise software by using custom Root CA. Is it a right way to do such thing? Has such way got some problems?

The sheme:

1. I have my custom Root CA. There is a set of the simple certificates, which were created by this CA.
2. There is a .NET assembly sets. The assemblies from set A signed with certificate A from my CA, the assemblies from set B signed with certificate B from my CA.
3. There is a set of client, which trust my CA (the have it's certificate in the Third-Party Root CA folder, in Certificate Snap-In).
4. The assemblies, which were signed with trusted certificate will be work fine, the assemblies, which were signed with untrusted certificate will not be work.
5. I revoke the certificate B (on my server with Root CA).

The questions:

1. Does information (certificate B was revoked) will be send to every client automatically by using OCSP?
2. Is every assembly load will make OCSP call by using internet connection? Is every computer with my assemblies will make such calls?
3. If one computer in the domain haven't got internet connection, it would countinue to trust revoced certificate?
4. Is it protected way - can the client break OCSP requests, block the address of my server or so on?
5. Is the certificate B will be automatically placed to the Untrusted Certificates folder on the client's server?
6. So, in general, can the client make my software work with untrusted certificate?
7. Is it possible to clear this certificate sign from the assemblies?

Answer 1

Assuming OCSP is properly configured:

1) The revocation should be stored in the Validation Authority database, and confirmed upon request. OCSP Responders will know of the revocation of certificate B. Clients should ask.

2) I don't know about an internet connection, but either the certificate provides a validation authority url to verify the certificate, or the client has one already configured. If such URL is an internet one, the answer is yes.

3) I think not, after all the certificate could be compromised. That said if you're using a custom root CA, you should need an internet connection. Network access yes, but no more.

4) The OCSP request is signed, so it wouldd take a big effort to compromise it and fake the response. It can be done, but i guess if someone can do that, it can do far more interesting things.

5) I think so. If the OCSP request is completed and the certificate is revoked, then it goes into Untrusted Certificates. That's windows standard behavior.

6) Thats a broad question, if you use a certificate for code signing, and it's performed by the CLR you should be able to load a signed assembly. But there may be a way.

7) I guess so, if you can open the assembly with ILSpy or similar tools, you may be able to get some version of the source code and recompile it. Same with ILDASM

Is it secure? Yes, pretty much. But if you need additional security you should offuscate your code and provide an internal validation step, something like an embedded certificate in the assembly that you explicitly validate via OCSP and any failure in the process prevents further use of your code.