Session Date/Time: 19 Mar 2026 06:00
Mike: My clock says it's start time.
Yoav: One minute past. Do you want to open us up, Yoav?
Mike: All right.
Yoav: Hi. Welcome all to the ACME meeting at IETF 125. In this case, both both chairs and the Area Director are not in the room. That's why you see the empty chairs up front. So, I think you're controlling the slides, Mike.
Mike: I think I am.
Yoav: Yeah. So, this is the Note Well. As it's Thursday, you've seen this multiple times. It mostly has links to all kinds of documents about the way we treat each other with respect and professionalism, and about the IPR policy, which is detailed in several RFCs like 8179 and 5378. And there are also RFCs for the guidelines of conduct and the anti-harassment procedures. If you feel that you are being harassed, please contact either the chairs or the ombudsteam. Right. Next slide. So, make sure you're signed into the session if you're one of the few people in the room. Please use the Meetecho light to join the queue, show hands, and all that. If you're joining remotely, as a lot of us are, please keep audio and video off if you're not on-site. The remote room can obviously keep the video on. Remote participants, make sure that you're off unless you're chairing or presenting. And it's strongly recommended to use a headset, although the remote room has very good sound without any headset, so that's good. Okay. And state your name each time you go on the mic. That's good for the people taking notes, as well as the AI that is listening in and trying to write a summary. Okay. Here are links to the agenda, the Meetecho, and where to look for technical assistance. Next slide. Okay. Do we have minute takers? We have to have minute takers; otherwise, we can't proceed. We're not allowed to yet have minute takers.
Aaron Gable: I'm happy to take minutes for everything except for my own session.
Mike: Thank you, Aaron. And I'm sure other will join in and help with the minutes when you are talking. All right. And the chat, you can see the chat either in the dedicated Zulip client or on the left side of this webpage. Right. Important things, though, are not for the backchannel but for the room mic or the other mic. Okay. Next. Okay. So, we've had one RFC published, 9891, getting really close to that 10,000 mark. That was DTN Node ID. And next. Okay. ACME integrations is still in missref. And Device Attestation has completed IETF Last Call but requires a structural change to add the JSON, so we have slides for this one. I won't do spoilers now. Next. Okay. So, we're going to hear about ACME profiles, then RATS, DNS Persist, and finally ACME client. No slides, but we will talk about it.
Mike: Yeah, I'll just make a quick note about this. So, Kathleen sent an email to the list a couple of hours ago. She's not presenting this round, but she welcomes co-authors and she is planning to do another update to the draft. So, keep your eyes peeled on the mailing list for updates for ACME client.
Yoav: All right. Yeah. In the chat, Michael Richardson says that ACME integration depends upon Anima RFC 8366bis, which is now mostly past AD review. Don't want to open a can of worms and ask what "mostly" means in this case, but okay. And we'll see a presentation about draft-ding-acme-pubkey and ACME EMRTD-01, Sebastian although Mike will present it. All right. Any agenda bashing? I guess not. So, let's get on with it.
Mike: Um, this one, I think is me, because none of the authors are present for this session. So, these are not my slides, or not my slide, but I can speak to it. So, the update is Device Attest, if you remember this draft has been around for a while. It sort of stalled when the primary—it was a single author draft—it sort of stalled when the single author, I think, was no longer doing this work directly. Um, so we have a new set of authors that came on maybe six months ago and there's been some juggling involved in handing over the draft to the new authors, especially the technical content. I see Richard is coming on, but not in queue. Um, so—but I think Richard's here because he is the designated expert who raised the recent comment. Do you want to speak to this, Richard?
Richard: Um, I can if you like. Um, I mean the issue is that the registries require that things be specified and they weren't specified. Um, the format of the identifiers that were being registered wasn't specified, the way you'd put them in a new order request. Um, and—and so, you know, didn't make sense to register them because there wasn't a proper specification. So, we just need to get them specified.
Mike: I am shocked and embarrassed that the draft got this far without anyone having noticed that. So, thank you for your very detailed review. That would have been an incredibly embarrassing omission to publish. Um, yeah, we're getting that fixed. I think that's all we need to say for this one. Good. Next deck.
(Presentation: ACME Profiles update for IETF 125 - https://datatracker.ietf.org/meeting/125/materials/slides-125-acme-acme-profiles-update-for-ietf-125-00)
Aaron Gable: I think I pressed the right button to request control of the slides. No, Mike just needs to click on the little document thing with the plus sign in it, which will give you slide control. But Mike has to do that. Or I can do that, but then it comes back to mine, so... Sweet. Hi everyone. Aaron Gable, Let's Encrypt and ISRG, presenting updates on draft-ietf-acme-profiles-01. Updates since last IETF: draft-01 was created earlier this month. Around last IETF, draft-00 was adopted, very shortly before that meeting. The only meaningful change in draft-01 from draft-00 is that it now says the server should reject requests for profiles that it is not advertising. This is weakened from the previous statement, which was that the server must reject requests for profiles that it is not advertising. This change was requested because some people think there's practical use for private profiles that you might pre-negotiate with someone via external account binding or something like that. This is totally reasonable. In fact, even at Let's Encrypt, we thought of situations where we might want to use this already. So, we made this change. I think it makes perfect sense. I think the language we got in there around under what circumstances you might want to allow requests for profiles you're not advertising, I think that language is pretty good. That leaves us in a pretty stable state. This draft has barely changed for six months. It is currently fully implemented by two pieces of ACME server software and quite a few ACME clients. Something like 1% of all Let's Encrypt issuance, which is to say, like, several tens of millions of currently active certificates were issued via requests that explicitly specified a profile. This is working. It's pretty cool. We're using it for several migrations, but I talked about all of that at IETF 124. There is one open question, specifically on the GitHub repo. I have opinions about this. I will express those opinions at the end. I will express the open question first. Should there be additional structure in the way that profiles are advertised? Currently, the profiles advertisement in the directory meta is just a dictionary where the dictionary keys are the profile name and the values are a short textual description of that profile, which could be a human-readable string, or it could be the URL to a webpage that has a more thorough documentation or whatever. It's like purposefully structureless. People have proposed alternate structures here. One proposal is that it should be structured map values, so we keep the keys as the profile names, but the values, instead of being strings, become dictionaries of their own. This adds an extensibility point, but we don't really know what we would extend there, and I have some opinions about extensibility in this particular location. Proposal two would be structured array entries, so rather than mapping profile names to dictionaries, we would just have a list of dictionaries, and each one would have a name and also some documentation or whatever other details are in there. And finally, there is proposal three, which could work either with the structured dictionary values or structured array entries, separating out textual description versus like web-based documentation with two different keys, "doc" and "desc." In my personal opinion, none of these are actually better than the current very simple thing. I don't think we want to have a lot of structure here. Adding structure here encourages complex negotiation, and I think this is fundamentally a thing that we don't want negotiated by machine because the set of things that could be expressed in a profile is the full extent of X.509 plus whatever the heck you're doing in your private PKI. And so, like, we don't want to be negotiating that here. I don't think this actually needs extension points. I am very happy with the current version, which is just mapping profile names to bare minimum documentation. Use a URL if you think your subscribers need more documentation. But people have proposed these in good faith. I think it's important to put them in front of everyone to get real discussion happening. And if people in general, if the working group in general is strongly in favor of one of these three alternatives, I'm happy to listen to that.
Richard: Aaron, I would note that your current version is not in fact as simple as it could be. It looks like the structure here seems like kind of a half-assed attempt at documentation. Like, if you're going to be real serious, you'd like to make sure that it's a URL so you know it's a URL and you can go access it. Like, this is sort of half-way there. You could just have an array of strings and say all the information, all the documentation is out of band. Go plug this into, you know, Perplexity or something if you want to know what this means. Honestly, that's—I think for me the more appealing cases are either that or one of these things that actually builds a structure and has rich metadata. But I agree that rich metadata here seems undesirable. So, I would probably just go for an array of strings.
Aaron Gable: Yeah, that makes sense. The reason we went with where we did is that it felt like the appropriate middle ground between solely for machines and solely for humans, specifically for the flow of like, I'm setting up Certbot for the first time and Certbot prints for me, "Hey, there's some profiles for you to choose from. Here's the description of each of those profiles." And then maybe I get a string and I pick one of them, or maybe it's a bunch of URLs and I Ctrl-click them from my terminal or whatever. But like, a very simple way for an interactive, like first-time setup ACME client to present me with everything I need in order to make an informed decision. That—that's why we selected this as the starting point.
Richard: I think if you were going to do that, though, I think the minimal amendment you ought to make is to just say that the values in the dictionary are URLs. Like, don't have this ambiguity of maybe it's a URL, maybe it's not. Just say there's a URL that's the documentation. If you don't want to have a real documentation there, you point it to something bogus, some meaningless URL. But yeah, give that field a definition, don't have it be ambiguous.
Aaron Gable: I'm okay with that. Sean looks like you're up next.
Sean: All right. Hey, I'd say just leave it alone. There's probably 20 ways we can dance on this pinhead. Just be done with it and move on. Sorry. Thanks.
Aaron Gable: Fair. Corey?
Corey: Yeah, so I think what I'm going to say is going to fall pretty close to what Richard and Sean said. Just make it a URL universally. If someone wants plain text, they can use a data URI to do that with text/plain and then put their text in there.
Aaron Gable: Cool. I'm down with that. I actually quite like that as a way of imposing a little more structure on it without having to change any of the currently deployed clients or servers to expect like JSON structure there. So, yeah, I'm totally on board to just make a change to the draft to restrict it to being a URL.
Mike: And I'll just throw in one more comment. Michael Richardson in chat said either it's for humans or it's for machines, and that seems to be the general consensus here—is the middle ground is weird.
Aaron Gable: All right. Thank you for the discussion on that. Looks like there's no more hands in the sidebar. So, yeah, last slide. Obviously, we can wait forever for implementation by additional parties if we want to, but other than that, I think we're quite stable and this is being used pretty successfully. And so, whenever the working group thinks this has wide enough client and server implementation, I'm happy to go to Last Call, but that's not up to me. And that's it.
Mike: Okay, so what stands between us and ship it? Are you going to trigger a Last Call?
Aaron Gable: I mean, I'm just the author of this one. Like, I am happy to push it for that. I will publish a draft-02 that restricts profile values to be just URLs. I'm very happy to do that. I'll do it as soon as the document freeze is over. But from there, I would just go to Last Call.
Mike: The document freeze is over. Has been since Monday.
Aaron Gable: Oh, yeah. As soon as I'm back from vacation. Okay, so we'll make a note in the minutes here. So, the action is you're going to do that restricted to URLs change and then we'll try and get this pushed through Last Call. Yep. Sounds good. Great.
(Presentation: Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type - https://datatracker.ietf.org/meeting/125/materials/slides-125-acme-automated-certificate-management-environment-acme-remote-attestation-identifier-and-challenge-type-00)
Mike: Next deck. I don't know who's in the minutes. Probably all of us are talking, but if someone could note that in the minutes. This one is Peter, I believe.
Peter: Thank you for live tech support. Okay. We should be good to go. So now the clicker has the control, right? It's basically an AI agent that is an AI ent. Lame joke. Hi guys, this is Peter. I'm giving a update for ACME-RATS on behalf of the authors. Quick recap: what does the document do? It's to combine the RATS process with the ACME process. In this way, we can give certificates to attested devices only. And recap for the use cases: we have network access use case for enterprise campus networks because usually we have some kind of power company inspector clients that wants to have a more useful and more convenient certificate rolling mechanism that can help them to inspect their power plants easily. And the ACME server in the cloud situation would like to put a security policy on the ACME clients that wants to know about certain attributes such as private keys and the secure modules he is using. Changes from last IETF: so we issued a call for adoption, and the ACME working group has adopted the draft. And thank you all. Thank you the authors and ACME group. And after that, we have two design meetings. That was before Chinese New Year when I went back to—so, Mike has created two PRs that are critical to the contents of the document. One is for editorial and one for the protocol designs. So actually, we had several design choices and Mike gave a thorough review on that and led the design meetings to discuss and got we all to agree on, except for there's small design choices we're going to show later. Let's take a look. So until now, we have the major design decisions listed here. Give me if I miss anything, but I think that's probably everything or most things you're going to need to understand or implement a POC. So we have the first thing is that the important question is that how will the attestation challenge work with other challenges? So basically, we decided it should be work as a supplement to other identifier challenges. So you have to complete at least one of other regular challenges and then you have to do remote attestation as addition. So the remote attestation identifier value is dummy, is not an actual identifier, but in the future you could also—you could be empty, but also you could use to carry the property that you want to be attested. And also design choices for carrying or transmitting the attestation evidences results or endorsements is that we post a attestation result to a challenge URL. And also when we post it, the format is either raw JSON or RATS CMW wrapper. And for some situation, the evidence would transport over public networks, so it could benefit from encryption to avoid sensitive information leakage. So in this situation, if we want the evidence to be encrypted, it must be encapsulated into a JWE envelope. And I think the current suggested way to get a attestation freshness nonce is that we currently—we with this is the point we could collect some working group feedback or suggestions. Right now, we say the client should use freshness nonce randomly generated by the server provided in the challenge object as a attestation freshness nonce. But for the next slide, we put this as a discussion point because you know, there are questions like the freshness nonce provided in the challenge object, something like it may or should or should not or must not be the same as the ACME nonce, the ACME itself's nonce of the challenge URL. This is the part, you know, sometimes we can reuse nonce, sometimes we should not. So this may be the discussion point. The second one is the when we do evidence encryption, we need to fetch the proper, correct public key to do evidence encryption. So when we are retrieving this from a URL, should it always be a JSON Web Key format? That's a question. And the third one is that will be the cases where the access challenge does not act as proof of control of a identifier, such as validating a serial number a component. Can I finish first and then ask for suggestions? Yeah. So next step, ACME RATS design team meeting's going to continue. We'll finish up some to-dos and editorial notes, for example, like doing some compare and contrast with Device Attest and other to-dos. So I think because I have been working on a proof of concept, but that's kind of half-route so this was not taken to the IETF this time, but it will be taken to the IETF next time. And also, yeah, if you're interested that we are doing regular design meetings and welcome you to join. Discussion. Questions? Suggestions? I don't see a queue, but I can maybe prompt a question. Yeah, here comes Aaron. So, Aaron's the person whose careful eyes I want on this. So, we've abused the identifier mechanism because the behavior that we want is that the device attestation complements the existing challenge types rather than replaces them. You can't necessarily use device attestation to prove that you own a website, for example. So, in order to get the attestation or DNS-01—attestation and DNS-01, we needed to get a bit hacky with how we're using identifiers. So it's definitely a bit abusive of the protocol, but it's how we got it to work. So, I would like review on this for sure.
Aaron Gable: Yeah, I have not done a detailed reading of the latest version of the draft, but this approach where the attestation is its own identifier is exactly what I was imagining and exactly how I think this should be done. The only thing I need to refresh myself on is like, in the resulting cert—in general, ACME identifiers and this sort of goes back to what we were talking about a few minutes ago with the Device Attest draft. In general, all ACME identifiers have two representations. One of them is a JSON representation used in the ACME protocol and one of them is an X.509 representation that shows up in the resulting certificate. And—well, if—if these attestations end up showing up in some sort of weirdo bizarre extension in the certificate, then we are 10,000% good to go. If they don't, um—well, I think we're still fine.
Mike: So this is why it's abusive, right? Because the RATS data may not contain anything that is actually an identifier. It might be saying, "I am an HSM," "this key is on an HSM from HSM 9000 and here's its FIPS certificate," and absolutely none of that ends up in the final certificate. So it's like a wild abuse of the concept of an identifier. Yeah, you're right, we're going to have the same what-goes-in-the-JSON problem that Richard is listening very carefully for. But this is the only way we could figure out how to jam this into ACME in that it doesn't—because any other way to—if we just did it as a challenge, then you'd get to choose to either do RATS or do DNS-01 and that's not the behavior we want. So it's all—yeah. Anyway.
Aaron Gable: I—I think it's completely fine. I think a lot of the attestation are things that you can imagine showing up in the certificate, right? Like, the CA might want to say, "Hey, when I issued this certificate, I did in fact verify that this pub key or that the private key corresponding to this pub key is stored on a FIPS certified HSM," right? That—that is a valuable thing that a relying party might care about, and so that is something that could be encoded in a certificate and so I think we're fine here. This is fine.
Mike: Yeah, or—or it's just a requirement of the issuance profile. To get a code-signing cert, CAB Forum compliant, you must do this, it's sort of implicit. Anyway, we are out of time. I want to yield the floor, but would love to continue this on list. Thank you, Aaron.
Aaron Gable: Yeah, I—I had one other thing that I was actually raising my hand for, which was if you go back to the open questions slide. Yeah, this one. I need to think more about numbers two and three, but number one, it seems like the freshness nonce should be basically the same thing as the token provided in the DNS-01, HTTP-01, and TLS-ALPN-01 challenges, right? It's just a field provided—like when the ACME client fetches the challenge object, it contains a token and in DNS-01, that is the token that you would populate into DNS, and in this, that is the token that you would end up signing some attestation blob over. Um, I think we should use the exact same transport mechanism for it. It definitely should not be the freshness nonce from the HTTP header. Um, it definitely should not be that.
Mike: And I think chat has agreed with you. Yeah, they should be independent nonces. Great. Thank you. Okay, any other discussion on this draft or do we go to the next? See none, I think we go to the next. You have to pull the thing back from the clicker first, though. You have to click on the—there you go, you did it.
(Presentation: draft-ietf-acme-dns-persist - https://datatracker.ietf.org/meeting/125/materials/slides-125-acme-draft-ietf-acme-dns-persist-00)
Mike: Then DNS Persist. It looks like I have the clicker. Thank you. Hi, I'm Shilo. This is the DNS Persist discussion. The DNS Persist lets domain owners place a persistent TXT record that authorizes a specific CA to issue certificates. It was adopted by the working group last October. So, we've had some substantial changes since Montreal. We have three PRs that are merged. The most significant one is 35, which is decoupling the account URI from the challenge object. The—in the earlier version, the account URI was tied to it and now the DNS record stands on its own. We also added a many-to-one URI model for privacy. CAs must accept the account URI but may issue alternative URIs to prevent cross-domain correlation. And the next one is PR 36, which came from Samantha implementing Pebble. This is: why is policy case-insensitive but account URI isn't? These are different types. Now, we have a comparison following RFC 3986, and it's explicit for all parameters. PR 41 renamed the authorization domain name to validation domain name to align with BRs. And the implementation status is that Pebble and Lego have merged the initial code. Cert-manager has a community feature request open, and I put a prototype together. We have an -01 version publication pending some editorial fixes, and we have four open issues that we're going to discuss today. So, subdomain validation gap. The problem is that the client has a record with a policy of wildcard. And in this example, we have three levels down. The CA does not know which level of authorization the client intended. So, there are—there's an ambiguity there and we also have the problem of that if the CA is traversing the entire hierarchy, then we have a ton of DNS queries. So, the solution here that we propose is a new ADN response field that directs the CA to use the ancestor record. So, the ADN response field is part of the ACME extension point. Uses that to supply the ancestor record. The CA then confirms that that is a valid authorization domain name for the record for the certificate request and then the CA looks that up, finds the policy and validates. So, there are—with this mechanism, there are two open questions we have, which is: do we want to restrict the label pruning? And should this be in the same draft here targeting version two? The next question is TTL as a validation ceiling. The—the current text defines three ceilings on how a CA can—or the previous text defined three ceilings on how long a CA can reuse validation data. The issue is that this is some a layer confusion. And TTL governs DNS caching. It was not designed to control the CA business logic and we wrote this as a must originally, but the analysis has changed our position. So, we are removing the TTL ceiling in -02. Next is IP validation via reverse DNS. The scope is—the question here: do we want to put this into the same draft or a companion document? And this is based on SC-91 passing and we have some support for this, so we—this is an open question here as to whether we want to pack this in here now or not. Oops. Next up is client-side persistency check. Should clients check that before responding to a challenge? And we have another one which is deferred until we understand better the ADN failure modes, and that is to clarify and add error types. So, priorities for -02 release are resolving the TTL question, speccing the ADN field for subdomain validation, deciding the IP validation scope, and the editorial cleanup. So, right now, we have -01 mostly ready and we have some editorial fixes for that, and then the subdomain and TTL question will be for -02. If that resolves everything, then we'll do a Last Call at -02. Otherwise, the IP validation would make it -03. We have Let's Encrypt is implementing currently, Fastly still committed, Amazon is assessing. And that's time for questions.
Aaron Gable: On the topic of slide four, the proposed ADN response field. Indeed, there's some interesting comments that just came in. And yeah, worth getting this in here. I'm still thinking about this, but on the GitHub issue representing this open question, which full disclosure, I filed, someone just posted a comment literally a couple minutes ago saying, "Hey, doesn't the RFC ACME for Subdomains actually, which is RFC 9444, actually provide a way to do this already?" And I think the answer is yes, and we need to spend some more time thinking about whether the answer is really truly fully yes. But yeah, so that's one possible direction for this to go.
Shilo: Yeah, it's interesting. So, the ancestor domain is the mechanism that that would use, and I think that—I think it is—it is actually workable. I think that the question—one question that comes up is architecturally, does this make sense? Do we want to have the order involved with the authorization domain name, rather than keeping that only within the challenge validation piece of it? So, that's my initial reaction, and I think we need to look into it a little more, but it could work, certainly.
Fabian: Yes, hello. I posted that comment. Sorry, I didn't state my name for the AI, so Fabian of Google Trust Services. I posted that comment earlier on the GitHub issue. To be honest, I haven't reread that RFC in a very long time, I'm not familiar with it. What I wanted to ask is basically, is there—so I'm sure that the proposal in the DNS Persist proposal is probably more elegant than the existing one. But now is there a world where a CA may implement both? And then which one takes precedence? So maybe we need to think about compatibility between the two or explicitly states that one is not compatible with the other or... yeah, basically, do you have some ideas about that?
Shilo: I think they are compatible with each other. I—and as far as precedence, that would, yeah, that would be a good question then.
Aaron Gable: I off the top of my head, I think the really big difference is the RFC 9444 version is basically saying, "Hey CA, you should create an authorization object that is based around this other ancestor domain," and just putting the ADN in the challenge object is sort of a way of saying, "Hey CA, I don't care what your internal authorization storage structure is, please just go authorize against this other name." And so it feels—putting the ADN in the challenge post feels less invasive, but that doesn't mean it's better. So yeah, we need to just do more architectural thinking about it. I—I would love to hear from CAs who have actually implemented RFC 9444. I have no idea who that is. I don't know who is doing ACME for subdomains. I have no idea if it has any deployment. If you know anyone, please reach out. I would love to talk.
Shilo: Yeah, I think that definitely adds more complexity over what is there now. Okay, so would we like to discuss the next pieces of the discussion in these boxes here? Yes, please. Where does this go next? Okay, so the—the boxes here on the bottom are where we want to chat. So, the ADN, if we do it, we sort of covered those, I think. But yeah, I think make sure there's—see what comments there are on the proposals and if there's any discussion on IP validation pros and cons for adding it now.
Mike: Michael Richardson's comment is interesting about DNS Persist is greater than subdomains and should deprecate 9444, so that's an interesting perspective.
Fabian: Me again, so it's already written on the slide, but I just want to underline this, that Google Trust Services supports the same draft approach.
Shilo: We authors are not enough for or against that necessarily, so we just want to get the feedback here.
Aaron Gable: I'm supportive of putting IP validation via reverse DNS in the same draft. I don't think it's too much extra work. I think there's—like, I don't think this draft is two weeks away from going to Last Call or anything like that. Like, it's really good, but clearly we're still working through a few things on it, and so I think incorporating this isn't going to meaningfully delay us. The BRs have already done it. Let's Encrypt intends to implement it. So, I say we just do it.
Shilo: Cool. That sounds like consensus to me. Do you have what you need to continue? Indeed. Yes. Excellent.
(Presentation: ACME Extension for Public Key Challenges (slides) - https://datatracker.ietf.org/meeting/125/materials/slides-125-acme-acme-extension-for-public-key-challenges-slides-00)
Mike: Then on to the next. John Gray points out Entrust also produces these stacks, as does Keyfactor. They don't operate them, but they produce them. Okay, so that concludes that. Topic has been proposed. I will work with the author to get a draft posted, and then we can continue discussing suitability.
Aaron Gable: I was just going to say real quick in terms of looking for a co-author and implementer, I suspect you might be most likely to find that at a commercial CA like DigiCert or Sectigo. Yeah, that's the best I got.
Mike: All right, thank you. Pan, are you presenting? Here we are. Give to the clicker.
Speaker 1: Okay. Hi everyone. Thanks for time. And this work is contribute by Genfeng Wupanyu and Xialiang from Huawei and Chenxin from TrustAsia. I'm here to presenting and Chenxin is online to help with the questions. I'll go through three things. First, I'll introduce the PK challenge and we have to know why we need it and how it look—how it works. It help us to remove the CSR in web PKI and it helps to issuing certificate to device and users in non-web PKI. Second, I'll mainly touch on some use cases as we have already discussed on the mail list. We will split them into separate drafts and—and separate drafts. And finally, I'll go through our next steps. Okay, let's start with the motivation. There are two main things we have trying to address. First, on the web PKI, the ACME recently use a CSR to in every certificate request. So, but in practice, the CSR can be more a can be more complex to the client side. So our mind is simple here. If everything is everything is proved during the challenge, so maybe the CSR can not have to be the mandatory. Second, in non-web PKI, ACME recently prime tot—recently works well in the domain name, for example, like the web survey using DNS or HTTP. But more and more system are built around public key identity for users and device. So where is PK challenge comes? We can use it to issue certificate to device and users. Okay, let's see the basic framework. We add two simple simple flag in at the order stage: the PKBinding, which can carrying the PK public key and the CSR-less, which can index index whether CSR is removed. So the flow is similar to the standard ACME flow. The ACME, the client sends the order and the survey returns a little of question challenges and the client select one challenge and reply prepare validation materials and finally the survey validate every every thing and made the challenge valid. Okay, the key question is why we can remove the CSR? Look at the CSR like the core component can be all covered. The subject can derived from the order identifiers and the public key can in the PKBinding. And SAN also can be find in identifies. And the signature, we can use replaced by the perform of processions. So this is why we say use CSR is a optional. Next is the core part: Proof of Possession. In web PKI, we extend the we extend the existing challenges, so we keep the real original real original domain control and we just add one more thing. We add the signature using the claimed private key. So it not only to control the domain but also can control the corresponding to corresponding public key. In the non-web PKI, the model is a little bit different. They are all rely on—we we define the challenge like the PKCS-R-01 and PK-Cert-01. They all rely on the public key authentication with the IDP. Just the client interact interact with IDP and IDP returns the assert. So the CA trust assert within use the PKBinding. Okay, let's make the backward option optional. At the ording stage, we add one flag CSR. If the CSR is true, so we can skip CSR. Otherwise, we have to follow the standard ACME flow. So this is effectively effectively makes the CSR optional and it doesn't breaks the existing development. We take the PK-DNS-01 as an example. The flow is similar to the ACME flow. There is just one difference is that we instead of putting the plan date on the DNS DNS TXT record, we also add the signature. So the client compute the hash of key authorization and sign it with his claimed private key and then publish it in the DNS TXT record. And finally, the survey re-recomputes the hash of key authorization and validate it using the public key in PKBinding. Then if it all make checks out, the challenge is valid. Okay, now look at the non-web PKI. We mainly touch things like enterprise internal systems, IoT device and so on. In this environment, identity are usually managed by the IDP, so the client are interact with IDP and the CA trust the the assert from the IDP to validate the request. So from this we can we instead of controlling the proof of the domain, we rely on the identity controller. Okay, we also looked at the combined with opaque. The main goal we have to issue is that it can security recovering and authentication. So it especially on the public terminal or device. We have already discussed on the mail list, so and we have planned it to we plan to split it into separate drafts. Okay, there is our next steps. I'll split our PK-00 baseline into a separate drafts and we recently update to the version five. And this is our main modify, especially on the web PKI and non-web PKI and CSR optional details. And if everything is stable, we will we will plan to issue a call for adoption. And what's more, we will work for the other separate drafts that draft by our PK baseline use cases. Okay, that is all from me. Thanks for listening and we are happy to take questions. Thank you.
Mike: So, there has been some discussion in the chat about CSRs and I don't know if we want to bring—if anyone from chat wants to bring that to the microphone for the benefit of the presenter, who is not looking at the chat. Because one—I mean, your draft is doing a number of things and one of them is that it's finally trying to tackle removing CSR from ACME. And so there's been a discussion in chat about whether that's useful and whether that's good. But that's only half of your draft. The other half of your draft is addressing, you know, the reason that you need to take out CSR, the reason that you need a pop challenge, has to do with the Opaque protocol. Um, so I would encourage people who've been in the chat to come on the microphone and discuss either the CSR aspect or the or the Opaque protocol aspect of this.
Richard: Hi. So yeah, thank you for this for raising this. I think all the way back to the beginning of ACME, we were pondering whether we needed CSRs at all or whether we should just have some signed JSON thing. Um, I think we went for CSRs out of convenience because it was widely supported um and you know other predecessor protocols used them. But I think it's wise at this point in the lifetime of ACME to start considering cleaning it up and being more native. Um, I think the thing that confuses me—so I understand the objective, the requirement here. I think the thing where I get confused with this draft is the way it ties into all the different challenges into DNS and HTTP and TLS. It seems like you could just as well have a more direct thing: don't validate the identifiers as you do today and then separately validate control of the public key. Um, I'm curious if there's if there's a reason um that you chose to architect it that way, if there's a reason you conjoin the identifier validation together with public key validation. And one thing I'll note is that one thing I think we lose in the way this draft proposes—we do lose a security property if you do things the way this draft proposes, which is that um the signature on the CSR uh covers the identifiers that are intended to be in the certificate. Um and having those subject private key sign those identifiers is important for avoiding unknown key issuer attacks. So um I think it wasn't immediately clear to me that this approach um got that property. Um, whatever CSR replacement thing we do needs to have that property. Um, so yeah, if you could comment on why you conjoined the identifier validation with the public key validation, I'd be interested to hear. Thank you.
Speaker 1: We just um keep the real the original domain control and we didn't cover the identity. We just add one more thing is that a signature from the claimed property, so there is a separate separate things, I think.
Aaron Gable: If if I can, Richard, I I think the draft is not coupling the pub key proof to the domain validation proof. Each of these challenge types is a brand new challenge type that is valid only for identifiers of type pubkey and they're just shaped sort of like the existing challenge types. So PK-HTTP-01 is like HTTP-01 in that you provision a file under dot-well-known ACME challenge, but the contents of that file are a verifiable signature over some nonce value. I think that's what they're going for here. I don't think all of these different methods are necessary. I think what we should probably focus on is one synchronous method and one asynchronous method. So if the key is online and reachable, then we should like do a TLS handshake with that key and if you're able to complete a TLS handshake with it, then that is clearly proof of control. And if the key is not online and not able to be used that way, then yeah, it should sign some object that probably looks kind of like a CSR because that's a thing we expect TLS keys to be able to sign, which kind of sucks, but at least it preserves some existing nice cryptographic properties. And then you could post that signed blob, which like, you know, maybe looks like a CSR with an extension and that extension contains a nonce, sort of like the current TLS-ALPN synthesized certificate, and you post that to the challenge URL and say, "Great, here—here's the thing that proves I control this key with temporality. I control it right now thanks to the nonce." So I think if we have those two challenge types, something that is synchronous and hopefully looks like a TLS handshake and something that is asynchronous and has some various nice properties, those are probably the only challenges we need, rather than all six of these. But I'm definitely open to hear arguments for why some of these six challenges should be preserved.
Peter: Hi, this is Peter. I think I continue to Aaron's asynchronous design part. I think that part of, you know, signing a blob and then returning to the challenge, I think that's totally makes sense and I think the how when we look at a similar work is OAuth Token Binding, where they kind of bind a access in an application layer to a transport. They have a similar approach, maybe we can look at, maybe the authors can look at and, you know, um maybe that's kind of the source of best practice to look at. Um,
Mike: So I'll raise a point here that I had proposed on the mailing list, which is to me, and I'm saying this with my chair hat on, um, to me there are two aspects of this work that are really quite separate. One is replacing the CSR with a more direct proof of possession, which is this slide. And then the other is using ACME to issue certs to passwords, which is the Opaque aspect. And to me those are really—the second thing, the Opaque thing requires the proof of possession thing. Like there's a—I see there's a dependency between those two, but they are really quite separate. So I would encourage the authors to split this into two documents because I think the people who are interested in PK-01 are quite different from the people who are interested in the Opaque, and I think the kind of review that those two documents need is quite different. So I think I—I would encourage you to split these into two documents so we can review them separately. Yeah, and Aaron points out that it's already been agreed on list that the split will happen. So maybe—maybe my point is as much for the reviewers as for everyone else is these two aspects I'd like to treat independently.
Richard: Just one other more minor syntactic protocol structure point. Um, we're looking at the thing that's on the screen here is all about challenges, which are subordinates authorizations which are all about identifiers. Um, so we might want to consider keeping the identifying the authorizations chunk of the protocol, chunk of the order flow, as focused on identifying on identifier and treating public key validation a little separately. Um, I could go either—it might be arguable but it might be worth considering um making a separate protocol affordance for key validation as opposed to identifier validation.
Aaron Gable: This is probably my fault, as we discussed at the beginning with Mike talking about Device Attest and like, "Ah, are we abusing the concept of an identifier?" I am the person who was like, "Hey, a pub key is a thing that gets baked into the cert, we can represent it as an ACME identifier, we can prove possession of it with ACME challenges. I think this is a good fit." So you can lay all that on my head and if we want to go a different direction, I'm open to hearing it, but it's definitely my fault.
Richard: Like I said, I think it's—I think it's arguable. I just wanted to put that on the table in case it hadn't already been discussed.
Aaron Gable: Totally.
Mike: So, as your AD, I think the first step is obviously to to publish drafts that separate these two ideas, and then you need to get reviews to see whether they're close to being ready to go and then you can do call for adoption. But I think you've got to publish the drafts first. And then you can have discussions, right? Okay. This seems to me that we've sort of reached a decision of what to do next. Authors, do you want to have a final comment here?
Speaker 1: Thanks for all your comments, and we will um define our drafts in version five or version six. Thanks, all.
Mike: Okay, thank you.
(Presentation: emrtd-data-01 - https://datatracker.ietf.org/meeting/125/materials/slides-125-acme-emrtd-data-01-00)
Mike: So then, if I'm tracking the agenda properly, we have one last presentation, which I am going to give in place of Sebastian Robin-Nielsen, who's not—who's not an IETFer. Um, we do have lots of time. I don't necessarily need this to take a whole 45 minutes, I'm expecting us to end early, but we do have plenty of time for discussion. So, this document is presenting EMRTD, which if you're not familiar with this landscape, is effectively e-passports and things that sort of act like e-passports: electronic driver's licenses, electronic citizen ID cards, these sorts of things. So this is—this draft is attempting to get us into the whole world of: can we use ACME to issue certificates to physical documents? Physical documents that contain a smart card chip. All right. So, what is an EMRTD? It is a machine-readable travel document. So this this technology stack is an ICAO standard, I believe it's an ETSI standard, correct me if I'm wrong. Um, is not traditionally IETF technology. So now we're colliding two technology worlds. So the original MRTDs without the 'E' was the generation of like passports that had a magnetic stripe and you could like swipe your passport on a swipe reader but didn't yet have the like tap functionality. So that's the MRTD and then EMRTD is when they started adding NFC chips into them. And then they could really properly do public key crypto because there was a processor inside. So we're talking about that—that technology stack here and they do use X.509. Um, I'm actually personally quite familiar, I've worked on the e-passport stacks myself. Um, so we're talking about how can we use ACME? ACME is currently not used in these infrastructures, but could we adapt ACME so that it is a viable technology for issuing X.509 certs into EMRTD chips? Um, yeah, and there's some details on the slide here. So the chip itself is password protected using using that word is pronounced "Pache" or basic access control. Um, passports, ID cards, driver's licenses, it's anything that has this symbol on the cover is—is the target is the scope here. Um, yeah. And I'll note that these—these ecosystems are complex, right? Um, one thing not on the slide but I'll add personal experience is the documents are one half of this ecosystem and it's, you know, it's tricky enough to issue a certificate to a passport that lives for 10 years and is will never be online again, right? The passport, when it is shoved under the cover of of the document, you never get to touch it again, you never get to update it, and that brings inherent risks of supporting a thing like that for 10 years. Um, also, the inspection stations get incredibly complicated. So, for those of you who traveled to Shenzhen this week and you presumably had to present your passport to one of those bright—brightly lit reader kiosk machines, um, the interaction between the kiosk and the passport is extremely complicated and involves more certificates and if the reader, it's one of these ecosystems where not all readers are created equal. The reader that belongs to an airline where you put in your passport to get a boarding pass or a luggage tag, it only needs to read your basic info: your name and birthday, but the reader that belongs to a customs inspector, it may actually unlock fingerprint data or or iris scan data or it may unlock the the full full high-resolution photograph. That data can be in the chip. Isn't always, but can be, depending on the issuing country. And so when you do a fingerprint scan at an inspection, customs inspector, it is possible that it's actually comparing your fingerprint scan against data stored on the chip and there's obviously huge confidentiality concerns there. You don't want to bump into someone on a bus and have them extract your fingerprint from—from the passport. So in that case, the reader needs to authenticate itself to the passport. And now we're in a world where the passport is actually validating a certificate presented by the reader. And so the passport needs the roots of trust and yada yada and it ends up being this hugely complicated ecosystem where every reader needs a certificate from every national CA. And you know, you count how many countries there are in the world, multiplied by each country may run multiple CAs on different algorithms or there were different expiry dates. It ends up that every reader could need like a thousand certificates that all have different expiry dates and whatever. So the—I just want to make the point here when we're talking about EMRTDs, the documents are already complex enough, but the readers are like they rival anything we deal with in the Web PKI world. So I can understand the motivation to try and bring ACME here, converge these technology stacks via ACME to try and make the issuance problem a little bit simpler. So that's the background where this work is coming from. Um, yeah, so why—why EMRTDs and ACME? Um, so this slide, I won't go through in detail but it's a pitch for why the author here believes that ACME would help to simplify. I mean, obviously this stack works and works at scale today, but the pitch for why he thinks that ACME would help to improve, making ACME an option in this space would be an improvement. Um, just leave this up for a moment. It allows for easier automated validation, ACME is more privacy-friendly, ACME is a well-established trusted protocol. The technical proposal, this is going to be a bit of an eye chart but that's okay. We decided to include the details. So the—there is a draft, it's not yet on Data Tracker, but there is a draft for this and it proposes a a modified ACME protocol flow, which adds the challenge type EMRTD data 01, which is attempting to facilitate the—the various things that need to be proved in order to do EMRTD issuance. And I'm aware that like the other drafts we're working on in this working group, like the federated ID, um, we're colliding two very different domain worlds here. So I'm not expecting the ACME working group to do deep review of the EMRTD protocol properties. Um, our job here as the ACME working group is to make sure that the way they're fitting it into the ACME protocol makes sense, but the draft that's going to be forthcoming does contain these details.
Richard: Sorry, I may have lost the thread here a little bit. Um, so I I kind of got what you were elaborating about the—the ecosystem here of passports and readers. What is the proposed use of ACME here? To what device are we issuing—is who issuing a certificate?
Mike: I believe the currently proposed draft is issuing to documents, to—to a passport. So you see there's the NFC submission is one of the blocks here, so—but I believe the passport is involved in the ACME flow via holding it against some reader. So I think I believe the target here is documents. I added the kiosk, the inspection station just as color that this ecosystem could involve more, but I believe this draft is just targeting issuance to documents themselves.
Richard: And is the idea that the identifiers in the certificate, as it were, comprises the information that is presented as part of the EMRTD: fingerprints, pictures, names, dates, etc.?
Mike: Yes, and I'd have to go back and review the details of the ICAO specs very carefully. I think the fingerprints type stuff, that's not in the certificate because it's—that is actually private data and the kiosk has to authenticate before it's able to see it. So I think the certificate contains a a subset—like so if you imagine the data that's on the photo page of your passport, the certificate is some privacy-reduced subset of that page. Yes, and I believe the intent here is that you would have to prove ownership, to use the ACME verbs, of those as part of the enrollment.
Aaron Gable: One comment and one question. My read of this was slightly different from yours, because this slide and the previous slide and some of the emails are specifically mentioning individual validation. Like, the top-right text block here says the CA issues the certificate which is IV-validated with the client's name inside. That reads to me like the intended use case here is issuing Web PKI certs that contain additional subject fields like the individual's name um in an automated fashion. Whereas, like, current Web PKI CAs have to like get a scan of the passport and have a human in a call center validate that it's correct or whatever in order to issue an IV cert. Um, and my read is that this is moving us towards a world where those CAs could issue a wider variety of certificates containing a wider variety of subject data with fewer call center people doing personal validation and instead doing automatic validation. So that's—that's the comment.
Mike: Okay, that actually could well be in which case I apologize for misrepresenting the the draft. If—if that's right, if—if this slide is how do EMRTDs help supplement ACME instead of why do EMRTDs need ACME then that would be a different view. Okay. Apologies to Sebastian for butchering his presentation.
Aaron Gable: I have no idea if I'm right, I I had a different read on it but I'm guessing just as much as you.
Mike: If if that's right, if—if this slide is how do EMRTDs help supplement ACME instead of why do EMRTDs need ACME then that would be a different view. Okay. Apologies to Sebastian for butchering his presentation. Um, just looking at the the leftmost column here. It says "applicable to all certificate types including code signing, TLS, etc." which yeah, sounds like you're talking about some it's basically the "papers, please" challenge. All right. Good. And so my question actually comes from the next slide. It says—oh, I—oh, well, fundamentally, the thing that's happening here is like the passport is providing this data, right? The passport is saying, "Here's the name that you should include, here's a signature over that and this signature chains up to some root that you trust, some ICAO root." That feels like a backwards flow from how most of ACME works right now. Like, what is the identifier in this case? Like, should the ACME client be saying, "I am going to claim that I have this name and this country of citizenship and these other pieces of data," and then the ACME server says, "Oh yeah, prove it," and then the passport reprovides all that same data? Or is the author really proposing that the ACME client just says, "I want to include data from a passport. Not going to tell you what data," and then when they do the challenge, they present all the data from the passport? Because if it's the latter, I have some issues with that, but I'm very curious.
Mike: Right, or or as Richard sort of implied, is it more that you're proving that you're the human who owns the website that the cert is being requested for? Yeah, okay. Questions. And I apologize that I don't know the answers. Um, next slide. Yeah, which I can read or I can allow you to read. Can be used to issue IV, for example, code-signing certs, can be coupled with other attestation mechanisms such as Device Attest 01 or the Lamp CSR mechanism, can be used for S/MIME. It's highly secure, I think because—because, as Aaron said, we trust the the ICAO infrastructure. Uses established PKI infrastructure, extremely trusted. Yeah, that's point number four. And can be tailored to the CA to use different initial authentications if passports or IDs are not stolen, so it's not necessarily tied to passports specifically. Could be coupled with an biometric web portal. Um, the—the author has tried to predict what some of the questions would be asked by the group are, which I believe is our last slide. So, let me—let me do the next steps and then I'll leave the expected questions and answers slide up. So, step number one, um, he has a draft on GitHub that he manually formatted into the RFC txt format, I think by hand. Um, I will help him port that into Markdown into our proper build tools and get that into Data Tracker. Then we will start a discussion on list, um, once the draft has been properly posted. Uh, make sure we understand what the intended use cases are and then we can ask all the "why ACME?" and "what do you need from us?" type questions. And then importantly, we're looking for an implementer. So, the I'll point out that the this is a single author draft. He is operating as an individual, not on behalf of of any deployment. So, this draft would really benefit from a co-author who's able to provide some sort of running code, or able to provide um some indication that this is this is useful either in the EMRTD space or for doing IV of other types of certs. So I'll put the questions-answer slide back up and any other discussion is welcome.
Aaron Gable: I see Michael Richardson suggesting that we just wait for the internet draft and continue this on list. I was just going to say real quick in terms of looking for a co-author and implementer, I suspect you might be most likely to find that at a commercial CA like DigiCert or Sectigo. Yeah, that's the best I got. John Gray points out Entrust also produces these stacks, as does Keyfactor. They don't operate them, but they produce them. Okay, so that concludes that. The topic has been proposed. I will work with the author to get a draft posted and then we can continue discussing suitability.
Yoav: I suppose so. Uh, thank you all for joining this meeting. Uh, hopefully there'll be more people in the room in Vienna, uh, with luck even a chair there. So, um, yeah. See you all in Vienna, and on the mailing list before that. Thanks everyone.
Mike: Thank you. Thank you.