**Session Date/Time:** 23 Jul 2026 09:30

[00:00:05] **Russ Housley**: Before you contribute. These have to do with how we treat each other and things such as the IPR rules. Please treat each other very well. It's okay to attack an idea, but it is not okay to attack the person with the idea. People in the room need to use the on-site tool. This is important to make sure we get a room of adequate size. If you don't sign in, we might have a smaller room than we need. And people remote, please make sure you are only sending your video when you're talking. These are the resources for the meeting, the agenda, the notes, the chat, and the two links for me to go, the on-site version and the off-site version. We have a lot of work that is already done. And unless I'm there's a big surprise, the things on this slide, we don't need to talk about because they're with either just published as RFCs or are in the RC editor's queue. Notice we missed being the first five digit RFC by

[00:01:28] **Sean Turner**: two.

[00:01:32] **Hannes Tschofenig**: So

[00:01:37] **Russ Housley**: Okay. So the next slide, the the first group are things that are with the ISG. So, hopefully, those don't need discussed either unless, of course, we got AD comments or ITF last call comments since the agenda was posted, which could happen. Then we have the active documents. We're gonna go through those today. And then we have some that are under consideration for adoption.

[00:02:17] **John Gray**: That's the old that's

[00:02:19] Speaker 4: not the updated one.

[00:02:20] Speaker 5: Yeah. You're right.

[00:02:21] Speaker 6: Oh, okay.

[00:02:23] Speaker 5: Yeah. I I I will be running the meeting off the updated agenda, so don't worry. So, yeah, you're presenting cert discovery, and there's a couple of additional yep.

[00:02:34] **Russ Housley**: Okay. Thank you. Any agenda bashes? Yes. I just heard one that and it's been updated on the agenda slide. The chair slides were not updated. The agenda itself in the data tracker was. Okay. Then we're gonna get started. Who's up?

[00:03:38] **Hannes Tschofenig**: Thank you, Russ.

[00:03:39] **Russ Housley**: Okay. Clicker now works.

[00:03:42] **Hannes Tschofenig**: Let me see. Yep. Alright.

[00:03:44] **Russ Housley**: Go for it.

[00:03:45] **Hannes Tschofenig**: Cool. Okay. So we took a little bit of break with this document. We hadn't presented at the last IATF meeting or the one in in Canada before. And so now I'm back with a bigger update, this presentation and this update on behalf of my coauthors. So why did we not talk about this for probably, like, something like a year or so? Because there was this ongoing work on the CSR, the station document that we've been talking about. And luckily, we made good progress end of last year, beginning of this year. And so this document builds on top of that work. So there was a little bit of dependency there. We spent all our energy on completing the CSR attestation, and now we are back on this one. With a number of changes. So you you if you have read an earlier version, if you're interested in this topic, you should definitely read this new version because it's substantially different. Okay. So what did change? If you look at the the box on the right hand side, version eight, we tried to not just do the alignment, but we actually restructured the whole document because we cover now EST, CMC. We cover what else do we cover? CMP. CMP as well. Yeah. I forgot that one. So all these certificate management protocols, but in one architecture with sort of harmonized encoding, but, of course, with different protocol bindings, and I will get to that in a second. The the data model is sort of, like, unified, but, of course, the description on on the CDDL varies a lot. We use CDDL for EST and for for EST over CoAP and EST over HTTP ASM-one, and with the corresponding encoding for the other protocols, obviously. So how does the architecture look like? So the you see the request and request nonce or nonce request and nonce response from the entity to the relying party, which is part of the the document. So that's what the, the left hand side of the figure shows what the certificate management protocol does. The right hand side is also important, for for the thing to work, the interaction with the verifier, but it's not part of this document. It's a that would be work that is actually done in the in the rats working group. So but keep this in mind. So the the the red line here, this is a potential interaction that where the relying party interacts with the verified to request an ons, but it can also sort of generate it locally and let the verifier know later on those sort of deployment options, which we describe in the document as well. One note based on discussions, so what's in scope, what's out out of scope, we focus on the left side of the figure, the non spaced freshness, which means when the relying party or the verifier provides the nonstudy attestor, which is on the end device, on the end entity, it needs to compute the new or apply use the attestation key to generate a new signature over the evidence. That's what this document focus focus is about to get that nonce, to get that random value. There's another aspect to this, namely the question of if you have evidence and data in there, like, when was that data put into the evidence? Also important, but not part of this document is because it concerns more the format of evidence, which is work that is being done in the RADS working group. But there's often confusion about both of those in in every discussion. I'm going through this, so just as a as a reminder of what we're actually doing here. There's also now with this document, there's some extensibility put into the the exchange. So it sounds like on a very simplistic level, it's very easy. Give me a nonce, and I get the nonce. But then different attestation technologies have different or require different lens of nonces. So this is the the first part, the lens field, which is included in there. And then there's an extension mechanism to convey some additional information about the attestation technology that the device has, the entity has, which can be conveyed optionally in this request type info. And I'll show you an example later on on, based on an existing RFC. And with the nonce response, there's some, potentially some additional information coming back in addition to the nonce. That's sort of an extension point. There's nothing standardized in there. There's an example in there that illustrates it based on an, published RFC in the RADS group. But you will see in a second on, how that example what that actually means in case of a TPM or could mean in case of a TPM. Depends on what you want to do. I spoke about the protocol bindings. Here's a sort of short overview of how these bindings, how these messages get then mapped into specific payloads. Of course, they differ over the different protocols, the different certificate management protocols, and, of course, the encoding differs as well. Needless to say, this is sort of new in the document, like, I think better described. We have the registry for all of those now as well. But the semantics is the same across all these different protocols, obviously, intentionally. In each previously in previous versions, version o five when we the the intermediate versions were sort of stepped towards the the design we have now. We didn't cover EST well. Now that's in there. We use CTDL to describe the messages for both EST over CoAP S and also EST over HTTPS. We also reached out to the RADS group and the experts there to touch on one architectural issue, namely, what happens if a device has multiple attesters? Does it need to get multiple nonces, which we had in previous versions? So we had an request for nonce was actually not a single nonce, but you may have may, in some circumstances, may request multiple in a sort of a batch. We are now simplified it down to one nuns. There's some current work in the rats working group to deal with this so gonna so called composite at testers, which is what the figure is supposed to illustrate here. It's actually taken out of one of their documents where the single nonce is provided and then sort of fanned out to the different sub atestors on a device. And so you can actually use the same nonce to link the different evidences together. But there's a separate document referenced in the in the draft to explain you the full storage, just a hint on on how this works. We also got questions on the security and operational requirements, so we tried to address those. Those concern the the randomness, of course, the randomness requirements, also the the size of the nonsense, what is the minimum versus what is the maximum of those nonsense, and also deployment consideration when it comes to the linking of the multiple requests. So we are dealing with non request, non response, and then we need to send the evidence and potentially other certificate management protocol messages. How do we actually keep that transaction in sync as we are sort of relaying it also, that communication potentially also to a verifier? So those need to all go to the same parties, and we talk about this aspect as well. It's not a unique issue here with this, use case, of course. Like, everyone knows this in a in an HTTP context with web applications. Right? You have a database access and a front end interaction. You need to tie this up. But, of course, different certificate management protocols deal with this separately, have transaction state and cookies and whatnot. So also discussed, of course, registration, probably boring, but still needed. Here's the example I promised. This is so what does this show you? So this is obviously sort of the JSON based encoding. So this is the request coming from the end. On the left side, you see the request coming from the end entity to the relying party. It says, I want a nunce with a length of 32 bytes. And here's some additional information that I can provide. There's a specific type. The type indicates, like, this is obviously a type that is made up here because we didn't register that OID. But it then that OID describes what information is conveyed in this reg info payload. And what it says here is for TPM, it says, oh, I have two attestation keys. So in the TPM can have multiple attestation keys. It says, those are the two attestation keys I have, and this is the signature algorithm I support. And then on the way back when the verifier or the the relying party responds with the nonce, it then says the same type. And, of course, the nonce, which I didn't print here, but then it says, oh, I want to use this attestation key and please give me the PCRs, whatever, number. And this is taken from, I think what is the name of the RAC? RADS document, CHARA. Also referenced in a document, the the RAC. So this is referring to work that is ongoing in the or has been done in the RADS group. Mike, do you want to jump in? I'll wait to okay. I'm done soon. So so I think this this version is a good architectural alignment for you to look at in case you care about remote attestation. There is also, Giuliano, a student put together an implementation that shows the end to end story with CMP, with I think he uses Verizon, if I'm not totally mistaken. I see. Nodding, and you can find it here. It's yeah. Run it and and give us some feedback on this. There's one open issue that came up recently, I think, was it Russ, on the on the IANA registry. So this is there's a pull request up there. So beyond that, I we are we think this is making good progress. Mike.

