Re: [Privacy-pass] Question on proposed charter

[Ben Schwartz <[e-mail]>]

Thanks.  With those changes I think this is ready to go.

On Tue, May 19, 2020 at 5:16 AM Alex Davidson <adavidson=
[e-mail]> wrote:

> Hi all,
>
> "Negotiation of cryptographic parameters during the protocol is an
> application-specific property and thus out of scope for the Working Group."
>
> What are the cryptographic parameters and why would they not need to be
> negotiated for interoperability?
>
> Also, is the following text a result of the algorithms being worked on in
> CFRG vs. this working group?
>
> I suspect this would be things like the curves and configuration used for
> the underlying crypto primitives. I think the idea is that the core
> PrivacyPass protocol wouldn't support any sort of negotiation, and the
> applications built on top of PrivacyPass would either specify the
> properties in their implementation or provide their own negotiation
> mechanism (for example an HTTP application might have the curves it
> supports hard-coded based on what the relevant clients/servers want to
> support for compatibility or have some HTTP-application-layer mechanism to
> choose corresponding server configurations..
>
> Though it might be worth specifying at the PrivacyPass layer what the
> actual "acceptable" combination of parameters is to maintain
> security/privacy properties.
>
>
> So I think the core of the matter here is that the ciphersuite is chosen
> by the Issuer ahead of time, and it is assumed that the client can retrieve
> this information apriori. So we can change this to: "The cryptographic
> profile used by the protocol participants will be determined by the
> specific instantiation of the protocol, and it will be chosen ahead of
> time.”
>
>
> "Specification of the underlying cryptographic algorithms or protocols is
> also out of scope."
>
> If so we might mention that this work depends on the work in the CFRG.
>
>
> I agree, perhaps we could replace this with: "We will work closely with
> the CFRG to determine acceptable cryptographic ciphersuites and parameters
> that satisfy the security/privacy properties of the protocol” to follow on
> from the sentence above?
>
> Additional changes:
>
> It was brought up off-list by Ben Schwartz that using the term
> “unlinkability” in the charter may lead to confusion, so I have replaced:
>
> "Any token granted by a given Issuer is unlinkable with all other
> tokens granted by the same Issuer.”
>
> With:
>
> "Any token granted by a given Issuer is indistinguishable from all
> other tokens granted by the same Issuer key at redemption
> time.”
>
> I’ve created a new PR with these proposed changes:
> https://github.com/alxdavids/privacy-pass-ietf/pull/27.
>
> Cheers,
> Alex
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>