Specify cryptographic operations properly

[martinthomson]

This markdown file contains a very detailed specification of some cryptographic operations (which I have not yet reviewed). These really should not be hidden in some markdown file here. I do not believe that specification of cryptography is a core W3C strength and so would insist that this work be taken to the CFRG via the IETF Privacy Pass working group.

[dvorak42]

Currently the ISSUER_PROTOCOL document is a more implementation focused overview of:

VOPRF (https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/), currently the spec is pinned on an older version of the VOPRF, though I've updated #156 to track updating that.

PMBTokens (https://eprint.iacr.org/2020/072), since that paper isn't a CFRG/spec-style document there's a gap between the protocol definition in the paper and what's necessary to implement, which ISSUER_PROTOCOL attempts to fill. There's still an open question long-term whether this variant is necessary for the API, so we've been holding off on trying to get it standardized in the IETF, our long term plan if folks start using this variant is to bring a spec draft of the paper to the IETF.

Until we've built the spec draft, hopefully the file in the repo is well-formed enough for interop, though if there's any gaps to be able to interop, that would be good to know until we've specced an IETF draft for it.

[dvorak42]

One approach near-term we're thinking about is to update to the current VOPRF draft and expose that token type. For the private metadata type, its still needed in some other APIs experimenting with using the underlying crypto code exposed via PST internally, but we can hold off on exposing the private metadata variant to the web API for PST until we've further specified/standardized it, so that it isn't an interop dependency for the web PST API.