v4: It is impossible to convert secret (sub)key packet into a public (sub)key packet, or compute fingerprint of secret (sub)key packet, in general

The following discusses a shortcoming of the v4 key packets. It has been fixed in v5, but I think this is subtle and I haven't seen it discussed. So I wanted to share our observation, maybe we even find a place to document it.

Converting a secret (sub)key packet into a public (sub)key packet seems straight forward: Because the secret key packet is a superset of the public key packet, just omit the fields that are only present in the secret key packet. Conveniently, the public key packet is a prefix of the secret key packet. Finally, change the packet type.

However, that either requires identifying either the fields present in both packets, or those only present in the secret key packet.

To identify the common fields, one needs to parse the algorithm-specific fields containing the cryptographic artifacts. This may not be possible if the key uses an unknown algorithm (it may be possible if the unknown algorithm uses MPIs to represent the artifacts, but this is by no means reliable).

Identifying the fields only present in the secret key is tricky if you don't know where it starts. You know where it ends, so an octet count at the end would help, but we don't have one.

Hence, in general, it is not possible to convert secret (sub)key packet into a public (sub)key packet.

As a consequence, because fingerprints are computed over the public key material only, you also can not, in general, compute fingerprints of secret (sub)key packets.

In v5 public key packets, there is "A four-octet scalar octet count for the following public key material.", fixing the issue.