# Automated Certificate Management Environment (acme)   {#automated-certificate-management-environment-acme}

*   IETF 118, Wednesday, 8 Nov 2023 1300-1400 CET (1200-1300 UTC), Room:
    Berlin 1/2

## Agenda   {#agenda}

*   Note Well, technical difficulties and administrivia (chairs) – 10
    min

*   Document Status (chairs)
    
    *   3 RFCs published bringing the total to 10
    *   1 in the editors queue (waiting on other drafts)
    *   1 in the AD queue (and the working group chairs)

### Work Items   {#work-items}

### draft-ietf-acme-onion (Q Misell)   {#draft-ietf-acme-onion-q-misell}

Q: Adding the already approved CA/BF method is done.

Q: CAA has caused a lot of discussions. CAA needed for consistency with
other TLDs,to prevent mis-issuance, organisational policy enforcement,
and publishing IODEF endpoint/contact details.

Q: -00 had an extra field in the TOR hidden service description which
causes issues with deployment, requiring CA's to run a Tor client,
audits for the TOR client, and client memory safety. Basically more to
implement and more to go wrong for the CA.

Q: The current draft sends the CAA data over ACME, under the service's
public key.

Q: signed CAA data could be placed inside the challenge response
(requires issuance within 8 hours) or finalized (more flexibility with
issuance time and validation types). - Q chose the finalized call as the
best option.

Q: asked whether the construction of the signed CAA data was the best
way. The expiry date is included in case the service wants to pre-sign
data for use over a period of time, but if that doesn't result in time
savings, then a nonce might work just as well. No suggestions from the
room. See draft/briefing for the details. Yoav asked Q to raise it to
the list after the meeting.

Richard Barnes (RB): One good way to get people's opinion is to ask for
WGLC.

Q: Wants to have the draft reviewed first for security issues.

Yoav: reminded Q that it takes some time to publish a draft. Yoav
suggested raising the issue to the list, and then if there aren't
overwhelming positions, it can be put forward for WGLC.

### draft-vanbrouwershaven-acme-auto-discovery (Mike Ounsworth)   {#draft-vanbrouwershaven-acme-auto-discovery-mike-ounsworth}

Mike: How do we automate discovery of the domain owner's preferred CA?
What they have discovered that this is harder than they thought.

Mike: showed an example where a cloud provider either can choose Let's
Encrypt or a PEM file. A PEM file won't work for any normal user if the
certs are only good for 90 days.

Mike: The solution is that the ACME client queries the CAA record for
the domain, which is overloaded a bit, but Mike thinks it is probably
ok.

Mike: the problem is where there are sub-accounts within a domain, web
certificates or S/MIME certificates for example, or sub domains within a
single ACME account, where there is segregation within a registered
domain.

*   How to associate the ACME request with the CA (billing) account? We
    can't use the ACME account as the provider may use one or ephemeral
    ACME accounts.
*   External Account Binding keys can't be used as permissions are
    broader (not fine grained enough) and may require cloud provider UI
    changes (undesirable).
*   Multiple CA (billing) accounts for the same domain
*   from the chat: OAUTH?

Mike: There are options, some are not great, but they would like to
understand what would help other CAs.

Mike: it might be possible to add features/information to CAA  
 Deb and RB: Is relying on DNS wise?

Mike: Need input from CA's, and need more design iterations or a design
group of CA's and CSP's

RB: You may have gone astray focusing on DNS as the configuration
mechanism, and the assumption is that the CSP will have to do some
better UI.

Mike: We didn't want to beg all the CSPs. RB suggested that they were
already having to go to CSPs anyway?

RB: What information does the ACME client need on behalf of the CSP?

Mike: Chairs should be split off a design team?

Yoav: This is not WG adopted

Q: I agree with RB, asking a CSP to either update an ACME client or UI
are both in the same situation of being annoying. There should be some
active part on behalf of the CSPs.

Tim Hollebeek: The ACME client is fairly small. Perhaps things are too
complicated, could we not put account/profile into CAA? The ACME client
is under the control of the customer, and might be more acceptable. But
if you are forming an informal design team, sign us up.

Greg Choules: It's possible for CAA to have multiple. Domain Control
Validation is another option. Mike: this is more than just DV, we need
to figure out what information needs to be conveyed - CAA, ACME account
URI.

Mike: What do you want to do with this work?

Deb: I think you need to do some more work before we call for adoption.
Probably easier to deal with the acme client vs CSP UIs.

RB: This is not purely a technical problem. It is still a potential
problem that CSPs aren't going to be willing to go to DNS for CA
suggestions.

Mike: How far do we have to get to for adoption?

Yoav: working group documents change quite a bit through the process.

Deb: Some path forward that the authors are happy to implement. We don't
want a WG item we later abandon.

### AOB   {#aob}

Bob Beck: TLS have a draft regarding multiple cert chains and related to
ACME if people would be interested in looking. There maybe be more
changes required for this work. If anyone is interested in multiple cert
chains, please reach out.