Consider the following implementation:
Bob wants to communicate long-term with his team over an unsecured channel. Bob and all members of the team generate individual public/private keypairs (ex. RSA) and store/share their public keys on an untrusted key server.
Bob, being the first member of the team, also generates a long-term random symmetric key for the team that he and all team members will use to encrypt their communications. Bob encrypts the team's symmetric key with his public key and also the public key of all current members of the team and stores them on the same untrusted key server.
When new members are added to the team, Bob (or any existing member of the team that can add new members) takes his own encrypted version of the team's symmetric key from the key server, decrypts it with his private key, then copies and re-encrypts it with the new member's public key, storing it back on the key server for the new member to use for future communications with the team.
The problem with this implementation is that the symmetric key can be forged by Eve, a bad actor with access to modify the key server. Since public keys are all available, Eve could take Bob's (or any and all members of the team) public key and encrypt a new symmetric key on the key server. Past communications would then fail to decrypt, however, if gone unnoticed by the team any future communications could be read by Eve. If the forgery occurred when the symmetric key was first stored, no member of the team would ever know that Eve has been reading their communications.
I think that we need some sort of signature on the symmetric key exchange, however, where would the key material for this signature come from? How could we produce a signature in a way that each member of the team could privately verify that their version of the team's symmetric key is authentic? Maybe some other way?
One solution could be for Bob to compute a hash of the symmetric key whenever he first generates it, then sign the hash with his private key and store it on the key server. Whenever members retrieve their copy of the symmetric key from the key server, they could also obtain Bob's public key, verify the hash's signature and recompute the hash to verify the symmetric key.
However, the problem I see with this solution is that it seems Eve could still forge a new symmetric key, sign it with her private key, and replace Bob's public key with hers on the key server. This would allow her to impersonate Bob's signature while other team members verify and use the forged symmetric key.