There are still a lot of "Debian weak keys" floating about. In the UK federation, we use a really revolting script to check embedded keys against blacklists to weed these out. This means that it isn't run as part of the main metadata build. I'd like to be able to bring this into the aggregator environment by creating a key modulus blacklisting stage.
Here's the original Debian advisory:
The two Debian-supplied blacklists are 8MiB each (one for 1024-bit keys, one for 2048-bit keys), each being 196K-line files with one hexadecimal hash value per line. Unfortunately the hashes are not of the moduli per se but of the line in OpenSSL output where the modulus is printed, so in order to reuse those files one would need to recreate that situation without OpenSSL. That shouldn't be too hard, though, and probably beats the alternative of regenerating the blacklists in a more comprehensible format.
For the Debian case, we definitely don't want to include the hashes within the bean configurations, but refer to the files containing them instead.
It may also be worth building a stage that blacklists moduli hashes for other purposes. In that case I'd suggest making the blacklist contain hashes of the actual moduli, and including them in the configuration directly. This is not that, though.