How RMS Revocation Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Revocation works by preventing binding, the process that allows a user to consume content, when a revoked entity is involved in the binding request. Revocation is implemented through revocation lists that are distributed to client computers. These lists are signed XrML files that specify the content, applications, users, or other principals that have been revoked by the principal that issues the list.

Each time that a user attempts to consume rights-protected content, the associated RMS-enabled application sends a request for the appropriate right, in a binding request, to the RMS client. For example, if the user attempts to open a file, the application requests a View right that enables the file to open. If the user attempts to edit the file, the application requests an Edit right.

While processing the binding request, the RMS client goes through the following steps:

1. It evaluates the use license for any revocation list requirements.

2. If the use license requires revocation, the client component verifies whether or not the specified revocation list is present, registered, and current, according to the refresh interval that is specified in the use license.

3. It verifies that the principal who signed the revocation list is specified in the use license as a principal who is allowed to revoke the license.

4. If these checks are successful, the client component then determines whether or not any principals that are involved in the original binding request have been revoked. If so, it denies the binding request.

Revocation lists can be distributed to client computers by the administrator, or they can be downloaded to the computer by an RMS-enabled application when required by a use license. When a revocation list is used to bind a piece of content, it is registered and can be used for binding requests with other use licenses, as long as the application remains open. After the application is closed, the revocation list is unregistered.

The following diagram displays the binding process and shows how revocation works in it.

Revocation is optional. The RMS administrator can require revocation by specifying it in one or more of the organization's rights policy templates. When revocation is required, a license cannot bind unless the required revocation list is present, registered on the user's computer, and no older than the refresh interval that is specified in the use license.

It is important to note, however, that revocation can still take effect for a given use license, even when the use license does not require it. Revocation takes effect whenever any issuer of any certificate that is in the chain of trust that is involved in a binding request has issued a revocation list that is registered on a client computer. In this scenario, the revocation list is used to process binding requests, even if the use licenses that are involved do not require revocation. This is true until the RMS-enabled application is closed, which unregisters the revocation list.

For example, if a user attempts to consume a piece of content whose use license, issued by entity A, requires a revocation list that is issued by entity A, the RMS-enabled application obtains the revocation list from the URL that is specified in the use license, and then registers it. When processing the binding request, the RMS client checks the revocation list for possible revocations.

Leaving the RMS-enabled application open, the user then attempts to consume a second piece of content whose use license was also issued by entity A. Although this use license does not include a revocation condition, the revocation list from entity A is currently registered on the user's computer. In this situation, the client component will examine the revocation list before processing the binding request.

The user then attempts to consume a piece of content whose use license was issued by entity C. The use license does not include a revocation condition. Because the only revocation list that is registered on the client computer is the revocation list that is issued by entity A, and entity A is not in the chain of trust for the use license, no revocation is in effect for the bind.

Finally, the user closes the RMS-enabled application, and then later reopens the second piece of content that did not include a revocation condition. Because the revocation list that was issued by entity A was unregistered when the application was closed, the RMS client does not examine it to process the binding request.