* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Acme Status Pages

Automated Certificate Management Environment (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2015-Jun-26 —  

IETF-103 acme minutes

Session 2018-11-08 1610-1810: Boromphimarn 1/2 - Audio stream - acme chatroom


minutes-103-acme-02 minute

          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
          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
          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
          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
          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
          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
          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
          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
          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
          AI: Another rev then WGLC

Generated from PyHt script /wg/acme/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -