@@ -8,18 +8,6 @@ Open Questions
88 since deriving a key with an explicit context seems like good practice, but
99 ed25519-dalek doesn't support it.
1010
11- - * Should filepack attempt to support PGP v5 (LibraPGP) or PGP v6 signatures?*
12- In the case of v5, no additional data is needed, we would only be generating
13- different message bytes. In the case of v6, we need an additional 32-byte
14- salt. Because the bech32m PGP signature string is already ` signature1ap4… ` ,
15- it would be easy to add v5 and v6 variants.
16-
17- - * Should filepack attempt to support other signature schemes, like signify and
18- minisign?* Any existing signature scheme which uses Ed25519 and SHA-512 and
19- signs a superset of the message signed by the core filepack scheme could be
20- supported and treated interchangeably. I think it's really only a question of
21- demand.
22-
2311- * Should filepack bech32m signature strings include the public key?* This
2412 would allow them to be self-describing and potentially easier to handle. If
2513 we did this, the map of public keys to signatures in the notes struct would
@@ -35,55 +23,15 @@ Open Questions
3523 will be detectable by failing to verify, but I want to make sure my
3624 understanding is correct.
3725
38- - * Will signatures made with existing PGP and SSH keys pass strict
39- verification?* We use ed25519-dalek's strict verification of signatures. This
40- prevents certain kind of signature malleability issues, however it was not
41- part of the original RFC, and I wonder if there are any users with existing
42- PGP and SSH keys which fail strict verification.
43-
4426Closed Questions
45-
46- - * Should filepack signatures include an additional byte specifying the hashing
47- algorithm?* Currently, three filepack signature types are supported,
48- filepack, PGP, and SSH. All use Ed25519 as the signature scheme. The filepack
49- signature scheme signs an unhashed message, so no other hashing algorithms
50- are in use. SSH on the other hand signs a message including a hash of the
51- message, and PGP signs a hash of an outer message that includes the inner
52- message. Currently, we only allow SHA-512 as the hash algorithm in SSH and
53- PGP signatures. This is both because it is the default algorithm that
54- ` ssh-keygen ` and ` gpg ` use when creating Ed25519 signatures, and because
55- Ed25519 uses SHA-512 internally, so using any other hashing algorithm
56- introduces a new dependency. So, and here we finally get to the question,
57- should we add a byte to the ` signature1a… ` bech32 representation of
58- signatures which represents the hashing algorithm? This would allow us to
59- extend the existing signature encoding scheme to support multiple hashing
60- algorithms, although we would only do that if absolutely necessary, since
61- SHA-512 is a perfectly good default, and the only reason to add additional
62- algorithms would be something like supporting existing signing devices which
63- do not support SHA-512. ** Conclusion: This seems a very common degree of
64- freedom in signature schemes, so I added it. Filepack, PGP, and SSH
65- signatures now start with ` af0q ` , ` ap4p ` , and, ` as0p ` . The last character is
66- the hashing algorithm, filepack does not hash the message, so it's ` q ` , which
67- is the 0th bech32m element, PGP and SSH are restricted to SHA-512, which is
68- ` p ` , or the 1st element. No support exists for alternative combinations of
69- signature scheme and hash function, this is only in case we have to add
70- support in the future.**
71-
7227----------------
7328
74- - * Should filepack re-use an existing signature system, like SSH or PGP?* I
75- looked into both, but the formats and algorithms are incredibly complex, and
76- allow a huge number of unnecessary degrees of freedom. ** Conclusion: I added
77- support for multiple signature schemes, filepack, GPG v4, and SSH. Filepack
78- is the simple scheme which filepack uses when signing messages using keys it
79- manages. The GPG and SSH schemes are compatible with GPG and SSH, but
80- restricted to Ed25519 as the signature scheme, and SHA-512 as the hash
81- algorithm. This allows signatures to be created using GPG or SSH, using
82- existing keys, key management, and signers, and imported into filepack. All
83- signature schemes sign the same message, wrapped in the case of GPG and SSH,
84- and the resulting message and public key are always Ed25519 keys, and aside
85- from the difference in message bytes, all signature schemes are verified in
86- the same way.**
29+ - * Should filepack support SSH or PGP Ed25519 signatures?* Supporting SSH and
30+ PGP signatures would let developers reuse existing Ed25519 keys, and make use
31+ of existing key managment systems and hardware signers ** Conclusion: I added
32+ support for SSH and PGP signatures, but ultimately decided to remove it. This
33+ is something that adds complexity, so I want to do it based on actual demand,
34+ concrete benefits, and actual use-cases. **
8735
8836- * Should Bech32m be used for fingerprints, public keys, private keys, and
8937 signatures?* This would make them distinct and easy to identify, and give
0 commit comments