GPGSignature loads and dumps different dict key

[PradyumnaKrishna]

Description of issue or feature request:
GPGSignature's to_dict method returns a signature key in dict but requires a sig key in from_dict method.

Also, GPGSignature schema in formats has field signature instead of sig that is used by a Signature. isn't DSSE signatures have sig for signatures?

Current behavior:
GPGSignature from_dict and to_dict methods are not configured properly and will not load a dumped dict of a self.

securesystemslib/securesystemslib/signer.py

Lines 129 to 133 in 873f276

	return cls(
	signature_dict["keyid"],
	signature_dict["sig"],
	signature_dict["other_headers"]
	)

securesystemslib/securesystemslib/signer.py

Lines 138 to 142 in 873f276

	return {
	"keyid": self.keyid,
	"signature": self.signature,
	"other_headers": self.other_headers
	}

Expected behavior:
Either use sig or signature for both methods and representation of GPGSignature.

Related to DSSE
My idea is to implement GPGKey similar to SSlibKey implementation as provided in #416 (comment) so that external representation won't affect the verification.

Regarding GPGSignature I think we should use sig and we can parse both sig and signature in from_dict method of GPGSignature.

whats your opinion @lukpueh?

[lukpueh]

Good find, @PradyumnaKrishna! Regardless of what the name is, GPGSignature's from_dict and to_dict should really use the same, so that serialize(deserialize(data)) == data. Would you mind fixing this upstream (in this repo)?

Regarding what name it should be:

1. "signature" makes it easier to start using GPGSignature with existing (in-toto) metadata.
2. "sig" makes it compliant with the DSSE envelope spec ("The following fields are REQUIRED and MUST be set, even if empty: [...] signature.sig").

I think either way is fine but lean towards 1 for the time being because of backwards-compatibility and because it seems simpler (e.g. we don't have to translate sig<->signature when calling securesystemslib.gpg.functions). Let's decide whether we want to deprecate "signatures" in favor of "sig", and whether we want to have a period where we accept both later. We can do this when we start integrating DSSE with in-toto, I'm sure we'll find a few more backwards-/cross-compatibility issues.

cc @MVrachev

[lukpueh]

My idea is to implement GPGKey similar to SSlibKey implementation as provided in #416 (comment) so that external representation won't affect the verification.

👍