[MINUTES] CCG Data Integrity 2026-01-16

Here's a summary of the CCG Data Integrity meeting on 2026/01/16:
Meeting Summary - CCG Data Integrity - 2026/01/16

*Attendees:* Dave Longley, Greg Bernstein, Manu Sporny, Parth Bhatt,
Stephen Curran, Ted Thibodeau Jr

*Topics Covered:*

   -

   *BBS Crypto Suite Progress and Future Work:*
   - *Current Status:* The group discussed the ongoing work on the BBS
      crypto suite, focusing on features like everlasting privacy via
NIM secrets
      and anonymous holder binding. Greg Bernstein indicated that
while the core
      is stable, there are ongoing technical discussions for blind BBS and
      pseudonyms that could impact test vectors but not the API.
      - *CFRG Process:* The slow pace of the CFRG (Crypto Forum Research
      Group) was noted as a bottleneck.
      - *Dan Yamamoto's Work:* There was discussion about Dan Yamamoto's
      research into more atomic breakdown of statements within BBS,
which doesn't
      change the canonicalization algorithm but allows for more
granular proofs.
      This could potentially enable features like proof of possession
with ECDSA
      public keys, which is of interest to European stakeholders.
      - *Prioritization and Trade-offs:* The group debated the trade-offs
      between releasing a simpler, more efficient version of BBS quickly versus
      incorporating more complex features like per-element proofs and ECDSA key
      binding. The consensus leaned towards prioritizing getting a functional
      version out, while keeping the door open for future enhancements.
      Collaboration with European efforts on ECDSA binding was seen as a strong
      opportunity if it doesn't cause significant delays.
      - *Next Steps:* Discussions with Anya to understand Dan Yamamoto's
      willingness to contribute further and to coordinate with European
      stakeholders were identified. The need for implementations to
move forward
      was emphasized.
   -

   *Data Integrity Crypto Suite Refactoring:*
   - *Goal:* The primary goal is to modularize the data integrity crypto
      suite specifications to make it easier to add new crypto suites,
      particularly for selective disclosure.
      - *ECDSA Selective Disclosure:* The selective disclosure functions
      for ECDSA, currently in a separate section, need to be moved to the core
      data integrity algorithms section. This is considered an editorial task
      that is time-consuming but crucial for enabling selective disclosure in
      other crypto suites (e.g., post-quantum).
      - *Publication Timeline:* This refactoring is necessary before
      proceeding with the first public working draft of version 11 specs and
      basing new work on it.
      - *Work Allocation:* Greg Bernstein and Manu Sporny are the primary
      candidates to undertake this editorial work.
   -

   *Quantum Safe Crypto Suites (Post-Quantum):*
   - *Lack of Progress:* Progress on defining post-quantum crypto suites
      has been slow due to a lack of dedicated editors.
      - *Available Algorithms:* Algorithms like stateless hash, crystals
      dilithium, and Falcon are identified as having available implementations
      (JavaScript, Python) for generating test vectors.
      - *Editor Needed:* The primary blocker is the absence of an editor to
      move the work forward.
      - *Algorithm Selection:* The current draft includes four post-quantum
      mechanisms, which is considered too many. The group discussed templating
      the spec to accommodate different algorithms with varying parameters and
      crypto suite names, rather than having separate sections for each.
      - *Algorithm Parameters:* The spec will focus on NIST Level 1 for
      now, with the understanding that other levels can be handled through
      parameterization.
      - *SkiSign:* SkiSign is a desired algorithm but is still in NIST
      competition, meaning it won't be finalized for years. The group plans to
      slow-walk its inclusion and focus on generating test vectors.
   -

   *SM2 Crypto Suite:*
   - *Request from China:* There's a request to add a data integrity crypto
      suite for SM2, China's national cryptography standard.
      - *Trivial Implementation (Potentially):* The SM2 suite is expected
      to be relatively straightforward to implement as it's based on elliptic
      curves, similar to ECDSA.
      - *No Current Resources:* The group currently lacks the resources to
      undertake this work. Involvement is contingent on individuals
from Chinese
      national standards bodies joining the W3C working group to contribute.

*Key Points Made:*

   - The pace of standardization bodies like CFRG is a significant
   challenge.
   - Balancing the need for quick releases with the desire for
   comprehensive features is a recurring theme.
   - Collaboration with international bodies (e.g., Europe, China) is
   valuable but requires dedicated resources and engagement.
   - Modularizing specifications is essential for future extensibility and
   reducing duplicated effort.
   - The lack of dedicated editors is a major impediment to progress on
   several fronts.
   - The group aims to make the data integrity specifications easier to use
   and extend.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-data-integrity-2026-01-16.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-data-integrity-2026-01-16.mp4
