I just realized that the case

#if !defined(OPENSSL_NO_OCSP)

is not needed any more for the CMP client :)

Thanks @mattcaswell for your swift and helpful review comments!
I've solved all issues - except for the deeper structural one: what to do while waiting for certificate responses - and rebased the PR.

In the meantime: are there any other open issues with this PR?

I've taken another scan through this PR and noted a couple of minor issues below.

Thanks - I've just fixed these, along with various minor naming inconsistencies I realizied.
Moreover I've extended the documentation of the new CMP client functions.

As noted above I continue to have some concerns about the transfer_cb API and how errors are handled.

I've addressed these as well.

Other than that and the outstanding issue about what to do while waiting for certificate responses, I'm ok with this PR.

Very pleased to hear!
I was planning to re-structure the code to address the waiting issue today,
but was held up by other things and will do by Monday...

Note - the AppVeyor failure looks relevant:

..\crypto\cmp\cmp_client.c(301): error C2220: warning treated as error - no 'object' file generated
..\crypto\cmp\cmp_client.c(301): warning C4244: 'function': conversion from 'int64_t' to 'unsigned long', possible loss of data
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 

Note - the AppVeyor failure looks relevant:

Thx for the hint; this will be solved with my next update..

Thanks @Akretsch for your two review comments, which I've handled. Did this finish your pass?

@mattcaswell, are you fine with the implementation (including tests and documentation) of the new OSSL_CMP_try_certreq() function?

@mattcaswell, yesterday there was the usual false positive of Travis CI due to timeout; everything else went fine.
I've just done two cosmetic improvements according to @Akretsch's review and pushed the result, which gives the CI a new chance to report all-green.

Anything else to do on this chunk from your perspective?

Travis CI went fine this morning.
I've just rebased the PR and added two minor fixup commits that came up during rebasing #10587.

Rebased again, on the just merged #10504.

Great, thanks @mattcaswell

In preparation of merging this chunk tomorrow I've squashed it as much as I believe makes sense.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually.

Merged, closing :)

Sorry, can we please revert this one, it shot down my #11393
which addresses the same issue but in a slightly better way.

Given the size of this PR compared to #11393, it makes more sense to adjust #11393.

Okay, I have not looked at the whole picture.

I deliberately kept my change to strncpy in a separate commit: b4ba2b7, so it could be reverted easily.
Yet I do not see that replacing the function by memcpy would be better.

But in general I do not understand why every PR addresses so many different
topics at the same time. What is this good for?

It was a fixup of a CMP-related change.

strcpy implies zero-termination. memcpy does not,
that is the reason why there was this warning in the first place.
also the strcpy below is funny, because it implies
okay. then I close my PR. I can impossibly keep up with your speed.

AFAICS using memcpy with the same length is wrong.
In order to copy over the NUL termination one needs to copy sep_len + 1 bytes/chars.
This is what my solution does.

Semantically neither of the fixes is/was needed.
Just some compilers brought a (in this case misleading) warning.
BTW, also clang did so, which motivated my change.

also the strcpy below is funny, because it implies

Indeed. Yet interestingly at least clang did not warn on

strncpy(p, (const char *)ASN1_STRING_get0_data(current), length);

For this line I agree that using memcpy would at least look better because apparently it is not guaranteed that that ASN1_STRING_get0_data() is NUL-terminated.
Yet, also here it is semantically not relevant due to the final assignment *p = '\0'.

The warning is not semantically misleading, but as I said, go with your change,
my life does not depend on the memcpy

BTW, can you give me a hint how to use gcc-10 on the latest Debian edition (10.3 "buster")?
It currently includes gcc (Debian 8.3.0-6) 8.3.0.

build it from source. that is not yet released.

After getting around some build issues I meanwhile have a working gcc (GCC) 10.0.1 20200326,
and my SSD has some 9.5 GB less space.

OpenSSL builds (with --strict-warnings etc.) based on PR#11404 (which includes the merged commits of this PR#11300) with gcc-10.0.1 went fine without warnings.