WICG/trust-token-api

Does the PrivateStateTokenPublicKey struct include id or not for key commitment?

colinbendell opened this issue · 6 comments

colinbendell commented

In ISSUER_PROTOCOL.md the struct for PrivateStateTokenPublicKey is defined as:

struct {
  ECPoint pub;
} PrivateStateTokenPublicKey;

But, the WPT test used in chromium specifies the struct as:

struct {
  uint32 id;
  ECPoint pub;
} TrustTokenPublicKey;

I'm assuming that it is chromium that has the bug? It appears to be redundant to include the id in the serialized form in the Key Commitment.

dvorak42 commented

It should include the key ID. The reasoning it was added was so that clients could just ship the raw unparsed key around and be able to verify with that, rather than also having to ship the entire key commitment dictionary (and then parse the key ID out of the keys of the dictionary). I'll add that to the list of things to update. As part of #230 we'll have the spec move some of the serialization into the doc and then point at the VOPRF draft directly.

colinbendell commented

Out of curiosity, why not just use JWK? JWK already has kid field for this purpose. The publicKey scalar for VOPRF calculations is just concat([0x04], jwk.x, jwk.y)

For example, the jwk for that's used in the WPT tests (P384_ORDER -1) is the equivelent of:

{
  kty: 'EC',
  crv: 'P-384',
  kid: 0,
  x: 'qofKIr6LBTeOscce8yCtdG4dO2KLp5uYWfdB4IJUKjhVAvJdv1UpbDpUXjhydgq3',
  y: 'yeghtWnZ05CiYWdAbW0j1gcL4kLXZeuDFiXO7EoPRz71n04w4oF-YoW84oRvFfGg',
  d: '////////////////////////////////x2NNgfQ3Ld9YGg2ySLCneuzsGWrMxSly'
}
colinbendell commented

If the eventual goal is to align this key commitment with the issuer-directory defined in PrivacyPass Protocol, then the token-key should not depend on an ordinal vlaue but instead depend on token_key_id (sha256(encoded_key)). This would further help disambiguate the two key_id's presented in the key commitment structure.

dvorak42 commented

Currently we're not planning on aligning with the current issuer directory definition in privacypass, as the current version isn't well-suited to having keysets with expiry to support using the key ID/key selection to notate "public metadata". Once there's a public metadata token type (or explicit support for it via key selection) we might migrate to that token type in a future version of PST.

colinbendell commented

The PrivacyPass protocol specifies that the last 8 bits of the truncated_token_key_id should be used for this identifier (last 8 bits of the token_key_id). Wouldn't that suffice and avoid managing an index by hand?

I'm specifically concerned that implementors will use the "6 key limit" and index the keys 1-6, and then just replace the actual key that is mapped. This will cause a client error if the client is out of sync with the public keys issued. Using a derived key_id would make it clear to both client and server which is out of date.