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

[00:00:26] **Aaron Pratt**: Please. Alright. Let's do this. Yo, would you like the honors taking us away?

[00:00:53] **Yoav Nir**: Sure. I think you got the slide control.

[00:00:56] **Aaron Pratt**: Oh, I do. That's true. Mhmm.

[00:01:00] **Yoav Nir**: So welcome everyone to the ACME meeting and ITF one twenty six. Some of us are in Vienna, some are not. Note the note well well. This you've seen the slide many times if you've been at this ITF meeting. The QR code is about the registering participation. Or or or is that or does that lead you to the RFCs mentioned in this slide?

[00:01:28] **Aaron Pratt**: These are the policies.

[00:01:29] **Yoav Nir**: It's okay. So it's linked to the policies. I'm not going to try to rephrase the policies in a few words. This is somewhat discouraged, but these are RFCs about harassment, about IPR, about all the kind of rules that govern working in the IETF. So please read them. If you think you have an issue with them, you can contact chairs, your ADs, or your company lawyer. So next slide. Make sure that you sign in to the session via the data tracker if you're remote. Use the QR code in the session if you're on-site. Use the on-site tool if you are on-site. And if you're connecting from remote, please use a headset. It doesn't really work well if you're trying to do it without headset. Even though I know that some other programs do work well without headset, MeetEco has these special challenges since it's combining people in the room and people outside the room, and that's a difficult task, and headsets help. Right. And if you are participating, state your name, and everything is recorded. Okay. Next. Here are some links to the agenda, to meet echo information, and technical assistance

[00:02:57] **Aaron Pratt**: if

[00:02:57] **Yoav Nir**: you need. So far, we don't have any in this session as far as I know. If you do get problems in your remote, please write it in the chat so that Mike and I can see it. Next. K. So we have drafts with the ISG. There's the ACME integrations. It's blocked in the cluster with Anima and BRSKI. Is that really with the I ISG, or is it already in the with the RFC editor?

[00:03:30] **Aaron Pratt**: It is with the RFC editor. The the Anima BRSKI cloud. Do you know what's Hey. Was hoping Michael Richardson will be in the room, but I think he's not. Dev, microphone, please. Dev, microphone, please. So

[00:03:51] **Deb Cooley**: I looked at Acme integrations a little while ago, not not today, maybe earlier this week, just because it's sort of fun to look at the clusters. The the the RFC editor stuff has all changed, and so it's easier to look at now. And you can see better what's relying on what and what's waiting on what. And so I think there's a couple things that are that are needed, Anna, before you before Acme integrations will be finished. The one below at Acme device attestation is waiting for me because I haven't had a chance to look at the changes Corey made.

[00:04:23] **Aaron Pratt**: That one's had a healthy amount of back and forth with discusses and comments, and it's, I would say, not blocked, moving well.

[00:04:30] **Deb Cooley**: So we had an agreement. I think there was one last discuss, which was Mike Bishop. And he had agreed to clear Mike Bishop had agreed to clear the discuss based on Corey's update. And then I suggest that they go back and really think about the update because they are updating a five five five with this. And so go back and look at the update and make sure it's really what you want in terms of an update to that RFC. And he went he changed it. I've not gone back to Mike Bishop to say, here's what's gonna I don't think he's published a new version either, has he? Not the type. Yesterday. Yeah. It came out. Yes. That's it's in my inbox.

[00:05:08] **Aaron Pratt**: So there is something here to flag for the broader working group, which is after it left working group, we decided it really needs to be updates eight five five five because it's changing normative behavior in one edge case. So the working group members may want to take a quick look at that discussion if you care about such things.

[00:05:25] **Deb Cooley**: Mhmm. I I do think so. Right? And I thought we've done that. Did we not do that?

[00:05:30] **Aaron Pratt**: I mean, the discussion's all on the mailing list, but

[00:05:33] **Aritra Sen**: we're remember

[00:05:33] **Aaron Pratt**: it's like all on the mailing list.

[00:05:34] **Yoav Nir**: But some

[00:05:37] **Aaron Pratt**: of it's

[00:05:37] **Deb Cooley**: on the mailing list.

[00:05:39] **Yoav Nir**: So so the difference is that the second item is something that the people in this room or at least on the mailing list can move forward, whereas the first item, we're waiting on others.

[00:05:49] **Deb Cooley**: Yes. The first item you're waiting on you're waiting on normative references that are either not received yet or not through or not something. And it's not in the security like, the the normative references are not in the security area. If somebody actually can cared about Acme integrations and you really wanted to do something about that, you might be able to actually do a little bit of rewriting and get rid of the normative reference that isn't available yet, and therefore, get it published. Like, we've done that in a number of other places. Like

[00:06:20] **Yoav Nir**: The people who wanted this are people who were heavily participating in Anima and BRSKI more than they are in acne.

[00:06:27] **Deb Cooley**: Four hundred years ago. Right? I mean, I was Cher when this came through. Right? So it's been at least two and a half years.

[00:06:36] **Yoav Nir**: Think it came

[00:06:36] **Deb Cooley**: Oh my god.

[00:06:37] **Yoav Nir**: Before you were Cher.

[00:06:38] **Deb Cooley**: So long ago. Right. So nobody's screaming for it. It's gonna sit until, like, whatever happens in Anima or whatever. If somebody wants to change that, then we need to go back and we need to do some rewriting of acne integrations. I like I said, I don't I don't remember because it's been forever exactly whether that's possible or not. Right. We have done this with other drafts, though. We have rewritten them to to basically make a normative reference not normative so that you can actually publish it.

[00:07:10] **Aaron Pratt**: Right. Okay. So, yeah, ACME integration's blocked. Device attest is clearing its discusses, and if you care about the normative changes, things like eight five five five, go look at it now.

[00:07:22] **Deb Cooley**: Yeah. I and if you wanted to do a short sort of informal working group last call with that, I think it might not be bad. Yeah. And that gives me an excuse to not do it this week.

[00:07:39] **Aaron Pratt**: Take something off my plate. Please.

[00:07:43] **Deb Cooley**: Do you know what I'm saying? So Mhmm. Because once I look at it and once we've cleared and discussed this, I can push the button and it's gone. But I do think if you I do and then that's what I said to the authors when I after after Mike Bishop said he was okay is that you just wanna make sure that these updates to eight five five five are what you want.

[00:08:05] **Aaron Pratt**: Properly flagged.

[00:08:06] **Deb Cooley**: But they don't open up, like, massive.

[00:08:10] **Aaron Pratt**: No. It's the obvious behavior, but it is a change to. Yeah. Okay. Perfect. Chair action noted. Let's continue with our agenda. Yep. Okay. So that's done. So adopted drafts. I crafted the agenda to give ten minutes to all the adopted drafts. We have not received slides for all of them, so some of these may be skip and we get some time back. But these are all adopted, and we'll go through them as much as is needed. And then we have a reasonably crammed new business section. Yoav, can you mute yourself when you're not actively speaking?

[00:08:47] **Yoav Nir**: Sorry.

[00:08:49] **Aaron Pratt**: Yeah. So these these bunch of new business topics, some of these have been to the working group before. The pk-01, Acme public key, we've seen before. Plants and MTC, if you're following plants, we've seen before, and the rest of these really are new. So we will have to see when we get there how much time we have and how much discussion. Some of these, I think, really do deserve some proper discussion. I suspect the p q g PQC agility profile will take some discussion. Sorry. Sorry. I'm sorry. Not the PQC agility profile. The one before, the PQC the Aritra's draft probably will take some discussion. And then the last two, the s m two in Acme, I'll note these were drafts that were only submitted to data tracker three days ago. So I suspect very few people in the room have read them. Hopefully, we have time for the presentation. We should decide as a working group whether we want to hold the discussion now or whether we want to delay the discussion until people have had time to read the documents. And we could do that on a list. We could hold an interim. We could if if the authors are okay to delay until San Francisco. So let's see how deep we get in the agenda, and we'll decide how we wanna handle the discussion points here. So first up on the agenda, Chris for JWT claim constraints. Do you wanna just come up and say a quick word about where that's sitting?

[00:10:16] **Chris Wendt**: Yes. We were in working group Black's call and didn't get a lot of reviews. And Mike very kindly came to STiR and asked for some reviews. And so we may get some more, but I think we did get a review from Russ who arguably is one of the more important ones since he's the author of JWT Clean Constraints, but both the original and the extended. So so glad to appreciate his review and noted his suggestions, and I'll work on a on an update for that. But that's where we are. Maybe we can get some other STIR folks, but I'd I'd say, again, Rust was one of the more important ones. So

[00:11:06] **Aaron Pratt**: So as chair on this one, it's currently in working group last call. That last call is currently open. I'm looking for two things. I'm looking for a review from the STIR community to say if this draft is well written and implementable and sound. I'm also looking for at least one review from an Acme person saying the same thing about the Acme bits of it. So Russ has given a review, which I have not I mean, I haven't read yet. I'm looking yeah. If we can get at least one other review on specifically the Acme bits of this, that would be great, and then we can close the working group last call.

