Subject: [Acme] Draft Minutes (and Memes)

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Nov 2016 10:17:53 +0900

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

---

From: [email-masked]
Date: Tue, 22 Nov 2016 15:22:35 +0000

On the minutes below for LURK BOF, did you mean “The DNO does not have to do any of the issuance checks.”?

Thanks
Sanjay

From: Acme [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Wednesday, November 16, 2016 8:18 PM
To: [email-masked]
Subject: [E] [Acme] Draft Minutes (and Memes)

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

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,

  Account Management

  We may need security considerations recommending counter signing, to avoid UKS-like risks.

  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.

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.

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

   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.

    application→ order

    registration→ account

Where do we go?

This iteration follows on from the LURK BoF, but there have been some changes to the proposal.

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.

Security Considerations; basically say that the CDN does not own the relevant DNS zone; also requires CAA record be respected:

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.

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.

CAA

STIR