Subject: Re: [Privacy-pass] Extensibility and public verifiability

From: "Christopher Wood" <[email-masked]>
Date: Thu, 12 Aug 2021 08:51:28 -0700

Quick update: carrying this change forward led me to a different conclusion, described in https://mailarchive.ietf.org/arch/msg/privacy-pass/mroCi5askpw3DbZovumUlQWIzDY/. 

On Tue, Jul 27, 2021, at 10:32 AM, Christopher Wood wrote:
> Adding support for public verifiability is currently in scope for the 
> WG. Now that we have one possible candidate [1], I found that trying to 
> add this feature was... awkward:
> 
>    https://github.com/ietf-wg-privacypass/base-drafts/pull/76
> 
> Many of the protocol message elements assume a VOPRF-like construction 
> that just doesn't work well with this type of blind signature. For 
> example, the IssuanceResponse carries evaluated elements and a proof, 
> whereas the things required for a blind signature protocol may be 
> different. This seems to suggest that too much of the VOPRF 
> instantiation has leaked into the Privacy Pass protocol messages. 
> 
> I'd like to propose that we fix this abstraction issue by keeping all 
> things specific to the cryptographic protocol encapsulated, as I've 
> tried to do here:
> 
>    https://github.com/ietf-wg-privacypass/base-drafts/pull/79
> 
> This change refactors the document and protocol details in order to 
> abstract over the cryptographic protocol underneath. With this change, 
> if we want public verifiability, then we can simply introduce a new 
> variant that supports public verifiability, define its protocol wire 
> format, and the rest should fall out. A side effect of this change is 
> that it removes much of the implementation-specific details for clients 
> and servers, which seemed unnecessary after a fresh read.
> 
> What do folks think?
> 
> Best,
> Chris
> 
> [1] https://datatracker.ietf.org/doc/draft-irtf-cfrg-rsa-blind-signatures/
> 
> -- 
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>