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

From: [email-masked]
Date: Fri, 16 Jun 2017 05:19:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment of the IETF.

        Title           : Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites
        Authors         : Yaron Sheffer
                          Diego Lopez
                          Oscar Gonzalez de Dios
                          Antonio Agustin Pastor Perales
                          Thomas Fossati
	Filename        : draft-ietf-acme-star-00.txt
	Pages           : 13
	Date            : 2017-06-16

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

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-star/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-star-00
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Jun 2017 10:08:15 +1000

A few brief comments on this draft.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jun 2017 08:34:23 +1000

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.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Thu, 22 Jun 2017 16:09:26 +0000

Hi Martin,

Thanks for your review.

> 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

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

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

> hard to type?) relates to "expires".

OK

> providing an example and commenting the JSON.

OK

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

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?

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

> without this level of proscription in standards.

Yaron: thoughts on this?

> cached beyond the point where a newer certificate will be issued.  You

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