Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

["Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[e-mail]>]

Hi Martin,

Thanks for your review.

On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson" <[e-mail] on behalf of [e-mail]> wrote:
> 
> A few brief comments on this draft.
> 
> On 16 June 2017 at 22:19,  <[e-mail]> wrote:
>     This memo proposes an ACME extension to enable the issuance of short-
>     term and automatically renewed certificates.  This allows a domain
>     name owner to delegate the use of certificates to another party,
>     while retaining the capability to cancel this delegation at any time
>     with no need to rely on certificate revocation mechanisms.
> 
> I found the introduction overly specific.  The generic use case is to
> simplify the deployment of certificates to unprivileged nodes.  The
> unprivileged nodes then only need to be configured with a URL for
> their certificates.
> 
> That requires a couple of paragraphs of exposition at most.  This
> extends to Section 2, which describes a system architecture that
> implies the existence of protocol elements that are simply not defined
> in this document.
> 
> Sections 1 and 2 could much more clearly describe what *this* document
> provides.  It provides an extension to ACME that allows for the
> creation of a certificate that automatically renews.
> 
> The focus on the CDN case affects the entire document.  The point is
> that the authorized entity is delegating the ability to use a
> certificate for its name to an unprivileged node.  Don't use "CDN",
> "content owner" or any of these highly specific terms.  Use generic
> terms; make new terms if necessary.  FWIW, while NDC is a cute
> reversal, "consumer" really isn't accurate.

Agree, there is still a bit of LURK baggage attached (especially here,
but also in a few other points).

We will do an editorial pass to streamline the document before -01
and take in the suggestions above.

> draft-iab-web-pki-problems has been abandoned.  It's not a great idea
> to cite it.

OK, will drop the reference -- too bad, though.

> In Section 3.1.1, I think that the resolution of these fields, being
> in days, is not conducive to reducing granularity.  (Or will you
> permit 5.7e-3 as a value?)

Seconds granularity then?  32 bit should be enough for >100 years while
allowing baryon-like lifetimes on the other end of the scale :-)

(Personally, I'd avoid any string representation, but that's my taste.)

> Section 3.1.1 needs to clearly articulate how
> "recurrent-certificate-validity" (could this be any more verbose and
> hard to type?) relates to "expires".

OK

> Please include a definition for the new attributes, rather than just
> providing an example and commenting the JSON.

OK

> In Section 3.1.2, you REALLY, REALLY need to authenticate this
> request.  

Sure.  Every non-RO operation needs to be authenticated.  We forgot to
be explicit about that; thanks for spotting it.

> My suggestion is to change this to a POST request with {
> "recurrent": false }.  (I'd have suggested PUT or PATCH, but ACME's
> reliance on JWS perverts that in ways that is incompatible with those
> methods.)

I have no strong opinion about the syntax of the order termination.
DELETE just seemed the most natural to me (certainly more
straightforward than POSTing '{ "recurrent": false }'), but I'm probably
missing something?

> In Section 3.2, the discussion about a Proxy is misleading.  The only
> relevant actor in this is an ACME client.  This section could be
> reduced to:
> 
> An ACME client discovers whether a server supports this extension by
> examining a newly created order.  The "recurrent" member will exist if
> the server supports automatic recurring certificate issuance; the
> "recurrent" member will be true if the server accepts the request.

Yes, agreed.  This is another example of the LURK clean-out that we need
to finish off.

> Can the server specify a shorter value for "recurrent-total-lifetime"?

Yes.  And if the client is not happy with the chosen value I guess it
will just abandon the order and let it expire (as suggested in 3.2).

> I don't understand Section 3.3 at all.  I'd recommend removing this
> section.  The DNO will decide what authorizations it requests amply
> without this level of proscription in standards.

Yaron: thoughts on this?

> In Section 3.4, the use of the Expires header field is a common
> mistake.  This is an HTTP caching directive.  It should probably be
> shorter than the expiration time of the certificate (half in fact),
> but not for the reasons that you might think.  The purpose of a
> recommendation on Expires is to ensure that the certificate is not
> cached beyond the point where a newer certificate will be issued.  You
> should remove this text.

OK

> Section 5.1 should be promoted to Section 5

OK

> Don't mention time-sensitive policy actions by the CA/B Forum.

Makes sense.

> Can't you simply ensure that the CDN can't modify the CAA record?

This is the minimum we could say.  At this point, I think we are trying
to explore a bit what other mitigations can be put in place.

> One further thought. ACME uses an absolute time for expiration. This
> uses a relative time. I think that I prefer the former. I realize that
> consistency might be impossible in this case, since the recurrent
> duration is necessarily relative, but I though it worth raising.

This is a good observation.  Maybe instead of mirroring
"recurrent-total-lifetime", server could come back with the absolute
time when the renewal ends on its side (e.g., "recurrent-expiration").

Cheers, thanks