5. Vendor Guidelines

This section is intended to assist vendors in understanding the requirements of government and the issues raised by TC/DRM, and how these issues might be addressed by vendors. The term ‘vendor’ should be interpreted in the loosest sense, as being any provider of ICT technology (hardware, software etc) or information product. The term should, therefore, be interpreted to include providers of free products, such as open source software.

The requirements can be summarised as followed:

• Real-time notification of the presence, nature (static or dynamic) and details of encumbrances.
• Provision for long-term access to government information.
• Support for anti-malware scanning of information and communications (or provide/suggest alternative means of protection).
• Configurability of TC/DRM features, for instance for notifications, communications, attestation and trust, and the ability to have them turned off by default (or at least provide the choice during installation).
• Pre-purchase notification of TC/DRM functionality and communications needs.
• Independent verification of the TC/DRM specifications and features.

5.1 Notification of encumbrance

Use rights expression wrappers

Software that applies DRM encumbrances should use rights expression wrappers to declare the encumbrance. The wrappers should not be encrypted, and should conform to a published REL (Rights Expression Language) standard, e.g. ISO/REL, ODRL.

The rights statement should be stable and not subject to unilateral external change – any change needs to include the informed consent of the recipient.

The rights statement should disclose the fact that the information is protected, and who has what access rights (e.g. can’t copy, can print).

Consuming applications should be certified as correctly interpreting the REL.

Use of rights expression wrappers will assist agencies in determining whether encrypted information is subject to a DRM encumbrance, and knowing the details of any such encumbrance.

Confirm non-revocation of access

Vendors should provide solutions for agencies to satisfy themselves that no access expiry exists on encumbered information, and that rights are non-revocable.

Software support for informed consent process

Where digital rights have been applied externally, agencies will need software support to:

• consistently identify files that have digital rights attached
• view the rights and enable a consent/reject decision process
• inform users on each use of the information, that usage restrictions are attached, and enable easy viewing if required
• ensure that rights remain fixed except by mutual consent of the agency and rights-holder.

The notification mechanism that informs users of attached rights should be controlled by the organisation, not by the vendor or the user. There should be a choice between passive notification, e.g. through appearance of a clickable icon, and active notification, such as a modal dialogue. The degree of passive or active notification should be configurable based on the source of the information. There should be an option to whitelist particular sources, e.g. information produced within the organisation.

5.2 Long term access to government information

Support for digital preservation

It is important not to overlook the needs of government for longer-term usage of its information. Software vendors are encouraged to support these needs in their products by:

• protecting against premature expiry of usage rights
• enabling migration of TC/DRM-protected information from data formats that are becoming obsolete.

Support time-based expiry of restrictions

Information providers may wish to apply usage restrictions in the short term, but without having a requirement for the restrictions to remain in force beyond a certain point. After that point, they become a needless hindrance to the recipient. Products that enable time-based expiry of restrictions would make TC/DRM use acceptable in a wider range of contexts.

5.3 Anti-malware scanning

Support scanning of information and communications

Suppliers of products that apply TC/DRM restrictions to the use of information, can assist agencies by providing a means for an agency to:

• inspect the information, using its normal scanning tools, e.g. anti-virus software
• inspect any TC/DRM communications required to use it.

5.4 Configurability

Support granular control of remote attestation

Trusted computing platforms should enable granular control of remote attestation, i.e. the user should be able to enable remote attestation per communications partner and even per communication, not just as a global setting. This will help users to ensure that use of this function is confined to the purposes for which it was enabled, and thus minimise the risk of it being misappropriated for unwanted communications.

Support for enterprise-level control of TC/DRM feature usage

Vendors incorporating TC/DRM as optional features into their products, should:

• generally have them set to off by default
• enable enterprise-level control of the capability.

By providing safeguards against inappropriate usage of the features, vendors will make their products more acceptable to government.

5.5 Pre-purchase notification of functionality and communications needs

Disclosure of TC/DRM functionality

Vendors selling hardware, software or information products should declare whether the product includes TC/DRM functionality, and provide documentation of these functions, options and procedures to remove those controls. Information products, for example, sometimes come bundled with DRM software, and the presence and functionality of such software should be declared.

Declarations of TC/DRM functionality should be kept up-to-date with all subsequent versions of the product, including patches.

Disclosure of TC/DRM communications

Suppliers of any products with TC/DRM features should support agencies in complying with Policy 12, Communications specifications, by creating communications specifications for their products.

General product specifications are unlikely to be appropriate, as they will often contain a large volume of irrelevant detail which makes it difficult to find the information agencies actually require. Instead, suppliers should separately document, in business terms, 'the triggers and content of any communications (including attestation and other background communications) that leave from or arrive at the computer'.

Some examples of the types of communications that need to be included in the specification are:

• remote attestation
• communication with a digital rights management server
• activation or heartbeat communications.

For each communication agencies will need to know:

• When: what triggers the communications?
• Who: where/what is the end point of the communications, and who else may it be shared with?
• How: what communications methods and protocols are used? Is it encrypted, signed?
• Are any of the details above configurable (per computer, -user, -application or -use)?

The communications specification should be kept up-to-date with all subsequent versions of the product, including patches.

Industry standard communications specification

Vendors are encouraged to collaborate to create an industry standard for a TC/DRM communications specifications.

Provide warranty against unauthorised information modification/deletion

Vendors should provide warranties that their products will not make unauthorised modification or hinder access to government information, without explicit government approval (notwithstanding software bugs and other unintended activity). This will support agencies in complying with Policy 9, Modification/deletion by hardware/software. Vendors could submit their products to an independent certification programme, for confirmation that their products do not behave in this way.

Provide privacy warranty or disclosure

Vendors should, where applicable, warrant that their products do not collect personal data without explicit user permission. Alternately, they should declare the type of data to be gathered and its intended usage, and provide appropriate legal remedies to the purchaser for any mis-use of the information.

5.6 Independent verification

Establish independent body to verify communications specification

Vendors are encouraged to collaborate to create a certification programme, where an independent body certifies that their products conform to their TC/DRM communications specifications.