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

From: Yaron Sheffer <[email-masked]>
Date: Mon, 2 Jul 2018 14:06:19 +0300

Dear SecDispatch chairs,

We would like to submit draft-sheffer-acme-star-request-02 
(https://datatracker.ietf.org/doc/draft-sheffer-acme-star-request/) for 
discussion in Montreal. If added, it will be presented by Diego R. Lopez.

The draft is part of the STAR (short-term, automatically renewed 
certificates) work that grew out of the LURK BoF. Initially we had one 
draft. We split it into two:

1. An ACME extension draft that's now a WG document at ACME.

2. The current draft that describes a very simple API where the delegate 
requests the owner of the identity (normally, the owner of a domain 
name) to initiate the ACME certificate issuance process for a STAR 
certificate. This STAR certificate is later pulled periodically by the 
delegate.

As the next step, we can see this draft moving into ACME as well because 
of its relation to the other draft, even though it is not strictly an 
ACME extension. We do not see a viable working group for this draft 
alone, so our alternative proposal would be for AD-sponsored publication.

We note that both drafts have an active community around them as well as 
existing implementations.

Thanks,
     Yaron

---

From: Melinda Shore <[email-masked]>
Date: Thu, 5 Jul 2018 17:02:13 -0800

> alone, so our alternative proposal would be for AD-sponsored publication.

It seems to me that if published, this ought to be an IETF
consensus document.  I can see it ending up in either ACME
or LAMPS (preferably the former, now that the core ACME
protocol spec is basically done).

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F

---

From: Michael Richardson <[email-masked]>
Date: Sat, 07 Jul 2018 13:17:39 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 8 Jul 2018 00:20:20 +0300

Hi Michael,

Thanks for your review! Please see responses inline.

Thanks,
	Yaron

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

> cancel the renewal (a commission), and to do so it has to remember the Order

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.

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

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

> 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

Looking forward to meet and discuss in Montreal.