[00:15:55] **Mike Ounsworth**: Hello. Mike Ounsworth. I have a presentation at SAG tomorrow, which you know about because you're a coauthor. Mhmm. But for everyone else in the room, we're starting to needle actually, with with Hannah's student, Juliano, we're starting to needle at privacy implications of rats. Can you go back to your extensibility slide? So what we're starting to sort of do research into is if the no. The extensibility, like the one that says extensible. Okay. So slide five or something. If the a tester wants to protect against the evidence getting logged by, say, a reverse proxy, then it needs to encrypt the evidence at the object level, not at the transport level. If the attester wants to tailor the amount of information in the attestation given for who the verifier is, then it needs to know the verifier identity upfront. This is, like, new. We've just started thinking about this this week. So my question is, is this extensibility mechanism sufficient to be able to jam all that kind

[00:16:53] **Hannes Tschofenig**: of information in later? Yeah. Yeah. It would be. So currently, it doesn't talk about it. And in fact, this is just we just included an example is, of course, the question of, like, should we actually register one mechanism and to to illustrate how it really works? We had that debate in the CSI at the station, had had information in there for some point in time and then stripped it out. Obviously, the same issue shows up here again, or should we leave that as an exercise for future work? So I think, like,

[00:17:28] **Mike Ounsworth**: the NOTS request, you've just defined this as a generic OID data. So if we decide later we wanna send down an encryption cert in the NOTS request, that that could easily be jammed in at a later date.

[00:17:39] **Hannes Tschofenig**: So it would actually be in a NONS response. But Sorry.

[00:17:42] Speaker 8: Sorry. Yeah.

[00:17:42] **Hannes Tschofenig**: Mhmm. Yep. Okay.

[00:17:49] Speaker 9: So this is. So for the part, because you have introduced the concept of the subartesters, so for each subartesters, maybe they need different verifiers. Then then different verifier may have different nouns. So you will think that that part will be included in the future version, or it is out of the scope how to manage these different nouns from different verifiers. So currently, if you have if each sub tester uses different verifiers,

[00:18:23] **Hannes Tschofenig**: you would have to run different protocol exchanges. Yeah. So there's no optimization to do it in one shot. Yeah. That's the sort of the trade off between because it the downside of doing dispatch things is that it gets complicated. Yeah. It gets very complicated. Question is, like, what's the main use case? And we thought that we should start, as simple as possible and maybe have optimize optimizations then later on, for these type of, use cases. But my understanding of the ongoing work is that this model is not a totally unrealistic model.

[00:19:00] Speaker 6: Oh, yeah. So it's

[00:19:01] **Hannes Tschofenig**: actually something that people want to do. Mhmm. So so it's it's a good starting point.

[00:19:08] Speaker 9: Okay. Thank you.

[00:19:13] Speaker 4: The previous slide you had with regard to nouns freshness versus claims freshness. Right? Yeah. Mhmm. Right. Freshness data and claims is at that snapshot. I mean, it may have been collected at a previous point of time, but when the evidence is generated, it's it's relevant at that point of time. It's not stale data. Right? It has not changed because there's nothing to change. Right? I mean, it's it's securely booted and nothing has changed. Yeah. So yeah. Though there was since there was no need to collect new claims, it's it's collected at a previous snapshot of time, but it's delivered even at the time when evidence was generated. So Right. That that makes lot of difference that it's it's fresh data, but collected at

