- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 28 Feb 2025 11:21:25 -0500
- To: W3C Credentials CG <public-credentials@w3.org>
Agenda: 1. Introductions 2. Post Quantum Cryptosuite Coordination 3. secp265k1 Schnorr Cryptosuite 4. BBS Status Update 5. Selective Redaction Organizer: Manu Sporny Scribe: Our Robot Overlords Present: Greg Bernstein, Manu Sporny, Hiroyuki Sano, Dave Longley, Patrick St-Louis, Will Abramson, Geun-Hyung, TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), Andrea Vesco, Alex Higuera Audio: https://meet.w3c-ccg.org/archives/w3c-ccg-data-integrity-2025-02-28.ogg Video: https://meet.w3c-ccg.org/archives/w3c-ccg-data-integrity-2025-02-28.mp4 Our Robot Overlords are scribing. Topic: Introductions Manu Sporny: Hi Andrea Vesco, good to see you we're just getting the meeting started. Manu Sporny: All right welcome everyone this is the data Integrity meeting that we have every Friday it's largely just a meeting to make sure that work can continue to proceed and people can get their answers or their questions answered and we can collaborate on whatever we need to we had a good turnout last week a good good you know number of people showing up this week just as a reminder to everyone we have an open Agenda in these calls just bring whatever your latest issues are to the group if you want feedback from the group just ask questions and we'll provide feedback and then we end the call as quickly as we run out of questions or concerns we try to keep these ones fairly quick to like 30 minutes but you know if they take a whole hour they take a whole hour it's fine okay we did go around and did some we did some introductions last. Manu Sporny: Do you mind giving an introduction I think everyone got to introduce themselves but but you last time so would love to hear back around on on you Andrea. Andrea_Vesco: Work for links foundation, work on post quantum stuff - presented my work to CCG, very interested in going forward with transition of overall framework to PQ. Topic: Post Quantum Cryptosuite Coordination Manu Sporny: Wonderful welcome welcome to the group Andre and so let's let's spend a little bit of time talking about that on the call today we were your you have some other colleagues from Italy and the Netherlands that we're talking about post-quantum last week as well so that's another Andre from dine in Fork bomb and they're currently working on the post-quantum cryptography Suite and making good progress I think that's certainly 1 of the items we want to support in the group and move that forward we need to incubate that a little bit more here that specification a little bit more here before we take it on the standards track the global standards track at the worldwide Web Consortium so as soon as we're finished incubating that specification we can put it into the next Charter for w3c we are expecting that next Charter to probably be proposed in you know. Manu Sporny: A month a month or 2 maybe 3 months at at most so it's important that we align the work that you're doing Andrea with the work that the other other folks are doing on post-quantum cryptography. Manu Sporny: With that said are you let's see a couple of questions Andre are you aware of the post-quantum crypto Suite that's being worked on in the credentials community group. Manu Sporny: Yet okay and okay great and then are you. Manu Sporny: I guess are you planning to contribute or a kind of join that work or are you suggesting a different kind of post-quantum crypto Suite that we should talk about like for example post-quantum for unlink disclosure post-quantum for Selective disclosure ZK Starks or ZK Stark you know based approaches what are your what are your desires to kind of collaborate with the group. Manu Sporny: Andrea_Vesco_(LINKS): Regarding plain text, did easiest exercise - pure post quantum -- simple and can analyze algorithm there - ML-DSA - easy to replace. What can be useful during this period for waiting for real Quantum Computer to be developed -- combine post quantum with traditional cryptography to reach post quantum hybrid approach -- combine two crypto in signature to ensure that if one is broken the other doesn't break. Andrea_Vesco: There is valid in addressing hybrid approach. Andrea_Vesco: For anonymous credentials, we've done some initial work, but there is lots of work to do at the cryptographic level, premature to think about standardization -- would like to keep everyone updated with the results we achieve in next months. Manu Sporny: Okay that sounds great. Manu Sporny: Uh okay so that that all sounds great Andre and is very much kind of I think where this group is on what work needs to be done and what work Need You Know needs to be kind of looked at in the future and everything so completely agree with your what what you believe you know that the next steps should probably be 1 thing that I wanted to make sure that you were aware of is that we already have uh a hybrid mechanism with the data Integrity work that we are working on so it is in the design the architectural design for the w3c data Integrity signatures we have these things called set signatures and chain signatures and it's a general architecture that allows you to do a hybrid signature not in the same signature uh Cipher text. Manu Sporny: But to put to. Manu Sporny: 2 Different signature. Manu Sporny: On a credential or on a a piece of data and have 1 of them use a traditional prequel like ecdsa eddsa or BBS signature and then in parallel you can do like an mlds or a stateless hash based signature or you know in the future Falcon based signature already so I think I I want to make sure because I I know that some of the work for example in. Manu Sporny: Cryptography approaches like you know Josie or cozy requires you to kind of mix both both the pre-qualify and post-quantum signatures together into the same Cipher text we don't require that for data Integrity we can have a a hybrid scheme where you can have a data blob and you can sign it with ecdsa and sign it with mlds for example in parallel and that's already done meaning the only thing that we need right now is a crypto Suite that does mlds or the satellites hash based stuff or falcon or maybe in the future the isogen things does that make sense I don't know if you were aware that we had already done that work or if you mean something different by hybrid. Manu Sporny: Yeah yeah let me let me find that let me see data Integrity. Manu Sporny: https://w3c.github.io/vc-data-integrity/#proof-sets Manu Sporny: And they're already multiple implementations of this and multiple implementations that are going standards track on this so I'm going to put a link in the chat channel here. Manu Sporny: Uh these are set signatures proof sets. Manu Sporny: And then. Manu Sporny: https://w3c.github.io/vc-data-integrity/#proof-chains Manu Sporny: And proof chains I I'm more I'm pretty I'm talking about proof sets largely here proof chains are where you just link the cryptographic proofs together where 1 signature is done before the other 1 and the the latter signature refers to the the the former 1 but that's the current work and that is that we are expecting this to become a global standard in April of this year. Manu Sporny: So very interested in your thoughts on that and if you think that that covers the hybrid mechanism that you're you know speaking to. Manu Sporny: And we know. Manu Sporny: There's also you know hybrid hybrid. Manu Sporny: Uh hybrid encryption schemes post-quantum you know doing traditional pre Quantum and post-quantum things that's not what we're talking about here we're just talking about digital signature schemes not encryption hybrid encryption schemes. Manu Sporny: All right so just wanted to make sure you were aware of the that that work and that's good news like I mean we think we are already done there the only thing we need is you know a standardized mlds a uh stateless hash you know DSA mechanism. Manu Sporny: Um did I miss anything did anybody in kind of my explanation to to Andre did I did the did the group hear me miss anything and something important to know. Manu Sporny: Go ahead there. Dave Longley: Um well the only thing I would say is just in your last comment you said the only thing we need is mlds but I think we're also looking eventually of course for unlikable signatures as well and then we might still we would need to do some analysis on it but it seems like we might still be able to use the same hybrid approach if we have 2 different proofs. Dave Longley: Um on the same reveal document with a post-quantum on linkable signature and a BBS signature. Manu Sporny: Mhm yeah go ahead Greg. Greg Bernstein: To see elaborated examples of proof sets and chains with a specific crypto Suite look at the VC data Integrity EDD DSA crypto Suite. Greg Bernstein: Did not repeat detailed examples in both the ecdsa Neds so I put a pretty elaborate examples of both proof set and proof chain. Greg Bernstein: In the eddsa crypto Suite. Manu Sporny: https://w3c.github.io/vc-di-eddsa/#proof-set Greg Bernstein: The mechanisms are saying but that shows you like getting down to like here's signatures here's where we use multiples Etc so that's a good place to go the only other thing I was going to say I wasn't sure who's leading the. Greg Bernstein: Effort at the ccg on mlds Save but. Greg Bernstein: I am happy to help generate. Greg Bernstein: Chest vectors like we did in the other crypto Suites I was the guy who did that my implementation is open source it's not a production level quality it's good for generating test vectors so if you need help or you want me to try verifying yours I did notice that the libraries I use just added the mlds a so got some post-quantum that's easy for me to plug in. Greg Bernstein: So just let me know if you have any questions about how I did those tests vectors and the process with the. Greg Bernstein: We generate separate files Json files for data and then we pull them in you don't have to like. Greg Bernstein: Up the text into the document there's a nice respect feature for that. Manu Sporny: Yeah plus 1 to that Greg I just put that link into the chat Channel as well the the link to the eddsa I'll I'll I'll put it in again because it kind of scrolled away 1 second. Manu Sporny: https://w3c.github.io/vc-di-eddsa/#proof-set Manu Sporny: Um and yeah Greg I think that would be super helpful to Andrea from dying in Fort bomb for the you to do the same kind of generation of text test test vectors it would we would get immediately we would get 2 independent implementations which is what we need for Global standards track and then an explanation of it would be would be great as well. Manu Sporny: And then I think we also need to build it into respect VC the thing that auto-generates this so you know we have this tooling that can autogenerate the digital signatures and the specifications so that people can see what it what it looks like so we might want to add that support into respect VC as well Let me let me get a people are probably not familiar with. Manu Sporny: Uh let's see. Manu Sporny: https://github.com/w3c/respec-vc/?tab=readme-ov-file#verifiable-credentials-for-respec Manu Sporny: So there are these tabs I'm going to put another Link in here there are these tabs that we can create in the specifications that will autogenerate different types of digital signatures and so we definitely need ones for mlds and. Manu Sporny: Sash and Falcon and time sorry well you've been on the Queue I'll go ahead. Will Abramson: Uh yeah thanks I I just wanted to ask Greg really I mean because this is kind of what I'm saying in my attention too for the small signatures and I saw your email was very helpful but I don't think you shared the get like it seems like you're saying you have like a a GitHub repo open source with a script that generates a test affect. Will Abramson: Essentially are all I have to do right is swap out the signature algorithm. Greg Bernstein: Okay let me go let me get the other link I also have a resource page on my website where I put like my presentations and things like that so let me. Greg Bernstein: Let me get that let me drop that in. Will Abramson: Because I saw like I mean I think how you've done the test vectors right on these you know there's a a file with test vectors and a bunch of different data objects in there I think that's great like I want to do that furthermore it's very useful. Manu Sporny: All right as soon as Greg puts that into the. Greg Bernstein: https://www.grotto-networking.com/VerifiableCredentials.html Manu Sporny: Move on to the next thing will which is you know if you wanted to if you wanted there we there we go There's the link from. Greg Bernstein: That has presentations and at the end it has all the different open source repos. Greg Bernstein: I even did a test server just I mean it is not optimized its kind of pluggable where I did each different 1 independently. Greg Bernstein: I am not competing with anybody I'm just want to make sure we can. Greg Bernstein: I used to teach cyber security and web development. Manu Sporny: Yeah in the test vectors are super helpful that Greg put together because not only are their test vectors he walks through every single step of the process so that anyone doing an implementation can go step by step to make sure they're generating the the proper values. Manu Sporny: It's been a huge huge help to the implementers. Manu Sporny: So thank you Greg for doing that work. Topic: secp265k1 Schnorr Cryptosuite Manu Sporny: Okay let's move on to the next topic which is well if you want to this is kind of your time to talk about the SEC p26 K1 schnoor crypto Suite you know goals are with it what timeline you want what's your hoping to get feedback on that stuff. Will Abramson: https://dcdpr.github.io/data-integrity-schnorr-secp256k1/ Will Abramson: Yeah I mean I can speak a bit I think. Will Abramson: You know this is the spec if people haven't seen it I I like the timeline at some point I get round to it I mean I really would like another editor right but I want to move it over to. Will Abramson: The ccg work item it's not there yet. Will Abramson: I think. Will Abramson: Think it's pretty close to being. Will Abramson: I have spoke to like Ryan and some folks from DCd and I think we'll rename it like you suggested mano to we'll use like bip 340 so like bip 340 Dash rdfc. Will Abramson: -2025 For example. Will Abramson: I think that's much shorter and it's also very clear what it is if you're in the kind world. Will Abramson: Uh there are a couple of things I would like to talk about in this like 1 is the multi key stuff I know we talked about that a bit last week uh. Will Abramson: But I think like so in this specification like using schnoor signatures you only need to use like X only public keys. Will Abramson: Um so like as an EXO and we set P 256 K1 for the key really the difference is that it's just dropped like the first bite because. Will Abramson: In the in a compressed public key right the first bite says whether it's like a positive or minus on the why I think right. Will Abramson: Um so it's a different key type and wondering and I have defined a new value I kind of just arbitrarily picked that value wondering if that's okay or if people think I should. Will Abramson: Just use use the compressed version I kind of didn't want to do that because I I thought then you know really this key is clearly should only be used for generating snore or if you use the compressor 1 then it's possible to do ecdsa Andel. Manu Sporny: Yeah that's a good question my my gut says just reuse the existing format the the problem is that what 1 thing that we've tried to do is to take the parameters of the signature from the key and not just presume the parameters and then just read in the key value and presume parameters about the key it can lead to like their number of like hoses vulnerability hoses and cozy vulnerabilities that like don't use the key to set the parameters and as a result you end up. Manu Sporny: Feeding it. Manu Sporny: Junkies to assigning process and then you have a you know security vulnerability so we've been trying to use the the keys to drive some of the parameter um choices that said for this 1 and definitely would love to hear from others in the group. Manu Sporny: It feels like what you're saying it has has some consideration will like you know if these are supposed to if these keys are only supposed to be used to generate snore signatures and and nothing else then maybe it does warrant a new key type the problem of course being that the like the only difference is kind of the the. Manu Sporny: Uh the header well so they're they're they're actually 3 choices here right 1 of them is just reuse the existing multi key. Manu Sporny: Value the second 1 is don't reuse the existing multi key value and create a different format that really only differs in 1 bite which is you know it it doesn't doesn't have. Manu Sporny: Uh the the leading bite for the you know the the . Manu Sporny: I guess it's a sign like positive negative or or yeah yeah and then and then the third option is reuse the same key format so just reuse the SEC p26 K1 key format because that's widely you know widely implemented and used but just change the bite header to say this is this is a this is a very specific type of sect p26 K1 key it is totally you know it's the the format for the keys the same but the bite header tells you that this key should only be used for shanar signatures or you know bit well I don't know what number you you mentioned but you know only for those so those seem to be the 3 choices I don't know if there are others and if I don't I you know and if if you feel very strongly about like no we really do want to lock these Keys down so that they're only used for schnorr signatures then I would imagine that third choice where you. Manu Sporny: I know that. Will Abramson: Yeah that's great I mean I don't feel that strongly I just I mean firstly I didn't realize there was a sec 256 K1 multi so I'm not saying I already defined. Will Abramson: That is the easiest option I'll bring this up with sort of folks and see what they think because I don't really mind and it is easier to just say what we're using this multi key and everyone knows what it is. Manu Sporny: Yeah and so and so so I I think then what that means is that just reuse the existing key format so you don't have to create yet a new key format that just differs in 1 bite but but the the question about the header. Manu Sporny: Multi key header on that whether it's a snore only. Manu Sporny: Or just a generic key I think that probably matters Dave Longley do you have any particular like thoughts about 1 versus the other it feels like the second 1's safer thing if we're going to derive some you know parameters off of the off of the key go ahead. Dave Longley: So I would choose between the existing multi-key sep 256 K1 option or making a new Option with a new header 1 of the advantages of a new Option with a new header is there's less there are fewer checks to do. Dave Longley: It sounds like. Dave Longley: Uh if if you get 1 of these in I well I guess what you end up doing is just ignoring a particular bite if. Dave Longley: For the. Dave Longley: Scheme because you just don't use that bite or does it have. Will Abramson: Uh this game says it's always this way so it picks 1. Dave Longley: Right and so that means you could get an invalid key in with a bite that's in the other direction and you would have to reject that as opposed is that right. Will Abramson: Sure I think maybe you could just slip it is that yeah I don't know it's kind of weird you could. Dave Longley: Yeah it it sounds well yeah I would think you would want. Dave Longley: So I I from my view you have 2 choices you have if we make this we either make implementers have to write some new key code. Dave Longley: Um and then that's the disadvantage of having a new key format and not just being able to reuse it. Dave Longley: The the advantage of having the new key code is that it's really clear what these keys are for and that no 1 has made a mistake for example if they hand you a key that has that extra bite because you could just decide know you've made a mistake there's a configuration error here and so that kind of becomes a question around how often or would you think that's a problem how much how much value do we get out of it and how much value do we get out of not telling implementers for this specific crypto Suite to not have to deal with that particular bite and they just throw things out if they get the wrong length for example th those would be the considerations it's really nice to have something that's really specific to what you're trying to do and it would it would apply to any other store signatures anywhere else I would expect not just necessarily the scheme. Dave Longley: But that's counterbalanced with the do we just want to reuse what's already out there that people have already been working with and we've got some special checks on it. Dave Longley: And that those those are those are reasonable trade-offs to have to consider. Will Abramson: Great yeah I'll I'll raise this with some other folks and see what we want to do I mean. Will Abramson: https://dcdpr.github.io/data-integrity-schnorr-secp256k1/#proof-serialization-schnorr-secp256k1-rdfc-2025 Will Abramson: Great and then I have 1 last thing to talk about about this spec and that is the proof serialization algorithm in this so I I I mean I guess most people know but I copied this from I think eddsa. Will Abramson: And I I think the only real thing I tweaked is in the proof serialization uh. Will Abramson: Ah okay no sorry it's in the. Will Abramson: In the. Will Abramson: Basically what I've done is I've like concatenated the data that I'm hashing so yeah it's in the hashing Step 1 like bites the hashes the result of concatenating like the 2 things so. Will Abramson: I basically I want to sign only 32 bytes whereas I think in the eddsa. Will Abramson: It was sign it was congas the hashes so it was signing 64 bytes right so it was like doing individual hashes of each of the. Will Abramson: Proof config and the document and then concatenate them and signing them. Will Abramson: I just want you know like I I I don't actually know if this is a a dependency on snore but it was a dependency on on the library that I was using maybe it used to be a dependency on bit 340 but it could only sign like 32 bytes 2.56 bits. Will Abramson: You know and you can Chuck it I I just wonder if I think that as a concern here or like if it's just a different approach I don't think there was a problem. Manu Sporny: No no there's a big problem you you're not securing the the proof options it would lead to a vulnerability I think you you need to. Will Abramson: But no no I am secure in the proof options. Manu Sporny: Oh you are you said you're not you said you're you're signing the first 32 and not the second or. Will Abramson: No no I I am I'm concatenate so like I canonicalize the proof options I canonicalize the document I concatenate those 2 things together and then I do 1 hash of that concatenated thing. Manu Sporny: Oh yeah that's yeah that's that that should be okay yeah I think that's that's fine alright Dave go ahead. Dave Longley: Know I would say that still there's still a possibility for a problem there if you don't have a a delimiter of some kind you you need a delimiter that does not appear in the format the canonical format so that you there's no consideration there's no concern that the first canonicalize thing could where the you need to be able to know specifically where the barrier where the end point is for that first canonicalization so you need a character that doesn't appear in either 1 of those to clearly delineate where that separation is otherwise you could have a confusion attack where the sum statement that's in whatever you have as a in the first place could actually be in the second place so the an attacker could move could move statements around and draw that delimiter wherever they want to because the the the thing that you'd be signing would look the same either way hopefully that makes. Will Abramson: Kind of let's see what Greg has to say Greg. Dave Longley: So so if you well just quickly if you had like the string ABCD and you assumed you took ab and concatenated it with CD and attacker could change that to ABC concatenated with d. Will Abramson: Yeah I guess I wonder if that's like because of like the the format of these proof configs and stuff you're already doing a bunch of. Dave Longley: Yeah you just want to make sure that you prove that that's not an not a possible attack with whatever approach you take. Greg Bernstein: So I don't know where the master like references on this. Greg Bernstein: But when I was. Greg Bernstein: With the BBS work in on the specs there I started noticing every time they were doing like these. Greg Bernstein: Things were. Greg Bernstein: Use the hash function as part of Fiat Shamir they would always add in these delimiters sometimes they were a length thing some other cases they were domain separation tags so. Greg Bernstein: I'm not sure where the like the master you know paper that said this is how you fix this kind of OB you know reversing changing the order of confusion error is but you'll see that in a lot of the specs maybe the hashes the curve spec might be a good place to look sorry go ahead. Manu Sporny: Yeah I guess like it's so just to make sure I'm understanding what's being said What will is doing with taking a final hash is fine it's just before the input to that hash function needs to make sure that there's a delimiter between the. Manu Sporny: Hash value and the proof options hash value. Will Abramson: Yeah okay that that's great I mean maybe 1 thing I need to do is like look again and maybe I can just copy what you guys did and. Will Abramson: Sign the 64 bites. Will Abramson: I mean I guess another. Dave Longley: Yes so I just want to I want to clarify because Mona you just called them hash values that is what the the other specs are doing and you know that they're hash values of a of a very specific length but what I was hearing will was that you're trying to avoid those extra hashes or something. Will Abramson: Uh yeah well I mean it's just I was trying to force the thing that's getting signed to be 32 bytes so the way I did that which is what I think we're saying is wrong is like concatenate the 2 conical objects and did 1 hash over the concatenation. Will Abramson: So yeah. Will Abramson: There is this concatenation that doesn't potentially have a separation which could have some confusion. Dave Longley: Yeah so I'm now this this might be this might be Overkill but it might be Overkill but it's actually really already what's EC DSA with ecdsa does which is you hash the. Dave Longley: Uh canonicalize proof document you hash the canonical document and then uh. Dave Longley: That gets fed into ecdsa uh. Dave Longley: If if it gets fed in directly it's just going to be hashed because ecdsa requires a hash over that too because it only signs a certain device. Will Abramson: So maybe that's. Dave Longley: And so you're either going to be doing that externally or internally with whatever you're doing so the you have options to move around there just just don't squish those 2 things together with in a way that they could an attacker can move it. Will Abramson: Yeah yeah okay that's great I'll tweet that back then I think I think that's good nice no. Manu Sporny: Yeah I'm I'm still confused because Dave I think what you just said is what will said he was originally doing meaning meaning you're taking 2 hashes are you the I guess. Manu Sporny: Oh yeah. Will Abramson: No no I'm just taking 1 hash. Manu Sporny: That's not good. Will Abramson: 1 Hash just a concatenation of the 2 can cause documents. Dave Longley: Yeah and that's not okay. Manu Sporny: Oh no that yeah right exactly so so what but if you but if you know that but if you in if you ensure that both values are 32 byte values then you don't need a delimiter. Will Abramson: Yeah but I would do that by hashing the concatenate the individually concatenate things right and then. Will Abramson: Which is what what the algorithm was that I changed so I'll change that back I think and I think you're right like schnoor signing algorithms you know if people are going to use it and you feed in too much data then it's probably just going to Hash over again. Manu Sporny: Yeah well I I think we let's let's take a look at the spec texts that you land on well and then. Will Abramson: Okay yeah great. Manu Sporny: Will all be on the on the same page. Will Abramson: Uh yeah and that's all I've got I mean apart from that I guess the only other thing that needs to work in the spec is like running up some security considerations I just deleted all the ones that CDs. Manu Sporny: There's there's another thing well that I think would be really nice to see and that has to do with the whole multi-sig stuff like that's 1 of the things that you're doing here that's like of I think of great interest to the to the the the group generally is is what exactly do multi sex look like I know that the signature is just it looks like everything else right but it would be really good for there to be a section in the spec that speaks at length about how this supports multi-sig and how you potentially set up for a multi-sig and how you do a multi-sig and then you can just say oh verifications just looks like everything else right but you know without that the you know there's not much different from this spec and the other specs meaning like it's just using K1 and that's that's the only Delta right. Will Abramson: Can write a section about multi I mean you know the question is like how detailed do you go for like you know to coordinate a multi you need to you need to like send a bunch of messages back and forth between the designers uh. Manu Sporny: Yeah and I don't think you need to I don't think you need to detail the protocol you just say effectively what the protocol needs to achieve and and then you know once you achieve that with the protocol these are the inputs to the signature function this is how the generation looks and this is what the end value you know looks like I think having a having a walkthrough of what that looks like would be our first demonstration of we actually got multi-sig you know in in 1 of these cryptos Suites. Will Abramson: Okay great yeah I'll look into that correct. Greg Bernstein: Uh what we did in data integrity and. Greg Bernstein: BBS is we made. Greg Bernstein: Extra informative sections to elaborate on this stuff or in appendix and so that takes the heat off of it's not a normative piece of text but people really find it helpful alright so I did an extra in appendix on proof sets and proof chains this is separate than the test Vector detailed stuff and over on if you look at BBS these optional features. Greg Bernstein: Trying to provide some explanation of them and it's informative text. Greg Bernstein: You can just it's okay for it to be a tutorial ish it doesn't have to be as complete and you can just state that you know this is the the concepts across you're not specking a protocol but I loved it when I read stuff like that when I'm trying to figure out why should I use this. Will Abramson: Okay yeah great I'll try. Will Abramson: That should be fine. Manu Sporny: All right all right anything else you wanted to cover today well. Will Abramson: No no that was everything. Topic: BBS Status Update Manu Sporny: Okay I do want to cover some of the BBS stuff BBS status update. Greg Bernstein: https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures Manu Sporny: So Greg maybe you could give kind of a a quick overview of what the next couple of months look like with with BBs just a short 1 and then I want to talk a bit about coordination with the security group at w3c and ITF CFR review and and that sort of thing. Greg Bernstein: https://github.com/cfrg/draft-irtf-cfrg-bbs-pseudonyms Greg Bernstein: I don't know if I put this onto. Greg Bernstein: Ccg list we have official repos now for. Greg Bernstein: The option drafts so this is known as blind signature which we use for the feature known as holder binding this allows. Greg Bernstein: The holder additional security that they must know. Greg Bernstein: Secret value that gets bound. Greg Bernstein: To the signature so that only they can use it this is not to. Greg Bernstein: This doesn't prevent abuse of the signature there's another 1 that we added in which is pseudonyms okay and that's another Nifty way to. Greg Bernstein: Anything from your revisiting a website but they don't really need to know who you are exactly to more General proof of personhood type stuff. Greg Bernstein: So we have those 2 specs the optional feature section is just be been Rewritten and VC Dibbs so using that and we're moving these specs along at the ietf their official working group documents. Greg Bernstein: For those. Greg Bernstein: That are implementing we just added. Greg Bernstein: And you can get them at those repos test vectors official test semesters I've I generated them and Dave is I think has this independent in implementation that's verified them so we're putting them in more folks to check those if you have problems with any of that stuff so. Greg Bernstein: Here's what. Greg Bernstein: It looks like. Greg Bernstein: Um I am waiting eagerly to get the. Greg Bernstein: My the prime author on those facilis Gallows very good Greek mathematician is putting the finishing touches on those we will publish an update to those drafts and presents at the ietf. Greg Bernstein: That should be. Greg Bernstein: Pretty much the end of putting with the external API. Greg Bernstein: If you've seen the BBS specs inside. Greg Bernstein: We Factor things and there's like internal functions that you don't need to organize that way but we've done it for a nice reuse across specs but you can implement. Greg Bernstein: However but so we were nailing down. Greg Bernstein: API and hopefully that won't change because. Greg Bernstein: Even through the standards process we've got working group documents if the API stable that means. Greg Bernstein: Vectors in the BBS spec at ccg. Greg Bernstein: Can finalize because these documents are on their way towards rfc's so that's you know the good news Okay want to get more folks to. Greg Bernstein: Implement and if you have any questions see us but. Greg Bernstein: We are trying to show what these API should look for like for Selective disclosure unlink credentials with a basic set of added features okay so even like the post. Greg Bernstein: I've seen some post-quantum papers. Greg Bernstein: Brought up like what we call holder binding they didn't include pseudonyms yet and so it's like hey no we want to complete solution this is what the API will look like I don't care if it's Chad traditional or post-quantum but this is what an anonymous credential with a a reasonably robust feature set looks like so that's where we're headed so that's why feedback on what the apis look like is great or if you don't understand what we're doing with these things. Greg Bernstein: Get a link to there's a Blog Post article we did with the div folks to explain pseudonyms a bit more. Greg Bernstein: And I am adding more explanatory texts that may not make it into this set of ietf. Dave Longley: https://blog.identity.foundation/cryptographic-pseudonyms/ Greg Bernstein: Rex but my co-author liked the idea of more explanatory texts too because we're tired of crypto. Greg Bernstein: Effects that don't explain what they're good for so sorry to make that long but that's where we're at aiming to nail down the API. Manu Sporny: Awesome thank you thank you Greg yeah and that and that's great so API locked down this month which means it'll be presented at ITF at the crypto form research group meeting which is also great and then implementations to be you know finalized shortly thereafter so there are 2 things we need from the community once that's put in place 1 of them is we need the community to engage with the w3c security group to do the broad the the wide scale review of BBS so the sooner that happens the better they are they have a pretty big backlog so we need to get on their schedule to make sure that they're able to to do the review in time we'll definitely need you there Greg we'll need Dave Longley there and we will need to pull in academics and researchers uh like on a mlynska. Manu Sporny: Who did enormous amounts of you know initial work on on BBS as well as people from the EU province of BC just Global academic community that can speak to you know the The Primitives we're using cryptographic Primitives that we're using and that that they work so 1 of them is engagement with the w3c security group I'll try to prompt that conversation get us on on their calendar maybe May time frame is. Manu Sporny: And then the other thing that needs to happen. Manu Sporny: There needs to be independent review submitted to the crypto Forum research group CFR so if any any of you know again BBS academics researchers the people that know the cryptography and depth we are looking for them to do a review on the ITF specifications and provide feedback and commentary to the group on whether they believe the mechanisms are secure or if they feel like there can be improvements to be made and and things of that nature. Manu Sporny: Okay I think that's it and we have definitely almost eaten up a whole hour any other items people want to cover before we and for the day. Manu Sporny: Go ahead Greg. Greg Bernstein: Just a quick question I saw that interesting discussion about selective. Greg Bernstein: Redaction and it seemed like it could make use of a lot of our. Topic: Selective Redaction Greg Bernstein: The mechanisms that we use for Selective disclosure not not the high level stuff but a lot of those Primitives seem reasonable have they contacted or mentioned that or I didn't know what what's going on there's like. Manu Sporny: We we've been in yeah we we've been in touch with Calvin and the the team in Singapore for you know a year and a half plus but there has been no analysis on reuse of Primitives they they can't they did The Selective redaction stuff kind of on their own we need to figure out if there are like selective disclosure Primitives that they could reuse from the the specs the question I had for this group on that specifically was what they're doing that there there's as a supply chain use case so the idea is that you start off with a a full-blown invoice so if you're shipping. Manu Sporny: Uh real quick if you're manufacturing Goods in the asia-pacific region and your shipping them to the the EU or the or North America or South America you start off with a big invoice of every single thing that's being requested to be manufactured all the parts all all the everything right. Manu Sporny: And that. Manu Sporny: Invoices sent from let's say you know North America to an asia-pacific region country and then there's a facility there that manufactures everything and builds everything and then it's put in boxes packed in shipped on a on like a a a ship a boat that comes back to North America and when when it comes back to to North America they want to know before it clears Customs they want to know who ordered the material from the United States who fulfilled the invoice who manufactured the goods in the Asia Pacific region so that they know whether or not those are known entities and and things like that they don't want to see every single line item that was manufactured in most cases and so what they need with Customs needs in North America is a. Manu Sporny: Is is they want. Manu Sporny: To see the invoice. Manu Sporny: But they kind of just want to see the companies on the invoice they in the amount of the invoice They Don't Really they don't want to see a line item for every single thing so the redaction thing allows someone to effectively cross out like you know use a a a black marker to Mark out every single item that was ordered without removing the the shipping and the and the receiving company in some times that needs to happen multiple times with more and more reduction or redaction as the invoices passed through the supply chain so it can go through 13 different companies where each 1 of those companies wants to redact more as it goes down the the line. Manu Sporny: So I don't know if ecdsa SD can just solve that use case and we don't need the redaction stuff or not I thought we did some kind of binding thing that made it impossible to do that but maybe not. Manu Sporny: So Dave is saying yes to a binding thing that makes it impossible to do that I'm thinking that's what the thumbs up means. Dave Longley: Uh know my well I'm not sure what you know my intuition is that. Dave Longley: Any binding you'd want to do with like I think you're referring to holder binding which I I still don't like that term but uh I think you're referring to what would happen in a presentation that and so that's separable it's an independent operation you don't have to you could put something in your credential that you would have to to bind to but it's not a requirement with the format so it seems like you could do. Manu Sporny: Okay so it's not a base requirement of ecdsa SD. Dave Longley: Yeah I don't believe it is. Manu Sporny: There's no cryptographic material that's that's passed on that would be dangerous. Greg Bernstein: The hmac key. Dave Longley: Uh yeah you might actually be right Greg. Greg Bernstein: But but what I was thinking was just. Greg Bernstein: Level properties of breaking. Greg Bernstein: Document into a set of statements and the mandatory disclosure kind of stuff and selective disclosure and some of those mechanisms I'm not you know because I mean this is very Json LD kind of stuff that. Greg Bernstein: Some folks here know a lot better than I but that seemed to be. Greg Bernstein: A bigger is harder part is getting the cryptography right you know the cryptographic operation so that's that was what was going I didn't see that piece in any of their proposals I was going well how are they breaking up the document of the pieces and so they can selectively redact. Greg Bernstein: So that was that was what I was looking for because we got some good Primitives. Manu Sporny: Yeah plus 1 to that but it's not a it's not a replacement for the redaction stuff is what I'm kind of hearing . Manu Sporny: We are at time we've got a we've got to end the call so we can go to other ones today did you want last word before we. Dave Longley: I was just going to say we could do someone else's on how the hmac key would impact these particular use cases because what it's used for might not be relevant or it might be. Manu Sporny: Okay meeting sharing the hmac he might not be a terrible thing. Manu Sporny: Right go ahead Greg. Manu Sporny: And then we really do have to go. Greg Bernstein: Sorry that was a thumbs up to Dave. Manu Sporny: Okay all right okay wonderful discussion as always thank you everyone for joining we will meet again next week and pick up whatever topics people want to talk about thanks all have a good weekend and we'll chat again next week.
Received on Friday, 28 February 2025 16:22:08 UTC