Re: [Privacy-pass] The PRIVACYPASS WG has placed draft-wood-privacypass-auth-scheme-extensions in state "Call For Adoption By WG Issued"

[Steven Valdez <[e-mail]>]

I support the adoption of these two drafts as WG items. I think having
support for some kind of metadata will be critical for a number of
applications of privacypass tokens.

For the sake of having a possible extension for the WG to build around, it
may also be worth trying to adopt either one of the extension drafts or
coming up with another extension with WG support. Maybe some time at 119
can be spent on either figuring out next steps for those?

It would also be good to see if there are other crypto primitives that
could be used to provide the metadata capability, but using partially blind
RSA as a starting point seems reasonable for privacypass (though that draft
should probably get some more reviews from the CFRG).


On Mon, Feb 19, 2024 at 12:10 PM Thibault Meunier <[e-mail]>
wrote:

> I'm currently going over the two documents (and the associated cfrg draft)
> about Privacy Pass with metadata.
>
> During the review, I've found these additional documents helpful:
>
>    - Two possible extensions for the registry created in
>    draft-wood-privacypass-auth-scheme-extension: geo-extension
>    <https://datatracker.ietf.org/doc/draft-hendrickson-privacypass-geo-extension/>,
>    expiration-extension
>    <https://datatracker.ietf.org/doc/draft-hendrickson-privacypass-expiration-extension/01/>
>    - Partially Blind RSA draft at CFRG:
>    draft-amjad-cfrg-partially-blind-rsa-02.html
>    <https://www.ietf.org/archive/id/draft-amjad-cfrg-partially-blind-rsa-02.html>
>
>
> Best,
> Thibault
>
> On Monday, 19 February 2024 at 17:56, Tommy Pauly <tpauly=
> [e-mail]> wrote:
>
> The core privacy pass architecture talks about metadata-supporting token
> types, so overall I think the WG needs to say *something* in this space.
>
> Looking at the two documents here:
>
> - draft-wood-privacypass-auth-scheme-extensions is a very minimal and
> reasonable mechanism. Assuming that we have drafts (like the other one)
> that will use it, I support adopting this document as the starting place
> for allowing the auth scheme to support extensions.
>
> - draft-hendrickson-privacypass-public-metadata, for an approach to adding
> metadata, also seems like a nice minimal approach. In general, I’m still
> concerned about metadata and the implication on privacy analysis. I think
> the document will need to say a lot more on what kind of metadata would be
> safe, how to guarantee consistency, and how to not allow the metadata to
> become a way to identify a single client across the issuance and redemption
> contexts. For example, if the metadata item is something that the client
> already is sharing with *both* the issuance and redemption contexts, and
> knows will be visible to everyone already, then adding the metadata doesn’t
> leak any additional state. However, if this is not the case, then it may be
> risky to reveal information to the issuance path that would otherwise not
> be visible. Providing some very concrete examples of what metadata can be
> would help immensely in the discussion.
>
> So, for this one, I am provisionally supportive of adoption if we can
> better articulate the bounds on usage and some clear cases that we can
> agree are admissible.
>
> As a nit on draft-hendrickson-privacypass-public-metadata: it uses the
> Blind(), BlindSign(), and Finalize() functions from RSA Blinding with extra
> parameters for the extensions that aren’t defined in the main RSA Blinding
> spec. Are these concatenations, or just cases of running the functions
> twice?
>
> Thanks,
> Tommy
>
> On Jan 30, 2024, at 11:28 AM, Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
> -extra aliases.
> ------------------------------
> *From:* Ben Schwartz <[e-mail]>
> *Sent:* Tuesday, January 30, 2024 2:21 PM
> *To:* IETF Secretariat <[e-mail]>;
> [e-mail] <
> [e-mail]>;
> [e-mail] <[e-mail]>; [e-mail]
> <[e-mail]>
> *Subject:* Re: [Privacy-pass] The PRIVACYPASS WG has placed
> draft-wood-privacypass-auth-scheme-extensions in state "Call For Adoption
> By WG Issued"
>
> Hi PRIVACYPASS,
>
> draft-hendrickson-privacypass-public-metadata and
> draft-wood-privacypass-auth-scheme-extensions have a mutual normative
> dependency, so (as previously discussed) the chairs have put them forward
> for a joint adoption call.  We hope that 3 weeks will be enough time for
> everyone to read both drafts and comment on their suitability for adoption.
>
> If you support or oppose adoption, please comment in this thread.
>
> --Ben Schwartz
> ------------------------------
> *From:* Privacy-pass <[e-mail]> on behalf of IETF
> Secretariat <[e-mail]>
> *Sent:* Tuesday, January 30, 2024 2:12 PM
> *To:* [e-mail] <
> [e-mail]>;
> [e-mail] <[e-mail]>; [e-mail]
> <[e-mail]>
> *Subject:* [Privacy-pass] The PRIVACYPASS WG has placed
> draft-wood-privacypass-auth-scheme-extensions in state "Call For Adoption
> By WG Issued"
>
> !-------------------------------------------------------------------|
>   This Message Is From an External Sender
>
> |-------------------------------------------------------------------!
>
>
> The PRIVACYPASS WG has placed draft-wood-privacypass-auth-scheme-extensions
> in state Call For Adoption By WG Issued (entered by Benjamin Schwartz)
>
> The document is available at
>
> https://datatracker.ietf.org/doc/draft-wood-privacypass-auth-scheme-extensions/
>
> Comment:
> Joint adoption call for draft-hendrickson-privacypass-public-metadata and
> draft-wood-privacypass-auth-scheme-extensions.
>
> --
> 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
>
>
>
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>


-- 

 Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |  Cambridge,
MA