*CCG Data Integrity - 2026/01/16 09:46 EST - Transcript* *Attendees*

Dave Longley, Greg Bernstein, Manu Sporny, Parth Bhatt, Stephen Curran, Ted
Thibodeau Jr
*Transcript*

Manu Sporny: All right, let's go ahead and get started. it's a small group
of us today. the, agenda for today is basically to kind of plan our work
for 2026. and that includes, figuring out what we need to finish up on the
BBS crypto suites. the updates that we want to do for the version data
ingrity modularizing the specifications so that it's easier to add new
crypto suites and hopefully using that new structure to do the quantum safe
crypto suites, the postquantum crypto suites.

Manu Sporny: there was also a outreach from folks in China about the SM2
crypto suite. They're interested in, doing a crypto suite over there that
supports their national crypto. and so that could be, a part of the
restructuring so to make it easier for them to add theirs as well. I think
that's largely the agenda for today. any other updates or changes to the
agenda? Anything else we want to talk about today? All right. then let's go
ahead and Let's, I guess get started with a quick update on where we are
with BBS.

Manu Sporny: Greg, if you could take us through kind of where we are with,
what, needs to be done. Ideally, we should be getting down to timelines at
this point. it's taking forever and we need to understand kind of how much
longer each one of these steps are going to take.

Manu Sporny: So, if you could give us a quick update on BBS, I think we
let's start there.

Greg Bernstein: So I don't know…

Greg Bernstein: where this general group left off. as far as knowledge of
what we were doing on BBS, the last big technical thing we were working on
was getting everlasting privacy on the pseudonym feature. and we ended up
doing that via a vector of secrets known as we call them NIM secrets.
00:05:00

Greg Bernstein: And there's a lot of different potential ways of doing
things, but we chose a way that did not require any new cryptography or
things like that. Basically using some of the techniques that were kind of
tried and true. so that leaves us with, I'll have to double check if I
incorporated those changes yet into test vectors for NE secrets. I may not
have or updated the document. Now, we are continuing to work on getting BBS
core in the last call. That seems fairly stable.

Greg Bernstein: We've had some technical questions on how we do certain
things in blind BBS that are somewhat underneath what the API would look
like. They could affect the test vectors but they wouldn't really affect
the API for we use blind BBS underneath pseudonyms and we use them for what
we call the anonymous holder binding. This allows the holder to prevent
other folks from using its credentials if they got a hand on the signed
credential. so only they can make actually a d selectively disclosed
credential.

Greg Bernstein: so it shouldn't affect the outside, but we have to satisfy
folks over at the CFRG. So, we're in the process of doing that right now. I
can't tell you about timelines at the CFRG for core and things like that.
it should have been done last year or a year before they move so slow.
being a research group as soon as you tell them to hurry up they slow down.
because why are you asking us to hurry up? We're a research group. So it's
kind of a spender that way. So we try and get along with the chairs there
and keep pushing things forward.

Greg Bernstein: We did get some in interest and requests for maybe some
generalization from folks that are working in Europe on UDI and such like
that. So as far as the Stephen okay.

Stephen Curran: I didn't mean to cut you right off. I just meant I had a
question coming up.

Greg Bernstein: So as far as the data integrity BBS suite,…

Stephen Curran: Would you finish

Greg Bernstein: I've got to check. I don't think I put in the NIM secrets
stuff yet. as far as the multiples for the everlasting unlinkability and
that needs to go in because that we pretty much have arrived at.

Greg Bernstein: So I would think what we can do now is update the text
portion. the only thing about the test factors is they may change if
there's some underlying decision changes that would impact what the
signatures look like. So that's kind of where we're at. I think we have
good API and functionality things specifi figured out for those two very
important features that go along with the basic unlinkability and selective
disclosure of BBS.

Greg Bernstein: so as far as trying to push the group quicker at the CFRG
the only thing for me is resolving some of these issues on so we don't
break test specters for the advanced features. the core seems pretty stable
and nobody seems too much want to change it but blind and pseudonyms are
potentially test factor breaking though not super big changes to any API
and how we would use it from the point of view of credentials.
00:10:00

Greg Bernstein: So, that's kind of where we're at. And people are back from
vacation.

Greg Bernstein: So, we've actually had BBS meetings for the C diff CFRG
folks. So, getting moving again.

Manu Sporny: All right.

Manu Sporny: Thanks for the update. go ahead, Stephen.

Stephen Curran: …

Stephen Curran: I understand the IETF process and that's kind of a layer
below data integrity in the crypto suite you're building here. what I was
wondering was where does the work Ken Yamamoto is doing and I had a
exchange with Dave Longley in December or so and wondering are there IETF
changes needed?

