Is this protocol secure?

Question

Before anyone freaks out, this is purely speculative and I am not developing a cryptosystem!

I can't see anything wrong with this protocol, but my knowledge of cryptography is rather superficial:

• Decentralized nodes need to publish a piece of information (their state, e.g. available/busy) to a central server S.

• Each node has an RSA key pair.

• Node A and node B have already exchanged their public keys via some secure channel outside of this protocol.

• Node A sends a message to the central server S. The message contains:

  1. A's public key
  2. The (state, timestamp) pair
  3. The signature for the above pair, which A calculated by using its private key

  This may be the first time S sees A's public key. However, S makes sure the signature checks out, and registers A's new state provided that A's previous state is either older or non-existent.

• Node B asks S for A's state. In its request to S, B identifies A by means of A's public key fingerprint (SHA-256 or whatever the best practice is), which effectively acts as node ID.

• S forwards to B the state message it previously received from A. B independently checks that the signature is valid (B already had A's public key on record) and registers A's new state provided that A's previous state is either older or non-existent.

Questions:

1. Is there a way a malicious node can fool B by making it accept fake or outdated state messages in A's name?
2. Given that S has no prior knowledge of A's public key before receiving A's very first state message, is this protocol able to ensure that no malicious node can convince S to persist and propagate invalid state information in A's name or somehow enact some kind of denial of service (not by intense network activity that overloads S, but by intelligently breaking the protocol) whereby A is unable to propagate its real state?
3. Is there any other problem you may want to mention (leaving aside the questionable utility of the protocol)?

Thank you.

Answer 1

Question 2 can be easily answered. Yes, an attacker could easily overload this part of the system.

This may be the first time S sees A's public key. However, S makes sure the signature checks out, and registers A's new state provided that A's previous state is either older or non-existent.

An attacker can easily send their own public key instead of $A$'s key. Then sign with their own private key. The signature will, of course, be valid, so $S$ will accept it. If $S$ ties that key to the identifier for $A$ going forward, then future messages from the real $A$ would be blocked. Also, no $B$ will ever request a message with said key's fingerprint, so it will wait taking space in the message queue, leading to an easy way to fill the queue and stop any new messages from being processable.