3.2.5.5.2 Issuing a Petition for a Secure Clock Challenge

The client MUST issue a new petition for each new secure clock challenge. The secure clock server MAY deny a secure clock challenge that has not been petitioned. Therefore, it is important that the client does not cache petitions.

The client obtains the petition URL from stored device configuration. In typical DRM-CD implementations, the URL is stored in the device certificate, and is retrieved by parsing the device certificate's SECURECLOCK XML node. The petition URL is located in the URL tag under the SECURECLOCK XML node.

The client submits a petition request to the petition URL and waits for the server's response. The petition request is a plain HTTP/1.0 GET request, as specified in section 2.2.2.1.

If the petition URL contains "https", the client SHOULD use SSL for the connection. If SSL is used, the client SHOULD check the server's certificate to ensure it is current, matches the domain, and is properly signed by a trusted authority.

The client MUST be prepared to follow HTTP [RFC2616] redirections during the petition. If the secure clock server responds with "HTTP 301 (Moved)" or "302 (Redirect)", the client MUST use this redirect URL as the new petition URL and start again by submitting the petition request to the redirect URL.

If the secure clock server responds with "HTTP 200 (OK)", the client reads the entire body of the response for the secure clock challenge URL. If successful, the client proceeds to the next step, submitting the secure clock challenge.

A valid petition response has the format as specified in section 2.2.2.2.