Stephen Curran: In other words, is there changes needed in the work being
provided to IDF to be able to support what Dan Yamamoto has put into his
version of the BBS crypto suite?

Stephen Curran: Or would we be able to adopt some of the things he's doing
that aren't in this crypto suite to make it more capable?

Greg Bernstein: I don't think Dan wanted to modify any of the lower level
algorithms.

Greg Bernstein: I thought he was coming up with a different …

Stephen Curran: Okay. Because

Greg Bernstein: what do we call it normalization type of thing and that was
a lot more fine grained but I wasn't sure how that all works out with
selective disclosure and making sure people don't play games with selective
disclosure I can't quite remember mono

Greg Bernstein: Dave, do you remember? Yeah.

Manu Sporny: Yeah, I mean at a high level I think that the short answer,
Stephen, is like it's R\&D that people need to do.

Stephen Curran: Absolutely.

Manu Sporny: I know Dan's already done, a good chunk of the R\&D. Now we
have to actually operationalize it. I think one of the big concerns is that
he's potentially changing the canonicalization algorithm. and…

Greg Bernstein: Yeah, that's the right

Manu Sporny: and if that is true, remember it took us six years to get a
canonicalization algorithm through W3C. he might have changed it in a way
where we can reuse the current one and…

Manu Sporny: then break the information. Okay.

Dave Longley: I can short change that.

Dave Longley: To my knowledge he did not change that All that happens is
each individual element within a statement is the elements are separable.
So in what we do in BBS right now is we take the entire credential and
break it into individ individual statements that are sentences and each one
of those is considered an individual message. You can go even more atomic
than that. So each statement has a subject, predicate and object and
technically also a graph parameter. So there are really four elements that
are in there and that's as atomic as you can go and his approach goes that
the negative drawback for that is you now need to prove each one of those
things is related to each one of the other things within a single statement.

Dave Longley: So there's more to prove, but none of that has anything to do
with changing the canonicalization algorithm. So you run the same
canonicalization algorithm, everything works the same way. He just goes
more atomic and has more to prove, but it also allows you to do more
interesting predicate proofs and so on.

Manu Sporny: Yeah.

Stephen Curran: Yeah, I mean the two things I'm looking at and…

Stephen Curran: so that answers the two questions is there anything
underlying that has to change in what he's doing either at BBS work at ITF
canonicalization. So that's good. it does open up and the big thing that I
think would be of interest is it may make it easier. My understanding is it
would allow us to do I think a proof of possession type proof with an ACD
DSA public key which would open up the Europe concern.
00:15:00

Stephen Curran: So now we would have both pseudonyms and we could have
hardware key and then also as Dave mentioned the other predicate
capabilities notably equality and obviously just basic predicates. I
believe it would be a necessary capability to do some of the other things
that are in an onres v2 verifiable encryption and things like that where
you're and the big thing there is you're operating on a single element a
single attribute of the credential.

Stephen Curran: yeah.

Dave Longley: So, I agree with some of that. I think the ES ECDSA piece you
could do either way. that's going to require some special treatment
regardless. and so you don't have to on breaking everything into every
individual element and then being able to prove all those things to
accomplish that but if you want to be able to do all these other
interesting things that Dan has the slide deck for then you do to do the I
think he calls it BBS or termwise

Stephen Curran: Mhm.

Dave Longley: something or other that has to do with the individual terms
inside of each statement. So you do get all the benefits you were talking
about in the latter case or the ability to do all those benefits if you
break it down at that level. but if you wanted to just have pseudonyms
statements and ECDSA key binding type stuff you could accomplish that
without going that far. I do want us to remember that there are lots of use
cases that can be served and there are trade-offs in accomplishing them and
if we have all the time and all the resources it would be great to have
both a mechanism that has the simpler and more efficient way of doing
things that covers that would still have pseudonyms.

Dave Longley: if necessary would have this key binding piece and we would
also have the opportunity to have the more complicated interesting proof
piece and then using proof sets you could always have both on your
credential and then you would have the opportunity to use either one of
these things. So if we had infinite time and resources I think we should do
both of these things but I do want people to understand there are
trade-offs in going just in one direction or…

Dave Longley: trying to do it all or etc. Gut.

Stephen Curran: Agreed.

Stephen Curran: And so from my perspective, the being able to do the
predicates and the other would be a nice bonus and I think it would be
valuable to leave the door open to that. but agreed that that to me is less
important than giving the opportunity for a bigger tent for this crypto
suite to include what's happening in Europe.

