> On Aug 2, 2017, at 1:27 AM, Gervase Markham <[email protected]> wrote: > > On 02/08/17 02:13, Peter Bowen via Public wrote: >> We have a customer who has a system that does not have a persistent >> clock when it is first unboxed. > > Is there any way it can lose that clock afterwards, e.g. if it is > completely reset? In other words, is it _only_ at time of first unboxing > that it has this problem, or could it potentially have the same problem > at other times? > > One solution might be for the box to be modified to not check dates, but > to check revocation, and issue from a CA which has guaranteed to > maintain revocation information for such certs indefinitely. > >> You might have already spotted the problem — at some point the server >> certificate is going to get renewed and will probably have a notBefore >> date that is after 2017-01-01. This will cause the firmware and >> configuration update to fail. > > Could it get the time via non-SSL means first? Isn't this what ROUGHTIME > is for? :-)
Gerv, I think you have hit on the points that we have already raised with the customer. I missed a few key points in my original email, which I think helps clarify. 1) These are sold worldwide by local retailers who buy from distributors who get them from the manufacturer (our customer). There are tens of thousands of units already in distributor and retailer warehouses, so they need a solution that allows all of these to update. 2) They have a new firmware build that avoids these problems altogether. However updating the old firmware uses TLS to fetch the update — hence the problem. New units coming off the manufacturing line don’t have this issue, as they have the new firmware. 3) The units are contacting a shared server. This is making the problem even more difficult, as the firmware fetch is request is made to a URL is for a shared hostname under amazonaws.com. This problem was only discovered when the server updated its certificate; we rolled back, but the existing certificates do expire soonish, so we need a solution. Hence AWS is the customer requesting permission for the CA to back date; the CA is not Amazon Trust Services, rather it is another Forum member. >> 1) Does anyone think setting a notBefore well before the issuance dates >> a problem, as long as the certificate includes a timestamp that >> represents the issuance date and the CA previously issued a certificate >> for the same domain name(s) to the same applicant that has a validity >> period that spans from the notBefore to issuance date? > > Backdating notBefore is discouraged (and for some CAs, banned). The > trouble with saying "but there's a CT timestamp which gives the real > date" is that then all clients start to take a dependency on > understanding CT information. I realize that it is discouraged, hence my posting. The CA is not banned from backdating as far as I know. >> 2) What is the latest acceptable notAfter date? 39 months (or 825 days >> in the future) from the notBefore date or from the issuance date? > > It's measured from the notBefore date. Thanks, Peter _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
