>Precisely! And I’m all for authenticode signing. That’s exactly what I was
talking about, in place of this misbegotten policy.
I am for authenticode with my own signature, but not Microsoft’s one.
Apparently, there is a guy or two in Microsoft pushing their stupid ideas
about driver signing.
There’s absolutely no point to check driver signatures at boot time, when
the root certificates are not available. The signatures should be checked
while the drivers are installed. Installed drivers should be hashed and the
checksums stored somewhere. At boot time, Windows just re-checks the
checksums not bothering with signatures.
One can say that someone can hack the checksums stored. Well, if one can
hack the checksums, they can easily hack the code that validates the
signatures, too.
My guess is, the Microsoft/Verisign monopoly’s idea of signing drivers with
their own signatures is nothing more than an attempt to suck out hundreds of
dollars a year from developers. Just another way to get money flowing in.
wrote in message news:xxxxx@ntdev…
Yeah…
Precisely! And I’m all for authenticode signing. That’s exactly what I was
talking about, in place of this misbegotten policy.
You say load-time authenticode validation can’t be done easily. We must
have different ideas of the meaning of “easily” – Calling out to user-mode
when a driver’s loaded isn’t likely to be TRIVIAL, but by the same token,
consider that this is precisely how most anti-virus programs work
(intercepting the file open, and passing the file spec to a user-mode
scanning program). Given the frequency with which drivers are loaded, it’s
not like this is a high-performance path.
I could give you the names of at least a half dozen devs in 26 or 28 that’d
be up to the task. If they’re too busy keeping themselves out of bug jail,
I’m sure Don would be happy to write the code… for a very reasonble fee 
P