On Wed, Sep 11, 2019 at 12:09 PM Thomas Fossati <[email protected]> wrote:
> 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? > I'm not Richard, but with respect to publicly trusted certificates, issuing a certificate with a notBefore set prior to that certificate was issued is seen as, minimally, problematic, and at times has resulted in a complete removal of trust in that CA, particularly if/when such actions have lead to bypasses of technical controls enforced based upon the notBefore. The clock skew problem is, admittedly, real, and the general solution as practiced by industry-recognized CAs and Subscribers is to generate the request and issue the certificate in advance of its actual deployment, rather than to issue the certificate and then back-date it to facilitate deployment. To that end, the language about "amount of pre-dating added to each STAR certificate" (in 3.1.1) is, as Richard highlighted, about the overlap that exists. The language in Section 4.1, however, should be clarified to be clear that the CA/ACME server MUST NOT set the notBefore to before the request, but instead about ensuring that the STAR client requests the 'next certificate' in advance of the actual deployment. This may substantially alter the protocol, it's unclear, but it's extremely unwise, if not outright fatal to interoperability, to issue a certificate with a notBefore set prior to the request, and it seems that is what is meant by Section 4.1.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
