Minutes IETF103: acme
minutes-103-acme-02

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.
(_<port>._<service>._acme-challenge.<domain> 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