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

[Ryan Sleevi <[e-mail]>]

On Wed, Sep 11, 2019 at 12:09 PM Thomas Fossati <[e-mail]>
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.