Here are the draft minutes from this week's meeting. Please review and provide updates and corrections to the list.
Thanks Ted ACME IETF 97 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: http://memedad.com/memes/1030645.jpg & http://memedad.com/memes/1030646.jpg Richard noted that most of the issues were closed late in the cycle: http://memedad.com/memes/1030647.jpg There was no discussion of the typos, or clarifications, in the developer friendliness-related updates, content negotiation was added: http://memedad.com/memes/1030648.jpg and PEM with chain made the default: http://memedad.com/meme/1030649 The ToS of service flow has also been simplified: http://memedad.com/memes/1030650.jpg even in the case where re-agreement is not required: http://memedad.com/memes/1030652.jpg The group agreed to replace the current Agreement with Action Required http://memedad.com/memes/1030654.jpg to better align the two. The group then reviewed the simplifications related to Key Rollover: http://memedad.com/memes/1030656.jpg, http://memedad.com/memes/1030658.jpg, http://memedad.com/memes/1030659.jpg The group then reviewed open issues. Account Management #170 & #172 address this. http://memedad.com/memes/1030662.jpg We may need security considerations recommending counter signing, to avoid UKS-like risks. http://memedad.com/memes/1030663.jpg <http://memedad.com/memes/1030663.jpg> 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. http://memedad.com/memes/1030665.jpg. 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 http://memedad.com/memes/1030666.jpg 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. http://memedad.com/memes/1030668.jpg We can avoid collision by creating a registry with very simple addition rules. http://memedad.com/memes/1030670.jpg & http://memedad.com/memes/1030672.jpg Object Model #195 Combine “requirements” and “authorizations”. http://memedad.com/memes/1030673.jpg This proposal removes requirements and oob, and use only authorization. http://memedad.com/memes/1030674.jpg Martin is okay with the new structure (Before & After slide), but the non-exploded version might have only a status field and series of URLs. EKR asks if this applies to the case where a CSR has already been sent? Yes, that’s right. http://memedad.com/memes/1030678.jpg Bike Shed Terminology changes application→ order registration→ account http://memedad.com/memes/1030676.jpg Where do we go? WGLC to get a stable version as an interop target http://memedad.com/memes/1030681.jpg http://memedad.com/memes/1030686.jpg Yaron Sheffer, short term certs (LURK BoF) Describes alternative approaches: online oracle, short term cert delegation. http://memedad.com/meme/1030689 This iteration follows on from the LURK BoF, but there have been some changes to the proposal. http://memedad.com/meme/1030692 DNO and CDN create a mutually authenticated channel and agree on a CSR for the short term validity certs. DNO registers with an ACME server. Bootstrap phase: CDN creats the CSR, the DNO validates it, then the DNO sends it to the ACME server, requesting a short-term certificate. The DNO has to do any of the issuance checks. Gets back the certificate URL, then sends it on to the CDN. The ACME server periodically renews the certificate, and the CDN retrieves it. No explicit X.509-style revocation, but instead tells the ACME to stop renewing. http://www.simplehrguide.com/assets/images/recruitment-flowchart.jpg Security Considerations; basically say that the CDN does not own the relevant DNS zone; also requires CAA record be respected: http://memedad.com/memes/1030698.jpg Also caaa-01 to restrict ACME checks to DNS authorization only Why not use the standard split client model? http://memedad.com/meme/1030699 Nick Sullivan (CloudFlare) DNS is operated by the CDN; it’s a common use case for them to be the same, so limiting to DNS authorization will not provide the the security considered. http://memedad.com/memes/1030702.jpg CT could use separate short-term logs rather than mingle them with long-lived certificates. DKG points out that this pushes the problem into a different operational tradeoff. http://memedad.com/memes/1030707.jpg CAA 5 new victims agreed to read the doc. STIR http://memedad.com/meme/1030709 http://memedad.com/meme/1030710 http://memedad.com/memes/1030712.jpg Recharter discussion on the list between the new year and March http://memedad.com/memes/1030713.jpg
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
