&
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.