ownership: upgrade sha1 key algorithms

[pinheadmz]

These changes allow a TLD owner who is stuck with a RSASHA1 key in the root zone to claim their reserved name on Handshake using the same RSA key but with SHA256.

Usage would be exactly the same:

$ bns-prove -b -K ~/Desktop/work/bns/test/data weakkeytld "hello-world"
Upgrading key algorithm for key ID 3810
AgMAADAAAQAAKjAARAEBAw1P1xREnYz8zP2rpSxk1j46...

The output of this example proof can be seen here: https://gist.githubusercontent.com/pinheadmz/ac9e30c50ff1630404d7885a8d2303b4/raw/511e34c926c31e77786215aaea5c2891e610fdfd/upgraded-key-claim-proof.txt

Notice in the TLD zone are two identical DNSKEYs but with different algorithms. The DS in root commits to the key with the SHA1 algorithm (5) but we sign the DNSKEY and TXT RRsets with the upgraded key SHA256 (8).

This example was generated with a custom root resolver and local nameserver to simulate a HNS mainnet claim.

From the Handshake whitepaper:

During our analysis of the root zone file, we discovered that a significant
majority of domains use SHA1 for RSA signatures and key fingerprints. This is
unfortunate, as SHA1's security against collision resistance was recently
compromised[shattered]. Our consensus rules must disallow for the use of
insecure algorithms, like SHA1, even with existing DNSSEC setups.

As a result of this, in order for an RSA-SHA1 nameholder to claim their name on
the handshake blockchain, they must upgrade their key-signing key to at least
RSA-SHA256 before creating an ownership proof. Unfortunately, to accomplish
this, the nameholder must contact their parent zone and request that they sign
off on a new key.

With this in mind, we must consider the possibility that ICANN may become
uncooperative and refuse to sign a higher security key for an existing
nameholder. If this were to happen, RSA-SHA1 root zone names would be
unredeemable on the blockchain. To mitigate this attack, our DNSSEC ownership
verification algorithm implicitly upgrades RSA-SHA1 keys to RSA-SHA256,
allowing a reserved nameholder to publish the same RSA key in their own zone
with a differing algorithm field (RSA-SHA256 or RSA-SHA512). This allows the
nameholder to bypass ICANN's root zonefile update process when creating the
necessary ownership proof.

[pinheadmz]

Fixed the KSK issue and also added a test mode for bns-prove itself:

bns-prove --test -K ./test/prove-util weakkeytld "hello, world!"