siemens / lightweightcmpra Goto Github PK

Dear project maintainers,

The default Siemens security policy will be applied to this repository on September 27, 2023.

If you're OK with that, you can close this issue. Otherwise, please create your own security policy.

If you have any further questions leave a comment in the pull request or send us an email.

This is a follow-up on #7, as discussed.

Please also tweak the description in README.md, as follows:

The **`TransactionMaxLifetime` object**
optionally specifies the maximum lifetime of CMP transactions.
The Lightweight CPM RA persists the message exchange state of each transaction
until its regular or erroneous termination or until its age reaches the
given number of seconds.
By default, or if the value 0 is given, transaction lifetime is not restricted.
Restricting transaction lifetime avoids blocking RA resources indefinitely
for instance when an expected subsequent request message by the client is lost
or the client terminates during a transaction without the RA knowing.

This is a follow-up on #7 und #8.

After our clarifying recent discussion, please further tweak the implementation and doc as follows.

• Rename TransactionMaxLifetime (and the leftover parameter/variable name downstreamExpirationTime) to DownstreamTimeout.
• The RA component sets up the internal time limit of a transaction in the moment when returning a response to downstream if it remembers the transaction because it expects further (polling or other) requests from downstream.
  If the response contains a retryAfter value, this value is added to the configured timeout value (such that the time limit is extended by the expected waiting time of the client).
• Adapt the documentation in the configuration README file accordingly, for instance like this.

The **`DownstreamTimeout` object**
optionally specifies the maximum allowed reaction time of the downstream entity
apart from any applicable `retryAfter` period.
That is, the RA will keep a transaction open while awaiting a further request
form the client side until it receives the expected request or the configured
number of seconds, plus any `retryAfter` time given in its last response, has elapsed.
In the latter case the RA cleans up and forgets the transaction.<br>
By default, or if the value 0 is given, no restriction is placed,
such that a transaction may idle indefinitely. It is recommended to specify
a nonzero timeout value in order to prevent blocking RA resources indefinitely,
for instance when an expected subsequent request message by the client is lost
or the client terminates during a transaction without the RA knowing.

• Adapt the documenting comment(s) in the respective CMP RA Component API Java file.

I get

[main] WARN com.siemens.pki.cmpracomponent.msgvalidation.BaseCmpException - error at ClientUpstream: message is incomplete protected but protection is required
Exception in thread "main" java.lang.RuntimeException: error processing invokeEnrollment
	at com.siemens.pki.cmpclientcomponent.main.CmpClient.invokeEnrollment(CmpClient.java:575)
	at com.siemens.pki.lightweightcmpclient.main.CliCmpClient.doEnrollment(CliCmpClient.java:206)
	at com.siemens.pki.lightweightcmpclient.main.CliCmpClient.runClient(CliCmpClient.java:377)
	at com.siemens.pki.lightweightcmpclient.main.CliCmpClient.main(CliCmpClient.java:317)
Caused by: CmpException [failInfo=65536, errorDetails=ClientUpstream: message is incomplete protected but protection is required]
	at com.siemens.pki.cmpracomponent.msgvalidation.ProtectionValidator.validate(ProtectionValidator.java:78)
	at com.siemens.pki.cmpclientcomponent.main.ClientRequestHandler$ValidatorAndProtector.validateResponse(ClientRequestHandler.java:129)
	at com.siemens.pki.cmpclientcomponent.main.ClientRequestHandler.sendReceiveValidateMessage(ClientRequestHandler.java:334)
	at com.siemens.pki.cmpclientcomponent.main.CmpClient.invokeEnrollment(CmpClient.java:482)

Instead, always the first element of the configured list is used.

This gives a user-friendly way of specifying for which CRL an update is requested.

I currently try to find out, how users decide to take which version of Californium in order to

• improve that decision
• improve newer Californium versions, if there are serious reasons to chose a older one.

So, have there been any serious reasons not to use one of the 2. releases of Californium?

As recommended in https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#name-cmp-message-transfer-mechan:

Independently of the means of transfer, it can happen that messages are lost or that a communication partner does not respond. To prevent waiting indefinitely, each PKI entity that sends CMP requests SHOULD use a configurable per-request timeout, and each PKI management entity that handles CMP requests SHOULD use a configurable per-response timeout in case a further request message is to be expected from the client side within the same transaction. In this way a hanging transaction can be closed cleanly with an error as described in Section 3.6 (failInfo bit: systemUnavail) and related resources (for instance, any cached extraCerts) can be freed.

So please add a configurable maximal time (in seconds) to wait for responses on the upstream interface (e.g. HTTP)
and to wait for subsequent requests (where applicable) on the downstream interface, with reasonable default values.
A value of 0 shall mean to wait indefinitely.

It could be considered an error if a non-zero downstream timeout value given is smaller than any configured retryAfter value.

For

|0..n| [`HttpClient` object](#the-httpclient-object) |
|0..n| [`HttpsClient` object](#the-httpsclient-object) |
|0..n| [`CoapClient` object](#the-coapclient-object) |
|0..n| [`OfflineFileClient` object](#the-offlinefileclient-object) |

it should be defined which of them is chosen if, e.g., both HttpClient and HttpsClient (with no or with same certProfile) are given.

Moreover, taking the issuer and serial number from a config file is not really useful;
better reuse the existing CLI parameter --issuer and add --serial.