CMP for OpenSSL

Interoperation with the Insta Certifier from Insta DefSec is work in progress.

They operate a demo service! Right now (2008-06-04) it is running Certifier version 3.3.

The IR sequence is working with versions 3.3 and 3.2.1, it was reported that KUR would be working with 3.3.

Compatibility modes
Version 3.3 brought huge improvments to the RFC conformity. To stay compatible with the older versions, we're having two compatibilitiy modes that may be set using CMP_CTX_set_compatibility(...) in the API:
"CMP_COMPAT_INSTA" for 3.2.1 (and maybe prior)
"CMP_COMPAT_INSTA_3_3" for 3.3 (and maybe later)

The cmpclient accepts "--insta" and "--insta3.3" to set the version to interact with.

Untested issues version 3.3:
It might be possible that the Certifier doesn't like the date to be set and requires to have the CRMF version set. This is done in 3.3 compatibility mode but untested what happens if it is done different.

Known issues version 3.2.1:
Insta requires to have a path (with trailing slash!) in the server URI of the HTTP which can now be set with the --path CLA of cmpclient. The demo version (3.2.0) seems to require this to look like "POST http://pki.certificate.fi:8700/pkix/ HTTP/1.1", while version 3.2.1 requires it to look like "POST /pkix/ HTTP/1.1". So far, in revisions up to 17, the first one is used while it was switched to the latter one when activating Insta compatibility.

It answers with HTTP messages using "Transfer-Encoding: chunked". This can be decoded by CMP for OpenSSL.

In messages conveyed by HTTP, there are 7 octets added before the actual CMP message. As specified in the weird IETF transport protocol draft, this is the useless (since redundant) extra header also specified for transport over TCP.