Sorry I didn’t see this sooner.
I’m checking with some of my colleagues first, because honestly I’m not sure, but we (Microsoft) are very keen to have a signing system that is able to work with our current processes.
In particular, having a way for wheels distributed on Windows (and macOS?) to be signed using commercially provided Authenticode keys would be ideal, as this would align with the processes used by all existing software vendors distributing EXEs, DLLs, MSIs, MSIXs, CABs, PS1s and other signed software.
My current fear is that a system that is tied directly to PyPI would prevent/exclude these approaches. Also, the current proposed constraint (in the linked PEP) that any signing solution be pure-Python is incredibly restrictive.
I would like to see the tool support be extensible to support private distribution sources (e.g. you need to install/configure another package before you get verification).
But, as I said, I’m talking with colleagues who know this area better than I do. If they come back and say that we’re happy to follow a TUF-like model where PyPI holds all the public keys (rather than following the trusted CA model) and RSA is not a strict requirement, I wil happily withdraw 