&
Chairs: Rich Salz, Ted Hardie
Scribe: Martin Thomson
Meetecho recording: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_ACME&chapter=chapter_1
After Administrivia, the Richard Barnes led the group in a review of the closed and open issues of version 4 of the draft ( https://datatracker.ietf.org/doc/draft-ietf-acme-acme/). His slides are here: https://www.ietf.org/proceedings/97/slides/slides-97-acme-acme-protocol-spec-01.pdf
The discussion was captured by Martin in MEME form:
&
Richard noted that most of the issues were closed late in the cycle:
There was no discussion of the typos, or clarifications, in the developer
friendliness-related updates, content negotiation was added:
and PEM with chain made the default:
The ToS of service flow has also been simplified:
even in the case where re-agreement is
not required: 
The group agreed to replace the current Agreement with Action Required
to better align the two.
The group then reviewed the simplifications related to Key Rollover:
The group then reviewed open issues.
Account Management
#170 & #172 address this.
We may need security considerations recommending counter signing, to avoid UKS-like risks.
Clint Wilson from digicert confirmed that this was useable for their
needs. They need to include a field that allows them specify the ACME
key. Martin noted that you need to prove that you hold the private key for
that ACME key--possibly a jws field. Martin and Richard will work
together to get a solution proposed, possibly based on Mozilla’s push.
From the floor, Rich Salz noted that
it’s an API key, so the security considerations are basically those of any
other API key; we likely don’t need to say more than that.
Additional CA Account Data
How to provide additional data
Working group polled on what to do?
Martin: this is just another form of the x- thing; this is bucket of things that might be useful. If useful for one, likely generally useful. Accepted wisdom is that we define these in the free form text fields that we already have. We don’t need a special bucket. Required extensions are a special problem that CAs create for themselves--we do have a mechanism for protecting the semantics (the version). [Toss these in the top level, in other words, don’t make these extensions]. Clint agreed.
We can avoid collision by creating a registry with very simple addition rules.
&
Object Model
#195 Combine “requirements” and “authorizations”.
This proposal removes requirements and oob, and use only authorization.
Martin is okay with the new structure (Before & After slide), but the non-exploded version might have only a status field and series of URLs. EKR asks if this applies to the case where a CSR has already been sent? Yes, that’s right.
Bike Shed Terminology changes
application→ order
registration→ account
Where do we go?
WGLC to get a stable version as an interop target
Yaron Sheffer, short term certs (LURK BoF)
Describes alternative approaches: online oracle, short term cert delegation.
This iteration follows on from the LURK BoF, but there have been some changes to the proposal.
DNO and CDN create a mutually authenticated channel and agree on a CSR for the short term validity certs. DNO registers with an ACME server.
Bootstrap phase: CDN creats the CSR, the DNO validates it, then the DNO sends it to the ACME server, requesting a short-term certificate. The DNO has to do any of the issuance checks. Gets back the certificate URL, then sends it on to the CDN. The ACME server periodically renews the certificate, and the CDN retrieves it.
No explicit X.509-style revocation, but instead tells the ACME to stop renewing.
http://www.simplehrguide.com/assets/images/recruitment-flowchart.jpg
Security Considerations; basically say that the CDN does not own the relevant DNS zone; also requires CAA record be respected:
Also caaa-01 to restrict ACME checks to DNS authorization only
Why not use the standard split client model?
Nick Sullivan (CloudFlare)
DNS is operated by the CDN; it’s a common use case for them to be the same, so limiting to DNS authorization will not provide the the security considered.
CT could use separate short-term logs rather than mingle them with long-lived certificates. DKG points out that this pushes the problem into a different operational tradeoff.
CAA
5 new victims agreed to read the doc.
STIR
Recharter discussion on the list between the new year and March