[00:11:39] **Mike Bishop**: Yep. Sounds good.

[00:11:40] **Yoav Nir**: Thank you.

[00:11:43] **Aaron Pratt**: Okay. DNS account label. We have slides for this one, I do believe. No. We do not.

[00:11:53] **Amir Omidi**: Okay. So this draft is in last call. We have so far support from people. The drafts, like the actual technical challenge, has been stable for a few years now. It has been added to the CAD form VRs for the WebPKI, which is currently the larger users the largest user of Acme. We have three or four CAs at least that have implemented this. There are at least three or four server side implementations that are interoperable with at least four clients. And, basically, I don't think there is something for us to do. We are waiting for the last call. I don't know if there are any comments or anyone else who wants to review it.

[00:12:49] **Aaron Pratt**: Yeah. Let me quickly check the last call date because that one is, as you say, currently in working group last call.

[00:12:56] **Amir Omidi**: Yes.

[00:13:02] **Aaron Pratt**: Also, while we're paused here, we forgot to ask for note takers. Right. This has been a lost call for a very long time, in fact. Yeah. So we're waiting for reviews at all to be able to close this out, please.

[00:13:38] **Amir Omidi**: Yeah. I think we have, like, three so far or something. Three or four.

[00:13:43] **Aaron Pratt**: K. So that's on us then.

[00:13:55] **Tim Hollebeek**: Perfect.

[00:13:59] **Aaron Pratt**: To the queue, please. Online or in the room? Some someone's in the queue. You wish to speak at the microphone?

[00:14:20] **Speaker 8**: No. Okay.

[00:14:21] **Aaron Pratt**: Okay. So that's that's a chair action to do a consensus call on this. Yeah. Got it. Okay. So then DNS persist, we have slides for. And this one is Shiloh. Hello?

[00:14:52] **Speaker 8**: Take it away. So

[00:14:56] **Shiloh Heirich**: I'm Shiloh Heirich, and together with my coauthors, Henry Birch Lee and Michael Slaughter, we are doing a short update on DNS persist. Recap is that it the the, promise here is that a DNS persist is gives us a long lived DNS TXT record that has an account URI that authorizes one account to issue for a domain, but no action needed at each issuance. So we have spent most of the time since Shenzhen with a substitution gap. And the the background is that there's a property of non transferability that our c h o o five has with DNS o one, h t p o one, and so on, that our initial, version of this, draft did not carry. So we use the raw account URI with no key binding and that allows for a particular type of attack where an adversary can be in the middle and provide their own account URL at a an anonymous CA for the victim to publish and then therefore own that that domain. So we wanted to make it so that a this transferable about this transferable authorization does not happen. So we looked at a few approaches to a binding mechanism for for this property. We looked at an authenticated post and the problem there is that that requires online actions. Then we looked at a pub key scheme using the hash and that was a new wire format. And then we actually selected a scheme that has the the hash and the key and the account URL bound. And I'll I'll get into that in a moment. So that was that allows us to keep offline, and it has a provision for key rollover, which part of that is still an open item. So I'm so sorry. I've been switching the wrong slides here. So this is actually the the presentation slide here. This is the diagram. Sorry. I was discussing, which is the substitution attack. And, so and then these are the three approaches, to, to defeating this attack. And next, we have, the, chosen method, which is constructed from a an account hash prefix prefix, which this is defined by the CA and allows for offline provisioning. It uses the hash algorithm identifier and then has a base 64 encoded hash value, and the hash is the concatenation of the domain name length, the domain name, the account public key, and the account URI. And by having each of these components in there, it exactly one account with the key proving that that account is the one authorizing this this validation. And it allows for offline use and non transferability. So that those were sort of our goals and the scheme matches with those. When we originally as I said, we originally had a raw URL as the only account URI spec. We ended up with three in between o one and what's gonna become o two of our draft. And we ended up calling the original one three a, the a privacy hash URI as three b and the subscriber account URI defined by the CA as three c. So what we've done is is re simplified and now we're back to only having a client computed hash URI. So the privacy preserving URI is the only supported method. The both the raw account URL is dropped and the subscriber account URI can be used under CAB forum method 22 as and and put in the CACPCPS. So what we wanna find out here, of course, are there any objections to moving forward with o two with with this in mind? What we have reviewed and and decided so far was that the interoperability handled by by using by by explicitly putting in the digest. We have a key rollover specification which allows for prior key acceptance, which is bound by time. And where the authors are are discussing if that's strictly necessary to to do it that way or not. And we also have reused the Acme thumbprint specification so that these can be implemented using existing library, components. So we've let's see. We've gone through a number of, issues and NPRs on the repository. So the things that we are going to work on but will have to happen after o two are going to be IP validation, the subdomain question, and whether we're going to register challenge specific errors, and we're going to keep doing looking at privacy analysis. I think one thing to keep in mind with this construction is that because h t t p o one exposes the, account key, thumbprint, in the clear, this doesn't mean that there there's not a guarantee of strong unlinkability, but this is a, best effort of anti correlation, across across sites. And so the the ones that we're going to defer, I just mentioned. And the other things that we have settled in this Went over most of them. I think the two important ones here are that we're going to allow a domain name and of star that allows, no domain any domain to match or no domain is specified. This allows one record to be used, across domains. If you know, and this has a caveat in the draft that, you know, this defeats the anti privacy measure if you as the client choose this, choose this path. And the other thing is, the key rollover, we're looking at whether there are ways to preserve key keys rollover, key rollover without having to have a window specified. So, we also wanna see are there any objections to the domain name star proposal or any inputs on the rollover design?

[00:23:09] **Aaron Pratt**: No rush to the queue, so unclear if you're gonna get an answer.

[00:23:15] **Shiloh Heirich**: Top of our mind. There's also a parallel cap forum work, going on, that is coming from this, this draft work. And that's all. So

[00:23:36] **Aaron Pratt**: what are your next steps?

[00:23:40] **Shiloh Heirich**: So we are going to publish o two as soon as we have completed the work for the key rollover and the the the binding that I was mentioning before that's, newly constructed.

[00:24:00] **Aaron Pratt**: Perfect.

[00:24:09] **Shiloh Heirich**: And the other things that I mentioned, we'll have to wait till after our two, which were these, this list of deferred items. And, yeah, I know the IP validation was was one you had in, Aaron, and and some of these others might be interesting as well.

[00:24:26] **Aaron Pratt**: Aaron?

[00:24:29] **Aaron Gable**: Yeah. I haven't looked at the proposed rollover text yet. I'm I'm really happy with the direction that you and the other authors have settled on for account key binding and just requiring everything to be the hashed form, dropping the other three a three b. Like, all of that's fantastic. I'm really happy where where this has ended up. I haven't looked at the rollover stuff yet. Is the intent to require that CAs support rollover or just say, if CAs want to support previous keys, then this is the maximum amount of time they can do so, etcetera?

[00:25:11] **Shiloh Heirich**: So that I think that's under heavy discussion right now, and I don't have a definitive answer yet as to how that that's gonna play out. Okay.

[00:25:20] **Aaron Gable**: Do you have I I would put in a slight preference for not requiring CAs to support rollover just because especially in the case that, hey. What if the prior account key is not just a key that that account has decided to roll over from, but a key that was reported as compromised to the CA, then we really, really don't want to support and performing validation is tied to that key that has been recorded as compromised. And so any flavor of requiring support for rollover, I would really want to have carve outs for that, and then it gets even more complicated. And so my vote would just be don't require support for that.

[00:26:13] **Shiloh Heirich**: Gotcha. Well, I think one thing to to consider though is that if the key is compromised with the CA, then CA will no longer honor Acme requests for it. So even if the authorization is still technically valid, it they with the key, not usable anymore. I'm not sure what the what the model threat model would be then.

[00:26:38] **Aaron Gable**: Oh, because the CA would you're you're expecting that the the CA would

[00:26:44] **Shiloh Heirich**: CA will have revoked that account key for the accountant.

[00:26:48] **Aaron Gable**: I I mean, two two pieces of subtlety here. Neither the BRs nor the Acme spec actually requires the CA to do so. You're required to revoke all certificates associated with the compromised key, but, like, revoking accounts associated with the compromised key is actually just, like, a thing that is morally right and correct, but not required by anything. So that's fun. Also, are are you operating under the idea that, like, the account key that the CA looks for in the DNS persist record is going to be whatever account key was used to sign the request saying, please go validate this challenge, not necessarily whatever account key the CA has associated as this is the most recent and most correct account key for this account.

[00:27:48] **Shiloh Heirich**: So it sounds like you're describing a situation where the CA is allows multiple account keys for a particular I

