Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4723
After reviewing this document, I'd like to reconsider the proposed status of this document. Based on Section 5, it doesn't appear that there are any production implementations of this document. Are there any existing or planned production implementations from live CAs or clients? If not, this seems like a better fit for Experimental. IMPORTANT S 3.4. > present and set to true, the client requests the server to allow > unauthenticated GET to the star-certificate associated with this > Order. > > If the server accepts the request, it MUST reflect the key in the > Order. it seems like some security considerations are needed here to prevent enumeration. S 4.1. > of clock-related breakage reports which account for clients that are > more than 24 hours behind - happen to be within 6-7 days. > > In order to avoid these spurious warnings about a not (yet) valid > server certificate, it is RECOMMENDED that site owners pre-date their > Web facing certificates by 5 to 7 days. The exact number depends on I don't understand how this works. The client is able to provide the notbefore date, which gives a pre-date for the first certificate, but S 2.2 just says that the re-issue is "before the previous one expires". So suppose it is currently 2018-07-15" and I ask for a certificate with "recurrent-start-date=2018-07-10" and "recurrent- certificate-validity=5", I thus get back a cert with validity "2018-07-10 -- 2018-07-20", i.e., pre-dated by 5 days. The next certificate needs to be issued on or before "2018-07-20", but the text doesn't say when it's notbefore has to be, so it could have validity "2018-07-19 -- 2018-07-25". It seems like this document needs to specify an explicit way to pre-date, but it doesn't. COMMENTS S 1. > new short-term certificate is needed - e.g., every 2-3 days. If done > this way, the process would involve frequent interactions between the > registration function of the ACME Certification Authority (CA) and > the identity provider infrastructure (e.g.: DNS, web servers), > therefore making the issuance of short-term certificates exceedingly > dependent on the reliability of both. I don't see why this is the case. Once you have authorized once, the CA can just return that no authorizations are required. S 3.1.1. > o recurrent-certificate-validity (required, integer): the maximum > validity period of each STAR certificate, an integer that denotes > a number of seconds. This is a nominal value which does not > include any extra validity time which is due to pre-dating. The > client can use this value as a hint to configure its polling > timer. This text is confusing. The client produces the order, so how is it using it as a hint. S 3.1.2. > > Issuing a cancellation for an order that is not in "valid" state has > undefined semantics. A client MUST NOT send such a request, and a > server MUST return an error response with status code 400 (Bad > Request) and type > "urn:ietf:params:acme:error:recurrentCancellationInvalid". This doesn't sound like undefined semantics. It's just illegal.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