Stephen Curran: give the folks in Europe that are trying to get BBS or ZK
capabilities in and to do it in a way that's aligned with W3C instead of
what appears to be happening which is they're on their path this group is
on its path and there the twain shell meet. It would be really nice if that
could be added to this crypto suite especially if we don't even have to
change all the underlying handling to try to include that there and I think
you talked about we've got to do all that work that would give a bigger set
of people to do all that work which might be helpful

Manu Sporny: Yeah, plus one. Completely agree with that. Stephen, I think
we have various things that are creating tension,…

Stephen Curran: Yeah. How's the

Manu Sporny: the first one is getting anything out at all, right? So if we
delay for another four years, some other things are going to be deployed
that are less capable that have worse privacy characteristics like we're
seeing that happen today right in Europe. So getting something imperfect
out would be better than waiting another four years or three years or even
two years I think to get something out. but also a huge plus one if we can
collaborate with folks that want to collaborate in the EU on the ECDSA
binding thing since that seems to be a strong requirement in the EU. and we
can do that with a fairly light lift on our side. great, we should do that.
00:20:00

Manu Sporny: again, as long as it doesn't delay us by years to get the
thing out. And I have no idea how much that would delay us. Greg, I don't
know if you've looked into the binding mechanisms that they're looking at
now. and then finally for the predicate proofs and things of that nature
that is something I think that could be layered in the future. meaning is
that a make or break, thing? I think Stephen, you mentioned it's a nice to
have. I agree with that. I think it would be nice to have, but it is, extra
work that the group would need to do and I'm hesitant because we're already
struggling with people doing implementations and that sort of thing.

Manu Sporny: And all of this is dynamic. things can change from month to
month and hopefully for the better. but as you know, Greg said, it is
taking absolutely forever to get this stuff through ITF. And so, I'm very
hesitant to introduce something that is going to push it back,…

Manu Sporny: at ITF even further, based on the glacial pace that, things
have been going there. go ahead, Stephen.

Stephen Curran: I think the premise of this conversation was we wouldn't
have to change anything in IETF.

Stephen Curran: So, first of all, I don't think that's an issue for these
things. I would disagree with you that we could add these things in later.

Stephen Curran: I don't think this is the chance to do that is now because
if it isn't in there now it won't ever be in there because this isn't what
people are going to be working on five years from now. so if it is going to
get used this is the opportunity to do it again on the work side of it be
intrigued to know what Dan Yamamoto would have to say about that. Would he
do the work?

Stephen Curran: would he put his name on this as an editor and do the work
necessary for that again yes nice to have but if we don't go to the element
level we don't have any chance of using any of those capabilities and they
are pretty important capabilities nice to have yes compared to the biggest
thing with the key is that it's a check mark in the EU by politicians

Stephen Curran: This is the privacy that it exists. They've made it a check
mark and so BBS has no chance unless that gets included in Europe. So to me
it's a different argument than we get better privacy if we have the element
level but if we can get some sort of proof of possession ECDSA type cap
solution and especially one that doesn't involve IETF. Let's get Anya on
the phone as soon as possible and Christian Borman and see what can be done
cuz they're going down another path and…

Stephen Curran: they're putting resources into it. I know that if we could
align those resources that would be super helpful.

Manu Sporny: Yep, definitely. go ahead, Greg.

Greg Bernstein: So as far as …

Greg Bernstein: the holidays kind of derailed things and I was out in
December, but talking with IF diff BBS folks,

Greg Bernstein: that there was a paper by Ana particularly about
integrating a particular type of proof about ECDSA into BBS and that was
the second immediate example of adding an extra proof mechanism to BBS the
first extra proof pro was actually the proof or pseudonyms where you prove
that you use the secret appropriately to compute the pseudonym and such
like that. That's an extra proof we add on top of the selective disclosure
proofs.
00:25:00

Greg Bernstein: Anna's work with and talking with the people that have come
up with this fairly efficient way of incorporating ECDSA proofs about the
keys and such like that into BBS is another example based on that they came
and talked a bit to I wasn't there to the main author of the BBSEX Facilus
And there's the notion that we may refactor blind and pseudonym drafts in a
way to incorporate those changes easier. Okay.

Greg Bernstein: So the net effect for us is to have an API that we'll be
calling that will not change as we add in more features or allow for
expansion. the thing that's the biggest problem for me right now is if we
change some of the internals even for our basic features we have now extra
features I mean pseudonyms and the holder binding all my test vectors
change if and so that hurts us with getting ABS crypto suite 1.0

Greg Bernstein: O out to be able to get to, 1.1 or whatever. as folks
figure out what those requirements are and what they're going to look like,
that's another story. But we're trying to take into account because people
have been asking for things like more general proofs, but nobody has had
the killer application. And so pseudonyms plus the ECDSA style proofs is a
pretty strong application.