[00:27:57] **Aaron Gable**: mean, I I don't know any other way that a CA would support this sort of rollover. Maybe I just need to go read the proposed rollover text, and then we can have

[00:28:06] **Aaron Pratt**: this discussion on the list.

[00:28:07] **Shiloh Heirich**: K. Sounds great.

[00:28:09] **Aaron Pratt**: I I I'll just chime in as someone who, I think, is a bit of the sort of more aggressive needs of word. The essentially, the core idea like, so that at the moment of

[00:28:25] **Aaron Gable**: server act. Henry, we're only getting about half your words. You're really cutting out.

[00:28:31] **Aaron Pratt**: Yep. Sorry. We're also out of time for this. Can you could you chat type your point in chat, please? Yeah. Tim and

[00:28:42] **Tim Hollebeek**: the next Thank you. Tim. This is actually one one of the things I'd really like to avoid is IETF writing something and then Cab Forum sort of having to change the policy on top of it when they try to adopt this, which would delay the introduction into the ecosystem, and I think that would be bad. Rollover is a complex enough topic that I think couple of us should start a discussion over on that side and see what the consensus is over there. IETf is, of course, under no obligation to follow that discussion, but I think it would be very useful because there is a lot of complexity in rollover in the ecosystem and a lot of perspectives. So I I am also going to read your proposal and think about it quite a bit, and I'll I'll give you my point of view. But maybe Aaron and I can start a discussion on the list over there and and see what happens.

[00:29:35] **Shiloh Heirich**: Great. I think we're we're we are trying to keep this, of course, aligned as much as possible with cap form and making sure that those those ones that I mentioned that are parallel are not required, for this to be used. They're they're sort of enhancements, of of, baseline requirements. Not required, but just enhancements.

[00:30:03] **Aaron Pratt**: Okay. We'll close this one here. Next on the agenda, but we do not have slides, is acne profiles. Aaron, I don't know if you wanna say anything about this one.

[00:30:15] **Aaron Gable**: Yeah. Thirty second update at IETf one twenty five. We decided on a path forward for the last remaining open question. For most of the time between 01/25 and now, I did not get around to addressing that path forward. It has now been addressed, but within the document publication window. So right after 01/26, I will publish a new version of this document that addresses the feedback from 01/25. And the conclusion of 01/25 was as soon as that's addressed, we can go to working group last call. So, yeah, I'm just, it's like a one and a half sentence change. I'll get that draft o two published, and then we'll be done with this doc.

[00:31:02] **Aaron Pratt**: Thank you very much. Next should be acne rats.

[00:31:16] **Peter**: There's another one. Thank you. Previous.

[00:31:19] **Aaron Pratt**: Sorry. Yeah. Fabian. Yes. Thank you. Fabian from Google Trust Services. I have a question from for Aaron regarding the Acme profile draft. Is this so is there the possibility to support a combination of profiles or just a single one in this draft?

[00:31:37] **Aaron Gable**: This draft only supports a single profile per order. Several months ago, we made the decision that any progress on things like profile sets or other things that David Benjamin has been talking about would happen outside this draft.

[00:31:54] **Aaron Pratt**: Outside of this draft. Okay. Yep. Thank you. Thanks.

[00:32:01] **Russ Housley**: Okay. For enterprise profiles.

[00:32:05] **Peter**: Hi. This is Peter. I'm here to give some updates for document. We also presented this at a hackathon. So quick recap of what does the document do is to grant certificates to devices past attestation. Basically, add two processes together, and there are use cases of granting Wi Fi accesses to many different campuses so it can make your life easier and also Scott server use cases. So for from last ITF, we have implemented the Acme Rats based on open source codes for the client both for for both client and the server. The Acme client is based on the fork of open source Go dash Acme, which also known as Lego, which is the less encrypt Acme client library. We added a new challenge type, attestation in the challenge dot go file. The point of this work is aimed to be having this code to be production ready, maybe merged into the origin in the future, and the code is over there. You're welcome to try it out. For end to end demonstration and end to end user story, we implemented Acme server. Usually, that's public service server to provide this kind of thing, but I also did that. So but but, basically, what it does is just to support remote attestation signatures verification and respond to client requests. So this code is also there for you to try it out. So when you have those two pieces put together, you have a full user story that is end to end playable with. So in here, we have changed several things for the Acme clients. When it posts, the new order, request, it will post a new order with remote attestation identifiers, and the Acme server will react by creating a challenge object that maintain this remote attestation as a challenge object, and it will respond with those challenges. And then the client will retrieve attestation results or evidences reasonably from a local directory. Usually, in our demo, it's a file dot JSON file. Also then, optionally, it will also retrieve a GWK to encrypt the evidence if it's requesting evidence. This is for privacy and confidentiality considerations because the transport may go through Internet. And then it is posted to the challenge ID URL with the attestation result or encrypted evidences to the server. And the server will verify the validity of the response and basically a signature. So this is the whole user story. So try it out. There are some insights or, I would say, like, reflections from the implementation that could be in reverse, improve the the draft. There are several points to that. The first one is that because the most, I will say, 85% of the work is on the client side. Sometimes we kind of not think about Acme server behaviors enough, but there should be more explicit with certain expected Acme server behaviors. For example, I'll give you some examples. Number one is that sometimes the server would suggest with a a test client claims hint set that that he he that the client should response with those kind of, like, inquiry thing. But if the client did not respond with the exact claims, maybe this the server could reject or could just proceed with warnings. I think this is up to the server's discretion, but we should be more explicit, like, or or this the server should decide this behavior. And the second is that from the last several IETFs, we have decided that the remote attestation identifier or challenge should not be completed on its own. It should be used along with other existing challenge types like HTTP or DNS o one and use it as a complement. So the question is that some sometimes, you know, for the RFC eight five five five, one authorization could return multiple challenges. So there are design choices or considerations. So should we have one authorization with many challenges, including, for example, HTTP and a remote adaptation, or should we have different other authorizations? One authorization gives one challenge. The suggested after discussing with the all the coauthors, the suggested way to go, but also we welcome inputs, is that maybe we could we should have, you know, different authorizations, and this is a one to one mapping relationship. This would make things easier, without having overlaps or much complicated things. And, also, the Rats challenge should be done at least once or at most once or exactly once. Because when you have the previous question, maybe it will have the situation. You have more than one challenges. The suggestion is that it should be server's discretion, but we should be more explicit. The second one is that we should give at least one mandatory to implementation for certain things. For example, we allow JSON WebKey to encrypt raw evidences. We should give some format or algorithms like RSA just for this thing to work. Right? We use RSA, so we write RSA. Maybe PQ methods in the future. The third one is some miscellaneous things like a unified code format or something miscellaneous, just some changes to the text. Next steps, interoperability test. We'll be continually continuing up updating the draft and code. And in the San Francisco, we'll be also running hackathons. We're running interoperability tests, maybe in the future, some stress testing. And maybe will be the best for the CS to do the server part, but we don't, you know, hope, we we could do our own demo and then update the draft to clear the issues and problems during, implementation. So this is trying to get stable. If you're interested, please also, we we discuss regularly. That's it. Questions? Suggestions?

[00:39:28] **Aaron Pratt**: No one jumping in the queue. You seem to have been clear. Seems all good. Thank you. Seems all good. Thank you. Okay. The last adopted draft in the agenda is OpenID Federation, which we did not we we received a no presentation note from the authors. I don't know if the authors are here and want to speak to it. I think I

[00:39:55] **David Benjamin**: think we

[00:39:55] **Aaron Pratt**: have no update this cycle. So then that gets us into our new business section, starting with the pk-01 challenge.

[00:40:13] **Speaker 8**: Hello? Hello?

[00:40:19] **Aaron Pratt**: Hello. Yes. Can hear you, sir. You've requested to share. You would you rather share, or would you rather I share and give you control? How can I I need to share? That's how this works.

[00:40:38] **Speaker 8**: Okay. Okay. Okay.

[00:40:52] **Aaron Pratt**: K. You should be able to change the slides yourself. Please please go ahead.