[00:20:00] **Hannes Tschofenig**: a previous point of time. Right. The it the document doesn't impose any any restrictions on the attestation technology, it just says, give me the stuff. You need to compute the signature again to because you include the nonce in the evidence, but it doesn't say anything about that data because that would be for example, if you would want to say in evidence that, oh, this was generated at, like, five months ago and and didn't change since then, making this up or ten minutes ago, And I didn't do it and didn't do a measurement again, or it didn't change since then. This is not what this document does that you

[00:20:42] Speaker 4: I thought it's implied that it's

[00:20:47] **Hannes Tschofenig**: It we we might need to fine tune the wording. So I put some text in there. It I I don't think it says anything that it's implied at the

[00:20:59] Speaker 4: Yeah. Because it's relevant for other other working groups as well. Right? Yeah. They're they're relying on nouns, but not the claims. Yeah. And whatever you're doing is is people don't have to repeat the same thing in different words. Yeah. So if you get it right, right, this can just refer to this and get done with it.

[00:21:15] **Hannes Tschofenig**: Yeah. It would be it would have been great if this is this text is already available in some other document. We would just copy and paste it, but at least I couldn't see it. So I'm happy to take whatever text is available from from anywhere on this issue. I because we just don't want to deal with this. It's the wrong document, so so we do whatever other

[00:21:40] Speaker 4: people do. And on the lead register one. Right? Right. It's it's a good scenario that you have added the lead register, but I'm just trying to understand, like, if you have multiple Ts in a device, which is quite possible today. Mhmm. Right? And and why do I care about let's say, I'm storing private key in one of the TEEs. So why do I care about the state of the other TEEs? Right? I've been to really looking I I care about the platform, which is very much important and the TEE on which I'm storing the private key. Yeah. So is the application also supposed to be bothered about the state of the other TEEs? Like, it's good to know the posture of the device, but the the I don't see any much discussion on that. So was just wondering what is the security implication.

[00:22:32] **Hannes Tschofenig**: I guess

[00:22:33] **Russ Housley**: Is this about a RATS topic?

[00:22:35] **Hannes Tschofenig**: Right. That that's what I was trying to get to. It's I think it's a more a RATS multiple at testers topic to to really discuss on what that actually means if you have these composite devices like with GPU and NIC and and multiple TEs and who knows what and how how does this all make sense in a different scenarios. I I fear if I add that this type of discussion and this document, at a later point in time, we will have to remove it again. I'm I had that happened to me before. So I'm I'm sort of like don't want to complain, but

[00:23:14] Speaker 4: Thanks. One last question. I think you want to add some statement that multiple wafers are out of scope of this document?

[00:23:22] **Hannes Tschofenig**: It's not out of scope, but you have to do run separate exchanges with them.

[00:23:27] Speaker 4: How's that gonna work with regard to nouns exchange? So each each one has to be contacted to get in different nouns?

[00:23:34] **Hannes Tschofenig**: Yeah. You would you would have to like, if yes.

[00:23:41] Speaker 4: Okay. Thanks.

[00:23:42] **Russ Housley**: That's not gonna

[00:23:43] **Hannes Tschofenig**: work. Yeah.

[00:23:45] Speaker 10: Okay. We need to move on.

[00:23:47] **Hannes Tschofenig**: Okay. Good.

[00:24:03] **John Gray**: So I'm gonna talk very quickly about certificate discovery, the update since IETF 120. You'll see on the slide, there's actually six authors. That's because we combined the chameleon draft together with this one, so the two authors groups joined. So there's six of us. Not too much activity. We're working on simplifying the draft. So probably the biggest thing is that we remove the cert hash. So you see on version two on the left from the cert location. Remove the cert hash because RFC ninety seven sixty three came out, and it already has a binding property. So if you wanna use the cert hash, we didn't wanna have another option, you know, another field. Because if you need that property, then just use what they say in ninety seven sixty three, and you basically get the same thing. So just trying to simplify it so that some of the you know, that brought up some edge cases and things. We did get some we had some hackathon samples generated, but we wanna put them in the draft. So, really, that's pretty much it. So in our next step, we have, like, 12 open issues. Thanks, Daan Van de Woestijne, for your very thorough review. Thank you. There's eight of them we need to respond to plus a few others. So we need to do that work. So our group needs to get together and just do the work, finish adding samples for the different use cases that we've identified in there and get them into the draft. And then once that's all done, we'll ask for working group last calls. That's pretty much it.

[00:25:29] **Russ Housley**: One thing, if you have more than five authors that there's additional friction in the approval process, you might wanna consider that.

[00:25:37] **John Gray**: Okay. Thanks. Okay. We'll have discussions. Any questions?

[00:25:48] **Russ Housley**: K. Next.

[00:26:05] Speaker 5: Who's up? Once again, sir.

[00:26:08] **Stefan Santesson**: That's me. Great. Oh, so yep. One signature search. Since it's fairly fresh, if you don't have the background, it's a pretty simple profile for the situation where you generate the key before you sign the document, then you issue the certificate and bind it to the document you're about to sign. And then you sign the document, and you throw away the key. So it's the certificate is only used for one signature, and the binding is in an extension that assert that you're following this process. And because you do that, the certificate never needs to expire and never need to be revoked. So I'm gonna flip to this one. So since last IETF, we've done some updates, and we app actually updated the rationale for why you don't need revocation simply because if you revoke a certificate after you the signature is created, that doesn't invalidate the signature. So since we're only using the cert for one signature, revocation has no effect on the validation validity of the signature. Because we do not do vocation, there is no need to to expire the cert either. But we did change the requirements. It was a must never revoke and must never expire, but that's not necessary because when you process a certificate, you need to process these things that are in the certificate anyway. So it's a recommendation instead. If you have a strong reason why it would include revocation, a pointer because of your infrastructure requires that. You can do it, and you could put an expiry date if you want to, but that's not the typical use case. Then we added example certificates so that it's it's ready. Then it came up that the identifier we had, which was text is sort of string for the binding type, It's actually not like the ASM one style and requires IAN actions. So we decided now that we would change that to an OID. And when we do that, we're gonna update the IANA considerations and generate new examples. So the new structure is going to be binding type object identifier instead of an UTFET string, and we're gonna define the OIDs for the binding types. And that's basically it. And then finalize the draft, and there is no other recorded issues. So there are implementations. I have implemented this in our Sweden Connect implementation, and that's used to generate examples. If you follow those links, you can see those. And I have some emails from other implementers who wants to implement this as soon as it's ready. So it seems like there's an interest. So I don't think there is any other open issues. If there are, please post them. Otherwise, I think it's ready for work group last call and to ship it. Questions?

