Re: [Acme] draft-ietf-acme-star

[Thomas Fossati <[e-mail]>]

Hi Rich, Richard,

(Merging both your emails into one reply.)

On 09/09/2019, 23:57, "Salz, Rich" <[e-mail]> wrote:
> I don't care about the STAR acronym not bring known by those who don't
> know :) but I think Richard's comments – most of which are, really,
> wordsmithing nits of message-field names – deserve more consideration.
> After all, the STAR documents didn't get much attention from the ACME
> members.

Sure, high quality feedback is always welcome.  Our worry was that
making such changes after the doc has been through IETF LC and a couple
of AD reviews means that very few people will get to double-check that
the protocol is still correct/consistent.  But, let's be bold as it's
probably worth taking the risk :-)

Now addressing Richard's comments:

> On 28/08/2019 at 15:52, Richard Barnes <[e-mail]> wrote:
>
> - The use of the "STAR" acronym is not helpful.  This is not an
> acronym that will be familiar to a reader, and less so an implementer
> who has not fully read and absorbed this spec.  Instead, you should
> say what you mean, e.g., for the "meta" fields:
>
> star-enabled -> auto-renewal-allowed
> star-min-cert-validity -> min-cert-validity
> star-max-renewal -> max-auto-renewals

OK, will do.

> - Likewise, "recurrent" is not a common word in English.  If you want
> to use a single word, "recurring" is more common, but referring to
> "auto-renewal" would be even better.

OK, will do.

> - It would be even cleaner to group all these "recurrent" fields into
> a sub-object, so that you wouldn't have to worry about them being
> present if "recurrent" wasn't set.  In other words, just signal the
> "recurrent" boolean by the presence of the object, and specify the
> parameters in the object.
>
> { "auto-renew": { "start": ..., "end": ..., "lifetime": ..., } }

OK, will do.

> - The idea of "predating" is toxic.  Pre-dating a certificate means
> making the notBefore date earlier than when you actually issued it,
> which is a huge problem for a real CA to do.  That's not what you mean
> here..  You just want there to be some overlap between certificates.
> Say that instead ("recurrent-certificate-predate" -> "overlap") and
> adjust Section 3.5 accordingly.

There are two aspects to consider:

1 The recommendation we added in section 4.1 to address the clock skew
  impact on HTTPS (cfr. the cited Google paper), which was discussed at
  length during the STAR side-meeting in Singapore.  This bit is
  controlled by the ACME client (via recurrent-certificate-predate) who
  might optionally ask the ACME CA to pre-date all the certs by a
  certain amount if it knows it's client population is clock-skewed
  (this is probably the "toxic" bit you are referring to?)

2 The pre-dating that the ACME server MUST do on cert rotation to
  prevent the client to fetch a not-yet-valid credential (i.e., the
  overlap you mention).

IIUC, you are suggesting to drop the former, i.e., removing the ability
for a client to request recurrent-certificate-predate, correct?  Or are
you suggesting to only remove the RECOMMENDED from section 4.1?

> - The Not-Before and Not-After headers should be removed.  On the one
> hand, it's not clear to me that it's any easier to parse these headers
> than it is to parse the certificate.  On the other hand, there are
> existing HTTP headers that express almost exactly the same semantics,
> e.g., Expires.

Expires is not completely unrelated (in fact, your observation had me
thinking that we should probably discuss the operational impact of HTTP
caches on STAR cert resources) but I'm not sure it really has compatible
semantics -- it's a signal for the caching / validation layer of the
HTTP protocol rather than an intrinsic property of the resource.  OTOH,
looking at already registered HTTP headers we couldn't find anything
suitable.  So I think the only choices we are left with are to either
remove the headers altogether or keep them as they currently are.

> - It's not clear that there's any reason to negotiate certificate-GET
> on a per-order basis.  Just have the CA allow it or not unilaterally
> and delete the "recurrent-certificate-get" field.

The client decides whether it wants to use the GET interface (e.g., if
STAR is part of a delegation workflow) or not (i.e., STAR is used for
plain auto renewal.)  It's not up to the server to decide which workflow
the client is interested in.

> - The "star-certificate" attribute is unnecessary.  Instead, you
> should just say that when auto-renewal is enabled, the "certificate"
> attribute points to the current certificate, and use "previous" link
> relations to expose earlier certs.

The idea behind the "star-certificate" attribute was to mark the fact
that the underlying resource is of a different kind.  More specifically,
it's not immutable as opposed to that in a non-STAR Order.  ACME Section
7.4.2 has:

   "A certificate resource represents a single, immutable certificate."

(BTW, I guess a "previous" link can - and should - be used
irrespectively of how the Order attribute is called.)

Cheers, thanks both for the input!



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.