| Back to associated article: Standard Language Could Aid DRM Interoperability |
| Rights Management Service Pack Planned (Sidebar) | ||||
|
By Matt Rosoff [bio] The following is the full text of an article published by Directions on Microsoft, an independent research firm focused exclusively on Microsoft strategy & technology. Each month we make one or more key articles available to non-subscribers.
Improvements Support Highly Secure Environments Improvements in RMS SP1 include the following: Offline enrollment. Today, an enterprise must activate its primary ("root") RMS server by connecting over the Internet to Microsoft and receiving a signed certificate. In addition, each RMS client must be activated by connecting to a Microsoft-hosted service through the RMS server; this service generates a machine certificate and a "lockbox" (software-based secure storage for encryption keys). However, for security reasons, some customers might want to use RMS in a completely closed system that lacks Internet access. SP1 addresses these problems. RMS server activation can occur via removable media—one PC can retrieve the RMS certificate over the Internet from Microsoft, then this certificate can be transferred to an RMS server in a closed system via disc. Client activation is no longer necessary at all with SP1—instead, each RMS SP1 client is delivered with the lockbox already included, with all the logic necessary to generate, store, and digitally sign the machine's credentials. Smart card support. Windows and RMS use different public key infrastructure (PKI) technologies, and although Windows PKI allows end users to authenticate themselves with a smart card, RMS does not. This problem is addressed in RMS SP1: users will be able to have a single smart card with both their Windows and RMS authentication credentials on it. Eventually (perhaps in the next version of RMS), Microsoft hopes to better integrate the two systems so that identity credentials from a Windows PKI can be used by an RMS system. Client rollout eased. Each PC in an RMS system must have an RMS client on it. Currently, to deploy the RMS client via Systems Management Server (SMS), a script must be included to trigger each RMS client to activate itself. In addition, users need administrative privileges to activate their clients. With SP1, clients will self-activate the first time they're used, regardless of whether users have administrative privileges. This eases the process of distributing the RMS clients via SMS, as no "trigger" script will be required. In addition, with SP1, RMS clients may be deployed using Group Policy. Better B2B a Priority SP1 does not address one drawback of RMS, however: the difficulty of exchanging protected documents beyond the firewall in business-to-business (B2B) scenarios involving customers or partners. Today, organizations can establish one-to-one trust relationships, so that certificates created by one RMS system can be trusted by other systems, but this quickly becomes unwieldy when protected information must be exchanged among many parties. Another option is to use a hosted version of RMS provided by a Microsoft partner such as GigaTrust, but organizations that are particularly concerned about confidentiality might not trust a hosted service. In the long run, Microsoft hopes to enable federation among RMS organizations—that is, allowing the credentials issued by one organization to be trusted by other organizations without requiring them to have a direct, one-to-one trust relationship. Third-party trust brokers such as Entrust or VeriSign could play a key role in this scenario by providing a central hub for trust relationships. However, Microsoft has not revealed how or when it intends to meet this goal.
| ||||
| Member Log On | Contact Us | About Us | Samples | Subscribe | Jobs | |||
|
|
||