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

[Yaron Sheffer <[e-mail]>]

Hi Michael,

Thanks for your review! Please see responses inline.

Thanks,
	Yaron

On 07/07/18 20:17, Michael Richardson wrote:
> 
> 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.
> 

This document has a companion (and much more advanced/detailed) 
document, draft-ietf-acme-star. This is where the ACME extension is 
described, as a "delta" from the baseline ACME protocol.

Even though draft-sheffer-acme-star-request is NOT strictly an ACME 
extension, it is arguably close enough to belong in the ACME working group.

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

I understand your point. However the current design assumes high 
availability (at least to some degree) of the CA, which is a reasonable 
assumption from an ACME server. The IdO is not necessarily highly 
available, and relying on it for certificate renewals could result in 
failed operations.

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

Yes, it's a bog standard REST API. I think the sentence at the top of 
3.1 should be rewritten to clarify who "the client" is. It is the same 
as "STAR Client" as you already figured out.

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

No, this is not the architecture we're targeting (and I'd need to 
re-read the draft to understand which part is unclear). The STAR Proxy 
is the IdO, the component that requests *once* the STAR certificate 
sequence from the CA (a.k.a. STAR server). The CDN is associated with 
the CA (not the Proxy!), to ensure that new certificates are always 
available to download.

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

Agree, we should have mentioned it in draft-ietf-acme-star.

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

Again, IMO, such implications belong in draft-ietf-acme-star.

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

Looking forward to meet and discuss in Montreal.

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