-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does the PrivateStateTokenPublicKey struct include id or not for key commitment? #245
Comments
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. |
Out of curiosity, why not just use JWK? JWK already has For example, the jwk for that's used in the WPT tests (
|
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 |
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. |
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. |
In
ISSUER_PROTOCOL.md
the struct forPrivateStateTokenPublicKey
is defined as:But, the WPT test used in chromium specifies the struct as:
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.The text was updated successfully, but these errors were encountered: