Re: [Privacy-pass] Issuer directory representation (#369)

[Christopher Wood <[e-mail]>]

On Jun 16, 2023, at 12:58 PM, Colin Bendell <[e-mail]> wrote:



On Thu, 15 Jun 2023 at 19:28, Christopher Wood <[e-mail]> wrote:

To hopefully close the loop in this, I put together this PR that conceptually lifts the concept of key commitments from PSTs into the current Privacy Pass issuer directory:

I initiated this thread after contrasting the similar key-sets exposed forPrivacyPass and Private-State-Tokens. As an outsider here, I'd like to see PrivacyPass expand the set of tokens so that PST can remove the definition from the W3C spec and depend exclusively on the PrivacyPass definition. To this end, the issuer directory should also include:

* expiry

* batch-size

* key-id / version

I think expiry information can be inferred from the resource’s cache control directives, and version is implied from the list of keys in the directory. That leaves key ID and batch size. The former is computed directly from the public key, so we don’t need to redundantly include it. The latter could be included as an optional parameter for issuance protocols that want to communicate this hint to the client. That parameter could even be included in the batch token issuance spec (https://datatracker.ietf.org/doc/draft-robert-privacypass-batched-tokens/" rel="nofollow">https://datatracker.ietf.org/doc/draft-robert-privacypass-batched-tokens/). 

So altogether I think we’re covered?

Best,

Chris 

Expiration is important for PST because it is used by the UA to select from a set of possible keys. HTTP Cache-Control does not serve the same function as a certificate expiration. The cache-control header reflects the ttl of the directory, but the expiration for each public key. If we were to use HTTP cache policies, all public keys would be treated as if they had the same expiration. 

Batch-Size is interesting for VOPRF workflows where the issuance request includes multiple nonces. In this case the compute work for the issue request needs to be known apriori. Can the issuer handle 1 or 10 or 100 token batches?

key-id or version is not needed for the protocol, but as a dev ergonomics it is nice to have a common implementation. Is it called 'version' or 'id' or 'key-id'?

 

I think we can pursue alternative representations separately.

Sounds good. 

/colin