[00:40:56] **Speaker 8**: Hello, everyone. I'm from. Today, I will introduce pk-01 on behalf of the authors. At IETf-one two five, the working group has us to separate identity and the delivery consoles from the duplicate key port and to preserve the CSR binding between the key and the requested identifiers. We did that. The draft now focuses on on your own certificate keyboard. As our draft has modified and updated a lot, I will describe I will say something about our migration. By the time an acting order reaches finalization, identifier control is already established. The CSR repeats the requested identifiers, carries the certificate public key, and provides the subject key pop through its self signature. Then making them sound, but in this draft's target flow, the key is declared and the port is completed during the order processing. So the four key cases, number 10, container, is no new issue as improved. This motivates just a free finalization. It does not mean PKS number 10 is broke. For construction and IoT clients, avoiding for PKS number 10 construction can can also reduce code in the processing. Can modeling keys are the primary motivation in current structure. For these keys, that this is a hard gap rather than an PKCS number 10 can carry an MLKM public key, but that they cannot produce the subject key signature expected by normal ACME finalization. The account key JWS also indicates the account ACME account, not possession of the certificate key. pk-01 eight certificate key, option alongside the existing identifier validation using easier signature or a team based response before CSR free finalization. ESTC five zero nine separately shows the same type of need in question enrollment. It is not integrated with ACME today. Future work could explore ACME-five zero nine profile for compact order bound enrollment. Then what I will show the the proto flow. This diagram shows all the most changes on the line. Directory met advertise this new order is or key beside beside identifiers, and the order accuses the accepted key. Existing challenges validate identifiers. PK01 validates position of that certificate key. In signature mode, the server sends off nouns. In CAM mode, it sends challenges several tasks. After both requirements succeed, the order becomes ready and follows normal account authenticated finalization and the certificate retrieval. At the same time, there was some compatibility and processing rules. Four pack depends on the certificate key. If pk-01 support or pop key acceptance is absent, a signature capable client can use standard c c s r based tracking. A cam a cam calling client must choose a supporting CA or stop. The finalized AWS remains authenticated by account key. The proof hashes the original decode in order payload before JSON passing. So neither side may reconstruct all the like the serialize it. Every proof use fresh challenge material and respond to one. Here, there are two proofs. Both proofs use edge, the hash of the running order payload. For signature key, the client signs the domain separated message containing the fresh of nouns and edge. The server verifies it with pop key. For a turnkey, the server encapsulates to a pop key. The client decapsulates whose size derive a MAC key with HKDF, and the client also indicates H with HMAC. The correct top graphic differs as the property is the same. Position of certificate private key is proving for this exact order. The chem construction still needs focused correct graphic review and published test factors. Here, there is one open design choice. One design question remains, where should order bound apply properly? The current draft baseline puts pk-01 in which identifiers and authorization. It will use its challenging URLs, status, and error handling, but does not fit alternative challenges and metrics clean. The piece for formatting identify orders and prevent prevents use of an otherwise valid authorization. An order level pocket is one to further and most requirement drafted, but it is an order field or resource and the new release date rules. A dedicated order bound authorization also need one proof and reuse the rule that every authorization must be valid, but requires a defined container and explet non u reuse rules. All options must preserve the same environments, identifier control, flush port bound to the exact new order and port key, and with the certificate key. Which representation does freeze? And the next next we will focus on several errors. Resolving the the clock placement and the state model, hiding for the IP handling and algorithm update, and validating the chem construction through cryptographic review, test the factors, and the implementation experiments. We believe the problem is real and this document is a useful starting point. Adoption would not freeze this design choice. It would give us working group a framework to resolve them. We ask the chairs to consider another. We welcome review and implementation help. Thank you.

[00:49:20] **Aaron Pratt**: Thank you. Okay. So before, Aaron, before we get to the queue, I'd like to note this document has evolved quite a bit in the in its seven versions. This is a very different document than it was in its OO. It has been greatly simplified due to many discussions on the list. It is not adopted. It had it had an adoption call in May, which did not pass. So I would like I mean, there's great great depth of technical detail in this presentation. I would like discussion to focus on the adoption question if possible. Does the Acme working group want to evolve the Acme protocol to have a CSR less flow, a flow which does not include the DARE based CSR? And from there, do we want to be able to support enrollment of chem keys using that mechanism? So I'd like to focus the discussion on adoption, please. Aaron.

[00:50:15] **Aaron Gable**: Yeah. Aaron Gable. Let's encrypt. Number one, I do support adoption perhaps unsurprisingly. He's one of the earliest people asking for this draft and its current simplifications. And two, real quick on the on slide seven, which of the three proof of possession representations? I strongly support the third option in which it is a standalone authorization within the order. I think that that model fits really nicely within the Acme protocol as it exists with no need for other extensions. And, yeah, that's it.

[00:50:58] **Yoav Nir**: Hi. So I'm not sure if I'm asking this as a chair or as an individual. Either way, this is mostly about chem keys and chem certificates. And really have to ask who wants them because and we've had drafts at this drafts advocating for chem certificates in IPsec and other places. And I'm not sure is anybody interested in deploying them? Anybody interested in issuing chem certificates?

[00:51:32] **Aaron Pratt**: I don't know if anyone's taking that. We do have another presentation coming up later in the agenda that depends on this one. There's a proposal for a, dual purpose pair of certificates where the chem one then requires, and there's a reference on this document.

[00:51:48] **Yoav Nir**: And does anyone intend to deploy that?

[00:51:52] **Aaron Pratt**: It's related to the s m two suite.

[00:51:55] **Russ Housley**: Well, I I do observe that the there are documents in the IPsec working group where there's photo chem and such being put in certificates. So I think there is a need. And I do think we need to have a pop mechanism. So whether it's this one or some other one, I don't care as long as we have a way to to do the pop for the chem keys.

[00:52:35] **Aaron Pratt**: Okay.

[00:52:39] **Julien**: Yeah. I think so. So can based authentication or even even chem for, like, email encryption. Yeah. Mainly chem certificate. So I do think it is useful.

[00:52:52] **Aaron Pratt**: I mean, Acme does support SMIME. Right? That is a pretty, pretty well established use case, and we've been cheating our faces off with RSA, and that's gonna be up soon. Okay. So how do we proceed? I would like opinions from the working group. Do we start another adoption call? Are we ready for that? Will it have a better outcome than last time? More decisive outcome than last time, do we think? I'm seeing a fair amount of support in the room and in the chat, so it sounds like we should proceed with show of hands. Of hands. Right? Thank you, Russ. Yeah. Yeah. Yeah. Where is the show of hands? I'm sorry. It's the thing that looks like a bar graph. Yep. That's fine. Right next to the chat. Yep.

[00:54:46] **Speaker 8**: Yeah.

[00:54:49] **Aaron Pratt**: K. This is starting to look.

[00:54:52] **Yoav Nir**: Would whoever voted no want to come up to the mic and say why? It's not me.

[00:55:01] **Aaron Pratt**: It's not you.

[00:55:10] **Speaker 8**: You don't have to. Don't

[00:55:12] **Yoav Nir**: have to.

[00:55:14] **Russ Housley**: No one's coming to the mic.

[00:55:17] **Yoav Nir**: Maybe the other one would.

[00:55:25] **Aaron Pratt**: Okay. The noes are not speaking. Now I suppose we take this result, and it looks The recess are growing. Thank you. Okay. Perfect. We have our we have our action for this that is clear. Okay. Next presentation is MTCs.

[00:55:54] **David Benjamin**: I am not that tall.

[00:56:03] **Aaron Pratt**: What? What are How many puns are you gonna get?

[00:56:10] **David Benjamin**: Is that a pun?

[00:56:11] **Aaron Pratt**: No. Not yet. Oh. It's not even pretty.

[00:56:14] **David Benjamin**: No. I don't think I have any puns. I just don't think so. I I I I I I was very rushing to get sliced up. Alright. Well, anyway, there are some plants here. Yeah. Okay. So Mike asked me to go give a talk on one of the sections in the Merkle Tree Certs.

[00:56:31] **Aaron Pratt**: Actually, maybe I will preempt you here. So just for the work group's awareness, this is not a draft in the ACME working group. It is a draft in the plants working group where section nine belongs in the ACME working group. So this is a plant this is a plant you I think you now update 8555, right, where you should update 8555?

[00:56:50] **David Benjamin**: Maybe.

[00:56:52] **Aaron Pratt**: Anyway, it's a yeah. We're doing this weird thing where another working group is presenting here because they wanted to keep it all together.

[00:56:58] **David Benjamin**: I mean, we can do which guess, like, this is the

[00:57:02] **Aaron Pratt**: I believe

