Internet Engineering Task Force Interim Meetings, 19 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-LAMPS-20220919-1300

Description

LAMPS meeting session at IETF
2022/09/19 1300

https://datatracker.ietf.org/meeting//proceedings/

A

A

Good morning we're trying to sort out one slide issue um trying to get those but they're, not the first presentation, so I think we'll just go ahead and get started and try and work that in the background, um let me bring up the slides.

A

Okay, so uh today we're gonna have a a short one-hour. um Virtual interim beating remind everyone that this is taking place under the note. Well, please pay attention to your UH responsibilities under the note well and please don't participate if you have not checked that out.

A

So this morning we uh have two presentations that were uh associated with uh itf-114.

A

After that, this slide is: is changes discussions on the list, Friday we're going to talk about the hashland sign issue with post Quantum signatures and then, if there's time left we're going to talk about the um and a status update on CMP, the two rfcs that are being updated there um so because of the slide issue, we're going to start with the pthcs12 presentation. While we try and sort out the slides for the CMS presentation before we go any further, though, of course we need a note taker as anyone willing to do that.

A

Can someone take notes in the in the chat you can get to I'm sorry The Ether pad that you can get to, but the button at the top of the um the upper right little pencil in a pad.

B

Yeah yeah I can do it. Russ it's John, Gray genre.

A

Thank you so much I appreciate it John all right. Let's uh then uh move to the uh first presentation. uh Dimitri. Are you gonna, be the presenter.

B

I think I think Hubert will be the presenter. The author of the draft.

A

Okay, Hoover is going to be it. Okay,.

C

Yeah, that was the plan. Can you hear me.

A

Yes, let me pass you uh the ability to do the slide. Control yourself.

A

Okay, did you get that.

A

um Do you see at the bottom of the slides, uh there's just the numbers and then an arrow to move them forward? Uh-Huh.

C

A

Okay, yes, okay, good, all right, good! All.

C

Mute, okay, so hello, everybody um um I will be talking about the use of PV Mark 1 in pkcs12 file format. uh My name is Hubert cardio and I'll be presenting together with uh Dimitra Dimitri. We both work at red hat in the crypto team, so quickly about pkcs12.

C

The purpose of the file format is to transfer private key certificates, secrets and extensions. The specification is in RFC 7 to 92.. There are a lot of implementations. The primary ones that we are interested in are in open, SSL and accessible to TLs, but there are also a lot of of implementations in Windows in by a lot of Hardware implementations in Network appliances and so on, and so forth, more or less interoperable.

C

Basically, the only interoperable file format that works for both our windows and Linux environments. The file format itself has a very extensive structure, but on the top level there is technically just three Fields the version the outsafe, which is the list of items which are inside the the file for the the file itself. And then there is the Mac data, which is working as the Integrity protection for the whole file.

C

What's important is that Mac data specifies just the digest that is used for the Mac protection, the the salt used for that hmac derivation and the iteration count that's used for the for the key derivation, while some implementations allow omission of the mark as this as the a71 specifications here shown. Does.

C

Most of them actually are quite iffy on that um Mark generation itself is specified in appendix B of the RFC, and there already is a specification that this this like when you choose with uh with password uh the key derivation is not recommended and it should be duplicated for a new usage one. So well, while we already had.

C

I used was uh duplicated. The problem for us is that this this kdf is not fixed compliant, so it's not possible to create a mark protected ptcs12 files that are fips approved.

C

um So our intentions, we want to have an up-to-date standard that allows use of new and current derivation functions. We want fips compliance. uh We also want, as far as possible backwards compatibility so that those files would be readable, at least partially by old implementations, and also we want that implementations to be easy to to do since we need to implement it in multiple libraries and, uh and so so, the the ease of implementation is important.

C

So the proposal we want to do is uh to prep to preserve the existing high level pkcs12 structure um and additionally, permit the use of the ID PB. Mark 1 object identifier as a valid type for the digest algorithm. So, instead of specifying as a hash algorithm, it would specify just the PB Mac one as the as the hash itself, then uh we would.

