biscuit-auth vulnerable to public key confusion in third party block

Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a ThirdPartyBlock request can be sent, providing only the necessary info to generate a third-party block and to sign it:

• the public key of the previous block (used in the signature)
• the public keys part of the token symbol table (for public key interning in datalog expressions)

A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.

Consider the following example (nominal case)

• Authority A emits the following token: check if thirdparty("b") trusting ${pubkeyB}
• The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B
• Third-party B generates the following third-party block thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC}
• The token holder now must obtain a third-party block from third party C to be able to use the token

Now, with a malicious user:

• Authority A emits the following token: check if thirdparty("b") trusting ${pubkeyB}
• The holder then attenuates the token with the following third party block thirdparty("c"), signed with a keypair pubkeyD, privkeyD) they generate
• The holder then generates a third-party block request based on this token, but alter the ThirdPartyBlockRequest publicKeys field and replace pubkeyD with pubkeyC
• Third-party B generates the following third-party block thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC}
• Due to the altered symbol table, the actual meaning of the block is thirdparty("b"); check if thirdparty("c") trusting ${pubkeyD}
• The attacker can now use the token without obtaining a third-party block from C.

Impact

Tokens with third-party blocks containing trusted annotations generated through a third party block request