Tuesday, June 7, 2011

CMP interoperability

I have been making more tests, and some improvements, on CMP interoperability for EJBCA.

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.
  • Etc...

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.

2 comments:

Anonymous said...

This is a great summary, since it's exactly what we do for CMP as well. It's kinda hard explaining to users that CMP isn't a standard but a bunch of ideas, many of them described only vaguely, and if you want anything beyond the lowest-common-denominator stuff, "issue a cert", "revoke a cert", that sort of thing, you're looking at custom programming to get it done. CMP is like a large box of lego, there's a lot of assembly required, and anything a bit out of the ordinary is a custom build of lego pieces.

(The fact that the protocol was never actually implemented by the folks who dreamed it up doesn't help, there are chunks of CMP that are incomprehensible, illogical, and sometimes non-functional as documented).

Anonymous said...

This is a great summary, since it's exactly what we do for CMP as well. It's kinda hard explaining to users that CMP isn't a standard but a bunch of ideas, many of them described only vaguely, and if you want anything beyond the lowest-common-denominator stuff, "issue a cert", "revoke a cert", that sort of thing, you're looking at custom programming to get it done. CMP is like a large box of lego, there's a lot of assembly required, and anything a bit out of the ordinary is a custom build of lego pieces.

(The fact that the protocol was never actually implemented by the folks who dreamed it up doesn't help, there are chunks of CMP that are incomprehensible, illogical, and sometimes non-functional as documented).