How to Support TLS Before the Date and Time Is Set

This page discusses how entry-level printers can obtain a reasonably correct date and time prior to doing a TLS session negotiation.

The Problem

Transport-Level Security (TLS) requires the current date and time in order to, among other things, generate and validate the X.509 certificate of the server and (if provided) validate the X.509 certificate of the client. Since some printers lack a battery-backed Real Time Clock (RTC) but still need to support TLS (which is required by many IPP-based logo licensing programs), these printers need a way to get the current date and time on power up.

IPP Workgroup Consensus

The current date and time is needed for TLS certificate generation, the "date-time-at-xxx" Job Status attributes, and the "printer-current-time" and "printer-xxx-change-date-time" Printer Status attributes.

Best Practice for this class of printer is:

1. Try to obtain the current date and time from an NTP server, either as provided in DHCP option 42 or using a well-known NTP service such as Google Public NTP ("time.google.com").
2. If NTP is unavailable, use the value from the first Client's Date: header. This necessarily means that the Printer MUST NOT advertise TLS support unless it has a certificate or its date and time has been set.

Notes (based on follow-up questions):

• Most Printers automatically generate a self-signed certificate either when the Printer first boots and has date and time information or opportunistically when a Client first requests a secure connection. Thus, a Printer that has the current date and time but no certificate can still advertise TLS support because it can generate a self-signed certificate on demand.
• A Printer that has TLS certificate (perhaps from a previous power cycle) but does not yet have the current date and time can advertise TLS support because the date and time is not needed for the TLS negotiation itself, just to determine whether a certificate is still valid (i.e. expired or not). If expired, the Printer will eventually generate a new certificate once it is able to obtain the current date and time through one of the methods listed above.

Common Solutions

The following is a list of common solutions that have been seen on shipping printers, along with some drawbacks. It is possible that some combination of these techniques might be useful:

• Ask the user for the current date and time on (first?) power-up.

Drawbacks: This is only available on printers with a display and is inconvenient for users. It also typically only provides a precision of minutes and (in order to minimize power usage) the date and time is lost when the printer is turned off.

• Set the time on initial setup using an application.

Drawbacks: Requires the use of an application to setup the printer. If the date and time is stored in some sort of non-volatile memory, the value will be wrong after a power cycle.

• Use a Network Time Protocol (NTP) server.

Drawback: This only works if the printer can connect to the time server, typically over the Internet.

• Use the Date: header in a client request.

Drawback: This requires an initial unencrypted connection to the printer. Since the preference is to use IPPS whenever possible, the only way to "force" a client to use IPP (unencrypted by default) is to not register the IPPS service types until the date and time is configured. However, that might cause more trouble as a static queue referencing the IPP service will require the use of HTTP Upgrade on every connection...