[00:57:04] **David Benjamin**: the charter says that we will work. We are so good at this. Alright. So there's this plants thing. There's this Merkle Tree Certs thing going on at plants. And we've got this whole messy new certificate thing. You mostly don't care how these certificates work, except that there are two of them. When you go to the CAA and you're like, please give me a certificate, you will potentially get two certificates. One we're calling a standalone cert, and the other we're calling a landmark relative cert. A standalone certificate is, for all of these purposes, a normal certificate. It's available immediately. You do not need any extra data to verify it. It's just a funny signature field. SPKIs, SANS, extensions, they all work the way you expect them to. And so hopefully, that is a not terribly exciting thing. The landmark relative cert is a bit more exciting. It is smaller, which is why we're doing it. But it is not available immediately. It's only available after the CA has done some kind of batch processing. And it doesn't work in every RP that trusts the CA. It only works in RP's that know about this landmark, which is some extra piece of information that you need to get. And getting that information is part of this batch processing that is delayed on. So what is sort of the aim here? We have our usual picture with I'm gonna assume TLS servers. There are other uses of Acme. I just needed something to draw a picture. We have our sort of usual story where you've got an Acme server, your Acme client, and TLS server where they talk to each other and TLS clients. And so the Acme client goes and request certificate, perform challenges, all the usual. And then the CA issues a standalone certificate immediately, which gets sent to the Acme client, and the Acme client deploys the TLS server in some way. TLS server serves that to the clients which trust the CA, what it does for other clients, you know, its business. And that's it. We could just stop here if you do and so this so far has not required any changes to Acme. This is just the normal picture for Acme. And And if you stop here, your server works. Everything's okay. However, this so we're gonna talk about more stuff, but everything from here is an optional optimist optional extension. So this is kind of a, like you know, if you have an an unmodified ACME client, then you sort of just do you play this game. And then if you can do some more cool stuff, then you get nicer things, but you do not have to. So after some time, the CA will be able to produce a landmark relative cert. Somehow, that needs to get handed to the Acme client. And then the Acme client sticks in the TLS server, which now has two certificates standing around instead of one. So it needs to keep both of them around. And then at some point later, the client various TLS clients will learn about the landmark, And then the TLS server should send the landmark cert, because it's smaller, to those clients while keeping the standalone cert for the existing ones. Importantly, at no point do you ever remove the standalone certificate. The landmark cert is not a replacement. It is an optional it is an optimization for clients that can handle it. But for other clients, you need the you need the standalone cert. So what's needed from Acme? If we zoom into this picture, because the part underneath was really just about TLS, we need to somehow deliver two certificates with one order. One of them is normal, and the other one needs to wait for some batch processing. But while we're waiting for batch processing, it should not block standalone deployment because we do not want for if you need to rotate your keys in emergency, for you to sit there and wait for the batch processing to be done when you've already gotten a cert that works. And then somehow, through all this, the TLS server needs to know how to select certs. So what have we done? We mostly took two existing things that Acme already has, and we just sort of extended them a little bit. One of them is alternate certificate URLs. In Acme, you are allowed to provide already multiple certs with a single order with this link rel=alternate. And it was originally meant for different chains to the same certificate. And we said, oh, well, use some heuristics to decide which one to use. And the second one is if you need to get multiple certificate formats, if you want to send more information alongside the certificate, for example, We use just sort of HTTP content negotiations, so they accept header and stuff to negotiate them. And so we've just extended these two. The first. So ideally, this looks very much like an alternate. But the problem is one of these alternates, the landmark, at the time you first get the finalized order is not ready yet. And the existing Acme clients will fail when miss when some alternates are missing. And this is not really wrong of those clients to do because from the client's perspective, maybe this alternate's really important. Maybe this alternate is needed for this client for this relying party, and this alternate's needed for that relying party. The Acme server knows that's not the case because the standalone cert is good enough and the landmark cert is an optimization. But the Acme client a priori doesn't know this. So we said after circling around a bunch, whatever. We'll just allocate a new link relation. It's basically the same as alternate, except that it carries this extra this is optional semantic. And so that if you cannot fetch it, it's still okay. You do not fail the order. The other thing is that it's not ready yet, but the URL needs to return something. Turns out there are some pieces of HTTP that seem to express exactly this. There's HTTP two zero two accepted, which indicates the request has been accepted for processing but is not ready, perhaps because there's a batch oriented process. And that sounds very suspiciously like what we're doing. There's also a retry header that tells you when to retry a request if it's not ready yet. And Acme uses this all over the place. So we said, oh, we'll just use these. So that's what's written in section nine of the plans draft. We can keep it in that. We can move it to a separate document if we think that makes more sense, but it's also just like a couple of paragraphs. So I don't know. Whatever folks think is the, like, most convenient. The other thing is somehow the TLS server needs to negotiate stuff. Tip, you are do you want this slide or this slide?

[01:03:09] **Tim Hollebeek**: Yeah. That's pretty good one. Alright. Yeah. Tim Holly, On the three paragraphs, my initial thought I don't have thoughts yet on whether I would like it somewhere else or not. But on the three paragraphs themselves, I like the three paragraphs, but I think the three paragraphs are underspecified. And regardless of whether it stays or goes in, I think we have to write it out formally.

[01:03:33] **David Benjamin**: Sounds good. I guess right now, they are in a plant's document, so I guess send an email. If you I'm on both lists.

[01:03:40] **Yoav Nir**: So if you send

[01:03:41] **David Benjamin**: an email there, I will at least read it. But yeah. No. We should definitely if there's problems with the text, we should fix the problems with the text. Okay. So the other half of this is somehow giving back two certificates is not useful if you don't know which one to send when. And so somehow, this information needs to flow from the Acme server, which knows what's going on, all the way down to the TLS stack in the TLS server. And while this is mostly outside of Acme, Acme needs to provide the inputs to this. So to get some background, TLS certificate selection. The general model here is that the TLS server has a list of credentials, probably in some preference order. We really like preference orders in TLS. And when the TLS when the TLS client connects, it sends a client hello with preferences. These are like CypherSuite preferences, signature algorithm preferences, and so on. This is sort of like usual TLS usually looks like client hello contains what I what I support, and then server picks something. And for certificate selection, the server will pick some credential that is usable for the client hello, probably the one that it prefers the most. What does usable mean? Well, it's gotta be of an algorithm that works. How do you figure out the algorithm? Well, it's gotta you you gotta be able to, like, generate a signature with it if that's what you're gonna do with it, and you gotta be able to negotiate a Cypher suite. So am I able to select parameters? If not, move on to the next credential. But that's not enough to distinguish landmark and standalone. So instead, what we're modeling it as is some form of trust anchor or issuer negotiation. Does the issuer of this credential is the issuer of this credential some CA that the client supports? There's a couple mechanisms for this. In 9846, already had the certificate authorities extension. And over in the TLS group, there's this trust makers thing, which is mostly shorter IDs, though we've also used those IDs extensively in Merkle Tree Certs. And then probably any TLS stack will need some kind of flag to turn this on or off because if you only have one certificate, you just want to always send it. And so that's kind of your fallback for legacy clients that don't say anything about what they support. But then you might have some other certificates that you only want to send if this client supports it. In particular, landmarks, our model is a funny issuer. So somehow, this needs to go feed into a machine that looks something like this. So the Acme server knows why there are multiple certs. Maybe one of these is a new and an old issuer because your private key got posted to Reddit and you gotta rotate the key. Maybe this is standalone versus landmark. That's the one we're interested in, but it's sort of nice to build reusable tools. The Acme client and TLS server don't really need to know this information. All they really need to know is how to select between them. And so the idea is that we will define some Whatever metadata is needed for the TLS stack to go communicate to do this configuration, we'll package that up in some structure that the Acme server sends down to the Acme client. And what we've end up doing in the trust anchor IDs draft is we define some extensible blob of type data properties, and then we wrapped it up in a PEM format and use the accept header. Hopefully, that is not terribly novel, but that is the idea here. And the thinking with making it extensible is that it'd be really annoying to have to go plumb this every single time we add a new piece of information that the Acme server might want to tell the TLS server. So we'll just have this container once and then move on with our lives. Questions?

[01:07:17] **Russ Housley**: That was really fast.

[01:07:18] **David Benjamin**: Oh, sorry. I do talk fast.

[01:07:28] **Aaron Pratt**: You're well done.

[01:07:31] **Yoav Nir**: Yes. So entirely as an individual about these paragraphs, whether there are three or more in that other document, I don't think they should be separated into an Acme document. I think we've had some bad experience with clusters, and we don't want to create new ones. So keep the keep the information there, and, we can review it on the list. Remember that, working groups are ephemeral. We don't really need we don't really own anything that, has ever been done by this working group. So, yeah, keep it there. That's my opinion. Only as a div individual, of course.

[01:08:07] **Aaron Pratt**: And I do think we will continue asking the m t MTC authors to keep the acne group updated given that this is a cross group. Yeah. Concern. I mean,

[01:08:16] **Yoav Nir**: it's the same people in I mean, there's a really big overlapping people attending both sessions.

[01:08:25] **David Benjamin**: I I am happy to send the occasional note over if we change things. Hopefully, we're done changing it. But, you know, if you all have opinions because we did something wrong, you know, please tell us.

[01:08:34] **Yoav Nir**: Oh, this is the idea if we all have

[01:08:35] **Aaron Pratt**: opinions. Bob's not in the queue.

[01:08:41] **David Benjamin**: Bob is asking how many new certificate properties it defined in the last month, and I think we've gone from one to three at some point. But yes.

[01:08:56] **Aaron Pratt**: Alright. Thank you very much. Next is Eritra.

[01:09:17] **Aritra Sen**: Yep. K. K. Yeah. That's fine. Yeah. Hello, all. Yes.

