I have been working with various PKI implementations since 2000, and I have two bits of advice for any new PKI deployment:
- PKI is not an end in itself, it is just a tool: before designing a PKI solution, you really need to know exactly what end solution you're trying to put in place: Windows Logon? VPN Access? Device authentication in your infrastructure? Email encryption/signature ? Web authentication? Once you know the requirements of your end solution, the choice of a PKI as a security layer for that solution will be far easier.
- The technical solution is the easy part: as can be seen on the other posts, there are plenty of Certificate Authorities around, all with their technical strenghts and weaknesses. What they do not address is the process part around PKI - the CP/CPS and others -, in other words how the PKI shall be used, who is allowed to do what, how the various components shall be protected, procedures defined to address various scenarios (administrator run over by a bus, role separation, administration procedures, key ceremony, key escrow, revocation policy, etc.). This is really the tricky part because it is what will make your PKI a really strong solution or just a gimmick...
As a conclusion, in some cases the Microsoft CA will be fine (say you mainly want to do smart card logon on a 'standard' Windows network), in other cases other solutions will be more suitable, but in every case, the hardest part (as in 'the most expensive part') will be the creation of the policies revolving around your PKI. If after analysis you find out a strong PKI policy does not seem that important in your particular case, chances are you don't really need a PKI but another form of strong authentication. For instance, 2 factor Auth based on one time password tokens or similar, which are much lighter to put in place from an admin point of view, though not quite as strong as PKI, of course...
Just my 2 cents,
Edouard