C

We could use the parameter field to store the PB Mach 1 params, and then those would include the information about like how to how to calculate the the hmac and the hmac itself would still be would be calculated according to the PB Mach 1 um standard, which is specified in RFC 80 18.

C

uh While for the pkcs12 structure itself, the max out and iteration values would be completely ignored, since those are while they make sense for for use with pbk df2, they don't make sense for a script or for argon2 like those those use, much more advanced and more complex parameters to to work. So we would need to completely ignore them to make for interoperability. The upside for this proposal is that pvmark is quite easy to implement, uses exactly the same key derivation functions as already deployed bulk encryption ciphers so like.

C

If you support AES in pkcs12, you already have all the plumbing necessary to also support BP Mach 1.. The hmac calculation itself is exactly the same as in ptcs12, just the key derivation for that age. Market changes.

C

We also already have a very widely deployed implementations that will be able to extract the private keys and certificates from files that use ppmac 1, just by telling them to skip the Mac verification. So you can use openssl, probably like even 098 or and definitely 101, that that's the one all this one I've actually tested that will allow you to read the file by specifying just uh to open SSL, ignore Mac verification and then you'll be able to uh verify like extracted their private keys and certificates.

C

uh Finally, uh it does provide a very clean upgrade path for modern kdfs. You can, as we specify with the specification already um we proposed, you, can use a script and are going to just needs the asl1 oid specification and parameter specification to be usable uh there too.

C

Now the alternative that was proposed on the mailing list was to use aesccm. Now the problems are that I'm not aware of any implementation of that inside pkcs12. None of the widely deployed libraries that we actually use uh supported. So none of the open, SSL green tls's, Java Windows, as as Windows implementation, I'm, not aware of them supporting them. That would also be the very first aad Cipher in pkcs12, so that would require a very new and potentially complex code.

C

This is also not a wildly used Cipher, so anyone that would need would want to use it in kcs12 would need to implement it verify and in some cases, also certify, since we wanted to flip certification that would um that for some implementations that would require another Cipher to certify. Finally, there is no clean way to handle as CCM together with hmac. If we live and live in the Legacy Mark in the file, then the straight flip compliance will be problematic. Since then, you cannot derive the keys necessary for hmac.

C

Well, if you omit a Mac, then you will lose the whole file, consistency, Integrity protection and for some implementations that is problematic, like they don't provide the apis necessary for telling the implement it to tell the library to to skip the Mac verification.

C

So the specification is on uh data records. The draft carrier pkcs12 PB, Mach 1. There is GitHub also with the source code, for that would have a quick and delete implementation of open SSR in openssl, and if the draft is actually adopted by the work group, we will provide a full implementation for openssl, nucleus and NSS. That's the absolute minimum. We also will be pushing for open jdk support. If you would like to look at the file itself, you can download it for also from GitHub, and the password is one two three four.

C

Okay, so questions.

C

So first question is from Tim Hall, big uh sorry, if I'm mispronouncing, the fifth compliance problem, is the use of absolute algorithms uh correct. The problem is that the key derivation function is not approved for fips use and we want to use pbktf 2 for the key derivation function so that it's effect compliant.

B

Foreign, so my misunderstanding is a little bit because I mean a higher level. Things like KDs are usually not in fips. Fips is usually about just the crypto. The individual crypto.

C

If we are talking about 140-2 and current requirements, a key derivation functions are very much in uh scope for fips. Oh.

B

You're right sorry.

B

I just see so many people implementing them on top of it.

C

Yeah and they won't be flips compliance with us, yeah.

A

So so my gut reaction- this is Russ, is that um the your first proposal makes more sense than the alternate uh and I'd like to know whether other people feel the same.

B

Do you mean the first proposal is using.

D

Of course, so sorry for um clarity.

A

uh I'm, you know in the slide, you had a uh our preferred Way Forward and then you talked about other ways forward and I'm. Saying I think your preferred Way Forward makes sense. Okay and I wanted to know if others thought differently.

