Meeting minutes
Wesley_Smith: Good morning slafter afternoon folks. I'm going to give people a few more minutes to trickle in before we get started.
Wesley_Smith: All right, that's probably enough time to wait. Hi everyone. welcome to the June 16th meeting of the barcodes and data integrity task force. reminder to everyone, this meeting is being recorded and transcribed. If that's something that you are not comfortable with, please let me know. the agenda today is largely the same as normal with a couple small exceptions. first I'd like to go through any announcements, introductions or process items. Then I'd like to briefly recap something that we talked about at the facetoface meeting in Brussels which is the VC forgery defense work. I'd like to discuss that a bit with the group. specifically I'd like to discuss what the sort of concrete next steps are and the plan for that work.
Wesley_Smith: And then as normal we will do poll request review and issue processing for both the BC barcodes and the quantum resistant data integrity work.
Wesley_Smith: With that in mind, does anybody have any announcements or introductions they would make today? Ivonne, go ahead.
Ivan_Herman: Yeah, just in case you haven't seen the mail going around,…
Ivan_Herman: the quantum resistant document has been published in the first public working draft about two or three hours ago. So that's done.
VC Forgery Defense Work
Wesley_Smith: Thank you in Greg's place and congratulations. That's very exciting news. Anything else from anyone else or the bond again? All right, sounds good. so next I want to talk a little bit about the VC forgery defense work. So for those who weren't able to make it to the VC working group face toface, either in person or remotely, during that meeting, we discussed a new technology for defense against key compromise for issued verifiable credentials.
Wesley_Smith: One of the major drivers for this is the kind of impending cryptographically relevant quantum computer threat which compromises traditional digital signature schemes. we discussed in a fair amount of detail this technology what it is and how it works. if you weren't able to make any of those presentations we'll be sharing some technical material for folks to review pretty soon here. But what I want to discuss today is what the concrete next steps are for this group with respect to how it's going to pick up that work item. So what we discussed during the face toface was that probably what makes the most sense is to do an update on the bitst string status list specification where we generalize it into a more general VC status specification.
Wesley_Smith: That's a pretty natural fit for the forgery defense work because the way that the forgery defense stuff works is you publish to the web a list of essentially small proofs that a credential was issued by the organization or entity that claimed to have issued it. And that works much the same way as bitstring status list. And when a verifier wants to check this, they pull down the list and they select the index in the list that they care about based on data in the credential they're receiving. So it functions very similarly to bitstring Concept is to do an updated version of bitstring status list to be general VC status mechanisms and include the VC forgery defense stuff.
Wesley_Smith: Folks at the facetoface mentioned that it's not clear that that is necessarily the best place for it to go. You could certainly make arguments that for example forgery defense could be part of credential life cycle management and there could be potentially a place for it in the vcom spec. there were other discussions as well potentially something to do with confidence method. so I'd like to get folks perspectives here on what they think concrete next steps are for the VC forgery defense work. which of those options sound good to people? What are next steps? Manu, go ahead.
Manu_Sporny: So I sent a quick email to Ivon and Brent and you and Elaine where I thought we had made a different decision at the face toface meeting and Von noted that the minutes were not clear about that. I thought we started off with the notion of we'll just update bitstring status lists and make this spec about status and we'll go forward like that because that's probably the easiest thing from a process perspective. and then my recollection is we talked about what would we do in the ideal case?
Manu_Sporny: it feels like we're kind of shoving it into this specification and it's not like the whole design around the verifiable credential specifications is that we should be able to advance the ecosystem in a decentralized way by issuing new specifications that solve specific problems and if we did not have process burden to deal with this should be a separate specification and I heard Brent, who is in charge of the process group, saying, "Let's do that." because let's not let the process get in the way here. let's do the right thing and then change the process so that the right thing happens. and so, the argument is the group can publish as many different documents as it wants to as long as it's addressing the problems in the charter.
Separate Specification Forgery Defense
Manu_Sporny: And that is the basis of us publishing this specification as a new specification as an FPWD where we basically say it's addressing a security vulnerability that the charter says we can address right so we could put it in the bitstring status list thing But we can also make the decision that we can split the bitstring status list spec into two specs. And so why don't we just fast forward and do that instead of kind of trying to shove it in a place that it doesn't belong. that's
Wesley_Smith: Ivan, go ahead.
Ivan_Herman: So first of all whether we define we put it into the B string status list spec or…
Ivan_Herman: we do a separate document we have a similar administrative step to do which is always a pain which is the first public working draft itself because that would require a first public draft for the next release of the bitstream document So we are not bypassing the first public working draft. If we put it into confidence method to be honest I don't remember about that being discussed but I was partly out then of course we don't have to do that because that's a new document anyway but the bitstring is already a recommendation so we start a new line you can do that.
Ivan_Herman: That being said, maybe money hasn't realized that, but we do not live in the ideal world. and in the current situation, I am trying to be very defensive because I know that there are dark forces out there that try to push against VC still and I don't want to get into a stupid war around that issue. So that's my very p a very conflict aware and conflict avoiding approach to the whole thing.
Ivan_Herman: And in a way if I call the document not bitstring status list or something similar then it doesn't sound so unnatural to have the mechanism being there as Wesley said it is fundamentally a similar idea to hide privacy this kind of issues behind a big crowd of data out there. so there are very similar things in there. So it seems to be pretty natural for me. It doesn't bother me if we do it that way even from a technical point of view. So I would be in favor to do it the way Wesley outlined it in the biting document.
Wesley_Smith: really quick.
Wesley_Smith: Ivonne, could you speak to with your, perspective that is conscious of dark forces as you put it, can you speak to the danger that you see in creating a new document for a BC4?
Ivan_Herman: that there will be not formal objections…
Ivan_Herman: but there will be objections to the first public working draft request to do that because it is not in the charter and the charter is as it is. I am very happy if Brent is able to change the process but that will take a long time. In the meantime, we have to move ahead with what we have. and that will be a refusal at that point or even if we get it done, there might be objection on the AC vote at the end of the whole process in a way saying that there was no entry in the charter to do this.
Ivan_Herman: Our charter is not open-ended. so yeah.
Wesley_Smith: Thanks, Mona. Go ahead.
Manu_Sporny: Yeah, I disagree that we should use fear and process issues to drive what we do in this group. I think we should do the right thing technically and that should drive what we're doing. the end. So Ivonne, I'm not saying that you don't have some points, and I totally agree that sure there are dark forces that might try and stop us, but to we should do the right thing technically and here's why.
Manu_Sporny: If we put this thing in status, the threat model for status all of a sudden has to cover two fairly different threat things. the threat vectors for bitstring status lists are different than the threat vectors for the key compromise detection stuff. So all of a sudden our threat model is this weird mashup of two different threat models. and the whole thing driving this is and I think Brent said there's justification in the charter for us publishing a document. I mean groups can decide to publish documents There should be no difference between putting this information in the status specification and publishing it as an FPWD versus publishing it as two different documents. Working groups are allowed to do that. Right? We can decide how to split the work up.
Manu_Sporny: So I think maybe Ivonne if you're concerned we run it by PL and ask them if they agree with the charter and process concern and if people want to fight this if they want to fight getting a security document out there I mean let them because they're going to fight it in bitstring status list if that's the case right if they're looking for a reason to object to something then object to the VC status spec because all of a sudden it's growing in scope, And it doesn't include things that the group was going to do. So I think it's defensible. I do agree with you that it's a little more risky than putting in the BC status spec, but we should be doing the right thing from a science perspective.
Manu_Sporny: And if the process does not support that or if people want to snipe it for reasons that they just want to stop the work. I think we should do the right thing from a scientific basis. That's it.
Wesley_Smith: Thanks acting myself. I am curious if it is possible to test the waters and do this publication publish a new document try to publish a new document as a first public working draft and see if we receive the kind of push back that you are concerned about Ivonne and if we receive the kind of push back that indicates that people are really dug in and it would be a extended fight to try to go through with that plan that course then it say okay we're not going to actually publish this as a separate document we're going to instead do an update to visioning status list or something to that effect I'm curious if that is an option Kevin go ahead
Generative Specification For Data
Kevin_Dean: Yeah, I'm all for having some way of publishing the key compromise information, but I'm not sold on the idea that it's part of should be related to the bitst string status list because they are two very different things. The key compromise detection is essentially static data that is side loaded during the verification process for the credential itself.
Kevin_Dean: Whereas a status list is something dynamic that can change over time to indicate that a credential has been revoked. The design principle behind the status list as well also required that it be as small as possible. That's why it's a bit string and that it be designed in such a way as to reduce the possibility of detecting who's using it and what credentials being verified. Whereas with key compromise, we're talking about much more data and if you have a large number of credentials, applying the same principles as bitstring status lists and having just a single file and then indexes into that file could lead to absolutely huge results. I think these things are sufficiently different that to try to shoehorn it into something into the bitstring status list would be a mistake.
Kevin_Dean: I would agree however with the idea that the two are related closely enough that we could come up with a consolidated specification for essentially sideloaded data which for now encompasses just bitstring status list could in compro compromise be composed of the key compromise material as well. And if we do it right, then if some other requirement comes up in the future where we need some externally referenced data as part of the verification process, we have a specification that can be used to do it in a generic fashion.
Wesley_Smith: All right. Thanks, Kevin.
Ivan_Herman: All right.
Ivan_Herman: Something else came to my mind right now. Maybe that can be a way forward. It's all come down how we sell this in a way. I mean that's obviously the problem or the thing to do. What if we publish it as a separate document but in the abstract or the introduction or both we put the emphasis of what you actually refer to Wesley that the necessity for this document is because of coup.
Ivan_Herman: So it is not part of the quantum resistance cryptosweet specification per se but it is something which is in a way related because we are answering to a threat coming up about quantum computers. And if we put that very clearly in the abstract in the introduction even if my understanding is correct the mechanism could be used in any setting it is not bound technically to quantum but it is made necessary by quantum. Let's put it this way.
Ivan_Herman: And if we do that then we may have the good arguments to make the cell so to say. Yeah.
Wesley_Smith: Acting myself plus one, Ivon. And I think the way that we frame that is this is a defense against key compromise and the threat that quantum computers bring is that key compromise is about to become a lot easier and a lot more commonplace, it's about to become free if you have a quantum computer essentially. so that's the way we frame it in the spec I would think. strongly agree with everything you said Ivon. I also will note that bigger picture with respect to process the work Brend is doing and the like.
Wesley_Smith: I think it is somewhat surprising to me as someone still fairly new to these organizations that it is difficult to do this because this thing publishing a creating and publishing a specification for a new security technology as a result of an emerging threat seems like exactly what this group is meant to do. so I don't know if I'm not proposing any solution. I'm just saying that if there's any process change that can happen in order to make this easier, that seems like that would be a really good thing to happen because again, if not us, then who? I guess I would ask. Okay. go ahead.
Ivan_Herman: No, let's not go down that route. I mean, I don't disagree, Wes, but this is not the place and the time to discuss it. That's something…
Ivan_Herman: which goes to Brent, but he's not here. He's on a trip somewhere. So, yeah. Yes.
Wesley_Smith: Understood. And I know there's a tremendous amount of complexity in managing these groups and…
Wesley_Smith: doing it in a consensus driven way and all that sort of thing. All right. so I think that we have a plan. Let's do a proposal. and…
Manu_Sporny: Sorry,…
Wesley_Smith: then
Manu_Sporny: We can't call them proposals in here.
Wesley_Smith: Excuse Sorry. Let's do it. I said was my goodness. Manu Sporny:
Manu_Sporny: No. P O L
Wesley_Smith: Do we need to specify things like short name in this poll? So then the new document I'm going to propose it should be titled VC forgery defense verifiable credential forgery defense with short name VC forgery defense.
Wesley_Smith: I suppose asking this verbally doesn't make much sense since I'm about to run a poll on it.
Ivan_Herman: Before we do that,…
Ivan_Herman: something that we almost missed with the quantum thing. do we want to put a version number to it?
Manu_Sporny: 1.0.
Ivan_Herman: We had to do it the very last minute for the quantum safe and sorry, quantum resistant. I don't want to get into that again.
Wesley_Smith: Okay.
Ivan_Herman: So the short name might be what you said Wesley 1.0 zero or…
Wesley_Smith: 1.0. Okay. Ivan Herman:
Ivan_Herman: something like that. Yeah.
Wesley_Smith: Does this poll need to cover anything other than the creation of this documents?
Manu_Sporny: Can we say publication as FPWD as well?
Wesley_Smith: That's okay.
Manu_Sporny: adopt the verifiable credential forgery 10 defense blahy blah and then publish as an FVWD.
Wesley_Smith: Give me one second.
Wesley_Smith: Before we vote, anybody have any changes that need to be made? Okay, hearing none, please vote on this poll.
Ted_Thibodeau_Jr: Plus one for me. My IRC is not cooperating yet.
Ivan_Herman: Okay.
Wesley_Smith: All right.
Ivan_Herman: You are twice dead.
Wesley_Smith: You're plus two. do we have an IRC for this meeting?
Wesley_Smith: It is automatically minuteed. So, the IRC participation is not required. Okay. …
Ivan_Herman: as an aside money.
Ivan_Herman: Are we sure that it works? Because it didn't work for the task force yesterday.
Manu_Sporny: Yeah, it failed last night because Google didn't move the files into place on time. So, I'll try and rerun it.
Ivan_Herman: Okay. Agree.
Wesley_Smith: what is the analog to resolved for pollled agreed? Is there one agreed? Okay.
Dave_Lehn: Is it resolved?
Wesley_Smith: It's resolved for a proposal.
Manu_Sporny: No, no,…
Manu_Sporny: don't use result.
Dave_Lehn: All right.
Wesley_Smith: Yeah. Agreed. Is that where we landed?
Manu_Sporny: You don't need anything. I think you can just say we pulled and it looked like there was consensus in the group.
Wesley_Smith: I will bring this up to the larger working group on the call tomorrow.
Wesley_Smith: Then I think that's it for that item. Anybody else have anything they want to say on the VC forgery defense topic? Mhm.
Ivan_Herman: on practicalities,…
Ivan_Herman: I would prefer just to be very formal about it to wait until the formal vote is done before taking over the repository. But I believe I need an admin access to your repository to move it to the W3C as you prefer.
Wesley_Smith: Would it be simpler for you to just create a repository and then I will raise a PR against that repository? Yeah, let's do that.
Ivan_Herman: in a way I can create an empty repository with a phony respect file and then that's fine that no problem about that let's do that …
Wesley_Smith: Just excellent. Thank you very much.
Wesley_Smith: That certainly sounds fine to me.
Ivan_Herman: but what will be the name of the repository I don't want to change that once we agree on it VC forger jury defense is Okay.
Wesley_Smith: I don't know if there are naming conventions for the W3C code.
Ivan_Herman: I just don't want to change it because all we have all kind of redirection that go wrong need…
Wesley_Smith: Right. Understood.
Ivan_Herman: if we change No,…
Wesley_Smith: All Thank you very much, anything else on that topic? I don't see Greg here, otherwise I would yield the rest of the time to the data integrity work.
Wesley_Smith: I suppose we potentially still could. does anybody here Avon, go ahead.
Ivan_Herman: no, no. Finish person.
Wesley_Smith: Yeah, I'm curious if anybody here has any updates they want to give on the data integrity work or if anybody wants to do some, discussion, issue processing, pull requests, anything like that for data integrity. Ivon, do you want to Q minus later?
Ivan_Herman: So that's actually an announcement I should have done at the beginning, but I just forgot. if you guys remember the charter includes an entry for the SM2 crypto suite, which I think it's a Chinese version of analytical curve algorithm. I don't know the crypto side behind it. I had some discussion with my Chinese colleagues. They are busy doing one thing now which is making sure that there are no IPR or other issues in China. Now this is obviously a discussion that we keep away from and let's suppose that it's done then I will have to convince people in China to send their necessary experts to do the work.
Quantum Resistant Document Publication
Ivan_Herman: I just want to check something with you guys because I am not an expert. I looked a little bit at the various crypto suites which are around ECDSA etc. and my impression is that they follow more or less the same structure as far as the transformation is done and then hashing and canonicalization and whatnot. And in a way using a new algorithm is just sort of copy pasting the current specification and plug in whatever is necessary for SM2. Is that grossly speaking correct?
Ivan_Herman: I use this argument to get people that in a way doing the crypto suite document for SM2 is not a big deal because it's mostly there and again if I remember eventually all those joint common things will go general as well so this means a crypto sweet document can be two page long eventually is that all correct Yeah.
Wesley_Smith: Mon, go ahead.
Manu_Sporny: Yes, almost all of it. Avon, I think that saying that generally is fine. Two pages, you want to have test suites and that takes six pages,…
Ivan_Herman: Yeah. Yeah.
Manu_Sporny: right? …
Ivan_Herman: Okay.
Manu_Sporny: but yes, in general, what she said is probably the work that they'll need to do.
Ivan_Herman: So, it's not a huge amount of work for them.
Manu_Sporny: No, it shouldn't be especially for elliptic curve.
Manu_Sporny: And they should talk with it is Yep.
Ivan_Herman: I think I don't know SM2.
Ivan_Herman: I seem to remember it's an elliptical curve, but it is okay.
Manu_Sporny: Yep. Ivon,…
Ivan_Herman: Thank I hope that it will be successful, but I do my best.
Manu_Sporny: something else that would be very interesting to learn is if the Chinese national standards for cryptography are going to use any of the NIST approved cryptography meaning like MLDDSA or…
Manu_Sporny: SLHDSA or Falcon. it would be really interesting if they had alternatives. but they might not be ready to speak to
Ivan_Herman: I understand.
Ivan_Herman: We know it's difficult to get information from there.
Wesley_Smith: All right. Thank you. Manu, did you have your hand up for a point about data integrity?
Data Integrity Updates
Manu_Sporny: Yeah. just a couple of updates. I think Ivon you did mention that it's published on TR now.
Ivan_Herman: Yeah. Heat.
Manu_Sporny: Did I miss that? All right. and that's great. because we have had a number of other people that are starting to become more interested in data integrity and postquantum. I will note that digital bazaar has an implementation of one of the crypto suites. This is the MLDDSA 44 for RDFC. and I did a JCS one as well. so there are two implementations of the spec there. Greg's got his own. So we've got two independent at least one of the base ones.
Manu_Sporny: I think Greg or we are going to work on the test suite for it as well. we don't expect it to deviate much from the way the ECDSA and EDDDSA ones are done. so I think that's on a good glide path. so just those updates there. so that all that's kind of good news. we've also deployed MLDDSA as a data integrity solution for a new blind witnessing service that we announced to the public credentials mailing list. Let me get the link to that.
Manu_Sporny: And that blind witnessing service uses data integrity to sign cryptographic hashes that you send it. And it will also use MLDDSA to do those signatures. So that's actually being used in an experimental data integrity signing endpoint. And the blind witnessing stuff is useful for things like did cell or these little mini blockchains that people are playing around with these days. so implementation's going fairly well there. The other thing I wanted to mention was ski sign.
Manu_Sporny: Most recently I've spoken with two people that want to do implementations beyond I think Greg's going to do an implementation or has already done implementations of ski sign just I think using Luca DeFeo's group's ski sign implementation so the official ski sign implementation I know Dig Bazar wants to do one. We're probably going to reuse somebody else's cryptography library to do it. And this new individual has written ski sign from scratch using rust. so that they have an implementation and they have committed to integrating with the test suite as well. So that gives us three independent implementations for skis sign.
Manu_Sporny: The challenge is going to be that I really doubt NIST is going to approve ski sign before we're where our charter ends, and it is not clear to me if an ITF RFC is required for ski sign or this paper that Luca Defeo's group has published and has been analyzed by NIST and NIST and has all of the implementation details in it is good enough.
Manu_Sporny: So there's a question of around can we link to the paper that NIST is using for evaluation or does this thing if it needs to come from CFRG that's going to make things more difficult. So there's a question on how stable does everything need to be. I think we can make the case for there's a stable reference for it but there's a different question around is the cryptography ready. My expectation is that we will have everything but that stable reference by the time we want to go to wreck. and as a result of that we're going to have to remove ski sign from version 10 before we publish the wreck.
Manu_Sporny: But we would do that during I think that's the default path. and I think that might hold for Falcon as well. I don't think Falcon has a FI I don't think Falcon We don't know when Falcon's FIPS, documents going to come out. And I don't know if we need a CFRG document for that one either. So, there's a chance that we have to cut Falcon and ski sign from the version 10 spec, which is super unfortunate because, MLDDSA signature sizes are 2.4 kilobytes for the smallest of them and SLH is just multiples of that. all right. I'll stop there.
Wesley_Smith: Ivon, go ahead.
Ivan_Herman: Yeah. …
Ivan_Herman: we know that what's really important is to have a freely available and stable reference. I mean I don't think that we are formally required that to be an RFC or whatn not. So if there is a stable reference that the community can rely on once for all and it's publicly available then I think we can make an argument for that and we are still a little bit far away from that anyway so we will have time to wait to see what happens but I think for something like crypto it is perfectly fine to sort
Ivan_Herman: of refer to stable documents that the community relies on. if there is one which is in danger as you said Falcon I would like to find a way to keep it in the document but not being normative or something like that. I don't know exactly the best way of doing it. I mean it would be a waste and a shame to just remove it all together. we do not recommend it but we add it as an appendix saying this is also an informal appendix which says this is on its way. The crypto part may still change and therefore it is not recommended.
Ivan_Herman: However, if that happens or I don't know. I mean, we can find some text around it, but let's try not to take out valid things from the spec.
Wesley_Smith: Morning. Go ahead.
Manu_Sporny: Interesting.
Manu_Sporny: I think I'm going to be more conservative than you are, Ivon, on this one. I do agree we should keep it in the document for as long as we can. I think it will potentially have a negative impact on W3C's reputation if we suggest cryptography and a recommendation that has not been approved by CFRG or NIST. So I totally agree that I Dave in the chat channel said we just refer to FIPS for ECDSA. So I think we need a stable reference to either fifth fips for both falcon and ski sign or at a very minimum CFRG.
Manu_Sporny: It's not going to happen in CFRG or Falcon or Ski Sign, I don't think, because the work hasn't even been started, right? it is much more likely that NIST publishes documents before CFRG does at IFF, which is surprising, but that's just kind of the way it's probably going to happen. So I think maybe what we do is we just keep it in the document for as long as possible, but we will need to publish a wreck and we will need to make a discussion at that point. And I think at that point, Ivon, we can just make it so we comment I think even putting it in non-normatively might backfire, So let's just comment the sections out, publish the wreck, it's not in there, and then immediately publish new11 working draft with it back in there, right?
Manu_Sporny: So it is clearly, marked in there as this is how you would do it, but we don't put it in the recommendation. So there's a little blip in history where we remove it, publish the final wreck, and we warn CR that this is probably what's going to happen. And then right when we publish the one one, it just goes right back into the spec as an option. That's it.
Wesley_Smith: Kevin, go ahead.
Kevin_Dean: Yeah, plus one to Manu. I think that, something as important as cryptography shouldn't be based on anything provisional. at this late stage, it's very unlikely that they'll find a weakness. I'm sure they've got their best people on it, but in the unlikely event that they do and therefore never get to recommendation, then it would look for us. Be bad to have that in spec.
Wesley_Smith: Thanks, Avon, go ahead.
Ivan_Herman: I hear both of you.
Ivan_Herman: So that's fine. But there is one thing that buzzers if my understanding is correct of what you said, I am gathering information here. I am not an expert. The one which is stable is the one which has huge keys. Is that correct?
Manu_Sporny: Correct.
Ivan_Herman: So in the worst case if we go with a recommendation which relies on that one we are providing a recommendation which is very difficult to use in practice because of this problem.
Ivan_Herman: So if that is the case and again we don't decide it right now but I might propose to do the same as we did with BBS leaving the whole CR open until the dust settles around these things and publish it as a recommendation only when that comes something like that. I mean that's my only worry. But again I think we can leave the discussion with we have roughly speaking a year to go anyway.
Wesley_Smith: Thanks, Kevin, is that an old hand?
Kevin_Dean: Yeah, that's an old hand. I'll take it down.
Wesley_Smith: All right, man.
Manu_Sporny: yeah van I agree we can make the decision later on. while it is true that the key sizes and the signature sizes for MLDDSA are gigantic and SLH is worse it is what Google and Cloudflare and all those people are deploying right so basically this is what people are deploying my concern with leaving it in perma CR is that people that don't like data integrity will use that as a reason
Manu_Sporny: that there is no postquantum secure mechanism that is a W3C recommendation and that would disadvantage us right so our customers when we're talking with our customers there are other vendors in the room and some of them are looking for any excuse to say that data integrity is not a good thing to use and they'll use that the fact that it's just in CR and it's not a wreck as the reason to just not use W3C's and not use data integrity. So that's my major concern with keeping it in, forever is that it never becomes a recommendation and therefore everybody else gets to go forward and implement MLDDSA and we're kind of left back waiting for the longest pole in the tent to kind of resolve itself. That's it.
Wesley_Smith: Dave Long,…
Wesley_Smith: you go ahead.
Dave Longley: So I think we should probably just give this more time to decide.
Dave Longley: Lots could happen in a while. one of the other last minute options is also to split the documents. publish one, CR the other and let that one go have a longer time horizon.
Wesley_Smith: Ivon, go ahead.
Ivan_Herman: Why? I want to promise you I did not think it with Dave,…
Ivan_Herman: but I was thinking about the same way. I mean, after all, what we did so far is we published one document per crypto suite. Not exactly because there's a GCS versus canonicalization split, but essentially one document per crypto algorithm. Let's put it this way. and if we end that by having what I pushed a little bit too far maybe but to say that a crypto sweet definition is a two-page document then we can just simply have if my memory is correct four crypto suite specifications one for each of the algorithm that are listed there and
Ivan_Herman: and could not go to a wreck separately from one another. That's perfectly possible. it's a bit of a pain on the editors and myself, but we can survive that.
Wesley_Smith: Yeah, I put myself on the queue to say that that seems to make a lot of fairly obvious sense as well since the publication of these documents is dependent on external definitions of maturity which we've been discussing in this group and the different crypto suites the different technologies are at different points in those definitions of maturity. it seems to make a lot of sense to not couple them together with respect to the W3C process. That's it. All right. Should we run a poll to that effect to split out the different algorithms?
Ivan_Herman: I would I'm sorry.
Wesley_Smith: It's okay. Go ahead.
Ivan_Herman: Go ahead.
Manu_Sporny: Yeah, I would like to not do that right now because it'll just create more work for us that I don't know if it's got let's wait. I think I agree with Dave like we don't need to make this decision right now. we just published the FPWD for the quantum resistant crypto suites. we're just going to create a bunch of other process headaches for us. Let's just wait. I don't think there's anything timesensitive right now.
Wesley_Smith: It is definitely an exciting time to work on quantum safe cryptography.
Manu_Sporny: That's it.
Wesley_Smith: Ivon, go ahead.
Ivan_Herman: Yeah, more or…
Ivan_Herman: less the same thing and I think we will have to engineer this spec anyway if all the common part go to the DIP spec which is boring but necessary editorial work that will come up and once that is done the current spec will have to be engineered anyway and at that time we can think about splitting it into four not. Yeah, that's it.
Wesley_Smith: Okay, it sounds like we're in agreement that it's sort of a no up for now with a general group understanding of what may happen down the line. That sounds good. All right. Anything else related to data integrity that we should discuss today? hearing nothing. we have seven minutes left, which probably is not worth shifting gears into doing issue processing, poll request reviewing. but does anybody have any announcements or discussion points they want to talk about for the VC barcodes work? Wanna go ahead.
VC Barcodes Threat Model
Manu_Sporny: Just one thing let me we see barcodes. I'm switching the topic back. at the face-toface meeting we spent a lot of time doing threat models and threat modeling. I believe I have a complete first pass for a threat model for the recognized entities specification. that is this pull request here that we are going to discuss later today at the recognized entities call.
Manu_Sporny: I feel pretty good about it for a first draft. meaning I feel like it's fairly complete. it took in the working group the enty recognized entities task force input onto the threat model. It created a diagram that I think the threat the security folks will be happy with. it's fairly not exhaustive but covers a lot of attacks probably goes a little too far and uses Joe's new threat modeling library for respect. so I think it's in a good state to review and I think we should potentially use it as the basis for the threat model in this group for VC barcodes.
Manu_Sporny: I know that Greg is working on a threat model for data integrity stuff in the quantum resistant stuff. on the barcodes work need to work on a threat model for barcodes. I think we went through that exercise where we collected a bunch of threats. which means that I think we're ready to do a threat model for the barcodes work and if we do that then we'll be able to ask for horizontal review. So my suggestion is that is the next big thing that the barcodes folks and the forgery defense spec needs to work on and I think everything's in place for us to do that.
Manu_Sporny: So now we just need a volunteer to work on those things. and I'm happy to help folks as they put those things together. I think for the barcode stuff, putting together a threat model is let's say 10 hours of work. I think it took me about 16 to 20 hours to put the one together for recognized entities. but that was mostly because I had to figure out I had to learn everything and so it might be faster with a smaller kind of target barcodes as a smaller target than recognized entities maybe. Okay, just wanted to put that out there. we'll still need volunteers to do that work and don't underestimate how much time It's going to take, at least 10 hours,…
Manu_Sporny: maybe 20 hours per spec. That's it.
Wesley_Smith: Right.
Wesley_Smith: Go ahead.
Ivan_Herman: a related thing…
Ivan_Herman: because the threat model comes in when the document is technically I don't say ready but more or less ready. Now I think that we have one pending thing for the barcode document and that is to move the crypto suite which is there out of the document and somehow put it into one of the crypt I think the SECDSA one. so I think this should be done first before we do we merge any threat model into the document because some of the threats might be actually around that crypto suite and not the barcode document itself.
Wesley_Smith: Man, go ahead.
Manu_Sporny: I agree with Von. We need to move it, but you can work on the threat model presuming that's going to happen.
Ivan_Herman: Okay.
Manu_Sporny: I think we have consensus to do that. And so the threat model shouldn't include the XI crypto suite because it's being moved, right?
Wesley_Smith: All right, that sounds good. noting that we are almost out of time. I think next steps for the VC barcodes work are pretty well understood. I'm not going to ask for a volunteer to do the threat That sounds like a painful exercise. the asking, not the modeling. I expect that person will be me. but…
Ivan_Herman: Bye-bye.
Wesley_Smith: if anybody on this call is interested in contributing to the threat modeling work for VC barcodes, please and we will go from there. All right, we are about out of time. thanks folks. thank you for the time and I will see you all next week.
Elaine_Wooton: Bye-bye. Meeting ended after 00:54:49 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.