Support PGP Ed25519 keys

[jas4711]

Hi. It seems rekor does not support OpenPGP Ed25519 keys, please add support for them. Thank you!

jas@kaka:~$ echo foo > foo.txt
jas@kaka:~$ gpg --detach-sign foo.txt
jas@kaka:~$ gpg --verify foo.txt.sig foo.txt
gpg: Signature made Fri Apr 14 19:03:46 2023 CEST
gpg:                using EDDSA key A3CC9C870B9D310ABAD4CF2F51722B08FE4745A2
gpg: Good signature from "Simon Josefsson <simon@josefsson.org>" [ultimate]
jas@kaka:~$ gpg --export A3CC9C870B9D310ABAD4CF2F51722B08FE4745A2 > key.txt
jas@kaka:~$ rekor-cli upload --signature foo.txt.sig --artifact foo.txt --public-key key.txt 
error: error retrieving external entities: invalid PGP signature: openpgp: unsupported feature: public key algorithm 22
jas@kaka:~$ 

[haydentherapper]

#286 is the blocker, the pgp library we're using is deprecated but another part of the code depends on it still. At a glance it looks like https://github.com/ProtonMail/go-crypto support ed25519

[haydentherapper]

See the update on the linked issue, we should be able to start using the newer library, but we still need to rely on the deprecated one for RPM packages.

Do you know if Debian packages or other packages you're working with use the openpgp v4 format?

[jas4711]

The relevant apt-signer OpenPGP keys I am uploading signed artifacts for are here:

https://gitlab.com/debdistutils/debdistcanary/-/tree/main/openpgp

I had to use gpg --export-options export-minimal on them to have canonical versions in rekor -- and interestingly, just having a Ed25519 signature on one of those keys caused rekor to reject an upload signed by that key, even though the key itself is RSA. This took some time to figure out, but makes somewhat sense given what I'm learning about rekor's PGP-support now.

It seems actually ALL of those keys are RSA v4 keys?! Uploading things signed by these keys works fine though.

jas@kaka:~/src/debdistcanary/openpgp$ for f in openpgp-*; do gpg --list-packets < $f; done | grep ':public key packet' -A 1|grep -v -e ':public key packet' -e^--
	version 4, algo 1, created 1555228135, expires 0
	version 4, algo 1, created 1472461287, expires 0
	version 4, algo 1, created 1336770936, expires 0
	version 4, algo 1, created 1555228608, expires 0
	version 4, algo 1, created 1555228608, expires 0
	version 4, algo 1, created 1483829507, expires 0
	version 4, algo 1, created 1549399120, expires 0
	version 4, algo 1, created 1417539282, expires 0
	version 4, algo 1, created 1537196506, expires 0
	version 4, algo 1, created 1588537086, expires 0
	version 4, algo 1, created 1613238862, expires 0
	version 4, algo 1, created 1610882316, expires 0
	version 4, algo 1, created 1610882224, expires 0
	version 4, algo 1, created 1610882224, expires 0
	version 4, algo 1, created 1537196506, expires 0
jas@kaka:~/src/debdistcanary/openpgp$ 

[haydentherapper]

I think we might actually support V4 signatures currently, since I believe x/go/crypto does in addition to V3 signatures. For ed25519, another thing to note is that the hashedrekord Rekor type doesn't support it currently, we need to switch to ed25519ph (but this is a moot point since our pgp library doesnt support either!). You may find more rough edges too, we appreciate the filed issues!

[jas4711]

Yes I think you do support V4 signature. The output above was to prove that the keys were OpenPGP v4, however what is also relevant is the signatures, and they are also all V4 for the keys that I care about. See output below. It is critical to strip all non-selfsignatures for rekor to accept these keys though, otherwise rekor will reject them if they contain a ed25519 signature from someone else.

The three concerns I have with PGP-handling in rekor are:

• No support for Ed25519 Support PGP Ed25519 keys #1438
• Allows non-related keys during uploads Unrelated PGP keys are stored together with PGP signature/publickey #1429
• Does not minimize or canonicalize the public keys, see Question: should Rekor canonicalize the Rekor entries it takes in? #1162 and Unrelated PGP keys are stored together with PGP signature/publickey #1429 (comment)

I believe if rekor would minimize/canonicalize the public keys, the #1429 would be solved as well, since it is really just a side-effect of not performing any sanitation of the received public key.

jas@kaka:~/src/debdistcanary/openpgp$ for f in openpgp-*; do gpg --list-packets < $f; done | grep -e ':signature' -A 3|grep version
	version 4, created 1555228268, md5len 0, sigclass 0x1f
	version 4, created 1555228268, md5len 0, sigclass 0x1f
	version 4, created 1555228268, md5len 0, sigclass 0x1f
	version 4, created 1555228268, md5len 0, sigclass 0x1f
	version 4, created 1555228268, md5len 0, sigclass 0x1f
	version 4, created 1555228135, md5len 0, sigclass 0x13
	version 4, created 1555228135, md5len 0, sigclass 0x18
	version 4, created 1474494078, md5len 0, sigclass 0x13
	version 4, created 1472461287, md5len 0, sigclass 0x18
	version 4, created 1336770936, md5len 0, sigclass 0x13
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228608, md5len 0, sigclass 0x13
	version 4, created 1555228608, md5len 0, sigclass 0x18
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228613, md5len 0, sigclass 0x1f
	version 4, created 1555228608, md5len 0, sigclass 0x13
	version 4, created 1555228608, md5len 0, sigclass 0x18
	version 4, created 1483829507, md5len 0, sigclass 0x13
	version 4, created 1483829507, md5len 0, sigclass 0x18
	version 4, created 1549399120, md5len 0, sigclass 0x13
	version 4, created 1417539282, md5len 0, sigclass 0x13
	version 4, created 1417539282, md5len 0, sigclass 0x18
	version 4, created 1461639076, md5len 0, sigclass 0x18
	version 4, created 1537196506, md5len 0, sigclass 0x13
	version 4, created 1651234024, md5len 0, sigclass 0x13
	version 4, created 1651234205, md5len 0, sigclass 0x18
	version 4, created 1613238862, md5len 0, sigclass 0x13
	version 4, created 1610882319, md5len 0, sigclass 0x1f
	version 4, created 1610882319, md5len 0, sigclass 0x1f
	version 4, created 1610882319, md5len 0, sigclass 0x1f
	version 4, created 1610882319, md5len 0, sigclass 0x1f
	version 4, created 1610882319, md5len 0, sigclass 0x1f
	version 4, created 1610882316, md5len 0, sigclass 0x13
	version 4, created 1610882316, md5len 0, sigclass 0x18
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882224, md5len 0, sigclass 0x13
	version 4, created 1610882224, md5len 0, sigclass 0x18
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882229, md5len 0, sigclass 0x1f
	version 4, created 1610882224, md5len 0, sigclass 0x13
	version 4, created 1610882224, md5len 0, sigclass 0x18
	version 4, created 1537196506, md5len 0, sigclass 0x13
jas@kaka:~/src/debdistcanary/openpgp$ 

[jas4711]

I think #1170 is another example of not canonicalizing the public keys received when uploading. Generally, rather than taking the public keys or certificates and store them verbatim, I think rekor should parse them, minimize and strip anything unrelated, and export it again and then store that public keys in the ledger log. Right now, I think that if I make two uploads with the same signature, artifact and the public keys only differ by some whitespace in the ASCII-armor (or a comment), rekor will create two different entries for them. Searching for particular public keys breaks in this case. A corner-case is how to handle signatures signed by multiple public keys, but I think rekor should require that all public keys mentioned in the signature file should be uploaded.