# ACME Working Group

Chicago - Thu, March 30 2017

## Slides
- https://www.ietf.org/proceedings/98/slides/slides-98-acme-acme-chair-slides-ietf-98-01.pdf

## Meetecho recording

- http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_ACME&chapter=chapter_1

## Review of Open PRs

- [#272 Use correct challenge names in the IANA list](https://github.com/ietf-wg-acme/acme/pull/272) (slide 12) is an important one about which challenge names to use.
 - **Decision**: use existing explicit versioning (i.e., http-01, tls-sni-02 and dns-01) to avoid unnecessary churn.

## Review of Open Issues

- [#242 Enable cleanup of "leaked" pending authorizations](https://github.com/ietf-wg-acme/acme/issues/242) (slide 14) buggy client(s) creating authorizations that were not finalised.
  - **Decision** is to close this issue with no action.  The rationale being there's no need to add protocol machinery to deal with what looks like a (mis-)implementation issue.  Besides, `orders` already have an `expires` attribute that could be used exactly for this purpose.

- [#237 Recommended polling Order vs. Authz](https://github.com/ietf-wg-acme/acme/pull/232) (slide 15)
  - Proposal to change the poll for status to `GET order` instead of `GET authz`.
  - Jacob: based on Hugo's feedback on retriable challenges, this should not be changed.

- [#236 ACME resource relations](https://github.com/ietf-wg-acme/acme/issues/236) (slide 16)
  - Chairs ask if there exist implementations that rely on this link relation.  No one has.
  - **Decision** is to get rid of `up` (i.e., third's third bullet in slide 16)

## Mailing list issues

- **Require servers to accept at least one automated revocation method** (slide 18)
  - Discussion: server implementers confirm this matches CA revocation practices.
  - **Decision** is to change the 2 SHOULDs in slide 18 into 2 MUSTs

- **Advertise server contact support** (slide 19)
  - Discussion: Ted highlights the risk of failure in negotiation (empty intersection) a single MTI scheme is necessary and sufficient for interop
  - **Decision** is to REQUIRE `mailto` as URL scheme so that it's always possible to fall back to it

- **Retrying failed authorisations** (slide 20)
  - (in the slide, there's a nice write-up of the problem)
  - Discussion:
    - Jacob H / RLB propose to re-POST the authz on failure while keeping a list of failed attempts with an explicit error attached by the CA - and a way to correlate those errors with their corresponding attempt.
    - Chairs: this approach is big enough to require a further WGLC cycle
  - **Decision** is for editors to apply the proposed change, then we will run another WGLC

- **Don't call it PEM certificate chain** (slide 21)
 - Proposal by Sean on the [mailing list](https://www.ietf.org/mail-archive/web/acme/current/msg01857.html)
   - **Decision(s)**:
    - Editors to go and fix the terminology (change MIME type + some stuff related to the charset, etc.) as suggested in the first of Sean's messages according to the referenced RFC;
    - Add text to the security consideration sections about the private key insertion attack raised by Sean.
  - (Any resolution will be revised on the list.)

- EKR from the floor: **Generating nonces probabilistically [#289](https://github.com/ietf-wg-acme/acme/pull/289)** (not on any slide)
 - **Decision**: either nonces are constructed to be unique or, if generated randomly, it should sufficient to require enough entropy (120 bits or more)

(Rich takes over from RLB)

## Other issues raised on the list

- **Require CAA as part of validation?**
 - Discussion:
    - RLB: not at the protocol level.  This is for the CA/B forum to prescribe, which, as Hugo pointed out, has in fact already specified this requirement in a recently published (March 2017) document.
 - **Decision**: add this to the CA consideration in document

- **Require DNSSEC for name validation?**
 - Discussion:
    - Viktor: CA burden to do validation is minimal (just implement DNSSEC client / validator resolver and MUST do validation)
    - Ted: instead of framing this as a requirement, explain the threat and put into the security considerations with associated mitigations?
    - RB believes we already have that kind of text in the security consideration, which proposes doing the verification from multiple vantage points as a mitigation.
  - Discussion non-conclusive.  Not enough consensus to even try the hum on this topic.  Put this back to the mailing list.

- **Changes are significant enough to require an interop round?**
 - Discussion
    - RB: no recent enough draft has been implemented
    - Let's Encrypt implemented -03 -- to catch up on -latest they think 2/3 months needed (optimistically); Digicert in the same ballpark.

  - Plan is to run WGLC and finish it before Prague -- that will inform the implementations.