for remote attestation transfers trust measurements and measurement logs to the corresponding verifier (PCA or RS in our case). These data can however — and this is a principal problem with remote attestation — be used to individualise the trusted platform, if, as in the PC domain, the number of system states and different measurement logs created at boot time, is very large in relation to the number of users of a TC-based service. Besides, avoiding remote attestation saves bandwidth and resources consumption. Since in this case no trust can be laid in the TA for ticket management, some kind of double, or multiple, spending protection or usage authorisation is needed at RS upon ticket redemption.

On the other hand security necessitates additional means of protection of content in transit. In many applications, for instance if confidentiality of transported payload is a protection target, trusted software usage cannot be avoided We show in Section \[sec:Push\] how TC can be used to establish end-to-end protection for $P$, but this definitely requires trusted software clients at both ends.

Two Applications {#sec:App}
================

Price Scheduling in Pseudonymous Rating Systems {#sec:Rating}
-----------------------------------------------

This application has been outlined in [@RepuTicketsVG]. Electronic market places for physical 