Greg Bernstein: So there's going to see how we can refactor the blind and
pseudonym draft to bear account for that Dave.

Dave Longley: Yeah, I just wanted to comment all that's definitely true
messing with the test vectors down at the IATF layer. I wanted to note if
that happens that would also mean regenerating them at the W3C layer. But I
did want to note that if we were to add a ECDSA key or something like that
feature at W3C layer, we already have a mechanism you could scroll around
in the spec and find it that there's a header somewhere that defines the
type of features that you're using. Optional feature summary maybe.

Greg Bernstein: Yes. Yes.

Dave Longley: and we would just be talking about adding another one there
for what we have today. And as long as there's a we define precisely how
that works with the ECDSA key, it just becomes another optional feature
that goes into that table and…

Dave Longley: then we have the key along with the credential. So to get
that feature in if it's well defined somewhere I don't think it's a lot of
work at the W3C layer.

Greg Bernstein: Yeah, that's true.

Dave Longley: Yeah yeah we need the details the lowle level bit defined and…

Greg Bernstein: We have a binding feature. It's whether it uses a BBS style
secret or a ECDSA style thing. Yeah.

Dave Longley: it's not a huge challenge for us to put that at the W3C layer.

Stephen Curran: Mhm.

Dave Longley: I think it's a much larger lift to do the per element stuff
and that if somebody wants to show up and do that work that I don't see any
reason why we would say no. I think it might have to be a different suite
or I don't know that we could map that one to be an optional feature, but
maybe a different suite doesn't mean different spec. It would just be,
we're going to rename this one, I think, to BBS 2026. it's currently BBS
2023. and that one might be not a great name. Termwise 2026 or something.

Dave Longley: And if somebody shows up to do that work, then it's possible.
they have to, be here and put on the timeline. But I wouldn't make it
blocking with all of those other basic features that are the simpler
version that has all the things that work both for,…

Stephen Curran: Yeah, there it is.

Dave Longley: people in the US in Europe. And I think you can do all that.
I think everyone would love to have the nice to haves, but I don't want us
to pretend that there isn't a lot of work and that there aren't trade-offs
in all the extra things you got to prove and proof sizes and stuff. and by
the way, that there's also more protocol work that would then be blocking
if we made it all one thing. go ahead, Ma.
00:30:00

Manu Sporny: Plus one all that. this has taken up twice as twice as much as
the time box as I'd hoped. so heard I think the next steps here are to see
if we can have some discussions with Anya to see if Dan is willing to do
the work on defining what his modifications would look like.

Manu Sporny: And then of course we need implementations. I think digital
bazaar is planning to do another implementation along with Greg's which
would give us at least two which is enough to get through the standards
process.

Stephen Curran: Okay.

Manu Sporny: And those next steps happen if people do the work right and if
people don't do the work it won't happen. And we'll check, from time to
time, Greg. we'll get some updates from you as things progress.

Greg Bernstein: Yeah. Yes. Particularly I will get a good handle at the
high level features part of our current spec. compare that to what we might
need from Anya or what they are looking for with the key binding stuff and
trying to then map out exactly what we need to have nailed down at the
layer below. But I think it would help to start with the update of the
features.

Greg Bernstein: So I can do that.

Manu Sporny: Okay, sounds good. go ahead, Stephen. Okay,…

Stephen Curran: A quick followup.

Stephen Curran: I'll reach out to Christian Borman and he's working
directly with Anya so I what he'll see talk him through this

Manu Sporny: that's great. and if we can bring them to one of these calls
and we can work things out like, the sooner the all right. okay, that was
the BBS we've got two items left on the agenda. The next one is a
refactoring of the data integrity crypto suite stuff. the goal here is to
make it easier to do cryptoes to create crypto suites. One of the, things
that we did not have time to do in version 10 of the ECDSA crypto suite is
we did a selective disclosure version of ECDSA and…

Greg Bernstein: Yeah.

Manu Sporny: only CA. and we have all these generalized selective
disclosure functions. but ideally we would have put these in the base spec
and we didn't because we ran out of time. so we are in maintenance mode for
these specifications. These are editorial changes. We're allowed to make
them. and the sooner we make them, the easier it is going to be for people
to add selective disclosure features to other crypto suites.

Manu Sporny: So for example postquantum crypto suites don't have selective
disclosure.

Manu Sporny: We would have to copy and paste all of these algorithms to
enable that at the most basic level. And so we don't want to do that.

Greg Bernstein: So would we …

Manu Sporny: We want to put it in the data. so we have the windows open and
has been open for the past I forget a couple of months and the windows now
closing for us to do this work. so we should do this work and get it done.
no,…

