Using `getSuppressRedundantExtraCerts` with `true` excludes certs too eagerly

[DDvO]

When getSuppressRedundantExtraCerts returns true, the behavior documented in the code is:

do not sent an extraCerts certificate twice in a message flow related to a specific transactionID.

(BTW, there is a grammar mistake in this sentence, using "sent" instead of "send"; please fix it along with this issue.)

The expected behavior is that in each transaction the component does not send extraCerts twice in the same direction,
(but of course still include it when used for the first time in the given direction on the upstream or downstream interface).
Please clarify the direction/interface-related behavior in the documentation.

With true, at least when re-protecting an IP message received from upstream, users experienced unsuitable behavior:
Although the signer certificate is used by the CmpRaComponent on its downstream interface for the first time in the transaction,
its signer cert and chain are excluded from the extraCerts (such that only the upstream issuing CA cert and potentially its chain remains).

Maybe this too aggressive pruning is related to the signer cert and chain already being used for re-protecting the IR message preceding it when forwarding it upstream. Yet this should have no influence on the behavior on the downstream interface.
In any case, such pruning must be done per each message interface (independently of other upstream/downstream interfaces).

Moreover, CI tests for getSuppressRedundantExtraCerts returning true appear to be missing.

[Akretsch]

I propose to drop the whole feature instead of fixing the behavior under various conditions.

[DDvO]

I propose to drop the whole feature instead of fixing the behavior under various conditions.

Why do you propose this - because you think it would be too difficult to fix?
Certainly for most scenarios (with non-constrained devices) this feature is not essential.
Yet it may be helpful in case message size is an issue, in particular with PQC certificates.
As written in RFC 9483:

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the EE has
    --   cached the CMP protection certificate from the first
    --   response message of this PKI management operation

[Akretsch]

Behavior is not completely clear:

• Which interfaces to handle (upstream/downstream)
• Which directions to handle (request/response)
• Which certificates to cache (protection/enrollment)
• How to deal with flipping protection certificates (CA, RA, LRA response)

So its too difficult to fix and describe.

[DDvO]

So its too difficult to fix and describe.

Not really.

• Which interfaces to handle (upstream/downstream)
• Which directions to handle (request/response)

As always, these two amount to the same: upstream implies requests being sent/forwarded.
downstream implies response being sent/forwarded.

The suppression should be independent for each of these to interfaces/directions (so not just a single one per transaction, but if enabled in both interfaces, then there are two independent sets of extraCerts).
This is the point of this issue.
The supp

• Which certificates to cache (protection/enrollment)

As specified: suppression can affect all extraCerts.

• How to deal with flipping protection certificates (CA, RA, LRA response)

This should not need special treatment: with suppression enabled for the given interface,
simply keep track of which certs have been included in the extraCerts in the current transaction already on this interface,
and whenever a candidate (possibly old or new) extraCert has already been sent, leave it out.

[ZMaradics]

Related code part:
com.siemens.pki.cmpracomponent.msggeneration.MsgOutputProtector
line:232

[ZMaradics]

Context class: com.siemens.pki.cmpracomponent.persistency.PersistencyContext

Only has 1 "Set alreadySentExtraCerts" set instead of 2 for both direction.

@Akretsch : Agree,
we need alreadySentExtraCerts and receivedCertificates for both directions (4 sets of certificates)

[DDvO]

As discussed meanwhile, for remembering/caching the received extraCerts better not distinguish between upstream and downstream direction. For these the distinction is not needed, and not doing it can even be helpful for the RA because for completing a chain used in one of the direction, the RA might have learned the missing cert from a message going in the other direction.

For even more completeness in chain building, it would help not to limit the scope of this bag of received extraCerts to the current transaction.
Yet having a more global bag may be harder to store persistently and to share between RA instances,
and such a longer-lasting bag would also need garbage collection (which at least should remove expired certs).