> If we are going to do modern cryptography, we will either have a standard json representation or we won't.
This hits a main point for me. We want to use modern cryptographic schemes, and would prefer to have a standard JSON representation. None of the existing JOSE formats work, it looks like JWP would work great, while also making use of the general architecture shared by other JOSE formats. On Tue, Aug 2, 2022 at 7:00 AM Orie Steele <[email protected]> wrote: > Good security is about building the right layers. > > Many of these arguments might be better focused in the CFRG. > > I wonder if the argument in this thread might be some version of denying > the problem... If we are going to do modern cryptography, we will either > have a standard json representation or we won't. > > If the assertion is, let's not use that cryptography... That's not exactly > an argument against the envelope format. > > I am in favor or resurrecting JOSE and defining JWP. > > Regards, > > OS > > > > > > > > On Tue, Aug 2, 2022, 4:51 AM Neil Madden <[email protected]> > wrote: > >> On 30 Jul 2022, at 18:26, Jeremie Miller <[email protected]> >> wrote: >> >> >> Isn’t this somewhat overstating the likely privacy benefits? If the >>> prover reveals _any_ PII to the verifier then the verifier can collaborate >>> with the issuer to discover everything about that user. >>> >> >> JWP as a container aims to make unlinkability _possible_ for applications >> to build, not a guarantee. There are many extremes an application may >> choose to design for to accomplish different scales of unlinkability (from >> multiple verifiers colluding, from the verifier and issuer colluding, from >> multiple presentations to the same verifier, etc). >> >> In my mind it's akin to you can cryptographically validate the contents >> and signature in a JWS, but how you decide if you trust the signer is up to >> the application or higher level protocols. >> >> And we know from many studies on deanonymisation that it is very easy to >>> accidentally reveal enough information to be identifiable. ZK proofs are >>> nice and everything but they only ensure zero *additional* knowledge is >>> gained by the verifier. In practice what is explicitly revealed is often >>> enough. >>> >> >> That's exactly why we believe this work is very important, having a >> container to support algorithms where zero *additional* knowledge is >> revealed by the container and crypto layers. >> >> It *is* very easy to incidentally reveal linkable factors, which is why >> JWP is hard to get right, and critical to do so to enable this capability. >> >> IMO if you want to have any hope of actually achieving the privacy you >>> want then you really need to design the entire protocol, including >>> specifying exactly what information is to be revealed. I think designing a >>> generic “privacy preserving” message container is likely to give people >>> unrealistic expectations. >>> >> >> We have the lowest level privacy algorithms becoming well established >> like BBS (and CL signatures, etc), next we need a privacy-capable container >> to make those algorithms more accessible and interoperable, then we need >> privacy protocols to leverage those containers, then privacy aware >> applications, ecosystems, and user experiences. >> >> >> I think perhaps we most fundamentally disagree on this roadmap. Although >> many standardised systems have followed this kind of modular design, I >> don’t think it is the best approach. Compare say IPSec vs WireGuard for an >> often-cited example. Privacy is not a separable concern. Start with the >> privacy-aware applications. Otherwise I think we’ll end up with lots of >> “privacy-related” tools with lots of sharp edges that inevitably get used >> inappropriately. >> >> — Neil >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- Brent Zundel Principle Crypto Engineer - Avast
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