B

E

B

Was just gonna say: uh yeah I agree with that uh the first proposal, because the aad decipher, obviously there would be a change in the structure of pkcs 12, which I think part of the purpose of it is backwards, compatibility and stuff.

B

Plus, you know the fips compliance is a good Plus on this, um because obviously lots of people need to use fips, so I think the recommendation of the first one makes sense to have PB Mac one plus we have another like we put it in CMP as well and other um of our protocols that we work on so I think it makes perfect sense to do this in pkcs, 12.

A

Okay, Sean.

F

One two three waiting for it to work: yeah um I, agree, uh definitely option one.

A

A

A

G

I think I'm gonna say the same thing that my colleague John just did, which is PB Mac one uh keeps disaligned with the changes we're doing in CMP, so PB Mac one would be good for both CMP and p12. That's aligned.

A

All right, I'm, not hearing anyone speak uh against that approach. um My quick skim of the internet draft was that's the only one. That's in it is that correct.

A

Only what that's the only alternative you wrote down in the internet draft.

C

Yeah in the internet, after is just BB mark one.

A

Good, okay, so uh would anyone at this point speak against working group? Adoption of the this draft.

A

No one is coming to the mic, so um I didn't see anything over in chat, so we'll have a call for adoption. I have to say we're.

A

Itf114 put a long list of uh documents to be uh called for adoption. We'll. Add this one to the end of that list, and so it'll probably be a couple weeks till until we actually do the call, but we will uh we will do that.

A

Thank you any further questions on this. This one.

A

All right, then, we will move to the uh PQ sigs draft.

A

A

A

I can hear you and I'm passing okay.

H

Thank you. uh So yes, the so this light set is just a an update of the previous presentation that was done maybe uh well six months ago, or something like that. So, um uh yes, we can just go through the slides.

H

So it's uh basically the idea I will remind the the idea of the the main idea of the of the RSC. So the purpose is to propose a solution to communicate a key uh individually encrypted to several entities. So the actually, if you can just go further in the slides, please.

A

I think you have control.

H

Okay: okay, sorry.

A

H

It's perfect so um yeah, so that was the the purpose of the of the RFC just to define a new mechanism to uh send a key to several entities and to encrypt the key individually.

H

So, basically, the idea is to uh to propose a combination of free algorithm that will be used for encryption. uh The first is a chem okay, encryption, encapsulation mechanism, then a kdf and finally, a wrapping algorithm.

H

So basically the algorithm is defined in this slide, so we will first generate a ciphertext and the shared secret thanks to the cam algorithm then derive the shared secret thanks to the kdf and finally use the key encryption key obtained from the kdf as the encryption key for a symmetric algorithm, uh the wrapping algorithm that will bring then confidentiality and integrity, and so the decoration mechanism is described here. So it's the opposite, so it works uh obviously, and uh so uh they're in CMS we will use.

H

uh We propose to use the the the recipient for type and to set it to a key trends recipient recipient info and um to set the following values. In the key trans recipient info, I mean we will set the the algorithm to uh oid IDK Trends, which will be the cam trans mechanism and then set the uh algorithm parameters of type generic hybrid parameters.

H

uh Well, let's, let's hit basically and uh so I just made a few updates. According to the comments made during uh last meeting. So especially, there was a discussion about the kdf uh which can be useless if the cam, for instance, outputs a key of the correct size to feed the the symmetric algorithm. So in the racer really clarified that this kdf can be the identity algorithm.

H

If we want to skip it and the other date was to make sure that this RFC proposal is aligned with the RSC 9000 180, which describes the hybrid the encryption mechanisms. So basically it's the same principle which is proposed in this RFC, meaning that it's a combination of the free algorithm, chem, kgf and and the symmetric algorithm.

H

So basically the RC is correctly aligned and um finally, in the sea there are still some open question that have to be answered well and with where I'm really open to discussion.

H

