共用方式為

Comparing RMS to PGP and S/MIME

  • 發行項

Over time, customers have asked us how RMS compares to or interoperates with S/MIME or PGP. This post will briefly address this issue without going into too much technical detail.

First, there are some important similarities between these technologies:

  • Every email or document that RMS handles is encrypted with state-of-the-art AES. RMS does not simply enforce DRM-style permissions on content users, like many believe – it also helps protect the content against unauthorized third party “eavesdroppers.”
  • In addition, entities involved in the RMS-protected document workflow (such as RMS servers and end users) have RSA public-private key pairs in order to enable the distribution of protected documents more securely.

Now let’s look at what is different:

  • PGP key management and exchange is mostly ad-hoc while with RMS it is the RMS server that manages user keys and key exchange is server-mediated and happens automatically; RMS offers better centralized management of users and keys and is easier to deploy
  • S/MIME is limited to email, while RMS, as used by Microsoft Office, offers you the ability to protect various document types and store them wherever you want
  • PGP offers the widest selection of encryption algorithms, most of which are not FIPS approved and standardized (e.g. CAST, IDEA) and there is no standardized front end or API making PGP (or its open source counterpart GPG) more confusing and more difficult to use (but also more flexible for a small group of power users)
  • RMS always needs connectivity to an RMS server the first time a protected document or email is opened, while PGP, due to its decentralized nature, does not need server presence
  • PGP and S/MIME offer sign-only no-encryption modes while with RMS content is always encrypted

As far as interop goes, from within Microsoft Outlook, which today is the main mail app that uses RMS, you can apply both RMS policy and S/MIME protection on the same email, e.g. you can create a “Do Not Forward” email that you sign with your S/MIME certificate. Interop between RMS and PGP is more implementation dependent, based on what PGP/GPG front end plugin you use. At the very least, you ought to be able to attach a PGP-encrypted file to an RMS-protected mail, much like you can attach any doc in an RMS protected mail.

Clearly, there is more to discuss here, and you should read some more about RMS, PGP, and S/MIME online in order to appreciate the similarities and differences between these technologies. I can post some more information in the future if there is interest on this topic.

 

Ivan Davtchev,

Program Manager

Comments

  • Anonymous
    May 03, 2005
    Yes, please post more. Good read.
  • Anonymous
    May 03, 2005
  1. What is the reason behind the idea to create separate (from S/MIME X.509 certificates) public key management system?
    2) Is it possible to extend RMS with other crypto algorithms (ECDSA and ECDH for example)?
  • Anonymous
    May 10, 2005
    In response to SiM's comment:

    1. RMS uses XrML certificates as opposed to x.509 certs. Currently, the other existing Windows PKI tools handle x.509, which partly explains why the cert management system for RMS is separate. XrML certs have the advantage that they allow much more flexible expression of policy and rights than x.509 v3. Rights management systems like ours have their own specific requirements about expression of rights and management of keys and crypto chains.

    2. As of today, it is not possible for a customer to completely replace the algorithms used by RMS (e.g. replace RSA with ECC), and the ones you mention are not supported right now. However, the RMS licenses and certs are XrML based which allows for rich expression, so it is possible to extend the platform to support other algorithms in the future.
  • Anonymous
    May 20, 2005
    Thanks for the answer, Ivan. It's sad that existing X509 certificates are not flexible enough for policy management