Rejected IR with MSG_SIG_ALG on IP with MSG_MAC_ALG leads to

[mpeylo]

If a IR with MSG_MAC_ALG leads to a IP with rejected, protected with a MSG_SIG_ALG, then the only issue shown might be that "no valid server cert found".

When MSG_MAC_ALG is used, no CA cert might be available yet to the client.

Therefore there could be more verbose output indicating the rejection.

[DDvO]

This must be due to an inadequate configuration of the client. If it has no means to verify the protection of the signed response message it will of course will not look into its payload. When equipped with a suitable trust anchor (using -trusted or -srvcert) it will be able to verify the protection of that response and then will output information regarding its (rejection) contents.

If you don't like this precautionary behavior of the client we could add a quirk similar to -unprotectederrors that allows interpretation of negative responses with a protection that cannot be verified. Though I don't think that's a good solution for security reasons and because very likely the client will need a proper trust anchor also to verify positive responses protected with a signature.

[mpeylo]

(this is mostly a note for me so I don't forget that)

Looks like as if -unprotectederrors doesn't work as expected for negative IP.

 -unprotectederrors    Accept unprotected error responses: regular error messages as well as
                       negative certificate responses (ip/cp/kup) and revocation responses (rp).
                       WARNING: This setting leads to behaviour allowing violation of RFC 4210

I got a MSG_SIG_ALG protected negative IP, where I gave the trust anchor, but the sub CA's / CMP server's cert was not available (neither in untrusted, nor in extracerts) this output:

apps/cmp.c:3996:INFO: using OpenSSL configuration file '/home/dems5uk4/NDAC/ndac-pki/RA/src/../local/ssl/openssl.cnf'
apps/cmp.c:4004:INFO: no [cmp] section found in config file '/home/dems5uk4/NDAC/ndac-pki/RA/src/../local/ssl/openssl.cnf'; will thus use just [default] and unnamed section if present
crypto/cmp/cmp_ses.c:186:INFO: sending ir
crypto/cmp/cmp_ses.c:212:INFO: got response
139745254712320:error:3607209D:CMP routines:find_srvcert:no valid server cert found:crypto/cmp/cmp_vfy.c:561:
trying to match msg sender name = /CN=TEST DA Sub CA 2019A/O=Nokia
  considering cert with subject = /CN=TEST DA Root CA/O=Nokia
 certificate subject does not match sender:
   actual = /CN=TEST DA Root CA/O=Nokia
 expected = /CN=TEST DA Sub CA 2019A/O=Nokia
no matching server cert found
139745254712320:error:360BA09C:CMP routines:OSSL_CMP_validate_msg:no suitable server cert:crypto/cmp/cmp_vfy.c:742:
139745254712320:error:360AA08B:CMP routines:OSSL_CMP_MSG_check_received:error validating protection:crypto/cmp/cmp_lib.c:1692:

[DDvO]

Also this is absolutely normal (and not a bug of the client). If the response message is signed and but the signer cert is not included in its extracerts the client has no chance to verify the protection even when equipped with some trust anchor. This situation can only happen due to a bug on the server side. What you can do as a workaround is to explicitly give the signer cert as -srvcert argument.

[mpeylo]

Security-wise, what's the difference between an unprotected message and one where the signature cannot be successfully verified?

[DDvO]

Well, I suppose in this case the signature can be verified after fixing the server's response or by using -srvcert on the client side as a workaround.

From the assurance level an invalid signature is of course equivalent to missing protection, but typically it is due to a bug or misconfiguration, which should be fixed, and otherwise I'd say it is more suspicious than a missing protection ;-)

[mpeylo]

While the scenario I have established above (during my issue hunting) is a bit quirky, it's not necessarily always a misconfiguration of the server if the client doesn't have the needed trust anchor to validate a signed error/rejected IP message.

E.g. when MSG_MAC_ALG is used in IR, the client might be waiting for an IP with caPubs to receive the needed trust anchor. If a signed but lacking the trust anchor not verifiable error message comes in this case, it is fully in line with the RFC section 5.3.21 "The CA MUST always sign it [error message] with a signature key".

There's no reason why the client should handle errors/rejected IPs with with no protection or protection which cannot verified differently when -unprotectederrors is set. If the protection which cannot be verified is due to an MITM attacker, then the attacker could with the same effort also just remove the protection. Therefore, the suspicious-level is pretty much the same.

[DDvO]

I was a bit confused since you wrote earlier that

the sub CA's / CMP server's cert was not available (neither in untrusted, nor in extracerts).

If the CMP server sends a signed response it should include its signer cert in the extraCerts. If it fails to do so the client has little chance to find out which cert it can use for verifying the signature and to obtain a copy of it. Independently of that, the client needs a trust anchor and potentially intermediate certs (or it might already know in advance and trust the signer cert, in which case it can be given via -srvcert).

Strange that the RFC requires that an error message (at least of sent by a CA) MUST always be signed with a signature key (i.e., MAC protection or no protection is disallowed for error messages. With this in mind, and considering caPubs, I now better understand the scenario you mean.

So let's extend the interpretation of `-unprotectederrors´ to include error messages that have a protection that cannot be verified. Should be very easy to do.

[DDvO]

This has been implemented quite some time ago, at least in cmp-dev and the OpenSSL master.