So it's about the way to communicate the info so for in this RFC we suggest to use the key trans recipient info, uh but well we could imagine different solutions just to avoid the updates of of rfcs.

H

Then uh some open parts are still left dealing with the certificates, especially because it depends on the work uh that will be done on the pqc IX.

H

And finally, uh maybe some algorithmic limitation should be put in the RLC, especially dealing with the choice of chem. For instance, do we only specify the caliber algorithm or shall we extend this use to any cam?

H

Maybe that's up to discussions and as well for the choice of kdf of the web algorithm. Should we limit them or should we be I, mean quite open on the choice of the kdf? Should we use well, she uh sha free or kdf base, or maybe that's still open. So if you have any suggestions, I will be glad to get them and incorporate them into the into a diversity. So that's it for this update. So please, if you have any questions suggestion please.

A

So um I think we talked in about uh keeping alignment. The RSA chem was advisable, um but to do something different if there were property.

A

That uh kyber, we didn't know that which one would be picked um supported, but I wonder if, if we would be better served by defining oids for triples that had kyber, which kdf and witchcraft.

A

As opposed to splitting those out, uh have you have you thought about that.

H

uh Yes, but we think that um the combination can make the the number of IDs really huge. So that's the reason why we propose to clearly split the combination into free algorithm.

A

Okay, Sean go ahead.

F

I'm just gonna say that, based on your uh request for input, I would probably just do Kuiper and all three whatever strengths, whatever they're called two four and five or whatever it is I, can't remember the numbers um and limited to that and not try to um make your competent Torx problem more difficult than it really is.

F

But again, I'm, not a cryptographer, so I'm, just throwing it out there from like. Let's not make this too complicated we're gonna have enough of these um less options is maybe better.

H

Yeah, that's I agree, but the only point is you know that uh in the nice competition uh there is another new round that has been opened for uh key encapsulation mechanism. So maybe for the time being Skybar, but maybe uh in a few years it could be changed or at least a update or enhanced. So maybe that's quite.

F

Yeah I think I. Definitely don't want to get out ahead of our um ahead of our skis, as some people would say to be specifying things in advance of what Nest is picked. So I would just go with the ones that have been actually selected um and then, when they come around, if they pick another version with two or four or just one other one, then we can update the specification. Do that there's.

F

You know, there's not supposed to be that much um to do to spin out a new internet draft and update an RFC, so I I think that's probably the better approach, at least in my mind at least.

A

I I would also observe that if we take the approach where we're using key trans, um then you really all you're doing is specifying the conventions for using kyber at the three levels. And so when another one comes along, we can write a similar one. That specialized specifies the conventions for using that one with key trans uh go ahead. Yuri.

D

First first I think uh it's. There is some a confusion, because uh Nest doesn't open fourth round for the key encapsulation mechanisms. Maybe unless there is a breakthrough and something with many times smaller key size and adequate performance comes up which is rather unexpected. So we can probably assume that key encapsulation mechanism remains what's selected, specifically kyber.

D

We can also expect I think that if, in the unlikely case there is a new, a cam, it will satisfy the same constraints, strength, wise and, of course, it is necessary to document those requirements to come, regardless of whether we decide to stay with the nist selection, which makes sense or go outside.

D

D

Open question is what to do with the kdf on the chat. The argument is that one of the reasons to use kdf is to deal with the key size mismatch with symmetric key size. Mismatch, that's a valid argument. I do not think we need kdf for strength. I would not argue for using it for size matching, though again I find it a rather expensive older.

A

Any response to that: okay, Mike.

G

G

This is Mike, go.

I

G

Yeah kill myself the response to Yuri in chat um so yeah, the kdf was there I think you know super conservatively in case. You know people end up wanting to put non-nist chems here that don't have that that property that you can just use their shared secret directly as a symmetric key. You know there have in the past, been chems that didn't have that property um I. Suppose.

G

If we're going to be sticking to the nest cams, then maybe we do get to just assume that that property and maybe that design problem becomes simpler and then yes, Yuri, said the the size mismatch. You know we don't.