[00:29:59] **Sophie Schmidt**: Hi. So, Google. I'm a bit confused because usually if

[00:30:03] **Russ Housley**: you

[00:30:03] **Sophie Schmidt**: have an ephemeral signing key, you did something wrong and can replace the whole thing with a hash. Why do you need the the signing key here and can't just use a hash of this one document that you want to sign and then use that hash as a public key?

[00:30:23] **Russ Housley**: We could. We could, but the idea was to just let signature validation work as it always has.

[00:30:31] **Sophie Schmidt**: Yes. Okay. So it's it's more for, like Right. We want it to look like the other thing even though it it really cryptographically does really not have to be. Okay. Yes.

[00:30:39] **Russ Housley**: Correct. Okay.

[00:30:45] **Stefan Santesson**: Any other questions? I'm done.

[00:30:49] Speaker 5: Actually, that might be a good thing to explain in the RFC. Yeah.

[00:30:52] **Sean Turner**: Yep. We

[00:30:54] **Stefan Santesson**: we will address that. Good.

[00:30:58] Speaker 10: Okay.

[00:31:01] Speaker 6: Next.

[00:31:05] Speaker 5: And DSA.

[00:31:08] **Russ Housley**: Sean, you're up. You're not used to being at the

[00:31:18] Speaker 6: front of the room.

[00:31:21] **Sean Turner**: I'm gonna do my best my best punk rocking person. Making it making it all work. Alright. Cool. Hey.

[00:31:28] **Russ Housley**: No wrong FFN DSA. Yep.

[00:31:30] **Sean Turner**: That's not the right one. I don't have slides for this one. This is, yeah. So the, the best part about the FN DSA thing is the draft is entirely reliant on the FIPS. In talking with Daniel, we are gonna spend about zero time on it until we see said FIPS. So I'm not gonna ask ever again for agenda time for that one. So we're gonna go on. I guess we're gonna move on to the, S/MIMEbis. Oh, okay. Just knocked those out. I'm not sure if they're in the order that you sent you sent them.

[00:31:58] Speaker 5: Yeah. Just let me find which one you want.

[00:32:01] **Russ Housley**: Yeah. I'm sure the people who put the headsets on enjoy it.

[00:32:04] **Sean Turner**: I apologize that in remote hand. Trying to not throw it on the ground. It's cool. Mic drop. There we go. Those look like mine. That looks like you. Big and orange. Alright. That's my version three question mark. Not sure which ones. So we got two drafts. I actually literally put pushed the generate new release button about twenty minutes ago. I'm it's in the email's in ether land. So eventually, will show up, and it will be a working group document birthed. Awesome. It was supposed to be birthed on Monday, but I got busy. Didn't get to it. So today, hopefully. Basically, it's a clone of the individual ID just with the right tags right in the naming and stuff. So the work will begin, and that's why we're here. Lots of things to do for editorial things. It wasn't XML. Thanks, Jim. But, now it's gone. So, the real first thing is we have to pick up the the name of, the version number. I'm a a fan of the whole numbers, but I think it's gonna depend on what how much we actually change. So we'll get into that a little bit. Obviously, we have to the references has been a couple of thousand RFCs since have been published since this one was published, so I'll to deal with that. And since we're going to markdown, we're gonna make it look pretty. So when it renders, it's got all the the cool names. And so we're gonna back tick all the things. We did that for the CMC RFCs, which were recently published, and it was a tedious amount of work, but it looks a whole lot better. Alright. To do the technical parts. Alright. Sorry? Yeah. Know. I I should, like, learn to use that stuff. Right? So the Falco attack of kind of the really the reason why we started looking about this, looking at doing this a couple of years ago when Blake and I were looking at it was to try to figure out what to do with Falco. So there's really two options here. There's one is kind of like the easy path, and one is kind of a little bit more involved. So, a bunch of people, like Daniel and others, wrote this draft. The the that's I think what the ISG is the draft-ietf-lamps-cms-sha3-hash-sig-constraints to describe the attack and the mitigations that are available. So, basically, the idea is you've need to, like, put news. You need to, like, require attributes, and then the verifier needs to make sure that they're actually present. And so one easy way to do this is to require signed attributes be present. Right now, RFC 8551 and previous said it's optional. And there's a long list of them. Some are pretty pretty obvious like signing time, message digest, and a couple of others. So the easy way is basically to just require that these attributes or some of them, some set of them are always present, and then make sure that the verifier verifies they're actually present and if not fails the signature verification. The other option is to go a little bit farther, which is to use a different and and you can keep using the same ID data content type. If you switch to do option two, basically, you're still gonna have the signed attributes, but you're gonna use the new content type. So the question is, which one do we wanna do? So are you gonna do a show of hands, Joel?

[00:35:00] **Russ Housley**: Oh, really?

[00:35:01] **Sean Turner**: I don't know that we need to. Does anybody think that we should do option two? I mean, we're we're I'm suggesting other big changes as well. So, like, this might not be that big of a deal. If you were only doing this, then you, like, wouldn't do it, but there's a bunch of other stuff that we're suggesting that's pretty big.

[00:35:16] Speaker 13: Alright. Sean, can you specify whether you're saying that you option two means that verifiers require MIME data?

[00:35:25] Speaker 10: Essentially, yes. No.

[00:35:27] **Russ Housley**: No. No. Use the MIME data content type instead of the ID data content type.

[00:35:33] **Sean Turner**: Yes.

[00:35:34] **Russ Housley**: My data is is always present in the content.

[00:35:39] Speaker 10: Yeah. It's a new yeah.

