Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upcoming PR for CMP (RFC 4210) extension, advice welcome #5926

Closed
mpeylo opened this issue Apr 10, 2018 · 6 comments
Milestone

Comments

@mpeylo
Copy link
Contributor

@mpeylo mpeylo commented Apr 10, 2018

Hi,

David von Oheimb (DDvO) from Siemens and I (mpeylo) from Nokia are planning to create a pull request for the CMP (RFC 4210) extension for OpenSSL in the near future. Even before the official pull request, we would enjoy if the community could already provide any possible thoughts and advice additionally to the generic contribution hints.

The latest code can be found at https://github.com/mpeylo/cmpossl in the "cmp" branch (our long-time SourceForge repo is nowadays discontinued).

The last rebase to OpenSSL master happened on 2018-04-10. Future rebases, done every couple of months and latest before any new pull request, will usually end up in the same "cmp" branch, sqashing all CMP-related commits into one single one, and archiving individual commits into new branches. Therefore, for successfully updating local "cmp" branches, rebasing will require either a fresh "git clone" or "git reset" to the remote branch.

There are extensive man pages for the cmp app and the library API. A quick-start guide is available, including references to a publicly available test server: https://github.com/mpeylo/cmpossl/wiki

The issue tracker with feature requests and bug reports can be found here: https://github.com/mpeylo/cmpossl/issues

We are currently in progress to close outstanding feature requests, and known “bugs”, prioritized to be done before upstream contribution. The most relevant outstanding tasks are polishing-related: increasing the number of unit tests and interoperability tests, consolidating the API, and improving compliance with the OpenSSL coding style. In parallel, David has started carving out and separately contributing general improvements which would also add value for other OpenSSL applications.

It has been over 5 years since the first attempt to submit the CMP patch as legacy RT item # 3101. Since then, a lot of things have happened, in the OpenSSL project, and also on the CMP code. All needed CCLAs, ICLAs are in place, and we have been busy implementing any explicit and implicit advice we got hold of over the years.

We are very close to having the extensive feature set prescribed by the RFC as minimum for standards compliance, with the missing pieces not really supported by any current server-side implementation. For message transfer, there is plain HTTP and also TLS (so HTTPS) support. One can make use of OCSP and CRLs and OCSP for CMP server validation, and use CRLs and OCSP including stapling for TLS server certificate validation.

The main CMP code is in crypto/cmp/, crypto/crmf/, apps/cmp.c, plus headers, documentation, test cases in their usual locations. While making extensive use of it, there is little interference with the other OpenSSL code, besides the absolutely needed additions to build scripts etc.

For quality assurance, we utilize static code analysis and did fuzz testing with leading commercial tools. The API and application documentation is rather complete and extensive - we might even slightly reduce it again along with the ongoing API consolidation. We regularly build on Linux (gcc) and Windows (with both, gcc on cygwin and Visual Studio).

We are constantly testing interoperability with both Insta Certifier and EJBCA, which leads to having a superset of the CMP features they’re implementing. Further, we became aware that there has been successful interoperability testing with other CMP-enabled CAs like RSA BSAFE and Nexus Certificate Manager in the past, at least for the basic set of CMP functionality. Also Wireshark includes a nicely working CMP dissector.

The work on CMP functionality was started by Nokia in 2007, with the main use case for 3GPP-specified LTE base stations. Since 2015 Siemens has become a very active user of and contributor to the CMP code.

There are several rather silent users of the CMP protocol and code; over the years individuals working in the fields of telecommunications, networking, academia, banking, and cloud have been reaching out when they had any questions using the code. Besides the use of CMP in 3GPP specifications, in LTE (aka 4G) and very likely also in the future 5G specifications, there is nowadays also standardized use of CMP in European Train Control Systems. While it might not be public when or where this CMP code is actually used, it is unlikely that there would be other open source or relevant proprietary CMP implementations which wouldn’t be based on this well-featured and nicely working FOSS CMP code.

As mentioned above, any thoughts and advice are very welcome!

Kind regards,
Martin and David

@primetomas

This comment has been minimized.

Copy link

@primetomas primetomas commented Apr 11, 2018