G

We didn't want implementers to have to worry about getting the choosing a cam that lines up with the key size of the wrap, um so the kdf sort of makes that go away, but I guess if Russ is suggesting that we we pick triples um chem kdf rap, maybe we could actually reduce that down to doubles and just specify chem wrap if we choose ones that happen to have the same size, and maybe that just makes everything clean over or.

A

Even uh Cam and at least key wrap key size right.

A

um Just a thought uh I mean I need to think it through some more. But the slides made me ask that question: uh go ahead. Yuri.

D

um I I wanted to say that a of the old case camps that did not have the necessary properties, probably shouldn't be considered here, hopefully we'll, learn something since and second making the requirements explicit would easily deal with this issue. You would just look at the hash, for example, and say: wait a bit. We require hash that does not have obvious collisions.

D

This hash has therefore it is not acceptable. It should be simple enough.

D

Likewise with Cam with document requirements. If a new cam comes for consideration and we see that it does not satisfy some of the documented requirements, that's just not an acceptable Cam, and why should it be over? There.

A

Mike your hand is up. Is it a new one or no?

A

ah Thank you. Quinn.

A

Quinn we're not hearing you so um I, don't I, don't know what's going on, can you maybe ask your question in chat.

A

ah There you go: go ahead, Quinn.

E

Oh, oh I'm, sorry, I, I, I, didn't know that I got to click on on the thing. um I have a few comments or questions. um The first one is regarding to the the secret K in kyber chem.

E

um So the first option is to make the k 256 bits for all two or three uh cam options, or uh on this could uh or we or we could. um Could you know, make the the length of K depending on the strengths that we're targeting, for example, if level one we're thinking about AES 128, so we could make the cam only 128 bits or you know we yeah, as you said, so there are two options there and um that's. A second comment is that they got into the choice of the PDF.

E

um As uh Mike pointed out. You know in the future. If we wanted to use um a different cam, which you know which does not have a PDF in the cam itself, then of course we would need a a kdf to improve security of of the cam outputs.

E

um So that's there's a reason for the camp there.

E

um But if, like the second choice, I I just mentioned where we output the cam size, it is, you know exactly the size that um the algorithm needs like one two 120 bits of uh AES 128..

E

um So there are two choices there, um I don't know. Which way is uh the right way to go um and the third one is you're going to the choice of rap um I'm, not sure if I get all the the understanding, the the need for the wrap here, because with the camera long, basically, you can. uh You know both sides and can get and get the secret key without needing a wrap.

H

E

And the thing is the the recipients uh must do um a decryptions, the bka decryption and then a bka encryption to check to make sure um you know the um the legitimate um ciphertext were received. There is a chance of failure, but that failure probability is extremely low, like like two to the two to the minus one uh uh 50 or something like that. That's it's like it's practically zero, so um so I'm not sure if we still one type of wrap in there or not.

E

H

Just yes, if I can answer yes to me, the rapper algorithm is absolutely needed, because the cam outputs a random key. But in our case we want to send a fixed key, because we want to send the same key to several endpoints. That's why we need to master actually the the kit to be sent.

A

Thank you, okay um I would propose that we do a call for adoption of this work.

A

Is there anyone who would like to speak against doing that.

A

Okay, thank you. uh We will add this to the list of documents. We're doing call for adoptions, for thank you next up, Mike is going to be your.

A

Presentation on a hash then sign to be dip. The slides up.

B

Sound check, okay,.

A

And you should have slide control now.

G

Okay, um I'll try and keep this brief, so that Hendrick has time to speak about the team. Here, it's more urgent um briefly. This is a land mine that we discovered in the pqc, the Sphinx, the lithium Falcon. We sort of stumbled with this laminate a couple weeks ago. I know we're not the first people to stumble and do it, but you know we decided to make noise about it.

G

So this is just a PSA talk to get it on our Collective awarenesses. So we can start thinking about this. uh So hash then sign. This is a pattern. It's used a lot and RFA required you to pre-hash.