[00:35:40] **Sean Turner**: But it's a it's a new asking whether

[00:35:42] Speaker 13: this is a requirement for generation or for verifiers.

[00:35:47] **Sean Turner**: It it will be for both is my understanding if I'm reading the way I'm looking at Daniel. Like, it requires that the verifiers ensure that the attributes are present. And that would be true anyways if you were checking the message digest, which gets included. So

[00:36:00] Speaker 13: So so you you would not be able to verify legacy signed data in this way? Like, all the legacy signatures would break because they're using ID data.

[00:36:12] **Russ Housley**: It's correct. That's a that's a real good reason not to do that.

[00:36:16] **Sean Turner**: Yes. You're right. So, yeah, if you switch, you'd have to have a backwards compatibility mode where you did both.

[00:36:21] Speaker 13: Right. Well, sorry. So what I'm trying say is we definitely should require this for generators, But requiring it for verifiers is gonna cause a world of hurt until all of your That's right. Peers have updated theirs their signing process. So I think it's a two phase process. I know you want it to be all nice done in one fell swoop, but I

[00:36:41] **Hannes Tschofenig**: think it's a two

[00:36:42] Speaker 6: phase process.

[00:36:43] **Sean Turner**: Yep. Fair enough. Good point.

[00:36:47] **John Gray**: Yeah. I was just gonna kind of say almost the same thing. ID data will be better bat for backwards compatibility and those types of things. Agree.

[00:36:58] Speaker 6: Daniel, I think he's I'm not advocating for a world of hurt. I'm just playing just playing out that verifiers will then have to check if it's v three or v or three or earlier versus four and then actually follow the recommendations in the CMS draft to check that the signed data is there for v four and for v three, YOLO.

[00:37:20] **Sean Turner**: Yeah. So, I mean, that's the, yeah, that's the fun part is trying to figure out the backwards compatibility text, and that gets into our next topic. If we're if we're gonna move to something that is, you know, on the next slide and we think we're we should be able to mandate AES-GCM, We don't really need enveloped-data anymore on the sending side. So I'm just saying we don't use it. It was kind of hinted at in version four that we were gonna go away, but this is kind of a big change. And, you know, I'm up here writing this. I'm not slinging code. So making these recommendations is great, but I wanna make sure that people are actually writing code or like, yeah. Yeah. That's cool. So I'm looking at all of you out there who do these things for an actual living. So I'm definitely interested. I don't need an answer right now, but let that the the way I'm thinking is that we should go ahead and just drop a PR to, like, basically get rid of enveloped-data except for backwards compatibility and whatever weasel words we need to put around there. Anybody think that's a horrible idea?

[00:38:18] **Russ Housley**: You know, people that do Outlook, Thunderbird, speak up, please.

[00:38:22] **Sean Turner**: Yeah. So we're I'm actually reached out to try to find some people at Microsoft that respond. I know we actually found a couple of other new implementers that actually started from scratch recently. So that that'll be really cool to get their input, and I'll reach out to others to see. Because I know there's various open sources around to try to see if they're they're gonna pay attention. And, obviously, you know, RSA encryption, like, can we just get rid of it? We'll see. It's we took it out of one protocol and then it came right back. So we'll go from there. The other thing is the ASM one in the document is based on 1988 syntax. I graduated from high school, and I got a long gray beard. A lot of you are a lot younger than I am. This probably predates your birth. So maybe it's time to move on to the latest versions. We have ASM modules that will work. There will be the the same people that complain every time we move. I think we'll complain. I'm not saying it's not a thing, but I think we have enough open source compilers that we can because we can we can update stuff. So I think it's okay. And there's others, GitHub issues. If you wanna add new something new to add, feel free to jump in there. Alright. So the next slide has a picture of a duck because that's what I'm gonna do. I don't want to tell you what to do here, but we have a lot of options. And so the question is, what are we gonna do in terms of picking the thing that we're gonna do? And I don't wanna run that process. I'm looking at you guys. I know you wanna get 500 messages about, like, private key formats doing this all again, but I kinda think this is one of those weird things where it's like, okay. Where can I legitimately get search from on off the public Internet? And those are the kind of algorithms we should be targeting, but this is me spitballing. And I don't know if anybody has any other options, but, like, I don't know how to make this choice because we have a lot of options in many of these drafts, like, 20 or so. Right? So whether it's pure and whether it's hybrid, like, you know, I don't know what to do. So I don't know how to frame this other than to

[00:40:19] **John Gray**: Well, I just have one comment. I mean, the basic thing first is you'll have to use the kem-recipient-info from draft-ietf-lamps-cms-kemri

[00:40:25] **Sean Turner**: 99. Because that's a million.

[00:40:26] **John Gray**: Like, the, you know, the infrastructure. What algorithm they choose? Yeah. I mean, that's there's always debates about that.

[00:40:32] **Sean Turner**: So it is. But, again, this document is about actual interoperability. And the last time we did this, we fought, like, key sizes in which algorithm and all that. So if we're gonna follow this I mean, I'm happy to rip it out and have it just be a straight protocol thing. But if we're following the same mode, we actually have to make these decisions and

[00:40:48] **John Gray**: Mhmm. Yeah.

[00:40:48] **Russ Housley**: So in the chat, says two step again.

[00:40:55] **Sean Turner**: I don't know what how to do a two step, but okay.

[00:40:58] **Mike Ounsworth**: Mike Ounsworth, very opinionated opinion. I think MTI as a concept is, like, paper thin away from just, a dumb exercise and wasting time. So whatever we do here, can we, like, not spend a lot of time on it?

[00:41:10] **Russ Housley**: That's what

[00:41:11] **Sean Turner**: I'm hoping. I'm I'm seeing a couple thumbs up here. Basically what I was hoping. That's why I put it in here. It's like, we can do it, but maybe we can do it at the end. Because, again, we have to update for the for the, you know, the recipient info is a big is a big change. So that's kind of a heavy lift. And once we get there at the end, maybe we can just figure out how to do So do everything else but pick the algorithms I'm perfectly fine with.

[00:41:32] **Stefan Santesson**: And that is it.

