Ok, the correct name of this kind of GPG key is "sign-only", they don´t have subkey, needed to have encryption-fu, so the current workflow can't determine its ownership. Talking with dsilvers, we suspect we should support this kind of key, which is commonly onwed used by debian maintainers to sign packages.
The workflow should be adapted somehow, to verify the ownership of those kind of keys based in its capabilities, i.e., verifyin if it can sign content properly. The preliminary solution should be, when confirmed a key is a sign-only one, instead of try to encrypt content and sent to the owner, we try to send plain text containing the respective token and when verifying the token we should require adittionaly than the LP password a deatached signature of the content sent.
Ok, the correct name of this kind of GPG key is "sign-only", they don´t have subkey, needed to have encryption-fu, so the current workflow can't determine its ownership. Talking with dsilvers, we suspect we should support this kind of key, which is commonly onwed used by debian maintainers to sign packages.
The workflow should be adapted somehow, to verify the ownership of those kind of keys based in its capabilities, i.e., verifyin if it can sign content properly. The preliminary solution should be, when confirmed a key is a sign-only one, instead of try to encrypt content and sent to the owner, we try to send plain text containing the respective token and when verifying the token we should require adittionaly than the LP password a deatached signature of the content sent.