Subject: [Acme] Draft minutes

From: Ted Hardie <[email-masked]>
Date: Fri, 31 Mar 2017 09:52:31 -0500

Thanks to Thomas Fossati, here are draft minutes.  Please review and
comment on the list.

thanks,

Ted and Rich

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