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

[Joseph Salowey <[e-mail]>]

On Mon, Jun 26, 2023 at 5:56 AM Christopher Wood <[e-mail]>
wrote:

> 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?
>
>
[Joe] Yes, Shepherd write-up is in progress, review welcome -
https://datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/shepherdwriteup/


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