inconsistent use of GnuPG

[lukpueh]

[from X41 source code audit informational note]

The Python implementation of in-toto supports the use of PGP keys via GnuPG.

When specifying a PGP key (via its ID) to be added to the layout, the key’s metadata is fetched from GnuPG and added to the key object in the layout. The metadata includes some (but not all) attributes of the key. It also includes subkeys of the specified key, which are accepted in place of the specified key during verification.

in-toto re-implements some (but not all) of GnuPG's validations when adding the key and during verification, however only the key metadata from the layout is used during verification and GnuPG is not invoked in the process.

X41 understands that in-toto’s goal is not to provide a re-implementation of GnuPG and therefore considers it an unnecessary risk – and avoidable complexity – to evade GnuPG's validations in the verification process.

Solution Advice
X41 recommends to only specify the key ID in the layout, and to leave all other steps involved with key management, signing, and verification to GnuPG.

[lukpueh]

An alternative (preferred) solution is to discard all information related to the PGP trust model (validity period, subkeys, etc.), when adding the key to the layout, and make it clear in usage documentation that the layout defines the ultimate trust and is thus responsible to expire a key or define trust hierarchies.

A non-backwards-compatible consistent GPG signer/verifier, which implements this solution, is available in securesystemslib, and becomes available to in-toto via #532, #533.

Once it is adopted a deprecation/replacement of legacy GPG signer/verifier can be considered.