[00:41:36] **Russ Housley**: No. No.

[00:41:43] **Deb Cooley**: I'm Deb Cooley. I'm your ID, but I don't have a hat on right now.

[00:41:46] **Sean Turner**: You don't?

[00:41:46] **Deb Cooley**: So I don't. Don't? I mean, I really don't. Really?

[00:41:49] **Russ Housley**: Okay.

[00:41:50] **Deb Cooley**: So this is S/MIME. Right?

[00:41:53] Speaker 6: Mhmm.

[00:41:53] **Deb Cooley**: You have to know what the recipient can do before you send it. Mhmm. So in this case, this is not a real time ex you you're not negotiating nothing here.

[00:42:05] **Mike Ounsworth**: That's correct.

[00:42:05] **Deb Cooley**: You have to know. Mhmm. So MTI is a thing.

[00:42:08] **Sean Turner**: Yeah. Mhmm. I'm aware, but I wanna have the thing at the end. Right. Because all the other stuff that we have to change, we have to make support that. Yeah.

[00:42:16] **Deb Cooley**: But just remember that you can't, like, you can't fake this.

[00:42:18] **Russ Housley**: Capabilities was the thing we tried to the standardized.

[00:42:22] **Deb Cooley**: Yeah. It didn't work, though, did it?

[00:42:23] **Russ Housley**: It didn't get picked. It just

[00:42:25] **Deb Cooley**: This is why I don't have a hat on.

[00:42:26] **Sean Turner**: With the market.

[00:42:27] **John Gray**: This is

[00:42:27] **Deb Cooley**: why my hat's not on. Right? That I'm retired, I actually don't care. Yeah. But from a from a purse from a professional point of view. Yeah. Right? But from a yeah.

[00:42:39] Speaker 5: Yeah. No. I think what would probably work better is instead of just having the lamps room, try to figure out what MTI is because there is a lot of, there is a lot of benefit to having MTI. You're you're right about that. It really needs to be you can't really do MTI until you know a consensus of what the industry has actually decided to adopt.

[00:42:58] **Deb Cooley**: Yep. Right. So they'll pick MTI?

[00:43:02] **Sean Turner**: Yep. Yep.

[00:43:03] **Deb Cooley**: Okay. Well,

[00:43:04] **Sean Turner**: we'll see. We'll see. Right?

[00:43:06] **Deb Cooley**: But Yeah. Well, most of the room did not see my eye roll.

[00:43:09] Speaker 5: So Yeah. Yeah. No. I I mean, it's it's going to be, like, look at them, see kind of where they are. They'll be all messed up, and somebody will be over there, and somebody will be over there, and we'll be like, hey. These three implementers have sort of gathered around this set of algorithms.

[00:43:26] **Deb Cooley**: You can put them in room and make them work it out?

[00:43:28] Speaker 5: We'll see. Right?

[00:43:30] **Deb Cooley**: I know. Right? Cage match.

[00:43:31] Speaker 15: Yeah. I see it.

[00:43:32] Speaker 5: But, yeah, I I think this this group of people is the wrong people. It's the actual implementers in the industry we care about.

[00:43:37] **Deb Cooley**: Absolutely. Yeah. But you can't fake it.

[00:43:40] **Sean Turner**: No. No. No. I I agree, but I think we can put it up. We can put off whatever that cage match is gonna be till later. Alright. Cool. Thank you.

[00:43:47] Speaker 15: Thank you

[00:43:47] **Sean Turner**: very much.

[00:43:52] **Russ Housley**: We have fifteen minutes left.

[00:43:58] Speaker 5: ESP.

[00:44:07] Speaker 6: Who's gonna talk? AST.

[00:44:20] **Russ Housley**: Come on up.

[00:44:23] Speaker 4: Yeah. Well

[00:44:28] Speaker 16: There there's no slides.

[00:44:29] Speaker 6: That's fine. Ah, okay.

[00:44:31] Speaker 16: No. So we we didn't we didn't ask for us a slot because the authors are working through the comments that we received. We started kind of trying to answer those questions, but we were lazy. We couldn't get that document updated before this meeting. So our plan is to update the documents, publish it before San Francisco, and hopefully discuss it in San Francisco.

[00:44:56] Speaker 6: Alright. Thank you. Yeah. Maybe any

[00:45:01] Speaker 5: updates on further cam?

[00:45:03] Speaker 6: The Just get it.

[00:45:05] **Russ Housley**: No. There's somebody who's gonna speak and tell us where we are with Frodo. Come on up. There should be one slide. Yep.

[00:45:17] Speaker 6: Wrong one.

[00:45:18] **Russ Housley**: Wrong Wrong one. No. No. Okay. He'll get the right

[00:45:24] Speaker 17: This line is hello. I'm from lamps-cms-frodokem certificates. There's no slides because there is no actually any substantial update to the draft except for adding a reference to ISO standards that has just been published just before it is meeting as, you know, as as informative reference is this draft. Well so we're still waiting for to make recommendations. So whether further is okay to use in x five zero nine or not. So the draft is currently parked.

[00:46:01] **John Gray**: Thank you.

[00:46:02] **Russ Housley**: K. Yulin, you wanna come on up? You're gonna say almost the same thing. I I

[00:46:10] **Deb Cooley**: have one slide.

[00:46:12] **Russ Housley**: Okay. One slide. You don't need to click on that.

[00:46:14] **Yulin**: I'm a lady, so I prepare one slide here. So their core changes here that we just to focus the the inference here and also the same ways where we we will keep in touch touch with CFRG about the the FrodoKEM. They are processed in in their draft. Okay. Thanks.

