What are the chances of an RSA signature collision? My understanding is: fundamentally it should be hard to produce a different message with the same signature. Therefore chance of collision should be low. But what exactly is the probability of a collision, taking into account stuff like the birthday paradox?

As a consequence, in a system with many signed messages, is it safe to use the (sha-2 or sha-3 hash of the) signature as a unique identifier?
So what you are asking is if we could create $\operatorname{Sign}_S(M_1) = \operatorname{Sign}_S(M_2)$ where $S$ is the private (and secret) key. Obviously, this cannot be the case. If you could then an adversary could claim you signed $M_2$ even though you actually only signed $M_1$. That would also mean that the signature would be repudiable; a signer could simply claim to have signed a different message. Non-repudiability is arguably the most important aspect of a digital signature in the first place (authentication can also be performed using other primitives, e.g. using a static DH key, after all). To round it up: if signatures would collide for separate messages and the same key (and the same configuration parameters) then the algorithm would be fundamentally broken.

Note that many signature generation algorithms are non-deterministic. In other words, they take the input of a random number generator as input, and will therefore generate a different signature each time the signature is generated. The often used RSA-PKCS#1.5 scheme is however deterministic and RSA-PSS can be configured to be deterministic by configuring the salt size to an empty octet string / byte array. Mind you, runtimes may decide not to make the salt size of RSA-PSS configurable, in which case RSA-PSS remains non-deterministic per default.

So yes, you can use a hash to subtract or condense the signature into an identifier, as long as your signature is deterministic (and presuming you want to regenerate the identifier later on). If your hash is too large then you can simply use the leftmost bytes or use a smaller hash function. There are also multiple ways of expanding the result - although that's unlikely required for your use case. Nowadays you would probably use a XOF such as one of the SHAKE functions (part of SHA-3 specs) for expansion. An KDF that supports expansion such as HKDF-expand would also be an option.



Note that most if not all modern signatures already include hashing of the data - if just to make sure that the requested property holds. It would be a good idea for the hash functions to have about the same security strength. Of course you need to use a secure hash function (e.g. SHA-2 / SHA-3 and not MD5 or SHA-1) for the hash function.

The smaller the final identifier, the bigger the chance of collisions, of course. Note that you would need $2 \cdot s$ bits to reach a strength of $s$ bits due to the birthday problem. Don't make your identifier too small, especially if you're planning of using many identifiers. Using the full hash output should of course be preferred.