[01:09:29] **Aaron Pratt**: So yep. Thanks. I'm expecting possibly some debate. So Yeah. We've saved a bunch of time, which is excellent. So I think you have time for that discussion. Yep. Yep. I think I

[01:09:38] **Aritra Sen**: got a sort of gist in the mailing list as well. So, yeah, obviously, first starting with the word profiles, I think the word didn't sort of go well. But, yeah, I think that's obviously it's a zero zero version. We have sort of going to change. But, yeah, essentially, what it does is the motivation is, of course, the vulnerable future due to cryptographically relevant quantum computers and current Acme deployments. They depend a lot of classical key cryptography in TLS and JWS. There's also the harvest now and decrypt data threat and where you can store data today and, you know, there's and CRQC is active. You can decrypt it. And, of course, there's an impact in Acme security. They can of course, the future CRQCs can break these algorithms like RSN, ECDH, and allowing attackers to recover TLS session keys and expose sensitive information like PII, which is, of course, there in ACME. And, of course, there's also risk of the man in the middle attack in Acme from a CRQC perspective if it's able to generate forge certificates and produce valid signatures, thereby impersonating a, well, material server, I would say. And so what it does essentially is we define we are not obviously defining new algorithms or new protocols as it is in TLS, and Jose is gonna be is working on it anyways. So we're defining this quantum ready Acme deployment profiles supporting both pure and PQT hybrid cryptography because we need to sort of update this RFC eight triple five, I would say, because it mandates the use of ES two fifty six in the RFC. And so that's essentially where the main motivation comes from, and it specifies PQCN, PQT hybrid TLS 1.3, which is, I think, recently became an RFC. And it's it's obviously, that's something which needs to be taken into account that TLS 1.3 needs to be supported in addition to being a PQ or PQT hybrid. And, of course, it defines the PQT and PQ hybrid for sorry. Pure PQC for JWS as well. Yeah. So we defined the two profiles. And, again, the name profile is subject to debate. We'll have that discussion. But yeah. So we defined two sort of profiles that we went through in the draft is a slightly softer profile, which is which we are calling the quantum ready profile, where the deployment profile is at such that we are going to support the PQ and PQT hybrid key exchange and authentication for TLS as well as JWS, but a traditional only authentication may be continued to be accepted until a certain transition period. And there's a strict quantum ready profile where we'll be like, well, it's sort of requiring PQC and PQT hybrid signatures such that there is no traditional only fallback. That's sort of a more much harder profile. And yeah. So I think this is, again, a given that whether we move to PQC and PQT, the first thing which obviously to have to use TLS 1.3 or later for all communications in the future, and that's sort of given. And, yeah, for the quantum ready TLS authentication, we can obviously support it. It may the ACME servers may support TLS server for PQC only or PQT hybrid, and it may continue to accept traditional only certificate signature dueling an explicitly bounded transition time, I would say. For JWS, of course, in Jose working group as well as Jose working group, there has been some work going on for quite some time. And Acme servers I mean, these algorithms were sort of defined and fixed in the composite sig algs group sorry. Composite sig algs draft as well as well as the pure MLDS drafts in, I would say, Jose, that MLDS is forty four sixty five eighty seven and the composites as well as SLHDSA shake is variant, well, may be supported by Acme servers. And, again, it's it's essential because e s two fifty six remains mandatory as of today for interop. And we sort of kept this profile as a a sort of simplistic or sort of soft profile where, you know, there's an option to have traditional only JWS until a certain period of time. This is this, obviously, the strict one. It sort of eliminates fallback to traditional only, and it rejects any authentication mechanism that relies only on classical cryptography, and this is true for both TLS and JWS. Yeah. So we got quite a few comments on, obviously, removing the normative text, I would say. I would say the word must and should not sit well here. So I would say we changed that to me and optional. So that's that's something, of course, we will I mean, again, the slides are based on the draft zero zero version. We'll be making the changes. But other than that, of course, we had other comments and comments as well. Thanks to everyone who commented. But, yeah, I'll be opening this to discussion now. Mike.

[01:14:49] **Aaron Pratt**: There you go.

[01:14:53] **Mike Bishop**: Yeah. I could I couldn't get what information need to be protected against, like, habitat or during Acme protocol executions. Like, do we need to protect some, like, secret information?

[01:15:09] **Aaron Pratt**: I can Yeah.

[01:15:09] **Aritra Sen**: I think I mean, Acme does have information, like like, the personal identifiable information and values. I think these are usually there in the Acme account, so these needs to be protected. Right? Because, of course, that's for the harvest letter they create now. And from a certificate perspective, obviously, because of man in the middle attack, it's essential to have, you know, stronger cert stronger signatures, right, which are which will protect against a quantum computer, I would say.

[01:15:38] **Aaron Pratt**: Yeah. But the signature like, certificate or signature is, like, that secret to any terms. Yeah. Use the mic. Oh.

[01:15:48] **Mike Bishop**: So certificate or signature is, like, not that secret mean, like, many cases. Like, I couldn't get, like so you were saying, like, embed some p like like, I I didn't want like, human ident however, identity into the certificate was the thing?

[01:16:07] **Aritra Sen**: No. No. No. So no. No. I think the obviously, the signature perspective, I think it's it's sort of more clear that somebody is in the middle, like, man in the middle attack. Somebody is in the middle and sort of spoofing and telling that, you know, I am a certain client when when in the reality, I'm not. I think it's more on not the signature itself being secret, but, of course, using the signature for nefarious purposes. That's where the threat lies.

[01:16:32] **Aaron Pratt**: The queue like, the attacker is

[01:16:35] **Mike Bishop**: attacking for authentication. Like, attacker need to have a, like, how to say, on the fly share, like, share accuracy access Yeah. To attack, and it's, like, bit far from, like, habit attack, like

[01:16:50] **Aritra Sen**: threats. Yeah. I think that's why we're also keeping this sort of softer profile where there is an option to do classical signatures up to a certain part of time. But, like, eventually, it's sort of going to be moved towards PQC. That's, I think, where every draft is moving towards anyways. So I think yeah. That's why

[01:17:10] **Aaron Pratt**: Oh, okay. Yeah. Yeah. Thank you.

[01:17:15] **Tim Hollebeek**: Yes. Yep. So on the transition, do you just mean to say that we will eventually have to get off of traditional, or are you going to attempt to have a discussion about exactly when that should be?

[01:17:30] **Aritra Sen**: Yeah. I don't think we I am not currently going to like, at this point, not to endeavor specific timeline in mind. This is, again, just to test the waters that how, obviously, the working group reacts to this. And it's critical that I do not say the exact time right now because, well, nobody knows that, essentially. So it's that's why we get both the profiles. Right? Because there's one on the softer side, one on the more street side, I would say.

[01:17:57] **Tim Hollebeek**: Yeah. My my opinion is I I would not mention the fact that there needs to be an end date because it's obvious, and I do not want to have that discussion. I think it's a waste of time. There are other people who will set transition dates and do a much better job. The other comment I have is on mandatory to implement for PQ slash t. I think that's gonna age badly. And so I would not do that.

[01:18:23] **Aritra Sen**: Yeah. No. No. I changed that to May anyways, so that's perfect. Thanks, Tim. Yeah. Yep.

[01:18:28] **Deb Cooley**: So I'm Deb Kuo. I'm not wearing a hat right now. I mean, literally not wearing a hat. So there's no Cypher suite specified in 08/05/1955. It's it references TLS. There are no Cypher suites in there. What are you migrating?

[01:18:46] **Aritra Sen**: The yeah. Actually, in in a triple five, so they're mandating the use of e s two fifty six, which is elliptic of DSA with p two fifty is that?

[01:18:55] **Aaron Pratt**: There's a JWS. There's an MTI for the JWS layer.

[01:19:00] **Deb Cooley**: There's a what?

[01:19:01] **Aaron Pratt**: Correct. Yeah.

[01:19:04] **Aaron Gable**: In section six dot two of RFC eight five five five, it contains the text. That that's the section talking about using JSON web signatures to authenticate Acme client requests to Acme servers, and it contains the text. The Acme server must implement the e s two fifty six signature algorithm and should implement the EDDSA signature algorithm. So it's basically saying, for the sake of interoperability between Acme clients and Acme servers, we must have at least this one algorithm, e s two fifty six, that all Acme clients and all Acme servers support. I personally think that this entire document could be reduced to boilerplate, obviously, plus one paragraph of motivation talking about post quantum threats and one paragraph saying, due to post quantum threats, ACME servers may or not post quantum. Due to quantum threats, ACME servers may choose not to implement e s two fifty six. And then everything else is just the TLS working group for Acme server TLS signatures, the TLS working group for session keys derived via the handshake, the Jose working group for other algorithms that can be supported in JWSs, and individual PKI policy for which algorithms must be supported by any given Acme server. So, yeah, I I I don't think we have to go further than that in my personal opinion.

