Double check adaptor implicit certificates

[burdges]

We include an implicit certificate scheme similar to ECQV implicit certificates, as described in "Standards for efficient cryptography, SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV)".

We also hash the issuer's public key when creating the challenge e, mostly because it sounds wise, but also since that helped with the MQV vs HMQV issues. Ristretto handles most point validation issues here, but anything like the identity, etc. needs checking.

I'll read through the security proof somewhat closer eventually. See:

Daniel R. L. Brown, Robert P. Gallant, Scott A. Vanstone. "Provably Secure Implicit Certificate Schemes". Financial Cryptography 2001. Lecture Notes in Computer Science. Springer Berlin Heidelberg. 2339 (1): 156–165. doi:10.1007/3-540-46088-8_15.

[burdges]

Also we need more tests if we're actually going to use these anywhere.

[burdges]

I wonder if ring implicit certificates make sense.. I could imagine these being useful in peer-to-peer networking, if either schnorrkel were also being used for a key exchange at the transport layer, or else if we standardized a mapping from Ristretto to Ed25519. #38

[burdges]

We killed ECQV in favor of an adaptor signature based implicit certificate scheme that can be abstracted better. We should still explore the MQV vs HMQV issues and do security arguments for this adaptor signature based implicit certificate scheme.

[burdges]

It's possible ECQV implicit certificates chain better than adaptor ones, not sure yet.