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

[Colin Bendell <[e-mail]>]

On Fri, 16 Jun 2023 at 13:07, Christopher Wood <[e-mail]> wrote:

>
> 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,
>

I think you missed my comments below.

As I said, the http cache-control only describes the document's lifecycle.
Two main issues:

1. The directory might have a TTL, but that doesn't reflect the specific
age of each entry. What TTL should you set for a directory of 100 keys with
a rolling 60 day offset for expiration? I think what you are assuming is
that the CC should be 60 day and then the expired entry just disappears
magically leaving 99? The challenge of course is that this doesn't give any
signal to the consumer which key is nearing expiration relative to the
other keys.

2. The TTL from Cache-Control does not cleanly map to an
expiration date/time since you need to depend on other transient details.
(This is a classic problem of the interdependence of the Age, Date and
Cache-Control headers). For an infrastructure operator, certificates are
expected to have a fixed date/time for expiration and when the cert will be
removed from rotation. This provides assurances of a token that is issued
and when to expect that the token should expire. Just depending on the cert
to be 'removed' from the directory is a surprising behavior for certificate
change management processes.

Further, as I mentioned below, in the PST case, the specific expiration of
a key is used in the selection process in the client-issuer communication.
In PST, the UA uses 6 keys with the longest expiry date. Only tokens issued
from this 6 can be added, while previous tokens are permitted. (I'm not
sure how strong this argument is, since I'm not sure how much of a priority
it is to converge the W3C / IETF variations. As an outsider, it would be
nice if these spec's did align. Allowing for these directory attributes
would pave a way to simplify the W3C spec. IMHO of course)

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/
> ).
>

Ah! Why not merge the support for batch-tokens into the type=1 definition?
I had assumed this was the intention since VOPRF BlindEvaluate function
(draft 21) already allows for individual or arrays of elements. The only
gap then is the TokenRequest & TokenResponse structs (and possibly
adding ristretto255-SHA512 ) This is probably a different conversation
though. The cross-over is the necessity to specify the batch-size in the
issuer-directory.


>
> 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
>
>>