Meeting minutes
Elaine_Wooton: C something like that. South of France. Yeah. it's filled with yachts. Yes.
Wesley_Smith: Good morning, Elaine.
Wesley_Smith: Good morning, Bright and early. so I'm gonna toss it over to you pretty quickly here, Greg. since we spent most of last week doing the barcodes work, I expect we can spend most of all the time this week doing the data integrity work. Do you have a link to the threat model template for data integrity?
Greg_Bernstein: Yes, it's morning.
Greg_Bernstein: No, I haven't started anything on that yet.
Wesley_Smith: That's totally fine. so what we did last week for barcodes was we took this exact document template that I just linked in the chat,…
Wesley_Smith: and we basically filled out section four, question mark.
Greg_Bernstein: I just mostly had issues that I want to confirm closing and…
<Wesley_Smith> Data Integrity Threat Model Brainstorming Template - Google Docs
Greg_Bernstein: two PRs I want to merge, but
Wesley_Smith: Yep, sounds good. So, whatever you want to do there is good.
Wesley_Smith: And then when you get over to the threat modeling stuff, you're going to want to tell people to go to the document that I linked in chat and basically have a brainstorm session where you take 10 minutes and let people submit threats essentially to the threat modeling section which is section four of that document. and then after that you can kind of go through item by item what people put in and discuss and categorize. Sound reasonable.
Greg_Bernstein: Okay.
Wesley_Smith: Hello Ivonne.
Ivan_Herman: Hello.
Wesley_Smith: I'll give it a couple minutes for people to trickle
Welcome And Announcements
Wesley_Smith: All right, I think we can go ahead and get started. Hello everyone. welcome to the May 26th meeting of the barcodes and data integrity task force. a reminder to everybody, this call is being recorded. if you are not comfortable with the recording or transcription of what you are saying, please let me know. we have the Brussels face toface meeting next week. So to those of you that will be there, looking forward to meeting you in person, to those of you remotely, looking forward to seeing you that way as well. The agenda for today, I expect first we'll go through process announcement items. and then I expect we'll spend majority the entirety of the rest of the call on data integrity.
Wesley_Smith: Last week we spent most of the call doing a barcodes threat modeling brainstorm session and I expect we will want to do a similar session for data integrity on the call today. with that said, does anybody have any announcements, introductions or process items they would like to discuss?
Wesley_Smith: Manu, go ahead.
Manu_Sporny: Mostly just a question about the face toface.
Manu_Sporny: Wes Elaine, y'all had a chance to kind of talk through what we're going to talk about on that Monday and then is it issue processing and then the day of? just curious as to the agenda.
Wesley_Smith: No, I haven't spoken with Elaine about…
Wesley_Smith: how we're going to break down that time. that sounds like a useful thing to do. Ivonne, go ahead.
Ivan_Herman: So you say Monday?
Ivan_Herman: I didn't even realize you have a meeting in Monday.
Wesley_Smith: Yeah, I believe there's a special meeting specific to the barcodes work scheduled for Monday afternoon. I believe that's from 2 to 6:00 p.m. local time.
<Elaine_Wooton> MY MIC IS NOT - SO ...
Wesley_Smith: Yeah.
Ivan_Herman: I didn't realize that to be honest.
<Elaine_Wooton> I did ask for the monday meeting for BCs since we have a chance to focus together!
Ivan_Herman: I was planning some private time with my wife which I may do after all. Okay.
Wesley_Smith: Yeah, I don't think that there's any obligation there or anything that anybody has to be at that meeting for in particular. I think it's just mostly a work session. so please enjoy the time with your wife. anything else related to the face toface meeting or…
Wesley_Smith: a different announcement or process item anyone would like to discuss? All in that case, I will go ahead and turn it over to you, Greg, for data integrity
Greg_Bernstein: Okay, let me I'm going to put up the repo so we can go through.
Greg_Bernstein: Let's see. Nothing's showing up. Yeah, here it comes.
Reviewing And Closing Old Issues
Greg_Bernstein: Okay, let me go directly to that screen. Let's start with the issues. I want to make sure we're doing the process correctly. So, last week after our discussions, I went back and looked at all our issues, especially some that are quite old. Let's start with issue number two down here. Register multibase values to identify MLDDSA keys. Okay, this was accomplished quite a while ago. the keys were registered with the multi. So I put in a comment on that over a week ago and I marked with a label pending closed on this.
Greg_Bernstein: Is this the correct approach to do this? M. Sporney gave it a thumbs up. Can I mark this closed? It's been marked this way for a week with the comment for a week. Process is question.
w3c/vc-di-quantum-safe#2
Manu_Sporny: Plus Yep. Plus one. That's the process.
Greg_Bernstein: Close it. Okay, let's go to the next one. We're gonna just Okay, SLHDSA issue number three not to include any reason not to include MLDDSA SLH DSA. We've added SLHDSA.
Greg_Bernstein: working on it. SLHDSA is in there now. Marking this closed. We satisfied that issue. Oops. pick can use multi key names and prefix values. Okay. we worked with the multi-key people to select the appropriate values and names.
w3c/vc-di-quantum-safe#3
Greg_Bernstein: Yes, they look like some of these ones that we put in here. ski sign is not yet standardized. Neither is Falcon. So, we're holding off on Any questions? We did work with the multicodex people to pick the appropriate names for Any other comments on this? Closing issue number five. Modularize algorithms to keep it dry. This was the big update. when was that done? That was PR 11 that was March 2nd.
Greg_Bernstein: So that's fine. a while since we did this and that merged pending Any questions about that? Otherwise closing the issue. Just scrubbing these down. Just double checking. this one has to do with this issue number seven has to do with the naming conventions. we have in data integrity a consistent set of cryptosweet naming conventions and we applied those in the merge number 11 that was back in March.
w3c/vc-di-quantum-safe#5
w3c/vc-di-quantum-safe#6
Greg_Bernstein: Any questions about that? So this has been the satisfied by PR11 and it's been merged quite a while ago. So this is issue number eight. This is encoding of keys and proofs 58 or base 64. postquantum keys and proofs can be significantly longer.
w3c/vc-di-quantum-safe#7
Greg_Bernstein: there is discussion about base 58 performance issues and such like that. where we did the drive stuff and things like that, we went with B 64 URL for both proofs and key values. so this issue is closed as far I mean was resolved. So I'm closing the issue. this issue was raised by me to set up our additional refactoring derived type of stuff.
w3c/vc-di-quantum-safe#8
Greg_Bernstein: This was resolved by PR number 10. so any questions about that? We added test vectors too. So this isn't ready to be closed yet, but I had a question. Let's see if so we did not put in secret key variants. the secret key values not defined.
w3c/vc-di-quantum-safe#9
Adding Secret Key Variants To Table
Greg_Bernstein: And we need to do that for consistency. So my question to Manu would be sufficient action add a table to the multikey section. Right now we have a multike key section that has all the public keys that we use. We don't list everything from the multicodex only the keys that we're currently using for the crypto suites. I could add a table with the private keys with the caveats saying make sure you don't publish private keys and such like that. Would that be sufficient? And then I'll put in a PR for this.
Greg_Bernstein: Go ahead.
Manu_Sporny: Yeah, I think that would be sufficient. I'm trying to see what we do in the and we refer to the SID spec, which we don't want to do in this case. I don't think multikey and SID. Yeah, in the ECDSA spec, we refer to the multike key section in the SID spec, which is probably wish we hadn't put it there. so yeah, I think just create a table that looks that mirrors.
Greg_Bernstein: We have a table for the public keys.
Greg_Bernstein: So can we mix both of them together in the same table?
Manu_Sporny: This is for the secret keys are also in this table here in the SID spec. So I think just follow that pattern like the look and feel of it but put it in the postquantum spec if that makes sense.
Greg_Bernstein: Yes. Okay.
w3c/vc-di-quantum-safe#17
Manu_Sporny: No, no, no, no. There's No. if you look at the SID spec, the link I just dropped in there, go ahead and…
Greg_Bernstein: I see the multi key.
Manu_Sporny: open that up. And then you might want to open it on your screen,…
Greg_Bernstein: We have the public secret key, multibase, and we have values.
Manu_Sporny: Greg. We can't see what you're looking at.
Greg_Bernstein: Yeah, sorry.
Manu_Sporny: No problem.
Greg_Bernstein: Switch the windows.
Greg_Bernstein: It's all right.
<Manu_Sporny> Controlled Identifiers v1.0
Manu_Sporny: You could just open a new tab there and copy paste the link that I put in the chat.
Greg_Bernstein: Yeah, we'll do.
Ivan_Herman: That's what I'm doing right now.
Greg_Bernstein: coming through yet?
Manu_Sporny: Yeah. Yeah.
Manu_Sporny: So, if you scroll down there, this is the public key table here that we listed, right? And…
Greg_Bernstein: And then we have a separate private key,…
Manu_Sporny: then down Yeah.
Greg_Bernstein: secret key.
Manu_Sporny: Yep.
Greg_Bernstein: Yeah, because we have the public keys currently in the safe postquantum and then I'll add a table that looks like this for the secret keys.
Manu_Sporny: Yep.
Greg_Bernstein: Okay. The other issues we are sorry
Ivan_Herman: Excuse me. So just from my understanding the goal is to extend the CI tables with these keys or you have a separate one.
Manu_Sporny: extend is the goal.
Ivan_Herman: Then I was worried for a moment that there would be a separate table somewhere.
Manu_Sporny: Yeah. …
Ivan_Herman: Sorry. That's why
Manu_Sporny: there will be a separate table in the postquantum thing. because if we don't do that, we have to bind the SIDS spec publication with the quantum publications and I don't think it was ever intended that we were going to centralize key registrations anywhere because if we do that then it means it kind of defeats the purpose of at least part of the data integrity specs which is people can in a decentralized way create their own specs and extend the table and that sort of thing. that's the reason is that we'll just be in process.
Manu_Sporny: It'll put us in a bad position I think with respect to process of
Ivan_Herman: The only problem I have is that I like to have a certain level of consistency along among our own specs.
Ivan_Herman: And if we put ECDSA or EDDDSA keys the key definition the expression for them into the CI then why are we doing something different here? I mean that's all.
Manu_Sporny: Yeah. the reason…
Ivan_Herman: So why did we put it let's put it this way.
Ivan_Herman: Why did we put it into the CD spec in the first place?
Manu_Sporny: because there were objections to move into a separate document where we could have managed it better. That's why the SIDS spec exists because Mike, Jones objected to, this stuff going anywhere other than that specification. And so for political reasons, we put it in this document, but it should never have gone in this document. It should have been,…
Ivan_Herman: Yeah. But his objection potentially is valid for quantum safe as well,…
Manu_Sporny: …
Ivan_Herman: isn't it?
Manu_Sporny: it's not So, yes and…
Ivan_Herman: I agree.
Manu_Sporny: no. It would be if we would be better if we had a multi key specification and we had a registry where we put this stuff in, but that was objected So that was objected to and we put it in the SIDS spec because we had no other place to do it and there were all this political objections happening at the time. if we want to do this right, we would move multike key into their own specifications. they would have registries at W3C and then you register everything in the registries and then we would have the mechanism that you're talking about Ivon. It's just we don't have that right now and trying to do it in the current charter is questionable. and we wanted to make sure that people could create new data integrity crypto suites without having to go through W3C for every single one.
Ivan_Herman: I am Okay.
Manu_Sporny: which means that they should be able to publish their own key formats. They should be able to publish their own proof formats completely independently of W3C if they want to. I totally get your argument to let's make it consistent but in order to get that level of consistency and not get wrapped around W3C process you would either have to add it to SID which I don't think is a good idea. I think I'd object to doing that because it would centralize something that was never meant to be centralized. or we would move, the multike key stuff out into its own specification, establish a registry. And I don't know if, people want to take that on with everything else going on right now.
Ivan_Herman: I don't want to start a long argument on that. if I wanted to implement a general tool for multi key handling or whatever, then I would be unhappy that I have to find the key prefixes at 10 different places like this.
Greg_Bernstein: Yes.
Ivan_Herman: I mean that just sounds a bit crazy…
Ivan_Herman: but okay I won't it comes back to the political discussion about multi anything.
Manu_Sporny: Yeah. …
Manu_Sporny: technically all of them are in a central place. They're in the multicodc registry. So, there is one place you could go and find all of this stuff. It's a multicodc registry. But then, people objected that that thing existed at all. They wanted it in W3C or ITF. Yeah. Yep. Exactly.
Ivan_Herman: Okay,…
Manu_Sporny: Eventually it'll work itself out the next charter.
Ivan_Herman: give up. Okay.
Manu_Sporny: We'll fix it in the next charter
Greg_Bernstein: So I will add the secret key varants in the table.
PR 24 Approval And Merging
Greg_Bernstein: Now we have two outstanding. PR number 24 is support for efficient post quantum cryptography selective disclosure. It's early. Sorry.
Greg_Bernstein: Let's see if we're doing this right. changes were happened last week or before the approvals came last week, but there's only one approval. Do I need two? We used to require two or I do not know. We don't have that many reviewers right now.
Manu_Sporny: It would probably be good to get another review on this. one No,…
Greg_Bernstein: I wasn't sure…
Greg_Bernstein: if you meant to review this. I have for the other that included test factors which builds on this one. you reviewed it and approved it. So it includes that. So, I'm not sure if you just reviewed the whole thing as a set. Okay.
Manu_Sporny: I did not review this one. I mean, I don't want to hold it up either because if it's wrong, we will find out in implementations. And Dave did a review. and…
Manu_Sporny: I won't have time to review it this week.
Greg_Bernstein: Do I need to wait another week or…
Manu_Sporny: I'm going to do a blind approval here, Greg. just No, no, no.
Greg_Bernstein: Okay. Manu Sporny:
Manu_Sporny: It's been two weeks. we should just get it in the spec and…
Support for Efficient PQC Selective disclosure by Wind4Greg · Pull Request #24 · w3c/vc-di-quantum-resistant · GitHub
Greg_Bernstein: …
Manu_Sporny: then see if the implementation's, Yeah.
Greg_Bernstein: yeah, it same thing with you can't trust test vectors until somebody else confirms them. I consistently check them and such like that, but you can be self-consistently wrong, too. okay.
Greg_Bernstein: I can merge these now or I can merge these offline.
Manu_Sporny: Let's go ahead and Merge them now. Let's get them in.
Greg_Bernstein: Okay, You're going to remind me of the language.
Manu_Sporny: …
Greg_Bernstein: We have to use that language.
Manu_Sporny: this is normative.
Greg_Bernstein: I have it somewhere but not at my fingertips.
Manu_Sporny: I can type some stuff in. so this is a normative multiple light reviews.
Greg_Bernstein: Trans. …
Manu_Sporny: No objections, no changes, no objections emerging.
Greg_Bernstein: you're doing it. You can merge. Manu Sporny:
Manu_Sporny: I was just putting in the language. it's there above the squash and…
Greg_Bernstein: I don't get to see that. What?
Manu_Sporny: Although you can just rebase and merge. rebase.
Dave Longley: You got to scroll a little higher on the screen. There it is.
Greg_Bernstein: Sorry.
Greg_Bernstein: Normative, multiple light reviews, no changes, no objections, merge, squash and merge,
Manu_Sporny: You don't want to lose all your iterations probably. yeah, that you've got a branch merge in here. A rebase should fix that.
Greg_Bernstein: Should I take those comments and apply them to the
Greg_Bernstein: Should I add the comments? Normative, multiple reviews, no changes,…
Greg_Bernstein: no objections, merging. …
Manu_Sporny: these are not normative.
Manu_Sporny: They're test vectors. yeah.
Greg_Bernstein: non-normative then. inform. No,…
Manu_Sporny: Or you can say editorial. …
Greg_Bernstein: informative is the term we use,… Manu Sporny:
Manu_Sporny: yeah. Yep.
Greg_Bernstein: right? …
Manu_Sporny: Yep.
Greg_Bernstein: it's been a while. We were doing so many for a while though that How we can Oops.
Greg_Bernstein: Where is cannot be reef b no, we broke something.
Manu_Sporny: Yeah, you'll just have to rebase this PR and then merge it later. But they're approval you have the approvals to do it.
Greg_Bernstein: Okay, okay,…
Manu_Sporny: So you just need to rebase and do it at some other
Greg_Bernstein: plenty of time. I have not been working on the threat model at all. did you want to lead the threat model exercise?
Ivan_Herman: Before we go there,…
Wesley_Smith: I think it'll be good for you to lead it, but I think it's going to be easier than what you're expecting. So, basically, can you folks see the Google doc that was linked at the beginning of the call before you joined?
Greg_Bernstein: Need to see if I can grab the link and put it up.
Ivan_Herman: can I ask something? sorry. Money was ahead of me.
Ivan_Herman: Thank You are damn money you preceded me.
Wesley_Smith: Man, you are Yep.
Naming The Document For Publication
Manu_Sporny: Thank you. we need to publish a first public working draft, Greg, and we need to name the document, the short name, before we do that. So, we should do that today.
Greg_Bernstein: Yeah. Greg Bernstein:
Greg_Bernstein: Yeah. Yeah.
Manu_Sporny: I don't know,…
Greg_Bernstein: And we're going to have it.
Manu_Sporny: Ivonne, if that's the same thing you were gonna Sorry.
Ivan_Herman: This is exactly what I wanted to ask. Manu Sporny:
<Dave Longley> Data Integrity Threat Model Brainstorming Template - Google Docs
Manu_Sporny: Sorry, Ivon. So we should cover that before we get into threat model.
Ivan_Herman: Yeah, we should get this published as soon as possible.
Manu_Sporny: Okay. So for that we need to pick a short name. I think it's going to be, something. quantum safe is not super great because you're not particularly safe when it comes to cryptography.
Greg_Bernstein: Where rest?
Manu_Sporny: So we should pick a name that works. postquantums. go ahead.
Wesley_Smith: I'm just curious if there's the various efforts to standardize and look into a lot of the technologies that are in this spec through NIST and other people. any useful descriptions in those efforts for the set of things that we're trying to describe Yeah.
Manu_Sporny: Unfortunately, no. I mean, we could do postquantum digital signature algorithm, to follow ECDSA and EDDDSA. each one though is broken into the short names we picked were MLDDSA and SLHDSA and things like that. we could do PQ for postquantum, VCDI,
FPWD
Greg_Bernstein: move on.
Manu_Sporny: PQ, or we could do BCDI quantum. These are all options. I don't know if anyone has strong feelings on any of them. go ahead, Avon.
Ivan_Herman: I try to be in line with the other documents that we already have in the same family.
Ivan_Herman: And yes, we say eddsa but in fact for example that one defines I am not sure I don't remember how many three or four different crypto suites which we may even extend because of barcode. So that by itself is not a problem for me. So PQ crypto suit is a bit cryptic but this is cryptography so that should be okay. Pick your crypto suits.
Manu_Sporny: So, you're saying PQ DSA or just PQ?
Ivan_Herman: Isn't it how the …
Manu_Sporny: No, we don't name any of the other ones. Cryptosweet. …
Ivan_Herman: that's so true.
Greg_Bernstein: Okay.
Ivan_Herman: Data integrity BBS crypto suites. That's the title of the document.
Manu_Sporny: no. I'm talking about the short name Aon,…
Ivan_Herman: …
Manu_Sporny: right? Because…
Ivan_Herman: I'm sorry.
Manu_Sporny: because the title doesn't matter,…
Ivan_Herman: We will have to discuss the title as well,…
Manu_Sporny: we can Yeah, that's right.
Ivan_Herman: but you're then it's VC PQ or something like that. What's the short name for the other ones? I don't remember from the top of my head. Let's say ECDs. Yeah.
Manu_Sporny: Yeah, it's just ECDSADSA. okay.
Ivan_Herman: is of ECDI PQ and I don't know if you want to have a version number because ECDSA says blah blah blah 1.1
Manu_Sporny: Do we want just then Dave's also suggesting BCDI postquantum
Wesley_Smith: I would argue that if we need to have quantum in the name quantum resistant is better than postquantum the entire rest of human history will be postquantum.
Manu_Sporny: I do agree with that and I do like quantum resistant 1.0,…
Ivan_Herman: What about the version number?
Manu_Sporny: right? Yes.
<Dave Longley> vc-di-pqc
Ivan_Herman: You tell me.
<Dave Longley> vc-di-post-quantum
Manu_Sporny: So Ivonne, I think we're going to have the version list thing redirect to the latest version and…
Manu_Sporny: then we're going to have a 10. Is that the plan?
Ivan_Herman: I'm just track testing…
Ivan_Herman: what we have for the current one.
<Dave Longley> vc-di-pq
Manu_Sporny: I think that's what we have for the current one where we have the version list thing just redirect to the latest version and…
<Wesley_Smith> vc-di-quantum-resistant is better IMO
Ivan_Herman: Let me see. I will just try it.
Manu_Sporny: we have a
Ivan_Herman: Wait one minute. Exactly. Yes, we have the VCDSA without anything else.
Ivan_Herman: which redirects to 1.0 actually not one to one because 1.1 is a working draft. So it redirects to the latest recommendation to be very precise.
Manu_Sporny: All right. So then that…
Ivan_Herman: That was
Manu_Sporny: then that would mean that the would be short name redirect VCDI quantum resistant like Wes mentioned. and then the versioned short name would be 1.0
Manu_Sporny: O and then the title would be hold on one second let me see DSA I'm trying to remember what we use for our current ones it would be quantum resistant crypto suites and then the subtitle would be crypto suites for data integrity. maybe data integrity quantum resistant crypto suites.
Manu_Sporny: So, I just typed something so that and…
Manu_Sporny: I don't know longly if you're argue. never mind. You're joking. I think D.
Ivan_Herman: Except that there's a spelling mistake in the subtitle.
Ivan_Herman: Although that's No.
Manu_Sporny: Yeah. Gertie inter gerty. I'll fix that. Okay, that's all right.
Ivan_Herman: Sorry. Let's put that one plus one as well.
Manu_Sporny: So, we need to do a proposal as well? Is that right?
Ivan_Herman: The formal proposal should be done on the working group anyway.
Manu_Sporny: Poll. Yeah. So Paul published the quantum resistant crypto suites version 1.0 specification with a short name of BCDI quantum resistant.
Manu_Sporny: Ivon, or do we need to include that? Okay, so publish the qant crypto suites version 1.0 specification with the short name of BCDI quantum resistant 10. Is that good enough? I'm not putting in the URL because we're going to change the URL because we're changing the short name.
Ivan_Herman: No heat.
Manu_Sporny: Does that work for you, Ivon? …
<Manu_Sporny> Short name redirect: vc-di-quantum-resistant
Ivan_Herman: Say it again.
Manu_Sporny: I'm not going to put the URL in the poll because we're going to change the All right,…
<Dave Longley> +1
Ivan_Herman: No, it's not important. The final poll is on the working group anyway. This is not a formal thing. Money. Yeah,…
Manu_Sporny: we go. So, there's the poll and then we can plus one minus one at least among us.
<Wesley_Smith> +1
Ivan_Herman: I am not chair.
<Greg_Bernstein> +1
Ivan_Herman: Thanks So I don't know whether it will be taken up this week but I presume to be realistic money the document will be in a publishable format after the face to face right there is no reason to rush.
<Ivan_Herman> +1
Manu_Sporny: Yeah, that's right. I don't think we need to rush it.
<Manu_Sporny> +1
Ivan_Herman: No, no,…
Manu_Sporny: U Yeah.
Ivan_Herman: no. I don't want to rush. I mean, Friday is my free day anyway. Then travel and whatever. That's all right.
Manu_Sporny: Yep. Yeah. I think we'll publish, second or third week of June, I think.
<Parth_Bhatt> +1
Ivan_Herman: Last question which does come up and this is the last moment where we can make this change.
Ivan_Herman: Namely, the change in the repository name or do we want to keep it as it is?
Ivan_Herman: Leave it as it is.
Manu_Sporny: We should change it.
Manu_Sporny: I think we should change it. and I could change it right now. So this would be resistant. It's thinking long and hard about it. repo name is changed and the publish location is changed and the document shows up at the new location now.
Manu_Sporny: So, we just Greg or I just need to go in and change the short name and title of the specification.
Ivan_Herman: and…
Ivan_Herman: label it as a working draft and not a community report with all that it means and…
<Manu_Sporny> POLL: Publish the Quantum Resistant Cryptosuites v1.0 specification with a shortname of vc-di-quantum-resistant-1.0.
Manu_Sporny: Yeah. That's right. Yep. Yep.
<Manu_Sporny> +1
<Wesley_Smith> +1
Ivan_Herman: the editor should be reduced to those who are member of the group. Don't forget that that's been will money rag I presume the two are not members of the working group etc.
<Ivan_Herman> +1
<Dave Longley> +1
Manu_Sporny: Yep. Yep. Yep. Yep. Yep. Yep. Yep. Yep.
<Greg_Bernstein> +1
<Parth_Bhatt> +1
Ivan_Herman: So the whole header is the one which has to be changed pretty well you may want to up I don't know whether you want to keep the related specifications to the 2.0 for the VCDM and etc.
Manu_Sporny: Let's see.
Ivan_Herman: I leave that to you. But all of them now have a 1.1 for a working draft. the PBS doesn't have that.
Ivan_Herman: But all the others I think have been upgraded to working drafts or…
Manu_Sporny: Yeah, I'll try to Yeah,…
Manu_Sporny: we can update that. I'm actually at Yep.
Ivan_Herman: use the versionless versions so to say if you…
Manu_Sporny: Yep.
Ivan_Herman: if you see what I mean.
Manu_Sporny: Yeah. …
Manu_Sporny: is there a dash between quantum and resistant or…
Ivan_Herman: That to English people.
Manu_Sporny: not in the title?
Manu_Sporny: Quantum dash resistant. Is that the correct? Yes. What's the proper?
<Manu_Sporny> Quantum-Resistant Cryptosuites v1.0
Wesley_Smith: Are you asking should there be or…
Wesley_Smith: Yes. And
Manu_Sporny: All right. Thank you see Yeah. I'm leaving that to English people as well.
Ivan_Herman: I presume all the other things respect will take care of
Manu_Sporny: So yeah, it should I'm making the changes right now. Asant sweets or Okay, I think resistant. Sorry, I'm
Manu_Sporny: All right, Greg. I think we can probably move on to the threat model at this point. I think will
Wesley_Smith: All right, Greg. So, what we're going to want to do is you're going to have people go to the linked Google doc and then give people five or 10 minutes or maybe the rest of the call depending. We're almost out of time to basically brainstorm ideas and drop them in section 4 for what are the various threats and then we're probably going to want to take some time I guess during the face to face or during the next virtual meeting to then go through those things categorize them discuss them that sort of thing.
Wesley_Smith: But the first step here is just everybody goes to that document and drops ideas in section 4. Does that sound good? probably.
Ivan_Herman: Can you put the link to the document in the IRC or…
Ivan_Herman: I see That's what they've longly put there, right? Yeah.
Wesley_Smith: I
Wesley_Smith: I would argue that is a pretty strong starting point. I think we're also starting to duplicate some of the listed attacks. so Greg, we're almost out of time for today, but next steps basically are we just go through these one by one. and again this could be off the call potentially or in person meeting. and we categorize them according to the four previous definitions.
Wesley_Smith: target threats, implementation threats, external threats, and dependency threats. and dduplicate coales some related threats into
Greg_Bernstein: Okay.
Greg_Bernstein: Target threats.
Wesley_Smith: I am curious to see where we land on this one specifically because data integrity is a piece of a larger puzzle that touches a lot of other pieces and a lot of the things that are written here are the sort of dependency threat style attacks. but interested to see the final breakdown is of what threats are discussed in what documents and that sort of thing because it seems like what we have listed here is pretty broad and all of them are at least tangentially related to data integrity but not all of them are strongly related to data integrity.
Categorizing Data Integrity Threats
Manu_Sporny: Maybe we could start there. meaning let's figure out the dependency threats. So there four categories. There are target threats which are specifically threats that data integrity tries to address. and then implementation threats like people implementers if they include a specific if they include a specific feature that's optional they've got to handle that. rather the choice is made up to the implement on how to implement the feature.
Manu_Sporny: External threats are this is a threat but it's out of scope for this version of the specification or this spec does not deal with it and…
Wesley_Smith: such as sphere.
Manu_Sporny: then dependency sorry yeah yeah I don't is that a dependency threat or…
Wesley_Smith: I said such as Dyson sphere which is number 15 or something.
Manu_Sporny: an external threat and then the dependency threats are just like we inherit the problem meaning data integrity does not invent new cryptography new fundament mental like cryptography like ECDSA or MLDDSA and so any kind of for example cryptographic break on the underlying technology itself is an acknowledge threat but it's a dependency threat it's external to us like that's ITF's and CFRG's problem not ours as an example so maybe we want to start with the dependency threats because a lot of these I think are dependency or external threats very little of it I think is data integrity.
Manu_Sporny: Even stuff like I mean do we have canonicalization scheme in here Shen fails to wondering …
Greg_Bernstein: I'm just getting used to
Manu_Sporny: but for even canonicalization it's a dependency thread because we depend on RDFC or JCS which are external to this group. So, Greg, usually you would start going down the uncatategorized list and asking which category does it fall into?
Greg_Bernstein: this approach to modeling. if you see my notes below, my modeling of threats was always based on CIA triangle and who the different players were and so that's what I did. So depend and we're about out of time. I'm gonna have to study up on this a bit. Greg Bernstein:
Wesley_Smith: Yeah, that sounds good.
Manu_Sporny: Okay.
Wesley_Smith: I expect that what you've previously done and the threat modeling approaches you previously used are pretty compatible with what we're doing here. so sounds good.
Greg_Bernstein: All right.
Wesley_Smith: All right, thanks for the time those of you that will be in person or remotely attending the face toface next week, I will see you there. and others will see you after we return. thank you for the time and have a good rest of the Meeting ended after 01:01:10 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.