Add Time Stamp Requirements for Timestamping of CAWG Assertions

[ScottSPerryCPA]

For digital assets that are relied-upon in perpetuity, timestamping provides assurance that assertions made at a point of time were valid at the time of signing. Therefore, it is essential to specify what types of timestamps are acceptable for CAWG and what sources of timestamps are acceptable.

The C2PA has specifications on the issuance of timestamps, and it has specifications for issuers of timestamps that are included in the C2PA Certificate Policy. But these timestamps are specific to the scope of the C2PA which is directed to C2PA generator products validated by C2PA Validator Products.

This issue is to explore what timestamp and timestamp issuer requirements are appropriate for CAWG which focuses on asserts made my humans and organizations for identity and metadata tagging.

The starting point for this discussion should be the specifications that the C2PA provides within its Certificate Policy and modify as requires. Here are those requirements.

=== Time-Stamping Authorities

Organizations that operate CAs that issue certificates in accordance with this CP MAY also provide an RFC 3161-compliant <> (TSA), and the organization MAY apply to the Conformance Program for inclusion on the C2PA TSA Trust List. The TSA MAY operate several identifiable Time-Stamp Units (TSU).

Two forms of Time-Stamping Authorities are permitted under this CP:

• Backend TSA, operated as a service by the CA.
• On-Device TSA, intended for use on mobile/edge devices to support local time-stamping without requiring a network connection.

==== General TSA Requirements

. The CA SHALL disclose its TSA practices including the hashing algorithms, the expected life time of the time-stamp signature, subscriber and relying party obligations (if any), any limitations on the use of the time-stamp and information on how to verify the time-stamp, the intended time-accuracy, and logging of TSA events including how long logs are maintained (and hence are available to provide supporting evidence).
. The time values the TSU uses in the time-stamp shall be traceable to at least one of the real time values distributed by a UTC(k) laboratory.
. The intended accuracy SHALL be defined in the time-stamp, and the time included in the time-stamp SHALL be synchronized with this accuracy. The declared accuracy SHOULD be of 1 second or better. TSA clock synchronization SHALL be maintained when a leap second occurs as notified by the appropriate body.
. The TSA SHALL detect if the time that would be applied in a time-stamp drifts outside the declared accuracy. In this situation, the TSU SHALL stop time-stamp issuance.
. The time-stamp SHALL be signed using Private Keys that are reserved exclusively for this purpose. A TSU SHALL have a single time-stamp signing key active at a time.
. The TSA SHALL only accept time-stamp requests that use SHA2-256, SHA2-384, and SHA2-512 hashing algorithms, per the normative requirements of the C2PA Content Credentials specification.

==== Backend TSA

. TSU signing keys SHALL be generated and stored within a secure cryptographic device which is a trustworthy system that has been assured to EAL 4 or higher in accordance with ISO/IEC 15408, or equivalent internationally recognized evaluation criteria for IT security, or as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.

==== On-Device TSA

. The On-Device TSA SHALL attempt to synchronize its time at least once every 24 hours with an online time source whose time values are traceable to at least one of the real time values distributed by a UTC(k) laboratory. The trusted online time source MAY be a Backend TSA on the C2PA TSA Trust List. In such a case, the On-Device TSA SHALL adhere to the following procedure:
. The On-Device TSA application SHALL run in a <>
. TSU signing keys SHALL be generated and stored within a Trusted Execution Environment.