BBS Cryptosuite v2023 2023-12-15 > 2024-01-15

[Wind4Greg]

• name of spec to be reviewed: BBS Cryptosuite v2023 Securing Verifiable Credentials with Selective Disclosure
  using BBS Signatures

• URL of spec: https://www.w3.org/TR/vc-di-bbs/

• Does your document have an in-line Security Considerations section, ideally one separate from the Privacy Considerations? If not, corrrect that before proceeding further.
  Yes.

• What and when is your next expected transition?
  Transition to Candidate Recommendation in January 2024

• What has changed since any previous review?
  No previous review.

• Please point to the results of your own self-review (see https://w3ctag.github.io/security-questionnaire/)
  Security and Privacy Self Review vc-di-bbs#106

• Where and how to file issues arising?
  https://github.com/w3c/vc-di-bbs/issues

• Pointer to any explainer for the spec?
  https://github.com/w3c/vc-di-bbs/blob/main/EXPLAINER.md (soon to be merged from PR Add Explainer vc-di-bbs#105)

Other comments: This is a specific cryptosuite for use in the VC Data Integrity framework.

[kdenhartog]

I think it would be useful here to get assistance from the SECDIR list until the security lead at W3C is available to lead this. @msporny could you assist with getting a review of this or do you know if it was already done by chance? In particular, the issue raised during the privacy review about challenge property would be useful for them to take a look at and also just general feedback here in terms of cryptographic usage of BBS would be helpful to see if there's a way we could better normatively define this.

[msporny]

@msporny could you assist with getting a review of this or do you know if it was already done by chance?

I believe @Wind4Greg is currently engaged in this activity for the low-level BBS primitives via IETF CFRG and SECDIR. We were going to request SECDIR review on vc-di-bbs once it entered CR at W3C, but could kick the process off earlier if necessary.

[kdenhartog]

I'll leave that up to @plehegar to weigh in on, but good to hear it's going to get review from them at some point.

[Wind4Greg]

Hi all (@kdenhartog , @msporny), currently The BBS Signature Scheme is undergoing cryptographic review in the CFRG at the IRTF/IETF. Generally there are two different aspects to BBS signatures that folks find desirable: (a) a space efficient (from the issuers perspective) multiple message signature scheme that also supports selective disclosure, (b) a scheme that can support unlinkable proofs of possession of the signature.

The unlinkability property is completely dependent on what explicitly or implicitly a holder may be forced to disclose. A unique challenge proof option would reduce the anonymity set size to one, therefore breaking unlinkability. Hence the advice in section https://w3c.github.io/vc-di-bbs/#linkage-via-proof-options-and-mandatory-reveal. However, this has no impact on property (a) of BBS signatures, i.e., a short multi-message, selectively disclosable signature scheme.

Note that more advanced work related to BBS is being considered Blind BBS and BBS per Verifier Linkability to combat replay (and related attacks) while preserving some notions of anonymity.

Cheers Greg

[plehegar]

fyi, @simoneonofri is trying to get additional eyes to look at this document.

[simoneonofri]

@plehegar thanks for the pointer, yes I am working on it.

[simoneonofri]

Although we are still organizing the Security Interest Group—SING w3c/strategy/issues/449—some volunteers are already active, and we are considering opening a Community Group (@Wind4Greg we want you!) to enhance the effort now.

Thanks to @andrea-dintino and @jaromil from @dyne are working on this issue. Since they have developed a system that already uses BBS and includes Zero Knowledge Proof Flow, they have previous knowledge of the context. They already upgraded their platform to BBS version 5 dyne/Zenroom/pull/843 and produced both the tests on BBS and its integration.

In parallel @iherman is doing the recharter of del (Verifiable Credentials Working Group at w3c/strategy/issues/455 and has included a paragraph in the Scope to allow for practical handling of any remediations:

Once all the planned Recommendations have been published, the Working Group will continue in maintenance mode to handle errata. No new Recommendations are planned. Class 4 changes for Recommendations published by the Working Group are out of scope, except if serious security issues come to the fore that require changes in a Recommendation.

As @martinthomson pointed out to me earlier in the issue, at this stage when tests need to be defined, considering that the IETF groups are doing a lot of work on BBS, it makes sense to coordinate the effort, possibly on complementary activities and on different levels, considering also the liaison we have between W3C and IETF.

[msporny]

Excellent, thank you for the update @simoneonofri! We are continuing to work on the test suite, implementations, and test vectors in the BBS for Data Integrity specification in the VCWG.

https://www.w3.org/TR/vc-di-bbs/#test-vectors

We will let everyone know when the final test vectors are locked in. Work at the IETF is continuing to proceed to simplify the lower-level cryptographic interfaces. During implementation, we found that the BBS interfaces defined in the IETF specification were not ideal, resulting in library code that was more complex than necessary. We will let the community know when the interface stabilizes and the test vectors are finalized. At present, we don't expect that much will change wrt. the W3C specifications.

[andrea-dintino]

Thanks @msporny we're looking forward to see the updated vectors. We have updated our BBS implementation in Zenroom to the latest draft, so we hope that we can get the vectors to match in no time.