Hi Rich, Richard, (Merging both your emails into one reply.)
On 09/09/2019, 23:57, "Salz, Rich" <[email protected]> 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 <[email protected]> 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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