[00:46:43] Speaker 6: So, despite it being parked, I wanted to point one thing out that in the CFRG draft, they have added the ability to store the private key as a seed, echoes of the war from a year ago. So I think we should update lamps-cms-frodokem to address that earlier than later so that we don't get kneecapped like we did last year. So I'm gonna send a message to the list saying Yep. This is what we should do. Hopefully, we update it quickly. Thank you. I think I'm up. Not much next. Updated Parameterized SIGNED ASN.1 Type for X.509 (PKIX) Yep. And now I'm here. Slides? Yes. There it is. Yes. Perfectly. That's cool. Okay. So this is a proposal to make a hopefully fairly fairly simple draft to update the ASN one type signed type for x five zero nine. It turns out that we have a problem with the containing clause and assigned, ASN one type in the 52. I'll see the draft number later. It can refer to an absent absent type. So in RFC 5912, in a signature bit string, it contains a signature algorithm value field. That field can be optional in a number of algorithms, including composites. MLDSA, blah blah blah, or is it even? The value is not assigned or not defined. What this means is once you go back to the signed, you are containing more. So turns out that this is not really valid ASN one. The syntax checkers and the compilers will let it slide because the type might be present for other signature algorithms, But decoders compiled from these modules will explode when actually parsing content for objects where the type is not absent where the type is absent. Sorry. I didn't right. I didn't someone told me it exploded, so I don't know the extent of exploding, but it will fail, and it should not fail. So the proposed fix is just to create a new, ASN one module, which uses a simpler version of the signed type, which doesn't have any of the ASN one constraints in. Side effect of this is that there will be no more constraints for DSA, ECDSA, and SA no signature. The code will have to deal with that. There was also an alternate fix proposed by Mike St. Johns to change the constraint by, to refer to the to be signed, and then throw a lot of pros in there for the developers to deal with. I don't know which one is better or not, so it's up to ASN one experts better than I to help decide that. Additionally, in the OneAsymmetricKey RFC, there's a commented out option, which does the same thing. So the current proposal was to just remove that comment. Alternate proposal would be to update that comment with the same suggestion that Mike gave. So we've actually seen this in the real world. Someone contacted me who is implementing the composite MLDSA using an ASML compiler using those modules. So, this could be a problem for other people in the future. So my question is, does the working group want to adopt this and potentially help those people? That's it.

[00:50:20] **Russ Housley**: Anyone wanna speak against adopting? Okay. Then we're gonna take it to the list.

[00:50:28] Speaker 6: Thank you.

[00:50:41] **John Gray**: Hi. It's me again, John and Gray from interest. So I'm gonna talk about, I think it's the composite PKC. Yeah. Preventing key reusing cross key forwarders and composite MLDSA. So that's myself and Ludovic been looking at this. So the motivation for this was essentially if you remember, we had lots of discussion about composite-pubkeys That's probably why we only have an hour long meeting now because we're not talking about them very much. But, anyway, we had we did have a a point in the draft where there was a a a public key in the kind of message format, but then that was decided that it was too complicated. One of the reasons was, how do you pick up the key? So and part of that motivation of having that there was it can cryptographically prevent, key reuse. Right now in the draft, we have language there saying don't do this. But if you require if you actually have the public key in there, then the verifier will actually require that, right, in the message. And the signer yeah. So there's that. And then there's this kinda cross key forgery attack where you kinda mix the two keys. So you sign the same message. You mix parts of the first key and second key, and you can kinda get get this, like, phantom signature kind of thing created. It's not really a problem in certificates at all. Well, it isn't because they're bound, you know, with the certificate signing key. But if you had other kind of niche use cases where keys aren't signed or just they're on their own, that can be a problem. So having the public key in there will prevent that. So, I mean, the solution's pretty simple. We have right now, we have this optional context. Right? It's a it's a length in the context. And just like MLDSA has, other algorithms have that we put in there, we think these things are good for the future. Well, it turns out if we you can just let the context equals the the hash of that public key, the the composite public key, it's pretty easy. And then the hash is just the same hash value that's specified by any of the composite combinations. So really nothing has to change except now we've just specified an application specific context. So, you might have a few questions about this. Well, how will the verifier know when to bind in the public key? Well, this would be for their own application use. Right? So if they decide they want this little bit of extra security, they can decide to do it. I mean, the other way to do it would be to supply OIDs for each of them, but I'm not planning to roll another 18 OIDs. I know we've had that discussion, so I'm sure you guys probably don't want that. If you did, we could do it. But it just be if basically, application context if someone wanted to do that. Then the question is how is the public key carried with the private key? Well, actually, turns out it's actually not a difficult thing to do. You can actually generate public keys from the privates for MLDSA, for RSA, for EC. It can be done. We actually did it in. There's other if if if you didn't wanna do that, there's other ways that can be done as well that are mentioned there. The PKCS eight, one symmetric key has an option. It could be fetched from an external data source or some other way of doing it, that alternate private key encoding. So it's it can be done. And the last question that you might have is what if I wanna use my own application specific context with this one? Well so currently, I did not put that in the draft. I just wanna keep it simple. But if we wanted to do this, you could just have, like, a hash over an application context and then the the the public key context as well if we wanted to do that. I'm not it's not there now. It's just I'm trying to answer your questions before you ask them. So the the next steps would be, like, to call for adoption. I I think it's a useful thing for certain. And and as an informational draft. Right? So we're not saying people have to do this. It's just if they wanna do this, if they want, there's a little bit of extra security. Questions?

[00:54:37] **Russ Housley**: Does anyone wanna speak against adoption? Okay. Then we'll take it to the list.

[00:54:48] **John Gray**: Okay. Great. Thanks. And I can do the next one really quick.

[00:54:51] Speaker 15: Mhmm.

[00:54:52] **John Gray**: Really quick. And please don't give me a groan when you see this, but this is slides are gonna come up, but it's a new p q p q composite combining FNDSA

[00:55:08] **Hannes Tschofenig**: Oh my god.

[00:55:08] **John Gray**: To an LMS.

[00:55:09] **Russ Housley**: I forgot the groans.