This would be a great addition to openssl.
I know lots of companies using CMP for all sorts of use cases, telco, industrial, IoT, token management, etc. I've tried out cmpforopenssl and it works really great to create very nice automated PKI workflows for almost any usecase. Everyone is using openssl already, so having this capability is fantastic.

Regards,
Tomas

@levitte

This comment has been minimized.

Copy link
Member

@levitte levitte commented Apr 11, 2018

Hi,

RT # 3101... that brings back some vague memories ;-)

I just looked through the current main commit, and noted a few things that you need to be aware of:

  1. some time ago, we decided not to polute the namespace like we've done before. That means that any new public API need to have an OpenSSL specific prefix, either OSSL_ or OPENSSL_. See for example include/openssl/store.h. Older already established bundles of symbols get to keep their names as they are. This applies to all public or exported symbols, be it macros, function names, global variables, types, ... (exported symbols means non-static function names and global variable names, because they are public symbols in static libraries)
    To be clear, this does not apply to openssl sub-commands, or public header file names (they are already prefixed with openssl/)

  2. A while ago, we started a scheme where test recipe specific data is stored in a directory parallell to the recipe itself and with almost the same name, see this explanation. Individual files can be reached with data_file("file.pem")... however, I noted that you want to pass the directory name to the test program, so I submitted a PR for that express purpose... all you'll need is to replace my $cmpdir=srctop_dir("test", "cmp-tests"); with my $cmpdir=data_dir(); in test/recipes/80-test_cmp_cli.t and git mv test/cmp-test test/recipes/80-test_cmp_cli_data

  3. I noticed there are some OpenSSL version dependent stuff... this is quite understandable for a project that wants to adapt to multiple OpenSSL versions. However, a CMP PR will obviously only be considered for the next feature release, whichever that will be. Adaptation to older OpenSSL versions can simply be cleaned away.

The timing is unfortunate... OpenSSL 1.1.1 is currently in its beta cycle, no new features will be added to it. The earliest a CMP PR can be considered for is OpenSSL 1.1.2 or 1.2.0, whichever we decide will be next. This is not a bad thing in itself, just something to be aware of.

@Behemoth17

This comment has been minimized.

Copy link

@Behemoth17 Behemoth17 commented Apr 11, 2018

Great to learn about this CMP PR !
On one side, we at Siemens Building Technologies widely use and appreciate OpenSSL; on the other side, we also strongly bet on CMP.
Recently, we have developed a successful proof-of-concept project -based on the former CMP patch for OpenSSL- for imprinting manufacturer certificates on the comfort controllers produced in our factory in Zug, Switzerland. It worked like a charm!
Our strategy is now to use CMP for handling all aspects of certificate management in our products and systems, as it fulfills so well all of our use cases.
... So, it would be wonderful to have the fundamental CMP functionality integrated into OpenSSL. That's why we welcome this initiative very much!

Regards,
Giorgio

@mpeylo

This comment has been minimized.

Copy link
Contributor Author

@mpeylo mpeylo commented Apr 12, 2018

Thank you for all the comments, especially to @levitte for the detailed advice - we'll implement that asap.

@stfries

This comment has been minimized.

Copy link

@stfries stfries commented Apr 13, 2018

Happy to see the CMP PR !
We are currently using CMP in the context of electric mobility in a funded project (FastCharge) in the context of the research and development program of the German Ministry of Transport and Infrastructure. As part of the project secure communication between the electric vehicle and the charging spot is integrated (based on ISO 15118) as well as the connectivity of the charging spot to the backend. The latter is necessary for the certificate management of the charging spot to enable its authentication towards the electric car. One specialty here is the application of short term certificates to avoid certificate revocation checks by the electric vehicle. The protocol of choice for the management is meanwhile the CMP, which copes best with the requirements of this use case. In contrast to other applications CMP messages are planned to be transported over the Open Chargepoint Protocol (OCPP). Up to now we made really good experiences with the existing CMP patch. We really welcome this integration into openSSL.

@mpeylo

This comment has been minimized.

Copy link
Contributor Author

@mpeylo mpeylo commented Jul 30, 2018

Pull request in #6811

@mpeylo mpeylo closed this Jul 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.