Greg Bernstein: would it be pulled into a new document with just selective
disclosure or would it go into the core data integrity?

Manu Sporny: no. Yeah, we would take section 34. We would cut it out of
this document.

Manu Sporny: We would paste it in this data integrity document in the
algorithm section.

Greg Bernstein: Okay.

Manu Sporny: And the algorithms would have a selective disclosure functions
section and we would define all of those in there.

Greg Bernstein: Yeah. That's Yeah, because I was in the BBS. I refer over
to the ECDSA and that's kind of weird.
00:35:00

Manu Sporny: And you'd refer to the data integrity base.

Greg Bernstein: It would be Okay. Okay.

Manu Sporny: And then we'd update all of the references to algorithms here.
this reference here references section this one's 35 some 34 reference this
one right the HMAC ID labeling function this would point to Yep Yep yep yep
so we just need to go and…

Greg Bernstein: Yep. Yep. Yep. I kind of went through that with the BBS.
Yeah. Yeah.

Manu Sporny: update all those it's just editorial work…

Manu Sporny: but it's time consuming editorial Mhm.

Greg Bernstein: Yeah, but it's for those of us that have been working on
selective disclosure,…

Greg Bernstein: it's really important because those algorithms that got
worked out, I think by Dave, they're really good and really important. I
mean, if you run through them and implement them, they work. They are not
easy to gro and I will not claim that I gro them completely or…

Greg Bernstein: remember them but my implementation worked against
everybody else's and so they are good I mean

Manu Sporny: Okay.

Manu Sporny: So that's just we need to do that work to move it over. We can
publish at any time. and we're basically waiting for this to be moved over
in order to publish.

Greg Bernstein: Okay, other people I can start looking into it and…

Manu Sporny: Okay. It's either you or…

Greg Bernstein: kind of outline it.

Manu Sporny: me, Greg.

Greg Bernstein: Okay, if nobody else want I got more time and…

Manu Sporny: He's gonna do the update. if you get to it before I do, Great.
…

Greg Bernstein: gave me something productive while It Don't scream at the
CFRG chairs.

Manu Sporny: Yep. Yep.

Greg Bernstein: You can't do that.

Manu Sporny: Yeah.

Greg Bernstein: they get really pissed. But okay,…

Manu Sporny: I'm wondering if we …

Greg Bernstein: I do have Okay,…

Manu Sporny: I don't want to revisit the BBS thing. we'll talk about it
later, but sure.

Greg Bernstein: I do want to say remember that's ITF that is not IETF.
That's right.

Manu Sporny: I know. It's Yeah.

Greg Bernstein: So, IETF you can get Yes.

Manu Sporny: It's a dis dysfunctional thing when we have to live with it.
Yeah. I get it. But it's really a ter Yeah.

Greg Bernstein: Not that's thing.

Manu Sporny: Yeah. Is it?

Greg Bernstein: Okay.

Manu Sporny: Yeah. …

Greg Bernstein: I now know because I was going how much we wanted to change
the structure of things and I go, " all these are a key port." I Yeah.

Manu Sporny: yeah. No. Yeah. Just Copy paste and then Yep.

Greg Bernstein: Yeah. Yeah. Yeah. But you got to make sure you don't screw
up any referencing.

Manu Sporny:

Manu Sporny: Yep. Yeah. Yeah. And then once and once you do that, we'll do
FPW to first public working draft of the version 11 specs and…

Greg Bernstein: Okay.

Manu Sporny: then base all the new stuff on it. So that's the refactoring
any questions on that before we move over to safe crypto suites. the
quantum safe crypto suites dine and fork bomb started off saying that they
were going to work on this crypto suite. a year. Not much work has been
done on it and I've asked them multiple times but they respond and they're
like we'll get back to you but I don't think this is a priority for them.
so we need to move it forward. other folks need to move it forward.

Manu Sporny: I think every one of the editors is now unable to move this
forward except maybe me and I can't move it forward because of lack of time.

Greg Bernstein: But I mean…

Greg Bernstein: is there any big issue? I mean I went and checked and I saw
that stateless hash and crystals diliththium so two what there are even
javascript implementations. I went and checked somebody just the Falcon
people. I don't know why 206 is pips 206. The Falcon thing isn't out yet. I
saw some stuff saying it's supposed to be out real soon, but god knows how
much fun it is to be at NIST right now. But I also found a very up-to-date
Python implementation of that even though I don't have a JavaScript.

Greg Bernstein: So we can generate test vectors. everything's there.

Manu Sporny: Everything we need.

Manu Sporny: Yeah. Yeah. Everything we need. Noble has a bunch of
JavaScript, implementations for all this stuff.

Greg Bernstein: They have the Noble and then for the Falcon stuff…

