Re: [EXT] ETSI TR 119 476 on selective disclosure

If by plausible quantum safe you mean that the correct signature suites
could be selected to either 1) introduce quantum safe components, or 2) use
a quantum safe signature method like dilithium then that table is "ok".

I feel pretty uncomfortable without some kind of note on the table that
lists acceptable and tested quantum safe signature methods that would be
required to get things actually quantum safe.

Mike Prorock
CTO - mesur.io

On Wed, Aug 30, 2023, 08:47 Sebastian Elfors <sebastian.elfors@idnow.de>
wrote:

> All,
>
>
>
> Thanks for your comments Brent, Manu and Orie. It’s very useful to get
> your feedback on the ETSI TR 119 476, and we will gather all feedback with
> the intent to present it to the ETSI ESI management. We’ll also propose a
> new work item to update the ETSI TR once we have reached a critical mass of
> feedback.
>
>
>
> I’d like to continue on the track that Peter pointed out: The main focus
> of the ETSI TR is to analyze the two PID formats that have been recognized
> for selective disclosure in the ARF, i.e. SD-JWT and ISO mDL MSO. Those
> formats were selected since the cryptographic algorithms used for
> signatures are approved by SOG-IS and allow for post quantum safe
> cryptography. Furthermore, the SOG-IS approved algorithms are allowed for
> use by the public sector in the EU.
>
>
>
> In Annex A.1 of ETSI TR 119 476, there is a table with a column indicating
> if the cryptographic algorithms are plausible quantum safe. Feel free to
> review, and let us know if you have any comments on that.
>
>
>
> Kind regards,
>
> Sebastian
>
>
>
> *From:* Altmann Peter <peter.altmann@digg.se>
> *Sent:* Wednesday, 30 August 2023 16:28
> *To:* Sebastian Elfors <sebastian.elfors@idnow.de>; Manu Sporny <
> msporny@digitalbazaar.com>; Orie Steele <orie@transmute.industries>
> *Cc:* Brent Zundel <Brent.Zundel@gendigital.com>; public-vc-wg@w3.org
> *Subject:* Re: [EXT] ETSI TR 119 476 on selective disclosure
>
>
>
> *CAUTION:* This email originated from outside the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> @Orie Steele
>
> Correct. I would even add assuming issuers are trusted not to collude with
> anyone, unsinkability is achieved when combined with batch issuance and
> single use attestations. This is why the ETSI TR recommends batch issuance
> for salted attribute hash based approaches.
>
> You also correctly point out that the batch issuance proposal is
> problematic and burdens several actors, not to mention makes revocation
> more difficult too. Note here that for some attestations, e.g., the PID
> (Person Identification Data) attestation, the public sector is not allowed
> to use non standard cryptography. We recognize the value of alternative
> solutions that do not require batch issuance and that can protect against
> issuer collusion too, and hope that these will be available for public
> sector use in the future as standardization efforts progress. In ways, I
> view the ETSI TR also as a call for standardization.
>
> @Manu Sporny
>
> Thanks for pointing out concerning areas! We always intended to update the
> text once we could gather input from experts. To respond to your concerns:
>
>    - *The TR does not include a variety of SD schemes that are under
>    active development*. This is due to several factors, non of which are
>    us being biased toward a particular solution. Our analysis is, however,
>    possibly biased due to our diverging understanding of the various
>    techniques / schemes. With that being said, we tried to focus our initial
>    analysis mainly on the techniques that were relevant for the eIDAS
>    negotiations. What is relevant is of course an opinion and we recognize
>    that we can make decision not everyone agrees with. For instance, we did
>    look at ACDC, ECDSA-SD, and Gordian Envelopes, but chose not to include
>    these since we either did not find them relevant for the attestation
>    formats that are currently prioritised by the European Digital Identity
>    Wallet (EUDIW) or could not find a clear enough description of the
>    technique in time for publication of the ETSI TR. This is not to say that
>    we do not recognize the merits of the work, and we may have missed how they
>    can support the core EUDIW formats. If so, please let me/us know. The field
>    is incredibly complex and any work such as this ETSI TR benefits greatly
>    from multiple eyes. For a future ETSI TR, we may extend the focus on
>    schemes / techniques that are relevant for formats beyond the core EUDIW
>    formats.
>    - *Some conclusions do not align with the specification text in the
>    VCDM, especially the claim that SD-JWTs are incompatible with VCDM*.
>    This was one of the topics we discussed the most and where we sought
>    external input. A few clarifications here, we only intended to state that
>    joint utilisation of VCDM 1.1 and the SD-JWT specification that was
>    available at the time was problematic to the point that the two are
>    incompatible without further work. We are aware of the ongoing work with
>    VCDM 2.0 and SD-JWT and SD-JWT VCs, and we would much welcome input on how
>    to jointly utilise the two (I know this is a core interest for several
>    large scale pilot actors in the EUDIW trials too), but these were not
>    included in the report for a few reasons. The two main ones being:
>
>
>    - The specification was not available at the time of authoring the text
>       - The Architecture Reference Framework for EUDIW specifically
>       mentions VCDM 1.1, so our analysis focused on VCDM 1.1.
>
>
>    - *Unlinkability and batch issuance*. I here refer to my above reply
>    to Orie. Batch issuance is not a good solution; arguably quite a bad one
>    that burdens the issuer, holder, revocation service etc. And as you point
>    out, past experiences are worrying. But for the certain public sector
>    issued attestations like the PID, we are constrained by certain
>    requirements and have to work with the assumption that issuers will not
>    collude. If you have a proposal on how to enable unlinkability using
>    standard cryptography and that works with salted attribute hash based
>    approaches, I am all ears! In particular, I am excited about the work with
>    BBS+ and hope that standardization efforts go smoothly.
>
>
> Thank you both, and with hopes of additional comments and inputs. As
> stated, we are in the process of collecting everything so that an updated
> version of the ETSI TR can address the concerns you mention, provide
> additional clarifications, and extend the analysis to a deeper and wider
> coverage of techniques that are relevant outside of the EUDIW Core formats.
>
> BR,
>
>
> Peter Lee Altmann
> PhD. Specialist Digital identitet
> PhD. Specialist Digital Identity
>
> DIGG – Myndigheten för digital förvaltning
> Agency for Digital Government
>
> +46 (0)72-464 18 06
> www.digg.se
>
> On 30 Aug 2023, 15:41 +0200, Manu Sporny <msporny@digitalbazaar.com>,
> wrote:
>
> On Wed, Aug 30, 2023 at 5:54 AM Sebastian Elfors
> <sebastian.elfors@idnow.de> wrote:
>
> Hopefully, this clarifies the principles of unlinkability as described in
> ETSI TR 119 476.
>
>
> Hi Sebastian and Peter, thank you for the paper and all the effort
> that went into it. I have skimmed it and found a number of areas of
> concern. I'll just mention three of them in this email, as I haven't
> been able to read it in depth.
>
> The first issue is that it doesn't include a variety of other
> selective disclosure schemes that are under active development...
> namely, ACDC, Gordian Envelopes, the Singapore governments work, and
> ecdsa-sd. The latter one is a part of a deliverable for the VCWG:
>
> https://w3c.github.io/vc-di-ecdsa/#ecdsa-sd-2023
>
> presentation about it is here:
>
>
> https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#
> <https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit>
>
> The second issue is that some of the conclusions reached in the
> analysis don't seem to align w/ with the specification text in the
> VCDM specification. Most notably, the claim that SD-JWTs are
> incompatible w/ the VCDM. I'll try to find more time to read through
> the material with my VCDM Editor hat on, but given the length of the
> paper (and the VCWG's current workload), it might take a while to get
> back to you on this.
>
> The third issue has to do w/ Brent's read on the paper... I was
> confused in the same way that he was wrt. how the term unlinkability
> is used in the paper.
>
> Issue a batch of SD-JWTs to the Holder to enable the Holder to use a
> unique SD-JWT per Verifier. This only helps with Verifier/Verifier
> unlinkability.”
>
>
> Oof, no, that's a dangerous thing to suggest.
>
> Hopefully, this clarifies the principles of unlinkability as described in
> ETSI TR 119 476.
>
>
> It helps, and it aligns more closely with what I thought the
> definition of "unlikability" was... but it highlights more concerns as
> a result. I'll be bold and say that it would be a stretch to say that
> the current trajectory supports unlinkability at any real depth. In
> fact, it proposes that unlikability is possible, but using an approach
> that has been demonstrated to fail in the past, which is effectively a
> variation on stateful signatures.
>
> The problem w/ stateful signatures over the many years that they've
> existed is that implementers usually get the "state tracking" part of
> the implementation wrong in a variety of ways. In fact, we had
> considered it for ecdsa-sd and decided that it would create two
> untenable issues:
>
> * a misimplementation at a wallet would result in a privacy failure
> (accidentally sending a previously used signature/hash).
> * it would require coordination among multiple devices if the wallet
> was multi-device capable (which we expect a number of wallets to be
> multi-device capable).
>
> So, instead of stating that "it is possible for ecdsa-sd to be
> unlinkable", we chose to say: "No, we shouldn't even promise that
> because it's so easy for an implementation to mess it up and create a
> privacy failure."
>
> That is why we believe that if unlinkability is desired, you will need
> to use a scheme that actually supports it at the cryptographic layer
> -- something like BBS+, which the VCWG is also working on.
>
> More as some of us read through more of the paper... thank you again
> for the analysis, you've got the attention of at least some of the
> people in the WG. :)
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>