 Hello everyone, can you hear me well? Okay, great So it's a pleasure to be here. Thank you for the invitation I will be giving a perspective on standardization of advanced cryptography at NIST and that's the title indicates It's not the perspective. It's one perspective. I've been for two years at NIST So in one sense this may be a limited perspective because I don't know the full history of NIST But I also believe it's a fresh perspective With respect to things that are whose time has arrived now, namely advanced cryptography with respect to standardization Okay, here we go Since I'll be giving a perspective about NIST I want to start with an introduction About NIST and I'll be spending a little bit of time kind of explaining how the crypto group Fits within the NIST organization the kinds of standards that it does and kinds of activities that we do then I'll focus the main part of the presentation in giving an update on a threshold cryptography, which is one of our Current projects that arguably can be called advanced cryptography And then I'll try to extract some considerations about the standardization process Then I'll give a very brief Note on privacy enhancing cryptography because time doesn't allow much more and then I'll conclude with hopefully some interesting remarks Okay, so NIST has been around since 1901 so it is it's been around for more than a hundred years Previously known as the National Bureau of Standards It's a non regulatory federal agency with respect to standards and what that means is that We don't regulate how the standards are going to be used so for for the most part and for many stakeholders Standards are voluntary There may be other agencies that then mandate that some standards be used in some situations the Mission statement has a number of keywords innovation competitiveness We do measurement science sense standards and technology and we do these things when we try to Enhance economic security and improve our quality of life So if you think of things like for example privacy does privacy improve quality of life that made Enhance economic security if yes, then possibly privacy is one Would fit in this mission So this is an image of The NIST campus is about 1.5 miles just for an idea of perspective. We have about Between 6,000 and 7,000 Persons working there are two campuses in in the US and There's a wide range of competencies which is divided in in labs. So we have physics measurement science communication And the information technologies that's where cryptography fits and then Organizational we have these labs We're divided into divisions and then divisions are divided into groups and then each group has a bunch of Projects and essentially what we do is standards research and applications about the subjects Okay, so the crypto group is within the information technology lab Which basically deals with technology mathematics and statistics This is a little slower than I had in mind Okay And then we are within the computer security division that works with a number of things related to security including cryptographic technology But also software security risk management and security engineering and in particular for example also testing and validation which in some occasions works closely with crypto with respect to evaluating Cryptographic algorithms and cryptographic Modules and then finally we have the cryptographic technology group Where again, we have a number of keywords research develop engineer and produce guidelines recommendations and best practices And within the scope of this presentation. This is what I will broadly call standards Okay, the kind of documents that we produce I Basically fit into three categories FIPS which are federal information processing standards. This is what more formally are called Standards they need to be vetted by the Department of Commerce. Then we have also a special publications in computer security Which does recommendations guidelines and reference material, which again, I will be called broadly as standards in this case and then we also have NIST IRs, which are basically Internal reports or interagency reports internal from the point of view that they're done internally But they're all made public and they contain research reports and background information namely about our initiatives such as standardization of advanced cryptography and other other fields and Very broadly we interact. We have an international interaction involving several sectors government industry academia and other standardization bodies Okay, so this is kind of a Very quick overview and just to have a glimpse of of dimension. So here's NIST with about six to seven thousand Persons workers, then we have information technology group seven hundred and something computer security a hundred and fifty and then cryptographic technology 30 something persons I think one one good reason to show this is to show that Resources are not infinite So there's a finite amount of resources and basically we have 30 something persons working in a number of cryptographic programs at NIST Some of these you may have heard about for example post quantum and lightweight cryptography. They're currently ongoing Privacy enhancing technology and threshold crap cryptography That's what I'll be talking about today And then we have other programs like for example the randomness beacon which is basically an application where we promote Public randomness as a as a public utility also some applications to privacy And then we also do for example basic research in circuit complexity and we have a number of other programs Okay, so now for the actual standards traditionally NIST has focused on What we may call basic primitives at least in contrast with what we want to call here advanced cryptography And basic primitives basically fit into these things like block ciphers when you want to encypher something cipher modes when you want encrypt arbitrary large string hash functions Signatures interestingly, we don't have here public in cryptography But it's within pair-wise key agreement that we actually standardize for example RSA and then we have digital Sorry deterministic random bits generators There's a bunch of items that we standardize here, and it would actually be a Somewhat interesting talk to talk about some of this, but that's not gonna be what I'm gonna be talking about I just want to highlight a few interesting points to show some diversity of Possibilities so for example AES advanced encryption standard and the shot three secure hash algorithm Versions three were both developed within International what we call competitions, so this was a very open and transparent process I think it's fair to say that they are very successful standards from the point of view of the trust and their trustworthiness But not all not all algorithms have been devised in such a manner. Maybe in the other Extreme we would have cases maybe less known for example EES, which stands for a screwed Encryption standard was something in the 1994 that was basically a list got a presidential directive saying that the list had a Certain amount of months to to publish this standard and this was a standard that basically referred to Confidential primitive a classified primitive So we actually had a standard where some of the operations that were going to be Executed were not publicly known and this was a scheme that had a law enforcement field that basically Intended to allow law enforcement under certain circumstances to the crypt Tech plain text that had been encrypted Also a different use case we have the dual EC the RBG which is a Was a method of deterministic random bit generators that in 2015 was We drawn due to concerns of potential subversion This talk is not about these things. I'm just pointing out these things to show different ways in which Different standards were developed Okay, then we have also Interestingly the case of RSA public key encryption that at least within NIST is Standardized as one of the tools that allow spare wise key agreement, although we don't have public key encryption Just the standard itself although we have for for digital signatures so it's another way in which something can be standardized as a tool that is that is Enabling some other thing to to happen and just as another example Of something that may happen this year very soon. We will have Edwards digital signature algorithm, which is basically a variant of Schnorr Algorithm standardized and the reason why I put it here and that I find it interesting is that this was actually in consideration In the 90s when the essay was selected and the reason one of the weighing factors at least That weighed on this not being selected at the time was that there were patent concerns Because the algorithm was patented so it's for example one consideration to have with respect to standardization Okay, so this is a General overview some of these standards were specified by reference to other standards of other standards already existed and There are basically many methods for which these things can appear either by internal development or interagency development Either by adoption of external standards that already exist or by open calls competition or what we now could call competition like Procedures which are not necessarily exactly competition Because maybe NIST reserves the right to to make some some tweaks in the end Okay, so just to give also a glimpse of other processes not mentioned there as I mentioned the post quantum and the lightweight Cryptography are ongoing processes that intend to standardize Primitives that have certain properties like resilience against Quantum computation and are suitable for example for IOT in the case of lightweight cryptography We also have cases where I'm sorry. Where should I put point this this way, okay? We also have cases for example like pairing based cryptography where NIST considered the interest of potentially standardizing it in 2008 had a workshop Then he had a study and call for feedback He made a report about it basing for basically forming its position and the position is this is very interesting But more research is needed and since then nothing else has been done But it's something that can potentially still be become a standard at some point, okay? final point about still the NIST standardization after the the concerns around the dual eCDRBG NIST revised and formalized some principles related to the development process of crypto standards And so we have this NIST IR, which I would recommend as a reading. It's it's fairly short, but it's very interesting Which is basically a NIST cryptographic standards and guideline development a process basically we formalize a number formalize a number of Principles transparency openness integrity, etc And this is the thing that we need to abide by as we do new standards and as we follow new standardization processes Okay, so this was quite an introduction for NIST in terms of time. Okay threshold cryptography This is one of our ongoing projects. The goal is to standardize threshold schemes for cryptographic primitives cryptographic primitives may include signatures, public key decryption, key generation and ciphering Basically everything that involves a key can also extend to things that only involve keys The basically what we want is to enable distributed computation of these primitives in a way that each component Operates only on a share of the key So no component knows the exact secret key and basically then we have Properties like tolerance to a number of faults f out of n faults And then we have interesting properties also like enhance resistance against side channel attacks This project raises a number of questions Potentially we we may have many standards just imagine several standards for each of the existing standards. So which Which ones are we going to standardize? What kind of standards are we going to have? What processes will we follow for this? Will we in some cases will NIST just come up with a direct proposal and ask feedback to the community? Do you agree with this or will we actually make an open call and receive any kind of Protocol that can come or will we just look look around and adopt standards from other organizations? And then it's also being a very very broad in scope it involves several areas of expertise So one of the questions we ask is how can we involve all the stakeholders basically to maximize human resources that we have Available for this. Okay, I'll talk a little bit about this project The things we've done so far so we've done a NIST IR report on threshold schemes Draft in July we open for public comments for three months. We finalized it in March 2009 19 Also in March 2019 we had a Workshop open to to any to everyone we had about 80 attendees And This is what we've done so far and now what we're doing is we're drafting a roadmap towards standardization and immediately after that we hopefully Well, we hope to get some good feedback About the roadmap and specifically about items for standardization and criteria for possible calls for contribution where calls for contribution here Can mean several possible things Okay Why bothering starting with this to initial steps? Why don't we just put the standards out? Well first off there are steps in this driving an open and transparent process It's part of one of those Principles that I mentioned before and also because the actual reflection that we do along the way And the learning process that we get is actually quite useful to determine what we'll get A few notes on some insights. So for example when we did the workshop Basically, we realized we can't just talk about threshold schemes and say yes threshold schemes are better than Than usual primitives one out of one It depends on a lot of things and so for example we define kind of a little framework basically saying okay Whenever we want to talk about threshold schemes, we need to identify a number of features. What are the kinds of thresholds? What What are the thresholds for each possible property that we may want to talk about what are the communication interfaces with respect to client that Ask something for the module because we can have very different schemes Somewhere the client doesn't know that he's talking with a threshold scheme others where the client actually wants to share His input and then send different shares as a way for example of preserving privacy of his own input What are the executing platforms? Are we talking about hardware or software or more? Importantly, are we talking about a single device that within it has a threshold circuit is designed or are we talking about? Multi-parties and then we actually have basically secure multi-party computation and then set up in maintenance Which essentially covers trusted assumptions and then things like are we able to rejuvenate components when they get? compromised Then there's a number of other Items dilemmas about granularity. Where should we standardize should we standardize the building blocks and then? Move up or should we just go immediately for the for the actual protocols that we want to standardize We've got some feedback in terms of being useful to separate Very clearly the single device from the multi-party scenario because they are substantially different We've got feedback about the usefulness of explaining rationale namely as we did in the report and we take that as a Motivation to do it in the upcoming process And we also notice strong willingness from the stakeholders to contribute So we are hoping that indeed we're going to have collaboration along this process And we're encouraged to move forward Okay, so how about this roadmap that we are writing? Well, basically what we want is we want to get a map We want to decide in which places of the map want to go and we want to know how to get there And what we're doing for that purpose is we're defining this thing we call mapping layer Which is basically coordinate system. Okay, we know what places we're talking about We then have weighing factors that allow us to decide where to go and then how to get there in particular We want to going to have collaboration Okay mapping layers. Here's a structure that we're developing so Let this be the potential standardization special teams As I mentioned as a clear-cut single device on one side Multipartion the other side even though some techniques sometimes simple basic secret sharing is going to be And then we define this Concept that we're calling route as like tracks track is already So Route a is what we're calling simple thresholdization. So imagine something like RSA There's very trivial ways of thresholdizing RSA where basically there's a secret share of the of the signing key and then each Each agent each party basically does The equivalent to an RSA with using a sub key and then in the end it just multiply everything So these are very simple. There may be very simple ways of thresholdizing cryptographic primitives That really don't Don't offer Much thought to it on the other hand then we have things like route B Where which we call compositional or complex designs which would be things like for example making a threshold version of a CDSA that does not lend itself easily to to a multi-party computation Except by using secure multi-party computation generic protocols same for example for multi-party a yes And then we also consider route C because we really want to keep at least the scope open Where would be things where we're actually even thresholdizing things that we don't even know yet if they're secure Imagine things like thresholdizing post-quantum Primitives while they were still in the process of evaluating if those schemes are good So this is really far a little more far in the future And then we also put this slightly different route D which stands for gadgets or building blocks Whatever name you prefer which would be things like secret sharing Oblivious transfer commitment schemes consensus Etc. Okay. This is a map. This doesn't mean that we want to go to all of these places But but these are the things that are within the scope of Threshold schemes. Okay, so just some conceived examples just to really put some Maybe to call some motivation for some people really want to do this thing So route A would be things like RSA decryption and signatures just use a normo-morphic property and you have it very easily a Snore signatures some versions of it can be very easily thresholdized a key generation for elliptic curves For example, and we also put here for the case of single device what we would call a yes a threshold circuit design using masking techniques Track B You see the assay signature RSA key generation Yes in cyphering multi-party version and then for the single device case There are more complicated cases that involve resilience against combined attacks and then the case see route C The ones that I've already mentioned and then route D. Whatever primitive one may sink is a building block Okay, just to note some of these items can actually be some of these primitives can be in different routes because we Because there are different threshold versions that we can that we may want to to implement And so that brings us to our final layer, which is what we call modes And as an example with these are slightly generic examples, there may be a few others But imagine basically the interchangeable mode is the case where you want to do a threshold Version of us of a cryptographic primitive where the client does not somebody was asking a module to do An operation does know that he's talking to a threshold scheme So the interface needs to be exactly the same the schemes need to be interchangeable Then we have the secret shared input and or output where the client Wants himself or herself to Secret share the input maybe as a way of preserving privacy Let's say if he wants to preserve privacy of the plain text that is being signed or we can have secret shared Sharing of the output if we want to have let's say privacy of an output of a decryption And then we can also consider the the auditable case Which would be for example a multi-signature where the client can actually prove that this was produced by a by a threshold scheme And that may allow for example that may have auditable or good auditable Properties by the way the slides will be available. So in some cases, I will skip a little bit some text Okay, what is the development process that we have in mind? Well, we're currently doing the roadmap Once we have that and all of these stages will include public feedback once we have that with public feedback We intend to do calls with criteria Then at some point will have evaluation of contributions and then at some point will have issue will issue standards This is a generic sequence of phases because again, this can go differently for different items in particular As I mentioned already a little bit so different items can have Different calls for contribution. So in some cases we may pounder just putting a protocol out there and asking Do you think this is a good RSA threshold? Algorithm do you have any feedback to improve it? But in other cases you may actually ask for new protocols In other cases, let's say for example route C We may ask for a reference implementations that show feasibility and research results that show that those schemes are good That will most likely lead to different timelines namely across different routes so what really what we want to do here is to keep our options open but Identify that there are things that we can much likely end in a short span of time and others that would take a longer Spend of time and then the actual final format of a standard can be very variable So we can consider addendums to existing standards. Let's say you have a standard They're now just add a little section saying this is the threshold mode for this cryptographic primitive In other cases you may have a standalone standard or you can reference other standards We will also be looking for Implementation and validation guidelines because that's also an important part of the process of having good standards And then we can have what we can call reference definitions, which is for example, maybe in many standards We will use secret sharing Maybe at some point it might be useful to have a reference definition of what secret sharing is somewhere of some other where some other gadgets Just again to emphasize this point public feedback is something that we really want and we're hoping that public feedback can indeed influence the way We can well the way that we will be taking including for standardization items for weighing factors and for a number of features such as Should should we have schemes that allow dynamic thresholds? Should what kind of security properties like composability and robustness should or can we have for certain schemes? Okay, this is the update. I wanted to give about threshold crypto now some considerations Let me give it what I'm calling a perspective on the granularity dilemma So one of the things that has been coming over and over is this well It's actually two ideas one is and I kind of relate to this one because my my background is in secure computation and usually when you have papers We start with an ideal functionality and then we devise a protocol and then improve it secure. So one question would be How about standardizing ideal functionalities and then everybody's happy everybody can propose their protocols? Well, one of the problems that that does not solve the the process that we need to have Namely for some of our stakeholders, which is the process whereby vendors need to have validated implementations To be able to use them. Let's say with the federal government So basically if we if we standardize an ideal functionality and you and we stop there that means now every time a vendor Wants to sell their product. They're gonna take it to an end to a lab that In a credit accredited lab for certification and now someone there was probably not a Cryptographer is going to have to evaluate is this protocol secure or not? So, okay, so should we go for concrete? Protocols immediately. Well, but then we go for concrete protocols Maybe we're not achieving the ideal functionalities that everybody wants So this is one of the dilemmas the other dilemma is between building blocks. Should we start building blocks and then? Should we spend let's say two years? standardizing very formally what two or three methods of secret sharing are and One oblivious transfer and two types of commitment scheme so that then people can build up on that With more two or three years or whatever or should we go immediately for complex constructions? But then maybe we'll have a lot of redundant work. Well, the idea I want to advance Maybe it's a little abstract, but I think it's an interesting idea is that we don't really have to well first off If we go on the middle point in any of this, we're basically also not solving any any problem So the idea that I want to put forward is that? Actually, all of these areas have a place in the standardization Process and unfortunately, I don't have enough time to kind of stay a few minutes in this slide But just as an example, maybe we can relate it to a threshold cryptography Although I think this is more general for other standardization goals as well Imagine that actually what we want as a goal at least for threshold cryptography is to actually have a protocol that does thresholds Makes a threshold mode of a cryptographic primitive So we really want to have the protocol, but we want to get there by passing through the ideal functionality so maybe or in some cases you can interpret ideal functionality as a Complete Sorry a comprehensive set of security Assertions and an interface just for cases where ideal functionality might not Be the right version so maybe this point could be in the point of defining criteria So maybe when we want to define a threshold mode for a threshold scheme Maybe we can define an ideal functionality that could even be part of the feedback that we get from the public And then when we ask for a call for contributions, we're actually asking please show us protocols that satisfy this ideal functionality and then on this side We want to have certain we want to have concrete instantiations of building blocks Let's say commitment schemes. There are many ways in which we can do them. Maybe hash base or Peterson commitments So we want to know how we do them in order to achieve this But we don't necessarily have to define our initial goal of standardization to be a building block and have to wait To get to this point. Maybe it's enough initially to know What kind of building block we need and then when we define the build the actual protocol that we want We know that we're gonna have to instantiate this Anyway, the diagram is left on the slides. We can Left for more reflection Another point standardization versus adoption. So what makes a standard good? Well, it shouldn't be a well done Specification definitely, but it also depends on the context so I would say a good standard should be a reference for Let's say best practices and minimal defaults for example picking up again with the threshold Cryptography if now we're providing a way in which people can share their secret and not having in a single in a single place If you have a key leakage from someone who was not using threshold crypto, then we can ask well Maybe at that point threshold crypto was a best practice. Why was this? company not using threshold crypto a Good standard would allow Interoperability would be suitable for validation certification of implementations and would be also a good reference to what to innovate upon However, standards can also possibly be bad. For example, if compliant in context where compliance is required a Standard would be bad if if the techniques are obsolete or outdated And for example, if we cannot verify and validate implementations that are actually Prone to error for example, if you need to use randomness, but there's no way of verifying if randomness is good And if the randomness is bad, then everything is broken. For example And standards can also be bad if the process that does not allow for correction Withdrawal or replacement of the standard when the standard should indeed be replaced Okay I'll move to speed 1.5 Still try to cover all the things I want to cover Another aspect that I think is relevant is the aspect of intellectual property. It's often a delicate Aspect but I think it's worth considering Explicitly and what I want to say here is basically based on the NIST Information Technology Lab policy, which is a few things that I find are quite reasonable First of is we can at least ask for this closure of patents. I mean, it's nothing We're not saying good or bad about people having patents But this closed them if you're being part of a process in particular we can call for this closure at any time including for people that don't have patents but know about other patents and Depending on the process for example, if we have an open call for submissions Then we can actually put in some conditions for example Conditions that the licensing in case somebody has a patent that at least makes a patent That is usually called friend which would send for fair reasonable and non-discriminatory Now one Point worth mentioning is that actually let's say for example in the case of NIST We can't force we can't force any cert party to disclose that they have patents or that they will enable This kind of licensing terms. However, when we do Guidance in standards we can have our own condition Which is well if at some point we find that this is Under a patent for somebody would not going to license it in a fair reasonable and non-discriminatory terms then we have the option of Making that no longer a part of the guidance. I've included in the slides not for for the talk now But if in case you want to consult some of some excerpts of the actual policy Another aspect just as an example is that I think it's useful with respect to the standardization processes to make transparent And to have a traceability of the evolution of documents to know why things were changed This is one example of something within the threshold crypto Which was we had a draft report and then we basically compiled the PDF version where we had all the public comments and corresponding Answers and then we had references to all the places in the text where changes were made and I think that's quite useful with respect to traceability of changes Okay privacy enhancing cryptography it's really very brief but just Basically to claiming that we are in the arena So we have this back project privacy enhancing the project the goal is to so we're interested in privacy That can be promoted by cryptography this includes techniques such as your knowledge proofs and secure multi-party computations And basically we want to keep up to date with the external initiatives. That's that's a main goal and an important goal in terms of of Output is to produce reference material, which does not have to be standards But it will be material that will be useful for several purposes It will allow us to assess the state of things in a particular area Let's say legs your knowledge proofs it will motivate applications and proofs of concepts in use cases That's something that can actually promote that later in time. This technology can be standardized It may frame the further development of standards. That's something we consider important basically We can a long a long time direct ourselves where to go and it may reference material may by itself enable interoperability across Across people that actually want to use these technologies Okay, so one one example of something that we're doing currently is we're Interacting with ZK proof, which is one of the standardization technologies that will be That Daniel is organizing and that will be discussed also during this workshop Basically ZK proof is an effort towards standardization of zero knowledge proofs It's an open initiative of industry and academia and one of the things that it does is produces open documentation in these feats our reference material Approach so what we've been doing is that we were asked by ZK proof earlier this year for feedback on their Documentation and we decided to engage with them. So basically a few things that we did we ported the initial documentation into latex we Provided some comments and then we proposed an editorial process to develop the documentation into a community reference Then based on that we also participated in the second workshop And we're now also in the process of producing contributions with the rest of the community. So in summary This is one activity one example of an activity that supports advanced Cryptographic standardization where we're not necessarily saying we're doing a standard on this right away, but we're collaborating with that initiative And just still within the realm of pack We are that we also want to promote promote the secret multi-party computation But no time in this presentation for that but hopefully in the future soon future. We'll have things to talk about. Okay concluding remarks Okay, the title contains advanced cryptography, but we didn't really talk about what is advanced cryptography I'm just gonna leave it as a question whereas a number of questions. So what is it that makes? What is it that makes it advanced at least regarding standardization is it that we have a Lot of times protocols, let's say with distributed systems within it instead of a single Single-side primitive where somebody just doing let's say signature. Is it because we have many paradigms and options to choose from? Is it because we're using complex techniques that were not previously standardized that may also be a case At least for example in the case of secret multi-party computation certainly Or is it simply because we have an uncertainty of what path we should We should take well, I'm not gonna give an answer But just make two notes which is well first off what is advanced today can be basic tomorrow so we never know what advanced is and One point that I think I mean it's I think it's really interesting to reflect about this. Maybe we actually also need more advanced Standardization processes and this might be what we need to tackle advanced cryptography standardization Okay, so just to have a call for collaboration here in these conclusions We want to collaborate with open and transparent processes towards standardization of advanced cryptography So please do let us know if you want to collaborate with NIST in any of the initiatives that we are Driving or any of the initiatives that we are collaborating with other people that are taking the lead Just two more concluding slides. So this one with concluding remarks just a number of items. So Just a statement NIST is interested in the development of advanced cryptography and this includes secure implementations technology adoption interoperability standards reference material etc The standard development process matters. So it's not just the final standard whatever preconceived vision we may have of it But we really feel that especially for advanced cryptography. We are exploring and we are learning with a process learning by doing Not everything should be standardized by NIST some things should but not everything Still that's not an impediment that we can collaborate with those things Set of final standards can be of several types can be what we typically envision as a standard But again can be other things can be reference definitions can be addendums in some documents The standard standardization considerations go beyond technical security involve trust for example And evolve a lot of things within the process Another one that I guess sometimes is relegated humans are part of the equation So we don't have infinite resources and so collaboration interstakeholders is essential And just also as a final statement NIST is currently active in threshold crypto and Privacy enhancing cryptographies and just to finalize with a question Which of today's developing standards will remain? Let's say 70 years from now as building blocks of advanced crypto and the reason why it shows seven years Just because I want to show a cool picture Which is from NIST. This is actually a wall that exists in NIST It's called the NIST stone test wall was built 71 years ago to study the performance of stone Subjected to weathering and so you have here the photo in 1948. It still stands But actually if you go close by you'll see that little little stones are actually quite eroded and others are still standing firm But actually I think it's a cool question to ask like what what will be crypto in 70 years? And are we are we looking towards developing standards that will be that we will have good durability or I mean difficult to answer of course and Thank you very much for your attention Thank you, Luis and mine is not a question just a comment from their perspective of the steering committee of the ZK proof standardization effort I would like to strongly commend NIST and Lois personally for their involvement in our effort They've been extremely invaluable in bringing their hard hard-earned lessons about standardization and what matters and how to do it properly and It's unusual and very encouraging to see them nurturing things from such an early stage towards eventual standards. Thank you