Minutes IETF98: acme
minutes-98-acme-00

Meeting Minutes Automated Certificate Management Environment (acme) WG
Title Minutes IETF98: acme
State Active
Other versions plain text
Last updated 2017-04-18

Meeting Minutes
minutes-98-acme

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