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

[Christopher Wood <[e-mail]>]

To close the loop here, we published a new version that included #381. All outstanding issues are now resolved.

Chairs, can we please move this forward?

Thanks,
Chris

> On Jun 16, 2023, at 7:51 PM, Christopher Wood <[e-mail]> wrote:
> 
> 
> On Jun 16, 2023, at 6:12 PM, Tommy Pauly <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Jun 16, 2023, at 11:13 AM, Colin Bendell <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> 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)
>> 
>> A meta-comment here:
>> 
>> There shouldn't be any “variants” between the W3C and IETF — any extensions for the web that W3C does should be built upon Privacy Pass, but not something in contradiction to it. All of these other deployment models (like what is proposed in PST) are just ways to instantiate Privacy Pass, and should align with privacy pass as a standard.
>> 
>> In this case, of course other specs can add recommended keys to add to a JSON dictionary (that can still align), or we could define “not-after” while we’re defining “not-before” and just be done with it.
> 
> Given that we have not had a need for not-after with current deployments, I suggest punting this to a future document. The cache control directives have been sufficient so far. Let’s not add complexity when it’s not yet needed. 
> 
> Best,
> Chris 
> 
>> 
>> Tommy
>> 
>>> 
>>> 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
>>> -- 
>>> Privacy-pass mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>> 
> -- 
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass