[MINUTES] Data Integrity 2025-05-02

W3C Data Integrity Community Group Meeting Summary - 2025/05/02

*Topics Covered:*

   1.

   *Bug in ECDSA Verify Proof Algorithm:* Will Abramson identified a bug in
   the ECDSA verify proof algorithm within the data integrity specification,
   specifically the omission of a canonicalization step for proof options. The
   group agreed it was a bug, and the standard bug detection process will be
   followed, notifying the Verifiable Credentials Working Group. The consensus
   was that this is likely an editorial oversight given the existing test
   suite and implementations.
   2.

   *Modern Zero-Knowledge Proof Systems (Ying Tong):* Ying Tong presented
   an overview of modern zero-knowledge proof (ZK) systems, focusing on a
   modular approach compatible with Google's work. The discussion highlighted
   the components of a ZK SNARK (arithmetization, polynomial IOP, polynomial
   commitment scheme, Fiat-Shamir transform) and strategies for achieving
   zero-knowledge properties. The group agreed on a modular specification
   approach, mirroring the data integrity spec, with the initial specification
   encompassing high-level generalization and specific component
   implementations. This reduces W3C process overhead. The scalability
   challenges of arithmetization with large credential sizes (75KB to 10MB)
   and the potential for pre-computation to optimize the process were
   discussed extensively. The group explored alternative approaches beyond
   standard ECDSA signing of the entire credential blob, including breaking
   down credentials into smaller claims and using compression techniques.
   3.

   *Google's ZK SNARK Work:* Google's presentation to the Credentials
   Community Group on ZK-SNARKs for ECDSA and cryptographic circuits was
   discussed. The group expressed interest in collaborating with Google, but
   with a focus on more generalized cryptographic approaches rather than hacks
   around existing ECDSA. The potential for dynamic circuit generation,
   eliminating the need for pre-published circuits, was also considered.
   4.

   *Post-Quantum Cryptography Updates (Will Abramson):* Will Abramson
   presented a large pull request adding quantum-safe algorithms (Falcon and
   SPHINCS+) to the post-quantum data integrity specifications. Discussion
   focused on the selection of appropriate identifiers for multi-key bit
   lengths and the use of NIST security levels, acknowledging challenges in
   the stability and consistent definition of these levels across different
   algorithms. The group decided to move forward using algorithm identifiers
   similar to IETF's approach to reduce confusion, recognizing the need for
   careful selection given the variability in algorithm parameters.

*Key Points:*

   - A critical bug was identified and will be addressed in the ECDSA
   verify proof algorithm.
   - A modular approach was adopted for specifying ZK SNARKs, allowing
   flexibility and easier future updates.
   - Scalability challenges of ZK SNARKs with large credentials were
   addressed through discussions of pre-computation, selective disclosure, and
   claim breakdown techniques.
   - The group is open to collaboration with Google on generalized ZK SNARK
   approaches.
   - The pull request for adding quantum-safe algorithms requires further
   review and discussion before merging.
   - Selection of identifiers for key bit lengths and algorithms remains an
   open issue. NIST security levels were considered but deemed unstable for
   long-term identification.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-data-integrity-2025-05-02.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-data-integrity-2025-05-02.mp4
*Data Integrity - 2025/05/02 09:55 EDT - Transcript* *Attendees*

Dave Longley, Eddie Dennis, Geun-Hyung Kim, Greg Bernstein, Hiroyuki Sano,
John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Sam Schlesinger,
Stephen Curran, Vikas Malhotra, Will Abramson, Ying Tong
*Transcript*

Manu Sporny: All right, we've got a decent chunk of folks here, so let's go
ahead and get started. we have a pretty packed agenda today. I doubt we're
going to be able to get through all of it. but Ying Tong, we're going to
optimize for giving you as much time as possible and then the other items
we can deal with next week if we run out of time. Our agenda today is
focusing primarily on Ying Tong's deep dive into some of the ZK stuff that
she was not able to get through during the last presentation. So we'll deep
dive on that.

Manu Sporny: related to that Google did a presentation on the zk snark
stuff that they're working on at the credentials community group and asked
us to engage with them on some refinements. This is very much related to
Ying Tong's work as so that's good. I think that we'll just make that a
part of this discussion. has raised a number of algorithm updates to the
postquantum data integrity specifications. Thank you very much if we have
time today, I think that's the thing that might drop off the agenda today.
if we have time today, we'll take a look at that. if not, we'll push it to
next week. give people more time to review that PR.

Manu Sporny: And then most importantly will I think you found some bugs in
the data integrity specification and we should take a look at those today
review them make sure that everyone agrees it's a bug and then we'll
process it using the standard bug detection processes and things like that.
are there any other updates to the agenda? Is there anything else high
priority that folks would like to talk about today? so let's take these in
order of priority. security issues are always the number one priority. So
will let's take a look at the issue that you found. Do you want me to
screen share or do you want to screen share?

Manu Sporny: Okay.

Will Abramson: It's probably best for me…

Will Abramson: if you do it. That's all right.

Manu Sporny: All right. let's see. We are looking at the ECDSA crypto
suite, right? I got it.

Will Abramson: I can drop a link if you want. There you go.
00:05:00

Manu Sporny: I got No problems. and I think the bug that you found is in
the verify proof algorithm for East DSA RDFC.

Will Abramson: Yeah. Yeah,…

Manu Sporny: we failed to document sending the proof options to be
canonicalized. so if we look at I think what was it in JCS so we have this
step in JCS…

Will Abramson: JCS is correct.

Manu Sporny: where we say let proof config be the result of basically
canonization right but we did not have that step here so we let's see
improve config we take the unsecured document and…

Manu Sporny: we canonize it in this algorithm and we print it as transform
data. so this is Yep.

Will Abramson: Yeah. Yeah.

Will Abramson: I think in that it should be number two, proof config really
is proof options. So that is still Number four, but then it's just missing
the step that canonicalizes the proof options into proof config.

Manu Sporny: Yep. So we just need to add another step in here to
canonicalize the proof options. The interesting thing here is we had nine
implementers. None of them saw this or none of them found the bug. and they
all have proper implementations of this. So we have basically the
implementers which The implementers paid more attention to the test suite
and passing the test suite than they did the algorithms and the
specification. you wouldn't be able to pass the test suite if you didn't
canonicalize the proof options here.

Manu Sporny: and then as Will is pointing out in the chat channel, the
canonicalization step for EDDDSA is correct. so if we look at what we do in
EDDDSA, one second, let me bring this over here. so if we look at EDDDSA,
here's the missing step that we don't have in the ECDSA verify proof thing.
So, I think is asserting this is a bug. I'm asserting this is a bug. Does
anyone feel like this is not a bug? Okay, it's a bug. I think the process
now is we'll notify I'm Greg's one of the editors of the spec. We will
notify the verifiable credential working group.

Manu Sporny: we will tell them that this needs to be fixed ideally before
the final wreck goes out. I think it's a substantive normative change
because it does kind of change the algorithm but I think there's an
argument that this is editorial because every other algorithm has this step
in here. We have nine implementers that got it right. and so hopefully
we'll just be able to update the one step and say, "Yeah, it was a omission
bug editorial. we'll make the change before the wreck goes out." I don't
think this needs to go back to the membership for a vote because it's very
clearly just fixing a bug that no one seems to have actually implemented in
practice. Any other commentary on this before we move on?

Manu Sporny: Okay, let's then move on into Yin Kong your presentation. I
will note that so let me stop sharing here and you can feel free to share
Inkong if you want to bring your slides up. while you're bringing those
slides up, I'll note that Google came and Abby Shellot and Mateo who have
been working on the ZK Snark stuff for ECDSA specifically and more
generalized cryptographic circuits came and did a really nice presentation
to the credentials community group this week.

Manu Sporny: they noted that they would like to see if the crypto that
they're working on works for verifiable credentials. They had some
proposals on revocation lists and pseudonyms which were nice to see. we
said that they're more than welcome to come into this group and propose
what they're working on and we would love to work with them just as we're
working with Ying Tong on figuring out one or more ways of pulling snarks
into the work that we're doing.
00:10:00

Manu Sporny: their work right now is very focused on the European digital
identity wallet stuff and using proving ECDSA. our work here is interested
in that work but I think we are more interested to put it bluntly not
having a bunch of hacks work with the old style crypto. We want to work on
things with less restrictions than taking ECDSA as a fundamental place to
start from. So ideally the snarks we work on in this group have kind of a
groundup good elegant architecture in the mathematical model in the
computational and…

Manu Sporny: space model and in the proof size results from that. with that
Ying Tong…

Ying Tong: H. Thank you.

Manu Sporny: if you would like to take us through anything that you feel
that you wanted to get into but couldn't last time you have the floor for
as much as you need it. and then maybe towards the end of the call we can
talk a little bit about how the Google work might apply to this. and then
if we can get to it, we'll get to the postquantum pull request will. And if
not, we'll just have to push that into next week. Over to you, Ying Kong.

Ying Tong: Yeah, I think my purpose today is very much to give an overview
of modern proof systems.

Ying Tong: and to do it in a modular way. and this approach is compatible
with Google's in the sense that it's targeting a higher level of
abstraction than them. So, we're going to get a sense of all the components
that go into a modern snark and we'll be able to apply this to
instantiations of proof systems such as Google's. And the advantage of
understanding it at a higher level of abstraction is that we're not tied
down to a particular instantiation.

Ying Tong: and for instance if the underlying canonicalization changes for
the issue we can swap out the arithmetization and still very much be
compatible with this framework.

Ying Tong: I heard someone raise a hand.

Manu Sporny: Your screen went away for us for some reason.

Manu Sporny: Or at least it went away for me.

Ying Tong: Okay. You see,…

Manu Sporny: There we go.

Ying Tong: sorry about that.

Ying Tong: So I had mentioned last week that I've started to look into the
proof derivation part of the data integrity spec.

Greg Bernstein: went away again.

Ying Tong: And…

Manu Sporny: Screen's gone again.

Manu Sporny: Yeah. Yeah.

Ying Tong: really that's weird. Yeah. …

Manu Sporny: If you have your deck online, one of us could share it if you
wanted.

Ying Tong: let me see. Okay.

Manu Sporny: We can see it again.

Ying Tong: Let me also share the deck here. so yeah, last week I had
mentioned working on the data integrity derive proof spec and this is one
way I see generic zer fitting with the rest of the verifiable credential
spec that

Ying Tong: it could be a privacy hardening layer above any chosen issue
mechanism. and yeah, this is very much the approach that the Google team
has taken to not modify the underlying ECDSA signature or canonicalization.
and to do all the parsing in the ZK layer. so my aim today is to go over
the components of a modern generic ZK nark. and a lot of this will look
familiar to you from having seen Google's presentation.
00:15:00

Ying Tong: so yeah, just from the top down, we start with some kind of
relation such as the verification of an ACDSA signature and a witness that
we claim to be satisfying. we arithmetize this in order to get a zero
check. So a constraint satisfaction problem. that is amanable to being
represented as a polomial identity.

Ying Tong: So we put the zero check into the second component called the
polomial IOP which is an interactive protocol between a prover and a
verifier so that we end up with a polomial identity that we can
probabilistically check. this is instantiated using a polomial commitment
scheme that introduces cryptographic hardness assumptions. but that also
gives us the succynness properties that we want and the oracle access
behavior that we want.

Ying Tong: And at the end of the polomial commitment scheme we get some
interactive argument between the prover and verifier. We put that through
what's known as the fmme transform to compile it into a non-interactive
argument. So high level this is the flow of a modern zero notch proof. also
please stop me…

Ying Tong: if you have any questions or comments. Yeah.

Greg Bernstein: Is there one particular place that they add in the zero
knowledge?

Greg Bernstein: when we heard the presentation from on Tuesday they kind of
had the outer part of I don't know it would be the polomial commitment
scheme here but they kind of had two proofs wrapped kind of together and
the outside one did ZKP or was that particular to what Google's

Ying Tong: Yeah, that's a really good question.

Ying Tong: So, there are many strategies for adding zero knowledgeness into
your protocol.

Greg Bernstein: …

Ying Tong: Yeah there are many strategies the most common strategy is to
commit to sort of random multiple of a vanishing polomial and…

Greg Bernstein: not one place then. Okay.

Ying Tong: add that to your actual polomial to blind it.

Greg Bernstein: Okay, gotcha.

Ying Tong: So that's at the IOP level. and then you also need a hiding
polomial commitment scheme so that your commitments are also random. so
yeah this is something that I think a spec for a generic ZK snark should
mention the

Greg Bernstein: Thanks. Thanks. Helpful.
00:20:00

Ying Tong: common strategies used to add their analog initiative protocol
and yeah point out which of these strategies are ure which of these
strategies can be composed securely. so yeah my thinking for this spec is
that we can specify each component in a modular fashion and then have a top
level spec as zero knowledge proof spec that points to each of these
components.

Ying Tong: that the top level spec were really focused on how to safely
compose these components with an eye to zero knowledgeness and knowledge
soundness. I heard another hand go up.

Manu Sporny: Plus one to that. I think that's an excellent strategy. it is
the same strategy that we took with the data integrity spec where the data
integrity spec kind of talked about the highle structure of what a data
integrity proof looks and then it left the implementation for all the
cryptography into each crypto suite specification. I think we can
absolutely take the same approach here which is exactly what you uh said.

Manu Sporny: to make our lives simpler though in the beginning what you
might want to do is talk about the generalization what's on the screen the
top we should have one specification right talk about the generalization at
the top high level and then in the same specification define some very
specific components that realize the top level and the reason for this is
purely process yingong the more specifications we have the more work it is
to take all of them through the process. it is much easier to take one
specification that has all of this stuff in there through the process and
then break the specification up later after it gets through the process
than it is to try and take multiple specifications through the process.

Manu Sporny: It's not required. We don't have to do it that way. so if
there's a very strong argument to do a strict separation between them,…

Manu Sporny: we can do that. but just noting that W3C process can be
painful the more documents that you have. but That's kind of a side
comment, but I want to make sure that's in your head as we put these
documents together. that they're process implications for how we put them
together.

Ying Tong: I see.

Ying Tong: Yeah, that's very good so in particular this does Vietir
transform okay I think we can go maybe two slides forward.

Manu Sporny: Yinong, your screen went away again. I'm going to start. let
me just share the screen so that it doesn't keep going away on us and then
you just tell me when to switch the slides. That work? Okay.

Ying Tong: So yeah, you can see this is the fiat shir transform draft
specification. Yeah. And it was very much developed as a modular draft just
one of the components in that whole ZK Snark architecture. so it's by
Mcklli and he uses it in his sigma protocols job specification. So yeah
this is an example of the modular specification approach. and this is over
at IETF. Yeah.

Ying Tong: you can go on to the next slide. So yeah because Mcklli has the
fiat shamir draft in progress what's remaining for us are the three main
components of arithmetization polomial IOP and polomial commitment scheme.
next slide.
00:25:00

Ying Tong: So yeah, Greg

Greg Bernstein: On flipping back to ariththmaization or coming up with the
circuit, one of the things we heard on Tuesday was particularly for some of
these legacy things like ECDSA, they use Shaw 256 and the arithmetization
grows as the size of what you're taking the hash over

Greg Bernstein: because while implementing SHA 256 in software, it doesn't
really matter about how big a thing you're hashing, but it seemed to be in
the case of if you're hashing a megabyte worth of stuff, your circuit grows
a bunch as opposed as…

Ying Tong: That sounds right to me.

Greg Bernstein: if you were hashing a couple kilobytes. Is that true? Okay,
because that means we've got some techniques where we really reduce that.

Greg Bernstein: If we started from our ECDSA SD approach where we hash and
sign each statement rather than so we sign each canonical stationation
could make a big difference. And so this is once again understanding each
of these steps and how they scale helps because I was going we have a
better way to start than the classic…

Ying Tong: Yeah, Lan had a comment.

Greg Bernstein: what folks are doing and we take out all worrying about
selective disclosure out of one place into another. Thanks. Sorry.

Manu Sporny: Yeah, and to add to what Greg's saying, plus one to everything
Greg said, this is one of the things that we feel like keeps being glossed
over in the snark discussion is that, in production today, the types of
credentials that we have are between maybe on average 75 kilobytes all the
way up to 5 to 10 megabytes. and they're 5 to 10 megabytes because people
want these credentials to live on their own. They don't want a phone home.
They want good privacy properties for these credentials. And so they shove
all of the images and imagery and all that kind of stuff into the
credential itself.

Manu Sporny: which means that some of these snarks are going to be multiple
megabytes in size or that is if we just use standard ECDSA if we just sign
the whole thing as a blob your input blob is 100 kilobytes in very nice
case to multiple megabytes and Abby kind of mentioned he was like yeah this
works great 200 or what is it 200 kilobyte proof for an input that's 2.4
kilobytes in size. so that was like a 100x it seemed like a 100x expansion
in the in the snark derived proof.

Manu Sporny: and as Greg said, so that's the big problem. that's kind of
like we're looking at it and we're like, that's really bad because that
doesn't work for the standard, production credentials that we see out there
today. what Greg also said is true. We do have ways in data integrity, we
have ways of transforming an input credential in a arbitrarily as you can
tell. So we can take in one of these things and then we can transform it in
a variety of different ways. One of them is we can break the credential up
into individual So literally just line by line claims. the person is a
citizen of France. this person's name is and so.

Manu Sporny: And we can break the credential up into kind of line by line
messages, statements, claims, however you want to say that. And then we can
take each one of those claim lines or message lines and we have another
technique called Seabore LD which is a compression scheme where we can take
big URLs that identify properties or people or enums or birth dates or data
types things like that and we can compress those things that are like 80
00:30:00

Manu Sporny: 150 characters in size. We can compress them down to one to
two bytes into a binary message where we can make each binary message as
small as six or seven bytes in size. and then as Greg also said, we can
also selectively disclose those things. so we have all these strategies
here where the standard blanket, we're just going to work with a start with
a fully signed ECDSA blob. We don't have to go that route. we can get far
more optimized and we're very interested in understanding how much those
optimizations buy us how small can we get the derived proof from the snark.

Manu Sporny: there are other things we're looking at Abby mentioned that
they need to publish a cryptographic circuit for each type of credential or
each type of proof that they want to do. there are other mechanisms that
have been used in the past decade that try to do that. Our experience with
that approach is it is not scal meaning that politically it is very
difficult to get states multiple different corporations within an industry
to agree on a single layout for a credential. it takes a very long time to
get that level of consensus.

Manu Sporny: So instead our approach here has been dynamically generating
the stuff that is needed in the cryptographic calculation. specifically
with snarks. we are wondering if it is possible to dynamically generate the
circuit such that it is provable based on the data that was given. meaning
can we get rid of that need to publish the cryptographic circuit ahead of
time? we feel like that might not be scalable. So apologies it's a lot but
it kind of fits into your arithmeticization box there.

Manu Sporny: We think that there's some pretty key things that need to be
solved at that level. That's it.

Ying Tong: Thank you.

Ying Tong: So yeah I think first of all flexibility at the level of
canonicalization would make a huge difference to efficiency of the zk
snark. We could pick relations that are very natural to arismatic circuits
and move the expensive JSON parsing out.

Ying Tong: yeah, and with regard to having to publish a circuit for each
credential format. I spoke with the Microsoft team who for them this is a
very significant issue because they're using the groth 16 proof system.

Ying Tong: which necessitates a trusted setup per circuit. so yeah in order
to reduce the number of trusted setups needed their approach was we
discussed two possible approaches. The first is to define your circuits in
ular and compose them. the second is sort of multipplexing your circuit. so
you can select from a set of credentials. and this would incur the overhead
of all the credentials formats you're not using.

Ying Tong: so these are two potential approaches to improve the UX of the
verifiers. a third alternative is just a universal CK circuit. So there are
projects that target low-level instruction set architectures such as risk
zero or was and so verifiers would just write the credential format in a
standard highle programming language like C++ or Rust and be
00:35:00

Ying Tong: able to deterministically generate an arithmetic circuit for
that. so yeah, these solutions will likely not be relative to optimized
implementations. yeah. So this is all yes money

Manu Sporny: I guess I understand all actually what keep going Inkong I
think we have a lot of thoughts on that can we make it performant though
right they're open questions like the way the verifiable credential
ecosystem works is that verifiers trust issuers to issue things right and
so if we can get the issuer to compile a cryptographic circuit for the
thing that they're issuing. And if we can make that circuit digitally
signed or fetchable externally or some kind of proof that circuit came from
the issuer, I think we've solved the problem.

Manu Sporny: So it could be that it's not performant in real time but if
there can be some kind of premputation that the issuer does and if the
issuer can say this is my cryptographic circuit for this type of credential
that I issue and it's specific to that issuer I think that's all we need.
if that takes a day to generate that that's probably okay as long as they
don't have to keep regenerating it for every single credential that they
issue. So I think we have ways where we don't need to generate that stuff
in real time.

Manu Sporny: we can generate it offline and as long as there's some kind of
trust relationship between the verifier that's verifying the ZK credential
and the issuer then I think it's a solvable problem.

Manu Sporny: So I want to make sure that we don't think we're as
constrained as kind of how the problem has been presented to date. but
that's it. Let's keep going and we can come back around to

Ying Tong: Yeah. this concept of premputation is highly relevant.

Ying Tong: And in fact in my mind the main differentiation between Google's
approach versus Microsoft crescent credentials.

Ying Tong: So Google does not do premp computation whereas Microsoft's
crescent credentials splits the provers's work into the first phase they
call prepare. and this can be premputed. This needs only to be done The
second phase they call show and the show phase has to be done once per
presentation. So what's done in the prepare phase is the verification of
the ECDSA signature.

Ying Tong: So knowledge of a valid ACDSA signature as well as JSON parsing.
so these do not change with each presentation. What's done in the show
phase is the disclosure. and this does change with each presentation
because each verifier could request a disclosure of a different set of
fields.
00:40:00

Ying Tong: and so the idea in this two-phase design is to perform a slow
prepare phase but to ensure that it is efficiently rerandomizable and does
not have to be duplicated in the show phase. And our work now is reduced to
simply ensuring we have a very efficient show phase.

Ying Tong: so Google's approach on the other hand does not involve
premputation is fully online computation of the proof and with each
presentation they redo the ECDSA verification and the JSON parsing and the
reason for this is because their commitments are not efficiently
rerandomizable. so yeah it's an interesting set of trade-offs between these
two designs.

Ying Tong: and this very much arises from the difference in the polomial
commitment scheme that they used. So Google uses lero which is a hashbased
polomial commitment scheme is not homorphic and is not efficiently
randomizable. whereas a Microsoft's crescent credentials uses the goth 16
proof system under the hood it more or less looks like a Patterson
commitment and rerandomizing it is really cheap is just adding a random
group element.

Ying Tong: yeah so I think this is a very good illustration of the choices
that you can make at each component in the modern proof system. we can go
on to the next slide. yeah.

Manu Sporny: I have a question on this one. the polinomial commitment
scheme in postquantum linear time homorphic where do let's say that we do
want something that we can start talking about as being postquantum secure
fully end to not the ECDSA stuff right because cryptographically relevant
quantum computer makes it so that It doesn't matter if the liarero sum
check approach that Google's using is postquantum resistant. The inputs to
it is ZCDSA and that makes it not postquantum resistant as far as I
understand it. so we would like to see also something that's in the end
postquantum resistant.

Manu Sporny: What do we need to kind of pay attention at each one of these
kind of processing blocks are there post-quantum concerns in the
arithmetization or in the polomial interactive oracle proof or is it just
in the polinomial commitment scheme…

Manu Sporny: where we have to worry about the post-quantum concerns

Ying Tong: This is just in the polomial commitment scheme.

Ying Tong: This is where your cryptographic hardness assumptions are
introduced. So if you are relying on discrete lock hardness or bilinear
pairings your snark is not going to be postquantum. If you're just using
hashes like Google is then you're plausibly postquantum or if you're using
lattice hardness problems and of course as you mentioned the relation that
you're proving itself has to be postquantum obviously. Yeah.

Ying Tong: If you're proving ECDSA verification then within a postquantum
scheme then your ECDSA itself will be pre-quantum. so I've linked my slides
here. the rest of the slides basically go through a selection of the most
widely used arithmetizations, IOPS, and PCS's. and I don't think I'll have
time to go into each of them today.
00:45:00

Ying Tong: yeah, I heard a hand

Manu Sporny: And that's fine. And I think what we could do is spread out
each one of these over the next couple of weeks if that works for you and
kind of learn this in bite-sized chunks because I mean you're the expert
here Ying Kong and we need to understand what some of these options are at
least at a high level to make sure that we're able to kind of help you with
the specification and put it together and that sort of things. but I think
we'll need time to listen and absorb over the next couple of weeks to
months. if that's okay with you, do you feel like that would be a good way
to go over these?

Manu Sporny: because I think we do need to go over at least some of the
highlevel things because we will need to the way we put together data
integrity crypto suites is we build a generalized approach but then we need
to make some very concrete selections. We can't just say you can plug in
one of these in any order. we need to package this up so that it's easy for
people that are non-cryraph non-mmathematicians to be able to use that. But
in order to do that, we need to make some very specific choices on what
we're going to …

Manu Sporny: standardize. would kind of going over each one of these, just
breaking it up over the next couple of weeks work for you or is there
something else that you'd like to kind of work on with the group?

Ying Tong: that would work for me.

Ying Tong: I think so far I've been writing this up in the form of slides.
but I think starting next week I'll present draft specifications even very
preliminary drafts in addition to the slides and I think that would be a
better venue for sort of collaborative editing. Yeah.

Manu Sporny: Yeah. Yeah,…

Ying Tong: Wow.

Manu Sporny: that sounds good to us. the other thing I'll mention is to not
be too dismayed if you don't see a lot of contributions early on. the way
this typically works is that there is a lead editor that's going to be and
we can provide input and thoughts and that sort of thing, but usually it's
the author that ends up making the refinements and presenting it back to
the group. but it might not happen,

Manu Sporny: Tommy, I don't know. Greg might Dave Longley might jump in and
do reviews. So, my suggestion is you just start off just writing stuff in
the specification without pull requests because you're kind of starting
more or less from a blank slate. and then we can bring that new spec text
up on the screen and maybe get some real time feedback on what you're
doing. in the beginning and then as things progress you could do them as
pull requests and then you will get much more specific feedback on those
pull requests like people will ask you to change certain sentences or add
specific steps or things like that. So as we get more detailed more
specific pull requests and pull request reviews might be the best way to
work on that.

Manu Sporny: Do you have any concerns about kind of structuring it that way?

Ying Tong: That sounds great to me. Yeah.

Manu Sporny: Just you are going to be writing the spec in the beginning and
showing screen sharing it for the first couple of weeks to months and then
after that we can get more fine grained in our feedback through oll
requests. we'll make that our plan. just let us know when you want to cover
things that you've done. We do just regular reviews in this call. So, we're
going to jump into one with Will's poll request. I think we have enough
time to at least start that. and then we'll just go from there. Just, a
week of heads up would be nice, but even during the day of the call would
work as well. Okay.
00:50:00

Manu Sporny: with that, let's jump into Will's poll request. Will, you've
raised a PR on the quantum safe. let me try and bring this up. spec would
you like to take us through the PR

Will Abramson: Yeah. I mean I could share my screen. yeah, we can just go
through it. Yeah. So unfortunately this turned into quite a large PR. I
think based on some discussion we had a few weeks ago. it was decided to
add some new cryptographic algorithms like quantum safe algorithms. Right?
So we have the stateless hash signatures or whatever that's for falcon and
SQI. So I've added all the sections and then I did it first just to copy
and paste and then I did a little refactor. So now we have this 3.6 common
algorithm section which just tried to extract out some of the algorithms
that were just the same modulo passing in the sweet string. So the crypto
street string is either experimental falcon or SHS or whatever right.

Will Abramson: So if you have a look at the transformation algorithm or
this one. Yeah. So how I did it is I said okay we're going to pass in this
crypto suite value right like parameter into these algorithms and we're
just going to check that instead. So whereas before that on the line down
so it was a specific concrete value now it's a parameter that we can pass
in. I guess one question I have that is my sense of how far you probably
could go further but I don't know if it's worth it right the other things
that are different are the actual algorithms themselves but I don't know if
you want to pass those in there man.

Manu Sporny: I think it's a good start, I mean, I think this is good enough
to review the draft and do a we can always generalize more later,…

Will Abramson: Yes. Get it in. Yeah for sure.

Manu Sporny: right?

Will Abramson: Yeah. Yeah. I agree.

Will Abramson: And then the other sections worth discussing then is scroll
up to the multi key bit. So yeah, all of those sections they're pretty much
copy and paste just dropping in the different algorithms. I have dropped in
the proper links the specs that manu provided. I mean obviously Falcon and
SQI are kind of not as well defined right I didn't know who the authors
were or what the publication was but I put in as much as I could. yeah so
this is the only thing that I'm not sure about we need to pick some values
for the multibase is there a process that I just pick them randomly so
every key right needs a header we need to pick those I know you put that in
there but I wasn't sure what header yeah I know

Manu Sporny: So the headers will be determined by what we register in the
multi-codec registry.

Will Abramson:

Manu Sporny: I did have an open question to the group which was right now
for MLDDSA we're using a 44 which is kind of arbitrary. It is a real value
in the spec and they talk about it. it matches up with NIST level two for
the strength. but that is not the same across all of these different crypto
suites. They use totally Falcon only supports NIST one and…

Will Abramson: Mhm.

Manu Sporny: five it's at the extremes. MLDDSA supports NIST 2, three and
five. SLH, so we'll want to align this will match one, two, and three. SQI
is one, two, and three. So I'm wondering if we want to switch over to NIST
security levels on this rather than the bit length of some arbitrary part
of the algorithm.

Manu Sporny: I mean that's…

Will Abramson: Yeah. Yeah,…

Manu Sporny: what we've been do that's what ITF has been doing for a long
time but I don't think it's useful. P256 and the identifiers for EDDDSA is
25519 and 448 it's doesn't tell you kind of the strength level of what
you're using. You have to be a at least a cryptographic architect engineer
to understand what to pick. whereas if we standardize …
00:55:00

Will Abramson: I was …

Manu Sporny: Go ahead. That's the …

Will Abramson: I'll just say this is good because this is one area that is
not well defined currently in the quantum safe. Like I thought we decided
we were going to pick Nest level one for all of them.

Will Abramson: So that's what I've kind of gone with in terms of the actual
concrete bite values, but I haven't really explained that well in the text
currently that we're picking the level ones. So I think it might be nice to
just say in the crypto suite we're going to say all of these algins use N
level one if they all provide a N level one or are you suggesting that we
should allow all this too.

Manu Sporny: that's the problem I bumped into. I thought ML44 was NIST one.
No, you go and read it and it's NIST 2. We don't go down to NIST one. And
then there's a further argument where it's like, but it might be NIST one.
And so I'm kind of like, all right. and this is in the FIPS spec. I'm kind
of like,…

Will Abramson: Yeah. Mhm. Right.

Manu Sporny: what is it? and then there's a danger that in the future
something that was 3 drops to NIST one because of some, flaw in the
algorithm.

Manu Sporny: Go ahead, Dave.

Dave Longley: Yeah, the thing you just said is…

Dave Longley: what I was going to comment on that then that the NIST levels
aren't necessarily stable and so using them to identify the key pairs is
probably not what we want because they could change and then there would be
confusion. So we want something that's more stable whatever that is.

Will Abramson: So in that case for example for it's SLA I put SHS where did
I get that anyway whatever maybe I need to update that but we would pick so
for example their version is they have 128 S is how they identify the
current key value that I use that what we' put in the cryptosweet
identifier yeah Yeah.

Manu Sporny: Hey, Yeah.

Manu Sporny: The problem with SLH is that they have eight different ways of
getting to the same next level, right? So, Dave, I don't know if it is very
different each one of these the way that the parameter set that's used and
the number of parameter sets to get to the same NIST level is quite
different.

Manu Sporny: Yeah.

Dave Longley: Yeah, but I'm suggesting that's…

Dave Longley: why we shouldn't use that as the identifier in the table for
go ahead.

Manu Sporny: I'm saying that they don't have reasonable identifiers pointed
out even the key size changes for the sameness level.

Dave Longley: The IETF is going forward in using things like you were
mentioning ML44 for their co and cozy algorithm identifiers. I expect IF is
going to go forward using algorithm identifiers in that way, that's what
people are going to expect and that's just going to become how people talk
about these keys. and so if you wanted to do a conversion between a cozy
key and a multi key, I would think you would want the names to line up to
reduce the confusion as much as possible. So if that's how the community is
already going in that direction, I wouldn't suggest picking something
different.

Manu Sporny: The other problem here is that they have not picked anything
for all of these yet.

Dave Longley: then we get to pick something.

Manu Sporny: with that, we've got 30 seconds left. thank you very much,
Will, for the PR. If folks want to do a review on it, it's PR4 on the
quantum safe spec, please take a look at it.

Will Abramson: Yeah, I'll just flag I'm away next week,…

Will Abramson: so I won't be available. But Yeah.

Manu Sporny: Okay, that's fine. I think, let's provide some input on it and
then I think, it's good enough to merge in Yep.

Will Abramson: Yeah. Particularly input on are the names correct because
maybe they aren't correct and we should change. Cool.

Manu Sporny: Yep. Plus one to that. looking for input on it and then maybe
let's give it two more weeks before we merge it in so everyone can get
their comments in and we can update and make changes. okay that's it for
the call today. you everyone very much for the wonderful discussion. thank
you Tong for going through the snark stuff. and we'll continue to work on
all these items in parallel. thanks everyone. Have a wonderful weekend and
we will see you next week. Take care. Bye.

Ying Tong: Thank
Meeting ended after 00:59:38 👋

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