[00:55:10] **John Gray**: Yeah. Sorry about that. But and it was actually myself and Jean-Pierre Fiszman. And you might say, okay. Why would you combine these two? Well, both of those algorithms have sharp edges. We know that LMS sharp edges are this is a stateful hash based signature algorithm. FMDSA, well, we haven't seen the final FIPS draft from this, so we're hoping they're fixing floating point issues and all that stuff. So, anyway, they have complementary hardness problems. Mhmm. But they are they are very small. Right? That's the signature that they produce. So if you combine them together, you get a very small compact PQ PQ composite. And so what we are suggesting and if we do this, we don't want 18 combinations of these guys. We just like three at the most. So we picked three kinda lows well, lower security, medium, and higher security. So there's the combinations. And then this is just for comparison, what it would look like, the public key and signature size of them combined together. It actually ends up being about 30 to forty thirty to 40% smaller than MLDSA itself as a peer. Right? But this is actually a PQ PQ comps. So that's that's basically it. So, obviously, this would be early to adopt because we still well, not to adopt. I would ask for adoption. But I'm sorry. I didn't talk about this. So it just uses the same signature combiners, composite signatures, which is about to become an RFC. Ask for adoption. Obviously, we'd have to wait just like we do for the f n d s a draft that Sean is doing until that thing comes out by NIST before we could get this finalized, but just wanted to

[00:56:47] **Russ Housley**: start this. LMS.

[00:56:49] Speaker 8: Hi, Scott. K. Obvious question. Other than the fact that LMS is self descriptive, there are therefore, you can just have a generic. Why shake? Why not what's wrong with SHA two?

[00:57:03] **John Gray**: Yeah. So we actually did have SHA two when we were first doing this, but shake because it's it's underlying. Right? It's LMS uses it. I mean, it was just to reduce the surface area of the the the crypto library. Yeah. Viktor, I guess, has a question.

[00:57:22] Speaker 19: Sure. It it's already too late for the composite chems, but we really rather have a mess there with my favorite topic, private key formats, where we have a single seed in the HPK case from which we derive two seeds from which we then derive the keys. And then on the lamp side, we have two independent seeds, and isn't it a lot of fun? What are we doing here, and how will this avoid the same trap of the HPK people coming along and saying, well, for these algorithms, there's one seed for both halves. And instead, you know, on lamps side, I don't know what the plan is.

[00:58:02] **John Gray**: But this one's a signature.

[00:58:05] Speaker 19: But the but well, but the it's a signature algorithm, so they'll we'll have private keys. Yes. Private key format.

[00:58:13] **John Gray**: Yeah. Yeah. So the private key format, I think, for LMS needs to be defined, and that'll probably be a separate draft.

[00:58:19] **Sophie Schmidt**: Can I can I take the key question?

[00:58:20] **Russ Housley**: We got a really long queue.

[00:58:23] **John Gray**: Sorry. Your compass is getting

[00:58:25] **Russ Housley**: to do This is going to be the end of the meeting. So we will drain the queue here and then wrap up.

[00:58:34] Speaker 8: Okay. One problem with LMS is it's stateful. Therefore, the private key has to include additional information.

[00:58:42] **Sean Turner**: Mhmm. Right. Yep.

[00:58:44] **John Gray**: Yeah. I don't think it's defined yet. So there would probably need to be another draft for that. JPS talking about doing that. Flow's next.

[00:58:58] **Flo Driscoll**: I look, I'm just gonna go. Flow Driscoll. I think it's gonna be it's gonna be difficult enough to get people to migrate to PQC authentication in any sort of reasonable time. I think unless there's, like, a really good use case for this, which I I haven't heard, I'd say, can we just not do this, please?

[00:59:16] **John Gray**: Well, would be more for the future. It's not for a p q migration. Right? Like, a p q p q strong?

[00:59:27] **Flo Driscoll**: I'm I'm not a fan, but others may feel differently.

[00:59:31] **Russ Housley**: Alicia?

[00:59:34] Speaker 15: Well, pointed out, the elements private key is the reference to the hardware that has the private key. So there is no. And definitely and for f and dsa, even this is saying that, no. Actually, you cannot have seeds for it because the key generation is very undeterministic about how it's implemented and so on and so forth. So it's only expanded. In general, like, seems to me a terrible idea. Sorry.

[01:00:05] **John Gray**: Thank you for that comment.

[01:00:09] **Sophie Schmidt**: Hi, Sophie Schmidt. I came here to say basically what Alicia just said. FNDSA keychain takes quite some time. You can't use seats for that. And, also, this is a horrifyingly cursed idea that I like, I really don't see the use case. Without a clear use case, I would not adopt it. Like, I really try to be nice here. But

[01:00:34] **John Gray**: Yeah. Yeah. Yeah. I think the use case anyway. Yeah. It was more of a constraint like, there was more of a constrained devices, IoT type stuff, but

[01:00:44] **Mike Ounsworth**: firmware signing that Mike? Two thoughts. I think the use case, as I understood it, was if you bork your LMS private key, you're not in well, you you you don't you should probably stop using it, but your data might not be host.

[01:00:58] **John Gray**: Right. Yeah. I mean, it's the resiliency between the two. Yeah.

[01:01:02] Speaker 15: It's just just to give

[01:01:03] **Mike Ounsworth**: you a redundancy if you if you leak your private key Yeah. Of your LMS. To Viktor's comment about the private like, we don't require like, we specifically added four whole paragraphs of Weasel words to allow you to do the HPKE combined keychain if you want to. We gave like, specifically you, OpenSSL, we gave you a whole four paragraphs of

[01:01:24] **John Gray**: Weasel words to let you do

[01:01:25] **Mike Ounsworth**: your private keys. I don't know why this is still coming up. Goodbye.

[01:01:29] **John Gray**: So I see Jean-Pierre might wanna say something. He is an author coauthor. He probably has some use case.

[01:01:35] **Russ Housley**: We're already over time. Be quick.

[01:01:38] Speaker 10: Ultimately, people in this room are not crazy about LMS, but we do have customers that rely on it. And FN DSA would allow them to sidestep the the state issue. So not everybody will agree on this, but there there's use to it, obviously.

[01:01:57] **John Gray**: Yeah.

[01:01:57] **Russ Housley**: Okay. Thank you. Thanks. We will talk about what to do with the rest of the agenda. Clearly, we couldn't do it in an hour. So thank you very much. I thought we could do it.

[01:02:21] Speaker 6: We only missed one.

[01:02:24] **Russ Housley**: I think we missed one. Yeah.

[01:02:32] Speaker 5: But, yeah, it it would be nice to be a little bit more leisurely than the pace we ran.