Greg Bernstein: which is about to come out as FIPS 206 or the initial
public draft of FIPS 206 that's available too. So I mean all the algorithms
listed here are available. okay.
00:40:00

Manu Sporny: Yeah, we are missing an editor.

Manu Sporny: That's what we're missing right now is we need an editor to
move this forward. If we don't have an editor move forward, it's going to
move forward at the pace that I can get to it, which is not surprising.

Greg Bernstein: Can I have my code.

Greg Bernstein: I will clone my code and I can start, doing the test
vectors. then we just got to double check the writing to make sure it fits
with

Manu Sporny: Yep. Yeah.

Manu Sporny: Yes, there are things in here I mean, this is largely text I
wrote a long time ago and I did not assign the multi key prefixes for the
public keys or the secret keys. so there are little things like that that
need to be done,…

Manu Sporny:

Greg Bernstein: Okay.

Manu Sporny: but it does ref FIPS 205. We should try to ref FIPS 206 once
it comes out.

Greg Bernstein: Once it comes out.

Manu Sporny: Yeah,…

Greg Bernstein: Yeah. better.

Manu Sporny: and then we need to figure out there are four different
postquantum mechanisms in here. it's too many, right? but at the same time
they are different right we've got hashbased falcon for smaller signatures
that has a fips thing on it and then ski sign which is what we actually
really want to use. We don't want to use any of these other ones but ski
signs in round two for the NIS competition…

Manu Sporny: which means it's not going to be done for years. exactly.

Greg Bernstein: But should we…

Greg Bernstein: then template it out? Because each of these they're all
going to follow the same basic template kind of like…

Manu Sporny: Yeah. Mhm.

Greg Bernstein: what we used before. we kind of want to be a little
cautious that if any of these things prove weaker, I mean, I know the first
thing is to use the ones with the shortest keys, but if you have to go to
the neck, we want to make it easy in case we have to go instead of the
whatever. And so we could we have a naming convention for right that we
kind of came up with to describe these things way back when we had the
different canonicalizations and the different algorithms.

Greg Bernstein: Maybe we could just instead of having to do a separate
section for each one, we just have a list of, however, SHs, this is ML Chem
or ML whatever. and then the algorithms…

Greg Bernstein: though just get filled in by use this signing arrange this
way maybe would that work something like that…

Manu Sporny: That's what's the spec already kind of does,…

Manu Sporny: right? …

Greg Bernstein: but it has I mean yeah…

Manu Sporny: it does Yeah.

Dave Longley: it doesn't quite do it as to the extent that we would have
preferred which I think is what Greg is talking about. you don't have to
verify proof all those things.

Greg Bernstein: because I mean

Dave Longley: It would be better parameterized

Greg Bernstein: And then of course test vectors are all broken out and
that's another story, but that's an appendex. I mean,…

Manu Sporny: Yeah. One thing we might want to talk about I'm hearing
parameterized and there are two ways that could be meant. One of them is
parameterize the algorithms and…

Greg Bernstein: yeah. Yeah. Yeah.

Manu Sporny: the other one is parameterize the way that we build a spec and
talk about the algorithms which is fine to me. The other one is
parameterize the crypto suite so it can do a thousand different things.

Dave Longley: No, no,…

Manu Sporny: I'm hoping we're not saying the last thing.

Dave Longley: it'll still be four or n many crypto suites, whoever are in
here. So, we're going to make that many crypto suites. I agree. We would
like to recommend fewer, but at this stage in history, people just don't
know and they have different properties. So I don't think that's a thing we
could do. So there will be four crypto suites but in the spec they will
refer to the same algorithms with different parameters including the crypto
suite name as one of those parameters.

Greg Bernstein: Yeah, we don't want to get into specking the details of
cryptographic parameters in here. Yeah. No, that's dangerous, right? Yes.

Manu Sporny: Okay, that sounds good to me.

Manu Sporny: The other question is, each one of these has different levels.
NIST 135. and I think we said we're just going to do NIST one for now. I
don't know if we're changing that thought or, it's kind of like do NIST one
and five.

Manu Sporny:

Manu Sporny: Yeah.

Dave Longley: So that'll just be more parameters and…

Dave Longley: we can have that conversation later. It's just different key
sizes I think.
00:45:00

Greg Bernstein: And they get,…

Greg Bernstein: and NIST has names for those.

Greg Bernstein: The algorithms have names for those just like we started
putting them in here.

Dave Longley: Yeah, that's

Manu Sporny: I mean, MLDDSA4 and that sort of thing.

Greg Bernstein: Okay.

Manu Sporny:

