Support for PGP signatures

[oej]

          > Supporting GPG signatures is good for backwards compatibility but do we want to put that implementation burden on new implementations, which this will be? Food for thought.

The availability of PGP trust anchors is the main reason PyPI removed signatures from their repository: https://blog.pypi.org/posts/2023-05-23-removing-pgp/
On the other hand Maven Central requires PGP signatures for all published artifacts: https://central.sonatype.org/publish/requirements/

I don't think we should require the support of the OpenPGP format, but we might allow users to publish the public keys as X509 certificates and mark their usage as "Maven only", "PyPI only", etc.
The main use case would be to allow a user to verify the authenticity of the sub-components of an ACME Miracle Server product. If Dependency Track can verify that a sub-component comes from an upstream supplier without modifications, it can provide security alerts before those alerts propagate to the ACME API server.

Originally posted by @ppkarwasz in #21 (comment)

[chrisdlangton]

I see TEA as being like Certificate Transparency (CT) logs, in the sense that artefacts published to TEA may not be (the artifact as a whole) stored or available to TEA. Just the location the artifact can be retrieved and TEA index metadata, specifically the signatures, will be provided to TEA.

If the artifact is published, it will likely be signed in many cases, by tools like Anchor Syft and Sigstore, Trivy and Cosign, Github SPDX and GitHub Attestations via Sigstore (my preferred, but new and not yet popular).

CTs employ several signature mechanisms that are both inherent to the transparency log architecture and extensions of standard certificate practices. The core CT specification (RFC 6962) defines specific cryptographic structures that go beyond traditional certificate signatures.

Signed Certificate Timestamps (SCTs) represent the primary signature mechanism unique to CT logs. When a certificate authority submits a certificate to a CT log, the log operator generates an SCT containing:

The log's identity and timestamp
A cryptographic commitment to include the certificate
A digital signature from the log's private key

This SCT signature differs fundamentally from certificate signatures because it represents a promise of inclusion rather than identity verification. Think of it like the difference between a notary's seal (the SCT) versus an author's signature on a document (the certificate signature) - both authenticate different aspects of the same artifact.

So far all I have read is the wrong kind of signatures for something like TEA, we have been focussed on the kinds of signatures that publishers will use rather than the kind of signatures we need for TEA that are specific to the requirements of TEA's goals.

i.e. "a promise of inclusion in TEA" like SCTs

That is not to exclude the common artifact signing
We can also do that too, but it is a solved problem, we should think of it as "not invented here"