Minutes IETF98: acme
Automated Certificate Management Environment
||Minutes IETF98: acme
# ACME Working Group
Chicago - Thu, March 30 2017
## Meetecho recording
## 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
- 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)
- 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
- **Don't call it PEM certificate chain** (slide 21)
- Proposal by Sean on the [mailing
- 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?**
- 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?**
- 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?**
- 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