Yeah, roughly this. It's only a matter of time before someone gets a signature verification error, then sees the public key here and adds it to their apt policy to get past the error.

That's no different from the apt-key adv --recv-keys <key id> that people do now on signature failures, so I don't see that as a reasonable argument.

We can only show the key id in the output, though, and then people have to go search on the web to get the full key (or they echo $signature | base64 -d | head -c32 | base64; but really, who does that).

It's an appeal against specifying what has been historically an anti-pattern in signature formats; it's caused problems for SAML (and XMLDSIG generally) and JWT already. It won't bite you hard, at least any time soon, because of how few verifying codebases your project deals with. But it's not what you'd call a best practice.

Compare this to the lack of verification criteria (cf HdV's post) --- the signature ambiguity is (sorry) unambiguously a wart on the format and one you should be able to agree, ceteris paribus, should be fixed. But it's probably less likely to cause a real world problem than this design choice.

I think there's a reasonable compromise of embedding the key id of the primary key, but shipping the subkey completely.

This way we lose the ability for checking total consistency without public keys present; but we have the technological requirement you want for the user to trust the primary key (and no way to construct it from the signature).

We discussed the signature format in great detail, and looked at multiple options:

  Ed25519-Signatures:
   base64<sig1>
   base64<sig2>

  Signatures:
    ed25519:base64<sig>

  Signatures:
    ed25519 base64<sig>

  Signatures:
    base64<ed25519 | sig>

The first option was rejected by people for reasons I can't remember, and the next 2 are equivalent, albeit the one with : is easier to copy-paste (who does that for an apt signature?).

The last one we did not like because it made the code more complex because we'd have to decode to a buffer first and then copy into the appropriate struct; and also because it's not clear from looking at the plaintext which algorithms it has been signed with.

Also, sure, the key type is also stored with the public key, and then the signature type must find a public key for the same type; so it looks like ed25519:<base64>.