proposal: Update invoice signature spec

[lann]

Following up on #284 and #292, I'd like to change the signature spec from signing data derived from the invoice file to signing the invoice file itself. This would require a few related changes:

• The signature(s) would not be stored in the invoice.toml itself, but as part of a separate structure (e.g. signatures.toml; name bikeshedding welcome)
• The server would need to store the bytes of the invoice.toml (and signatures) rather than just the semantic data
• Updates to bindle yanking to keep the invoice immutable
• Protocol updates to reflect these changes
• [anything I missed?]

Disadvantages

• Signature-verifying Bindle implementations must have a TOML implementation
• Some server-side storage overhead from storing serialized TOML
• An extra data structure (file)

Advantages

• Easier to reason about backward compatibility in invoice format
• Avoids any canonicalization attack problems with verification
• Signing and verification is somewhat simplified

[fibonacci1729]

@thomastaylor312 Would love your thoughts here!

[lann]

Another proposal for signatures; I think this is what I would prefer for a TOML-based solution:

[[signature]]
# Untrusted label: Maybe Real Signer <[email protected]>
signer = """
key = "1c44..."
role = "creator"
at = 1611960337
"""
signature = "<hex(sign('BINDLE-SIGNATURE-V1:' || sha256(invoice) || ':' || meta))>"

[lann]

I think I've covered most of the changes in #322 now. Biggest change to the protocol is that bindle GET/POST would work with a string version of the invoice, e.g.

invoice = '''
bindleVersion = "1.0.0"

[bindle]
name = "mybindle"
version = "0.1.0"
...
'''

[[signature]]
...

[thomastaylor312]

Just getting round to this in #322. I'll drop all comment there