[01:20:44] **Deb Cooley**: Okay. Because I'm looking at the registries going, I don't see anything in the registries. Like, there's nothing in the I n a registry for 8555. It's all buried in the text. Yeah.

[01:20:58] **Julien**: Yuck. Okay. Yuck.

[01:21:02] **Deb Cooley**: That's without a hat, though. Remember? It's just my own personal

[01:21:07] **Russ Housley**: Yep. So

[01:21:11] **Aaron Pratt**: this is, again, not an adopted document. We're at the we're at the call for adoption stage. So I think we could handle the adoption ness of this in a couple of different ways. We could decide whether we think those that one sentence that Erin read even needs updating at this point in time. We could just we could decide if we think that a draft that specifies profiles is necessary. We could handle those as separate questions. We can handle those as the same question.

[01:21:41] **Deb Cooley**: We even have to do it eventually.

[01:21:44] **Aaron Pratt**: Yeah. We may have to do it eventually. Eventually, you die die die easy, I suppose.

[01:21:57] **Yoav Nir**: Okay.

[01:21:59] **Aaron Pratt**: Okay. So do we have opinions about how to progress this towards a call for adoption?

[01:22:07] **Aritra Sen**: Yeah. But Aaron's comments, I think, probably reshape the draft a bit, change the normative that I'll do anyways. But yeah.

[01:22:20] **Aaron Pratt**: I'm good. I I injecting my own opinion here. I suspect we need to adopt something to address PQC. It's not clear to me exactly what shape of something.

[01:22:29] **Deb Cooley**: So this time I have my hat on. So I do think you wanna make this as you wanna future proof this so that you wanna push as much off to TLS and Jose as you can because then they bear the brunt of the updates. And so right now, you're specifying specific algorithms for JWS, I guess, and maybe for TLS. I don't know. But I'd like to see that you'd reference some the other protocols that are already being maintained. Right? So TLS, JWS, and have it be done there as opposed to have it be done here.

[01:23:07] **Aritra Sen**: Yeah.

[01:23:07] **Deb Cooley**: I mean, right now, it's it's in the draft. And so what you do is you take it out. You'd, like, work it so that you're just normatively referencing TLS and whatever you need in Jose and not

[01:23:19] **Speaker 8**: that's an option.

[01:23:20] **Aaron Pratt**: We could just have a draft that deletes a line. I think we'll have to do a deep dive to see if JWS provides the MTIs that we like.

[01:23:29] **Deb Cooley**: Maybe not yet. I mean, I don't know. I'm I should know. Right? Because I'm only the Jose AD, but whatever. It's been a it's been a week. It's been a week. Okay? So, yeah, you can look at that, but I think you have to I I don't know. It just seems to me that it's simpler and more streamlined to actually utilize to

[01:23:53] **Julien**: go to

[01:23:53] **Deb Cooley**: the source for the for TLS and and and Jose, right, rather than, like, to redo it here. And that's what you should discuss on the list. Right? Because this is only this is your lonely your lowly AD's opinion about that it would be simpler to have it. Like, you don't have to then maintain it every time it changes. TLS does or Jose does. That's just a suggestion.

[01:24:31] **Aritra Sen**: Great. So, Mike, I think we'll take to the list then. Yeah. I was gonna take Perfect.

[01:24:36] **Julien**: To the end today.

[01:24:37] **Aritra Sen**: Thanks. Thanks. Oh, yeah. Tim. I

[01:24:42] **Tim Hollebeek**: mean, if we're gonna delete one sentence instead of wasting a number, should we consider just eradicating this?

[01:24:50] **Aaron Pratt**: No. No. Okay. Sorry.

[01:24:57] **Aaron Gable**: What was the response in the room? No. No.

[01:25:01] **Tim Hollebeek**: Every everybody hated the idea for the re and I know why they hated it. They hated it because it's not actually a mistake in the original document. So yeah. I'm cheating you to use an optimization that everybody hated.

[01:25:13] **Aritra Sen**: Okay. Thanks, Adam. Yeah. Thanks, Tim. Yeah.

[01:25:15] **Aaron Pratt**: Perfect. That that chair action there is clear. Yep. Start a CFA adjacent discussion. Sorry? Thank you, Deb. Okay. Next, and I believe last, and we do in fact have the proper time this deserves. So let's I'm sorry. There's two topics on the list. There's a I'm sorry. Apologies. We have a topic that does not have slides. Aaron, I know this is a topic you can speak to. I know this is a topic I can speak to. Let me take the slides off. The there's been a healthy discussion on list about whether Acme needs a mechanism for I lost my account key. I no longer have access to it. Let me redo my domain validation and then boot out all keys currently registered to my account. Oh, good. The equivalent of a password reset flow for Acme. Aaron, please.

[01:26:16] **Aaron Gable**: I think the yeah. There's there's also a slightly different version of this. The the thing that is most prominent in my mind is slightly different from the sentence that you just said, which is I have lost my Acme account key. How can I register a new Acme account key, perform challenges to get valid authorizations for all of my domains, and then invalidate or in 08/05/1955 parlance revoke all authorizations for those same domains held by other accounts, which could be my previous account so that maybe an attacker has taken control of by stealing my Acme account key off of a compromised server or could be, like, some attacker did a BGP hijack and got in front of me and got authorizations for my domains? And now that I have control over my IP addresses back, I want to invalidate the authorizations that they were able to get.

[01:27:24] **Aaron Pratt**: But as you purchased the domain from someone else?

[01:27:28] **Aaron Gable**: Yep. Status quo within Acme is if someone else has certificates for domains that you have authorizations for, you can revoke their certificates per RFCA five five five. Let's Encrypt is literally as we speak implementing a thing whereby if account a revokes account b's certificate by virtue of controlling all identifiers in that certificate, then we will also go revoke all authorizations held by account b for those identifiers so that account b can't just immediately reissue that same certificate using authorization reuse. This has not existed for the last ten years of Let's Encrypt's operations, but we decided that this was maybe important. Some people in the open source community saw us implementing this on GitHub and then went, hey. But what if you don't want to wait until they actually issue the cert? What if you want to prevent them from issuing that cert in the first place? And they brought that discussion to the Acme- mailing list. I think there are two main approaches here. Approach number one is, yeah, allow there to be some sort of not just revoke cert endpoint, but revoke authorization where maybe you create a new authorization with a special flag in it that says when this authorization is validated, go revoke all authorizations for the same identifier held by other accounts. Maybe you create that authorization by hitting a special revoke auth z endpoint instead of, like, doing a new order request with a bunch of identifiers in it. So, like, there's a slightly special flow you go through. Like, I think we could design something that looks that allows you to revoke other people's authorization so they can't issue certs. The other approach is CAA account binding, where you just say, hey. If you want to revoke the authorizations held by other accounts for this identifier, just go put CAA records in place that contain your Acme account ID. And then when they go try to issue those certificates, the CA will have to go recheck CAA. They will find the account binding record, and they will refuse to issue the certificate. The CAA approach has one major advantage and one major disadvantage. The major advantage is that it means you don't have to go do this revoke off z's dance at every single possible Acme CA that the attacker could have gotten authorizations for your domains at. Right? Like, in theory, you would have to go potentially revoke authorizations everywhere, and that sucks, and, like, frankly, is impossible. The disadvantage of CAA is that at least per web PKI rules set by the CAA browser forum, CAA checks can be reused for up to eight hours. So if the attacker compromised you and got these authorizations within the last eight hours, you can put up new CA records as much as you like. The CA doesn't have to check them until those eight hours are up. And so, yeah, it's certainly not perfect. Yeah. That's that's sort of the status quo at the moment.

[01:31:39] **Tim Hollebeek**: I real I really like the CIA idea. The we can think about the eight hours one. That sounds like something we can probably figure out and solve. The first option scares me greatly, but so do about 10,000,000 things. The biggest thing I think you wanna think very carefully about is if you do it wrong, you are actually putting a new tool in the attacker's toolbox to make it easier for him to get rid of all the existing certificates from the legitimate owner. I'm not quite sure how you prevent people from just playing revoke wars and both just switching back and forth rapidly.

[01:32:19] **Aaron Gable**: Yeah. It's absolutely a like, revoking authorizations is not as much of a problem as revoking certs in terms of denial of service because, hopefully, the legitimate owner can just go get another authorization. Validation is basically free in the Acme world. But, yes, it absolutely is introducing something that looks like another denial of service factor, and

[01:32:43] **Andrew Chen**: that would need to be considered carefully. Andrew? Andrew Chen, Netflix. I think we we would love to have more of the account binding stuff on every CA. If we could find all of

[01:32:55] **David Benjamin**: our accounts to all all

[01:32:56] **Andrew Chen**: of our CA records to the specific accounts, that would it feels like in our on in our side, that would help eliminate a lot of the problems in the first place.