G

um This pattern is pretty well baked into a lot of stuff where what you're sending to your crypto module to sign is a short is a short message: you're, not sending the entire plain text, there's lots of good engineering reasons to do that, um like, for example, if you're signing an email, you could have a 25 Meg email with attachments and if you're signing out with a smart card, you don't really want to stream the entire 25 Megs to your smart card um and I.

G

Put a few examples: every Network, which are some similar example, uh latency, symptoms, processing, variable size messages, blah blah blah and I put golang here as an example just to show how certainly ubiquitous this is. The ecdsa interface in the crypto layer expects a digest that digest is currently performed at the x509 or TLS. Or what have you layers like? This is a just sort of making a point. This is a very well established pattern.

G

uh This pattern does not work with the three signature schemes that we're looking at Sphinx style, lithium falcon. It does not work because each of these algorithms internally begins with a message digest step that is prefixed Within nonce and in the case of randomized, sphinx and Falcon. That knots prefix is, is a rat is a completely random number chosen at signing time in the case of non-randomized, sphinx and dilithium.

G

That prefix is derived from the public key of the signer, so tldr here you don't want to pre-hash, because you're sort of stamping on this hashing, that's done as the first internal step of the algorithm um I started a thread on lamps and cfrg with a really bad email title last week, and then yesterday, Sunday I started a threat on the nist mailing list with a better title.

G

I think we've been getting some good responses, and so it seemed like the answer is yes, you really don't want to just prehash with shot 256, because you will clobber the security properties here.

G

So my fourth slide here I think we sort of already have an answer to this. Given the Miss nist manualist discussion this morning, the answer seems to be question one. Yes, we do care um question two: can we safely externalize the hash step of sphinx die lithium Falcon outside the crypto module?

G

The answer seems to be: no don't do that and then we're left I think then making this mailing list discussions sort of lining up with our question three here Chris said: if you want to be sending a short message across the network to your crypto module, then you need to Define an envelope layer at the protocol level, which is sort of I guess what we were needling at here with number three.

G

So I just want to put this out for General awareness that if we want to support a prehashed mode in pkicks, where you're, what the the actual message you're signing is short and compressed and digested, then we're going to need to Define that envelope format at the pkx layer and we'll need to worry about its security properties. Collision resistance contains a nods blah blah blah. We'll need to worry about all that at the pkx layer.

G

um That's it thought for General awareness I'll end here.

A

I would uh observe that this is just not a prefix problem. It's a CMS problem as well, uh but uh go ahead. Panos.

G

He kicks in the.

B

Church comment um so Mike. Thank thanks for doing that. You know thanks for trying to collect the data and I'm not I'm, not entirely convinced to be honest, uh that we, you know that the prehash fails uh for all of these cases. I think we should read it on a per algorithm basis and, in my opinion, I think we should collect all the arguments against it because I'm not sure that what we're hearing so far are practical concerns.

B

You know there are cryptographic theoretical concerns and there are practical concerns, so you know maybe for Falcon there are, but I'm not sure there are for Sphinx and die lithium. So in my opinion we should really understand the counter arguments before we embark on a trip, and thank you for doing that. You know my goal is to have to try to understand it. A little better foreign.

A

Okay, anyone else want to comment on this. um I realize it was a call to action, not a specification to adopt.

A

Okay, Mike thanks for raising the issue, um we'll move to Henry.

G

All the action here probably is for, like Massimo, Jake and Panos and Sean your draft that's doing dilithium like that's the place. This would need to get addressed. Indeed, I want to.

A

Stick up the lithium and the CMS Sphinx draft as well.

G

And the CMS Sphinx draft and the eventual eventual Falcon equivalency I, don't know if you want to stick placeholders in now, because this we're going to need to sort this out one way or another.

A

uh Go ahead, Yuri.

D

uh I just want to re-emphasize my previous argument: uh dependence on collision and resistance property of hash. Of course, we expect Collision resistance property of the modern hash and, if you insist on using md4 grow up there over.

