Thanks Richard for raising this and Ryan for taking the time to explain.
On 11/09/2019, 17:52, "Ryan Sleevi" wrote:
> 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.
OK, this adds a new constraint ("no back-dating") that we hadn't
factored in the initial design, and I agree this is a blocker.
I think the question is whether and how can we accommodate this
constraint with the ability to work around clock-skew -- IOW, keeping
recurrent-certificate-predate (*) while not messing up CA's cert
issuance best practices.
It seems to me that this might still be possible modulo
recurrent-certificate-adjust (rcp) being upper bounded by
recurrent-cert-validity (rcv), i.e., slightly changing the calculations
in 3.5 like this:
notBefore = nrd[i] - predating
notAfter = min(nrd[i] + rcv, red)
predating = max(predating_S, predating_C)
predating_S = f * rcv (.5 <= f < 1)
predating_C = max(rcp, rcv)
This should still leave a fair amount of knobs to ACME clients (rcp and
rcv) to play with their clock-skewed customers.
Would that work for you?
The (brutal) alternative is to get rid of recurrent-certificate-predate,
but removing the ability to address (at least partially) the clock skew
problem looks like a missed opportunity.
Anyway, whatever road we take, it looks like there's a bit of editorial
work to do in sections 3.1.1, 3.3, 3.5 and 4.1.
Cheers, t
(*) We'll rename it to "recurrent-certificate-adjust".
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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
