Any PKI infrastructure you choose is bound to have it s up sides and it s downsides. I can tell you from experience that the Microsoft PKI products generally play pretty well with other Microsoft products but tend to have interoperability problems with other non-Microsoft products. Over time, my understanding is is that their oldest PKI products have gotten progressively more standards compliant, but they still have their quirks.
Time stamping authorities are useful if you have concerns about the replay of signed messages:
http://en.wikipedia.org/wiki/File:Trusted_timestamping.gif
But it means that every end entity will need to use that TSA when generating signatures.
If you re using your digital certificates for SSL, you won t need it, unique per-transaction proof of private key is part of the protocol. If you are doing web authentication, many authentication mechanisms will use either SSL client auth or do something to force the private key to sign a unique value to assure that there is no man in the middle attack.
I m not quite sure what you mean by "Signature Proof". If you mean including a random, and unique value in every hash to avoid replay attacks, then the same advice as TSA applies. But I m guessing here.
It will all come down to -- what are you using it for? how well does it need to perform? how do users and other systems need to interface with it?
Given that PKI is expensive, not matter how you slice it, you ll want to take some serious time thinking this one out. Between the cost of licenses, the cost of installation (manhours) and the cost of maintenance, it s a major commitment worth system level requirements development and design.