Hi,
I understand that with the CMP implementation we've submitted a huge chunk of
code and it is probably not trivial to do the needed checks to ensure the
OpenSSL project's quality requirements for integrating it.
I'm a little concerned that this request might eventually be forgotten as the
request ticket hasn't been seen any update in the RT for ~9 weeks after we have
submitted the latest code update to enable also using the lightweight HTTP
implementation for transfer (as more or less suggested).
For planning our further work on that it'd be very helpful if somebody could
help me understanding where this request for integration might go.
Is there any chance for getting an owner for that assigned in RT? ;-)
Kind regards,
Martin
-Original Message-
From: ext Viljanen, Miikka J. via RT [mailto:r...@openssl.org]
Sent: Thursday, August 15, 2013 3:39 PM
To: Peylo, Martin (NSN - FI/Espoo)
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #3101] [PATCH] Add CMP (RFC 4210) implementation
Hi,
I just noticed that I had sent this reply only to the openssl-dev list
and not to the request tracker, so I'm sending it again here. I also
slightly updated the patch file and generated it against the latest
OpenSSL snapshot.
On 5.Aug.13 15:09:26, Viljanen, Miikka J. via RT wrote:
On 2.Aug.13 14:22, Stephen Henson wrote:
On Fri Aug 02 10:23:05 2013, martin.pe...@nsn.com wrote:
- the code in crypto/cmp also includes the functionality to perform the
most important cmp message sequences via HTTP. This code depends on
libcurl, so it is split into its own library (libcrypto_cmpseq.a) in
order to help deal with the circular dependency when curl is also
linked with openssl.
There is some minimal HTTP code which the OpenSSL OCSP library uses and some
functions to download certificates and CRLs. Could you use that and avoid
the
curl dependency?
The minimal HTTP implementation in OCSP might also be sufficient for what's
required by CMP. We will look into using that instead of libcurl, and get back
to you.
We have now adapted the HTTP code from OCSP and use that by default. In case it
is needed to have a full-featured HTTP implementation we have left using curl as
an option during build (`config curl`). Which one of the HTTP implementations
is used is hidden from applications behind the API.
In case libcurl is used there is now no separate library created anymore. It is
expected that the users explicitly deciding that curl is to be used resolves the
circular dependency manually on their own.
Now we basically just copied the HTTP code from OCSP, adding the option to use a
proxy on top. In the future it might make sense to refactor the HTTP code from
OCSP and CMP into its own HTTP client part and use the same in both clients.
The “new” HTTP implementations were successfully tested with the publicly
accessible Insta Certifier and EJBCA implementations. Text included below is
the updated text of the mail we had sent directly to the opensl-dev mailing list
for details how to build/test.
best regards,
Miikka and Martin
## UPDATED FULL PATCH DESCRIPTION #
We have developed a patch for OpenSSL adding the client side functionality of
the Certificate Management Protocol (CMP), as defined in RFCs 4210 and 4211.
The code was developed over the last six+ years and is now mature enough that
we'd like to offer it for inclusion in OpenSSL. We submit the patch with the
CMP code attached to this email also to openssl-b...@openssl.org as advised
in the README file. We will follow comments and participate in discussions
related to the patch on this mailing list.
At the moment, CMP is used mainly for 3GPP specified mobile networks but as
more implementations become available we expect to see more use of the
protocol. The relevant 3GPP Technical Specification 33.310 profiling CMP usage
is freely available at http://www.3gpp.org/ftp/Specs/html-info/33310.htm.
The code has been publicly available through SourceForge so far and we have
received reports that it is also used successfully by other major players in the
telco industry. The API has remained stable for a while now and we don't see
the need for drastic changes in the future. We are going to continue supporting
the CMP code after it has been inserted into OpenSSL at least by supplying
needed bugfixes, potentially also by adding more functionality. Others have
been able do meaningful changes to our code in the past, so we are confident
that it is understandable and well commented.
There are several CMP enabled CA implementations reported to be interoperable
with our client implementation, examples are EJBCA http://www.ejbca.org and
Insta Certifier http://www.security.insta.fi.
--- PATCH CONTENT ---
The patch contains the ASN1 definitions for structures used in the CMP protocol
(CMP from RFC 4210 and CRMF from RFC 4211) and functions to create and process
