Origin name encryption algorithm

[chris-wood]

The issuer's HPKE configuration admits multiple algorithm configurations, each one indicating a KEM, KDF, and AEAD tuple. Clients use this configuration when encrypting the origin name to the issuer. However, the client's request currently doesn't convey what algorithm selection was used for this encryption. We can either restrict things so that each HPKE configuration has exactly one algorithm tuple, or the request can convey the client's selection. (I don't think trial decryption is a reasonable option here.)

[tfpauly]

We have this today:

struct {
   uint8_t version;
   uint8_t client_origin_index_request[Ne+Ne+Np];
   uint8_t token_key_id;
   uint8_t blinded_req[Nk];
   uint8_t issuer_key_id[32];
   uint8_t encrypted_origin_name<1..2^16-1>;
} AccessTokenRequest;

Could we break this up as:

struct {
   uint8_t version;
   struct {
      uint8_t token_key_id;
      uint8_t blinded_req[Nk];
   } blind_token_request;
   struct {
       uint8_t client_origin_index_request[Ne+Ne+Np];
   } client_proof;
   struct {
      uint8_t issuer_key_id[32];
      uint8_t encrypted_origin_name<1..2^16-1>;
   } encrypted_origin_name;
} AccessTokenRequest;

[tfpauly]

@chris-wood is this sufficiently addressed by the updated drafts?

[chris-wood]

I don't think so. The request still doesn't convey the chosen HPKE parameters, so we can use this issue to track that.

[tfpauly]

If we're changing the challenge format for HPKE to not be OHTTP (#124) then we don't need to support specifying algorithm IDs in the token request.

[chris-wood]

Addressed in #139.