Manu Sporny: Of them I don't think SHS has it and I couldn't find Falcon
had it only for one and three but not for five or something like that. okay
and as far as implementations are concerned yeah I mean all the libraries
should be there to generate even for ske sign.

Greg Bernstein: Yeah, it's JavaScript.

Manu Sporny: But ski sign might need I think they only have a C and C++
library. There's no JavaScript anything for it yet. and all the noble stuff
was basically like we don't guarantee side channel prevention attack
prevention any of our libraries. so there's enough there to generate the
test vectors and that means there's probably there enough to generate test
suites to get us almost to the end there. we probably need to figure out a
way that we're going to talk about ski sign in the specification. it's not
going to be done by the time we publish 10 of this spec. And so we may need
to take it out at the very last second in order to get through wreck.

Manu Sporny: Unless we're able to ref some kind I mean there will be a
stable ref.

Greg Bernstein: Okay. let me take a look and I

Manu Sporny: I think in each round of the NIS competition there's a stable
ref but I'm pretty sure I don't know if people are going to Yeah.

Dave Longley: Let's not borrow that trouble from the future. We'll see
what's up when we get there.

Manu Sporny: Yeah. Yeah. I'm wondering that I'm like, should we even try to
ski sign in here?

Dave Longley: It's just more parameterization and then the tricky bit would
be the generating test vectors. So we should, slow walk that one. But with
the way Greg's saying he's going to set it up, I would imagine it says spec
side of it would be really easy. And so we can just slow walk generating
the test vectors and see where we

Manu Sporny: All right. okay,…

Greg Bernstein: provide feedback. or…

Manu Sporny: that sounds good.

Greg Bernstein: Either I'll put it as an issue or a PR, but mostly start
with an issue describing what I think would help and…

Greg Bernstein: such like that and kind of survey the document and put in
an issue and see what if people agree with that before we do any PRs or
anything. I mean that mechanism's worked pretty good, right?

Manu Sporny: All right.

Manu Sporny: That's Yep. okay. All right. That sounds good. the last item
we had is what to do about the SM2 crypto suite. So, just a background.
this is each national body has their own cryptography standards body. many
of them just refer to NIST but some of them Europe has its own stuff with
brain and China has its own stuff with the cryptography standards that they
do.

Manu Sporny: there was a request to add a data integrity crypto suite for
SM2. I believe it should be trivial because it's just elliptic curve.
They've just picked different things. it should probably mirror the ECDSA
one pretty closely. but we need someone else to do the work. it's not going
to be somebody from the Chinese national standards bodies would need to get
involved. and so I think that's a no- for us until we get someone involved.
I think the way that folks might get involved is through the W3C working
group.

Manu Sporny: Bons and W3C China are talking to those folks right now to try
to figure out to get them to join the working group.

Manu Sporny: So all that to say I think that's a no-off for us in this
group for now until someone shows up to do the work. it's a possibility,
but it would need a Okay.

Greg Bernstein: If they show up in February,…

Greg Bernstein: I will be in Australia, so I'll be closer to their time
zone. So, tell them to get off their butts if they want to be able to talk
easy.
00:50:00

Manu Sporny: All I'll communicate that.

Greg Bernstein: But otherwise it's kind of an odd Yeah,…

Manu Sporny: Yep. Mhm.

Greg Bernstein: it's Asia. Yeah, we've got that issue with other groups,
Trying to pull Asia in and…

Dave Longley: Some one more thing to put in your head,…

Greg Bernstein: Europe and West Coast and everything, it gets complicated.

Dave Longley: Greg. You might find that when you turn these four functions
that keep getting repeated here into something generic in this spec that
they might also be able to be put in data integrity as a way of doing those
four functions.

Greg Bernstein: Yep. It kind of makes sense…

Dave Longley: We wouldn't want to get rid of the base data integrity thing
that might be referenced and do something slightly different in another
spec. But if these four might move over there too and then any of the specs
can use it and that might also make their work easier.

Greg Bernstein: because the only huge change is when you go selective
disclosure versus not because it's got a bunch of extra steps, So if it's
not a selective let's just see what the structure looks like. Yeah.

Greg Bernstein: So, we don't usually get to take this nice highle view for
a little bit and so might as well take a look.

Manu Sporny: Okay, that sounds good.

Manu Sporny: And if that leads to, our ability to refactor all the other
specs into something simpler and better, let's take the opportunity to do
that. That's what a point release is about. So, we are there. We can do
that now, but we will only be able to do that for maybe another year and
then the door will close again on us. I think that's it for the call today.
Anything else that folks wanted to talk about?

Greg Bernstein: Okay. Bye.

Manu Sporny: All right. If not, have a wonderful weekend and we will chat
again, in a month or so. Take care. Bye.
Meeting ended after 00:52:20 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*