write new cryptographic signature library

[david415]

• we need directory authority and mix identity key agility; that is we need a system that supports offline longterm signing keys and online midterm signing keys, certificates for the midterm keys signed by the longterm keys, key rotation, key revocation et cetera.

• we should probably write a certificate specification before writing any code.

  • here's an example: https://gitweb.torproject.org/torspec.git/tree/cert-spec.txt
  • OK here's my rough draft certificate specification document https://github.com/katzenpost/docs/blob/certificate.0/drafts/certificate.rst

• we need to decide upon a serialization format: this tends to start bike shedding discussion but right now it seems the contenders are:

  • cbor
  • bson
  • msgpack
  • protobuf

• Can it be practical to use sphinc-256 or other more modern more efficient hash based post quantum stateless cryptographic signature scheme? Is there a coherent threat model where this makes sense?

[david415]

OK. I wrote a certificate library, here it is: https://github.com/katzenpost/core/pull/48

This needs review. Note that it uses core/crypto/eddsa (ed25519) and the CBOR schema-less serialization format. This seemed like the least annoying and laziest way to write this library. It should handle both of our use cases:

• mix medium-term key certificates
• directory authority multi signature certificates for signing votes and consensus documents

That is to say, we can use this library to certify key and documents with one or more signatures.

[david415]

OK. I've made various corrections pointed out by @nogoegst in the pull-request code review. I've added expiration validation and test vectors as well ;-p But we still SHOULD NOT merge into core until @mixmasala has reviewed it's viability to replace our JOSE library for encoding multiple signaures in directory authority documents.

[david415]

my cert library works. we've upgraded the authority clients and servers for both the nonvoting and voting authorities.