A few brief comments on this draft.
On 16 June 2017 at 22:19, <internet-dra...@ietf.org> 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.
draft-iab-web-pki-problems has been abandoned. It's not a great idea
to cite it.
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?)
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".
Please include a definition for the new attributes, rather than just
providing an example and commenting the JSON.
In Section 3.1.2, you REALLY, REALLY need to authenticate this
request. 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.)
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.
Can the server specify a shorter value for "recurrent-total-lifetime"?
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.
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.
Section 5.1 should be promoted to Section 5
Don't mention time-sensitive policy actions by the CA/B Forum.
Can't you simply ensure that the CDN can't modify the CAA record?
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