[01:33:15] **Aaron Gable**: So, yeah, I I I am personally of the opinion that I think CAA with Acme CAA account binding is probably just the right solution here. The answer is not introduce a new mechanism, but I think well worth discussing and here and potentially continuing discussion on the list.

[01:33:39] **Aaron Pratt**: Bob's in queue. Yeah. Bob, do you wanna make your comment, then we'll close this?

[01:33:47] **Bob Beck**: While neither is perfect, Bob back I'm gonna sell while neither is perfect, my I broke my Acme account. I broke your Acme account, and now I'm demolishing all other Acme accounts. Requires me only to break the Acme account. For me to change the DNS record,

[01:34:04] **Aaron Pratt**: I also have to break your DNS, which, okay, still probably a low bar, but at

[01:34:08] **Bob Beck**: least it's two things, not one.

[01:34:12] **Aaron Pratt**: Okay. So from a chair perspective, this is not even a draft. We do not have a draft submitted. So this was I put this on the agenda just so we could advertise that the topic is being discussed. I would like the discussion to continue on the list, and if anyone feels inclined to write a draft, you're welcome to do so. But this is just a discussion at this point.

[01:34:33] **Aritra Sen**: Perfect.

[01:34:36] **Aaron Pratt**: So now we're into the last presentation, which we still have time for, and is a presentation on the s m two ciphers in Acme.

[01:35:00] **Julien**: Hi. Thank you. So we just submitted two new submissions, yeah, called the SM to dual certificate using Acme. Yeah. So, basically, we have two drafts. The first one is that how we can start to use acme to issue SM two dual certificate system. Yeah. Second one is that we would like to use the star extension, yeah, from acme to to do the keying rotation or something like that. Refresh the key. Because here, SM two dual certificate means there is one signature key and also have a certificate. And, also, there is a a encryption key certificate, something like the key exchange. So a little later, I will give you more information about what is the SM two dual certificate. Yeah. So this is a short information about s m two. So, basically, we can say s m two model, yeah, assumes one key per certificate. But here, in s m two, actually, two certificates are linked together. Yeah. So in that case, how I can do this one? Yeah. Using ac Acme-. Yeah. I standards. Sorry. Yeah. So as I just mentioned, so SM to do certificate means we have two certificate, one for signature, one for encryption, or case change. Yeah. So SM two is algorithm, you know, standardized Chinese standardization, and it is also standard by ISO. By ISO, it should be 2016. Standard by Chinese, it should be 2012. So it is currently a a Chinese national standardization algorithm. It is based on elective curves. But the one more thing I would like to say is we know that one. Yeah. So, like, a SM two or the dual certificate system may be limited interest. So for both of the drafts, we're just the proposed for informational, not a standard one. Yeah. Okay. So when we can say the user Acme to issue, in the To issue the certificates. So for signature one, it should be easier because I like a standard one. Yeah. So we can use the p k one, use the, yeah, use the p k one order, yeah, to issue the Acme certificate. But for the for the encryption certificate, it will be a little bit more complex. Yeah. So, basically, here, there is a special requirements. Yeah. So the private key related to the encryption certificate, It's encroached, yeah, by KMC, to manage manage central. Yeah. So this is a very special one. So it's not so easy to do this, yeah, according to the current ACME framework. So we will, like, try to solve this one. Yeah. About the motivation, actually, we have two motivation. The first one is workers. Yeah. We would like to consider how actually Acme can be extent or adapted such that such as special SM to dual certificate can be benefited from Acme structure. This is the first thing. The second thing, at the same time, we also would like to by this chance, it also useful to show why Acme probably has a strong adaptability or have a wider application use in different scenario, not just the one certificate, one for for for for one k pay. Yeah. It could be two certificates can be linked together, etcetera. Yeah. We would like to do this. Yeah. Okay. So how we do it? So here, we just gave a short introduction because we just added this one, asking the chair to add this item, yeah, After the deadline of apply the presentation slot, we just go to a short presentation here. So later, we would like to maybe ask some detailed presentation a little bit later, you know, interim meeting, something like August or something. This will be better. This is how we can go. Did that change? Yeah. We can give detail about what is the essential algorithm or main structure of the about the SM tool or what is the SM tool dual certificate and how we do it in detail. Okay. So how we do it now now? So, basically, as I just mentioned, we we would like to do it two step or two layers. The first layer is to to such that your new certificates can be issued using the academy structure. The second one is that there is one additional requirement. The encryption key, a little bit like the ephemeral key, it need to be it it need to be refreshed, yeah, quite frequently. But the signature certificate can be held for quite a long time, yeah, by the owner. So this is also a issue. So we will can say the how we can use some, new scheme, a new technique, yeah, to actually solve this issue, something like a key rotation or a refreshment. Not to renew. Not to renew the certificate validity. We would like to renew the the the key itself. Okay. So here is about the first draft. Also, we call it the first step. So we would like to extend the Acme such that we can issue SM to do certificate. Yeah. For the signature certificate, as we just mentioned, it's easy. Yeah. You can just use the standard SAS approach. Use the p k zero one challenge and to do that. But but for the encryption, a little bit difficult because for the we would like to do the ACME issue request for two certificates. And these two certificate need to be linked together to show that, okay. I actually I am the owner of the signing certificate, but at the same time, I hold a current or maybe just apply a new encryption certificate. And the encryption certificate will be issued by the KMC. The KMC actually know the private key for this encryption key certificate. Yeah. So here, we use a a call to the key to bind the to bind the signature PK. So something like a signature PK and also the public key for the key will be included in the rest in the request. And at the same time, we will issue another order called the zero one just to show that, okay, For this application, yeah, it actually issued, yeah, by the owner over the particular signature public key. Yeah. Then by this way, yeah, we can do it, to actually apply yeah, to make two orders, but these two orders are linked together. Okay. As we just mentioned, in the second draft, yeah, as we, just mentioned in the because of the incubation key needed to be refreshed, very frequently. So we would like to do the automation for to renew the key, renew the encryption key. Yeah. So for this one, so we are we are actually, use the star extension, but the original star extension, yeah, in Acme is used for renew the validity of the same key, same key pair, I can say. So the key pair itself is not changed. But here, we would like to change the key pair itself. So here, actually, we use the some idea. Is some new technology called the ARKG. So asynchronous remote key, generation, currently, there is a draft in CFRG. It's for traditional algorithms. Yeah. They actually involve the for something like a two years. I think currently, it should be the current value should be running 11 already. Yeah. So we use this technology such that the key can be remoted remoted and generated, yeah, by the KMC, but it can also be retrieved by the by the user if he the himself. In the draft, actually, we have proposed the two modes, whether the motor a or motor b, because here, the key are originally generated by the KMC. Yeah. So the the new, actually, private key can be delivered to the user by a digital envelope or maybe by a different way. Just to use the ARKG can be update by the user itself. I use in something like the randomizing randomized actually factor, yeah, based on the original private key, something like this. Okay. So because we do not plan to give much detail, yeah, with just a new item, yeah, for the session. So I will finish my talk here. So we would like to ask you review or comments if you are interest, either it's the meeting or maybe in the mailing list. Yeah. Thanks a lot.

[01:45:24] **Aaron Pratt**: Perfect. Thank you, Julian.

[01:45:26] **Julien**: Yeah. Thank

[01:45:26] **Aaron Pratt**: you. So these drafts were submitted since the the posting freeze. They were submitted only this week, so I do not assume anyone has read them yet. But you you mentioned an interim, but you're okay to continue on the mailing list and discuss Yeah. In San

[01:45:42] **Speaker 8**: Yeah. Perfect. Yeah. Okay. Great. Thank Thank you.

[01:45:50] **Aaron Pratt**: So that takes us then to any other business. Unless unless, of course, there are unless, of course, there are questions for the s m two drafts, but I'm not expecting anyone has written this.

[01:46:06] **Russ Housley**: Is

[01:46:13] **Aaron Pratt**: no PGC agility profile. Correct. So any other business going once? Any other business going twice? Acme-one twenty six is adjourned.

[01:46:35] **Yoav Nir**: Thank you all. See you in San Francisco. Yeah. See you in San Francisco where we might both be, remote.

[01:46:56] **Aaron Pratt**: 1984 is a brilliant. Not not an accident, I'm sure. Comment in the hallway. Thank you, Joav. We're gonna disconnect here. Yes. Thank you kindly. Great. Yeah. I was following along. Yeah. Notes are excellent. Thank you. Back to the very first. I think it was the

[01:47:56] **Peter**: rather stuck in the cluster.

[01:47:58] **Aaron Pratt**: Yes. But I missed part of the discussion, but I just gave him about actually, the document that's blocking was now in the chat in two weeks. So Yes. Is getting along. But Deb gave us an update on the on the status of that cluster. So we're we're we're good. Yeah. Yeah. Sounds like like, we're we're not finally giving up. No.