In particular, I want many Bobs to be able to get many public keys (for an offline identity Alice) which can later be used to verify the signing of some data by Alice, without anyone (apart from Alice) knowing that the public keys belong to Alice.
In general, encryption schemes are not suitable for signatures. The misconception may stem from the symmetricity of operations in RSA encryption and decryption, which allows the core scheme to be easily used for signing as well.
That being said, all identity-based encryption schemes (IBE) can be used as general signature schemes, see e.g. Boneh & Franklin's original paper (https://crypto.stanford.edu/~dabo/papers/bfibe.pdf), last para of Ch.6. You will lose the "identity-based" in that setting though, so there may be not much point in using an IBE-scheme as a general signature scheme. In this sense, it is safe to use SAKKE as signature scheme, but this is probably not what you are looking for.
What I gather from your problem description, the problem is to detach the personal identity from the signature identity. This is not necessarily a cryptographic problem, as one might as well obtain "usual" PKI certificates using a pseudonym instead of the real name, or generate and publish personal PGP certificates with pseudonyms.
In a more restricted setting, it may be desirable to be able to sign anonymously, but still as a part of certain group. This falls under the category of group- and ring signatures. In the former, the anonymity can be revoked in special cases and in the latter not.
In the identity-based setting the concept is called Identity-Based Signature (IBS, e.g. Hess IBS, implemented in the PBC-library). In IBS, the verification can be performed using system-wide parameters and the identity only. Even in this case, the anonymity needs to be based on using pseudonyms. The advantages over conventional PKI include:
- The ability to announce a space of pseudonyms even before creating any private keys
- Depending on the administration of the master key, simpler and faster production of pseudo-identities with a corresponding private key.
Most likely the first advantage might suite your needs, as Alice could simply announce a space of identities (e.g. 0xA11CE000...0xA11CEFFF, 0x12345678...0x1234FFFF) and then use them up as needed, without having to bother creating private keys until actually required.
There is, however, a catch: if the system parameters (including the master key) are managed by a third party, this party would likely be able to associate the identities with Alice. If Alice manages her own master key, obtaining and publishing this public key is comparable to the effort of publishing a PKI public key. This will diminish the value of choosing the identity-based paradigm anyway.