You can see some of the results here.
In short, CMP mostly seems to work purely technical. What is cumbersome with the CMP protocol is that there are so many options. For a CA to say that you support CMP does not mean much. You must explicitly say which specific CMP work-flows, with technical details that you support. Otherwise it does not mean much. For example, how are enrolling clients authenticated? Common options include:
- Shared secret used for Password based MAC, where keyId is username (specified in profile in RFC). Shared secret must be in clear text in CA database, which is a down-side. Pre-registration of end entities needed.
- Shared secret with one-time password in regToken control. Pre-registration of end entities needed.
- Digital signature protected request message, where digital signature is based on an out-of-band issued certificate, possibly from another CA. Pre-registration of end entities needed.
- RA type application with Password based HMAC, where RA specifies the certificate contents in the request, and authenticated using a shared secret. No pre-registration of end entities needed.
- RA type application with digital signature authentication. No pre-registration of end entities needed.
The options virtually have no limits.
As you see it is a very large work to implement all options. The rule we use is that we implement options that we actually see usage of, which of course means that we need to improve continuously. I think it is the only way to work efficiently however, not to implement functions that will never be used. The downside is of course that someone can come along and find our implementation not supporting their use-case. Usually new things can be implemented with rather short investment.