A

Go ahead, Sean.

F

um I was just gonna say uh thanks for that, Mike I expect that you'll keep us honest so appreciate it.

A

Okay, then we're gonna go to Henrik status.

I

Yeah, so thanks can you hear me.

B

I

Okay, um thanks um for getting the chance to give a brief update, um just one slide: um early August, um the authors of CMP updates, including Mike, prepared the zero zero version of the 40 to 10 bits and 67 12 bits, which is mainly the original RFC text and then the zero one version where the we merged. The changes specified in CMP updates into the documents, and then we um did it did a review and um provided some additional editorial changes um sorting out some things.

I

We came across while reading and added an action item for appendix C to be reviewed more closely fixed some nits and we came across the topic whether this is now a good point in time to also add support for cam keys in 4210 bits and yeah. But this is just um that we wanted to to raise this issue and see whether there is any uh feedback or support for this activity.

I

Finally, it needs to be added to proof of possession as well as message protection um and if um cam algorithms will be supported in CMS envelope data in key trends, then we have the support already covered with the change we did in CMP updates. Switching to envelope Depot data for transferring centrally generated keys.

A

So thank you for raising this topic.

A

We we had a short discussion um when we were talking about chems at ietf 114, and it was observed that we needed a proof of possession mechanism to go with that and I believe that Sean and Panos had agreed to put together a draft on that uh am I, remembering that right.

A

Go ahead, John did agree.

F

I did agree to do that. I haven't done it yet.

A

Okay, so uh assuming that comes to happen quickly, then I think aligning this work and that work makes a lot of sense. Otherwise we're soon going to be doing an update on uh 42-10 bits, which uh seems kind of silly, so let's just make sure those go together as long as they go quickly.

I

Yeah um one one question: Sean: are you planning to um support chem key proof of possession for pkcs10 and crmf.

F

Good question, but I suspect it will depend on what we need.

I

Yeah because pkcs10 sticks to self-signed, at least as of as of today, crmf has more flexibility here.

A

Basically, I think that was the reason crmf was invented was to be held in Keys.

I

A

Right so uh I don't know if we want to open up P10.

F

No I, don't that seems painful, um more well more pain than I really want to endure. Oh um yeah, we'll we'll get to that I mean my. My I know that um uh we've already had some internal discussions amongst the authors about the motivations in which way we would do it and I think there were some other people that sent me a message off list. That said, hey, if you guys are going to do this.

F

You also going to do this pop thing um and um we noted that we had this discussion and they provided their input. So I'm sure it'll be a lively discussion, as we figure out which one of the ways to to uh go but um yeah definitely on the thing and I'm also hearing put this higher up on the priority list and uh can do so.

A

Okay, great I, appreciate that, because I think that uh moving these together makes a whole lot more sense than doing a second second update the 42-10 bits.

F

No completely agreed I've I'm I've, been in your I've, been in your shoes before and I, don't want to add any undue pain. That's that's not required awesome.

A

All right any other comments about this.

A

Okay, is there any other business, then, uh if not we're going to wrap up six or seven minutes early.

A

Go ahead, Quinn.

A

You have to push the the microphone at the top again there you go.

A

Ahead, Quinn.

A

Maybe you're locally muted because we're not hearing you.

E

Are you hitting me now.

A

Yes, now we hear you.

E

Oh, thank you I'm, sorry about that. um Put that the rap and one of them was used to send um different Semitic keys to different um recipients right.

A

No it's in order to get the same key to all of the recipients, so the cam gives a pairwise and then you wrap on that pairwise. Okay,.

E

All right all right, so basically we do different instances for for everyone. Okay, all right, I got that.

A

E

Yeah, thank you.

A

Yep all right, if that's it, we're going to wrap it up here. Thank you. I think this was a very productive hour and uh we have action items for a couple uh document call for adoptions and we'll be having that uh shortly and uh I look forward to further list discussion on the topics that uh were raised by Mike all right have a great day. Thank you.

A

I

You bye thanks bye.