Re: [Secdispatch] IETF 102: draft-sheffer-acme-star-request for consideration

[Michael Richardson <[e-mail]>]

I have read draft-sheffer-acme-star-request.
I am probably more ignorant of ACME that I should be, but the part where:

   The CA automatically re-issues the certificate (using the same CSR)
   before it expires and publishes it to the URL that the NDC has come
   to know at the end of the bootstrap phase.

seems to be new functionality required from the ACME CA, and therefore this
really is an extension to ACME.  The document would seem to belong in ACME.

When I started reading, I thought that the IdO would be in charge of asking
the CA to renew.  In that way, the IdO was completely (actively) in control
of when/if the certificate would renew, and that a failure of the IdO (an
omission) to do so would stop the process.  Instead, I read that the IdO must
cancel the renewal (a commission), and to do so it has to remember the Order
ID.

section 3.1.1, "the client" was ambiguous and hard for me to sort out.
HTTPS is assumed between the STAR Client and STAR Proxy, and the ability for
the STAR Client to connect to the STAR Proxy.

I was thinking about how I'd want to run this, and the ability to just
put some files in a directory and rely upon an rsync (over ssh) has some
appeal to me, assuming that rsync was used to populate the contents of
the CDN running on the STAR Proxy.

I am particularly pleased with "4.1.  Multiple Parallel Delegates", as it
not only makes it easy to do, but it also makes it clear the CA deals with
the IdO only.  The CA is going to have to be willing to issue parallel
certificates to the name cdn.example.com.
This is yet another implicit requirement upon an ACME CA.

It would be nice to have a section "Implications/Requirements for ACME CAs"

(I am also thinking about how this may apply to ANIMA ANI certificate renewal
needs)

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-