Publishing the public key on an HTTPS website is fine, and pretty common. However, it does introduce a security dependency between the website and the payloads. If the website goes down, payloads can't be verified. If the website is compromised, then the attacker could publish their own key on the site and send spoofed payloads that successfully pass signature validation.
Other options include:
- Publishing the public key as a DNS TXT record, with DNSSEC. Less attack surface than a website, but still creates a new security dependency. Means security of your payload signing key depends on security of your DNS registrar account. Clients must validate the DNSSEC signature or else an attacker can use a DNS spoofing attack to spoof the payload public key.
- Using the public key in your TLS certificate (which is signed by a CA as belonging to you). Certificates are often harder for attackers to tamper with than website content, and an attacker can't replace the cert with their own unless they get a CA to issue one fraudulently. Means the cert and the payload signing key rotate together, but this shouldn't be a problem unless you either rotate the signing keys very frequently. Certs can be re-issued, potentially with new keys, on a pretty frequent basis (indeed, some CAs only issue short-lived certs).
- Combination of the above: frequently-rotated public key on your website and/or DNS record, but itself signed by your TLS public key. This prevents an attacker from modifying the payload signing key without also compromising your TLS private key or replacing your TLS certificate, but allows you to rotate the TLS key and payload key independently (though you'll need to promptly update the payload key signature whenever you rotate the TLS key).
- Giving each client the current and future keys through some authenticated method (such as a download from a TLS-protected website), with scheduled rotations, and periodically supplying more keys as the old ones rotate out. Requires that the client have secure and persistent data storage for the keys and potentially complicates onboarding new clients (if you can't just embed the keys in an app bundle or something) and handling unscheduled rotations. A compromise of the authenticated distribution channel may result in some clients having compromised keys with a long duration, which could complicate incident response.
- Giving each client their own keys (typically a primary and a backup). This reduces the exposure of any individual key (if your concern is that the public key might be cracked), but is otherwise probably just a higher-cost version of the above.
You might want to examine why you expect to rotate the key pair so often. Generally, this isn't needed; even relatively weak public keys should be good enough for years. Concerns such as replay attacks or known-vulnerable versions should be handled using timestamps, monotonically-increasing nonces, monotonically increasing version numbers, or so on, all of which would be signed as part of the payload.
