Signature validation fails if a message contains BOTH a signature and a secret token

[peacekeeper]

Given the following message:

[+]!:uuid:8888[$msg]!:uuid:1234/$is()/([+]!:uuid:8888)
[+]!:uuid:8888[$msg]!:uuid:1234/$do/([+]!:uuid:8888/[+]!:uuid:8888)$do
([+]!:uuid:8888[$msg]!:uuid:1234$do/$set)([=]!:uuid:1234)<$xdi><$uri>&/&/"....."
[+]!:uuid:8888[$msg]!:uuid:1234<$secret><$token>&/&/"....."
[+]!:uuid:8888[$msg]!:uuid:1234<$sig>&/&/"....."
[+]!:uuid:8888[$msg]!:uuid:1234<$sig>/$is#/$sha$256$rsa$2048

When the secret token is validated, a "virtual" statement is added to the incoming message, e.g.:

[+]!:uuid:8888[$msg]!:uuid:1234<$secret><$token><$valid>&/&/true

This will subsequently make signature validation fail, since the normalized context node has the additional statement that is not covered by the signature.

These "virtual" statements should therefore be handled differently and not included in the signature validation process.

Workarounds:

1. Don't send messages that contain both a secret token and a signature.
2. In the messaging target's configuration, place the AuthenticationSecretTokenInterceptor AFTER the AuthenticationSignatureInterceptor.