ACME at IETF 103 # ACME is meeting at IETF 103 in the last session, Thursday II. 16:10-18:10 Agenda is as follows: ## Administrivia, 10 minutes Note well, jabber, minute-takers dkg for Jabber, Thomas Peterson for Minutes ## Brief updates, 10 minutes ACME, CAA challenge, IP identifier challenge, ALPN challenge Richard: I am still waiting for my co-worker to read an outstanding PR, I will probably merge it later tonight Chair: We will open another 2 week WGLC STAR, 30 min - ACME-STAR: Update as a result of the last-minute ACME changes, etc. Was already in WGLC; seeking a doc shepherd AI: Chairs to redo WGLC after the meeting (2 weeks), seek shepherd, and then send to IESG - START-delegation; now is an ACME profile, after feedback Call for adoption Richard: This is what is set to the IdO for DNS challenge? Yaron: Yes. Thomas Fossati: No, the DNS challenge is run just on the regular identifier name (the "value" of the CNAME), it is run by the IdO. Yaron: the CNMAE part is optional, simplifies synchronization of provisioning. Richard: What CNAME is provisioned as a result of this? Yaron Sheffer: CNAME points from DNO to NDC. Richard: I'll take a look at the draft and provide feedback Yaron: This could be used for long-term certs. Richard: This could be used for short term use case, but I don't see a reason to join this with long-term. Chris: If someone finds a solution where they are using them for long term, more power to them, we should encourage them. Yoav: What if we don't find such a use case? Right now we don't have any use cases Daniel Kahn Gilmore: If you are going to restrict delegation to STAR, how are you going to restrict it? What cut line would you use? Expiration or other? Yaron Sheffer: The document could restrict with a MUST. Tim Hollebeek: That (making delegation depend on lifetime) makes things more complicated, as this confuses delegation is for short term, but not for long term. It's more useful in short term, but generally useful, should not restict. Yoav: will want to take to the list. Chair: Are you requesting this be adopted? Yaron: That's on the next slide Rich: put it (restriction to STAR) in the draft as an open issue. Richard: If a CNAME has been delegated, the NDC "owns" it can do the HTTP challenge (maybe not the DNS challenge) just by having the record pointed at it. Jon Peterson: How does base ACME work when resolving the challenge? Richard: There are some CDNs today that do this today, for ACME issuance. Richard: It appears the CNAME here is confusing, but the rest of the document is sound. There is a scoping question if the CNAME connection is suitable. Jon: If you only have an account with the NDC, but not the IdO then yeah, you wouldn't be able to prove ownership. Richard: ACME accounts are cheap. Except where CA is imposing conditions. You may, e.g. lock a domain to an account but I'm unsure if that's being done in practice. Chris Wendt: Are you locking this to DNS type or open to other identifier types? Might want other identifiers in STIR. Yaron: Once this is a WG document, this is a WG decision, but I don't see a reason to lock it to DNS. Sanjay Mishra: The CNAME used here, the NDC is asking IdO to use it? Yaron: Yes. Hum on whether this area is of interest to the group - yes. AI: Chairs to issue call for adoption in 1-2 weeks, to give people time to read. ## Email TLS certs and EMAIL end-user certs, 15 minutes Who will read? Ready for WGLC? ## Email TLS certs Paul Hoffman: I don't understand the proposed change Alexey: At the moment service/port are single. If you wanted to issue multiple ports (IMAP/IMAPS) it needs to be multiple requests. Paul: I see no reason not to have multiple services. Chair: One array or two? Alexey: One array Richard: I'm confused. This document is talking about authenticating DNS, but what would go into a certificate is a Domain. Alexey: In theory you could issue SRV based IDs. In the most common use cases DNS IDs would be issued instead. Richard: I think this should be updated to cover SRV. Alexey: SRV is already covered in the document. DKG: I want to agree with Richard. If it's just on name, this is too complex. Several steps need including Alexey: For DNS challenge, there service name is included in the DNS name used for the ACME challenge. (_._._acme-challenge. TXT record.) DKG: If the cert being requested isn't specifically for the service, this could open an attack to other services for other protocols Richard: I suggest to create a new DNS-based ACME challenge type. AI: Alexey to add some clarifying text, Richard to send some AI: After next draft, WGLC; READ Paul Hoffman: These details aren't clear in the current draft. Richard: We have a copy of layers of indirection, what I am least clear on is the mapping of service to certificate. CA's may want to include SRV into the cert if you show control of the domain. Alexey: I'm hoping they'll issue certs with the service name. Richard: I suggest you implement SRV service IDs Tim: SRV has been discussed but not implemented Tim: The assumption all zones in a domain are controlled by the same identity is no longer true. Alexey: I am developing client side software that validate these, but first I need CAs to issue certs against this. ## EMAIL end-user certs Yaron: Are you expecting end user to perform this challenge or email client? Alexey: Both. If email client doesn't support this natively, it is possible to copy&past the challenge to an external program and then create a reply email with the calculated result. Chair: Is there any provision for multiple clients? Alexey: yes AI: Tim H and dkg said they would review ## TN Authority Token documents, 20 minutes Updates AI: Another rev then WGLC