I took a look at the design and think there are a few issues with the format as proposed.
# The public key is stored with the signature.
This should be stored separately. A public key found here is too tempting to use, rendering the signature worthless. Authenticating it would be OK, but low value. This is unauthenticated. A "key ID" should be used instead if the intention is to support lookups among multiple keys.
# The algorithm is stored with the signature.
This is slightly less bad than above, but still bad. Attacker-controlled algorithms have been used repeatedly in "downgrade" attacks. Agility is bad, but if you must support multiple algorithms, store this with the public key (somewhere else). Some info here: https://github.com/secure-systems-lab/dsse/issues/35
I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself.
Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for.
# The public key is stored with the signature.
This should be stored separately. A public key found here is too tempting to use, rendering the signature worthless. Authenticating it would be OK, but low value. This is unauthenticated. A "key ID" should be used instead if the intention is to support lookups among multiple keys.
# The algorithm is stored with the signature.
This is slightly less bad than above, but still bad. Attacker-controlled algorithms have been used repeatedly in "downgrade" attacks. Agility is bad, but if you must support multiple algorithms, store this with the public key (somewhere else). Some info here: https://github.com/secure-systems-lab/dsse/issues/35
I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself.
Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for.