PLASMA and Redacted Documents
draft-schaad-plasma-redact-01

Abstract

Redacted documents are designed to have a single document which allows different individuals to view different portions of the document basd on the attributes of the individual. In this document, a protocol extension to the basic PLASMA protocol is described that allows for multiple keys, each with a different policy, to be used in a single electronic document for enforcement of redaction levels. This document is agnostic relative to the actual format of the redacted document, the only requirement being that the redacted document be able to carry the PLASMA defined lock box.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 18, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Terminology
• 2. Creating a Redaction Lockbox
• 2.1. Redact Message Request
• 3. Decoding A Redacted Document
• 4. Security Considerations
• 5. IANA Considerations
• 6. Open Issues
• 7. References
• 7.1. Normative References
• 7.2. Informational REferences
• Appendix A. XML Schema
• Author's Address

1. Introduction

While many documents have a single policy for examination of the content, there are some documents where different sections of the document will have different policies for who should be able to read the document and who should not be able to read this specific section. In this specification, these documents are called Redacted Documents.

One method that the redaction of a document can be enforced is by providing different encryption keys for each section of a document based on the policy to be enforced on the individuals that can read the document. Both Word and PDF files have some method of doing redaction within a document that provides for a single that can conditionally display the protected sections, although the normal method is to create a new document that contains just the unrestricted text. This specification does not describe a method of creating an electronic redacted document, instead it provides a protocol that allows one to use cryptographic keys to protect different sections of a document and then to assign different policies to each of the cryptographic keys used. A PLASMA server is then used to wrap all of the information about the keys into a single lock box which can be distributed with the document and then the PLASMA server will be used to enforce the policies for release of each of the keys to readers of the document. The protocol provided here is an extension to the protocol defined in [plasma-token].

Readers of this document are expected to have pre-existing familiarity with RFC XXX [plasma-token] so little of the information in that specification is presented in this one.

1.1. Requirements Terminology

When capitalized, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Creating a Redaction Lockbox

Prior to requesting a redact token lock box, the client needs to obtain a role token from the Plasma server as documented in RFC XXX [plasma-token]. As part of the preparatory process, the client will construct all of the labels and keys to be used in the redacted document, each key will have associated with it a label that controls access to a section of the document. However, it should be noted that any section of the document can have multiple keys associated with it. A single key can be used to control access to multiple sections of the document, as long as all of the sections have the same access policy.

The response generated by the server is the same response token as is documented in #sendMessage-Response in RFC XXX [plasma-token].

2.1. Redact Message Request

This specification defines a new XML schema type to be used with the existing attribute "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest". Thus the request would look something like the following:

<eps:PlasmaRequest>
  <eps:Authentication>
    <eps:RoleToken>
      Role Token goes here
    </eps:RoleToken>
  </eps:Authentication>
  <xacml:Request>
    <xacml:Attributes Category="...:action">
      <xacml:Attribute AttributeId="...:plasma:action-id">
        <xacml:AttributeValue>
          GetSendCMSToken
        </xacml:AttributeValue>
      </xacml:Attribute>
    </xacml:Attributes>
    <xacml:Attributes Category="...:data">
      <xcaml:Attribute AttributeId="...:data:CMSTokenRequest">
        <xacml:AttributeValue DataType="...#GetCMSRedactTokenType">
          <redact:GetCMSRedactToken>
            <redact:KeyIdentifier>AABBCCDD</redact:KeyIdentifier>
            <eps:Policy PolicyId=".../Policy1">
              ...  Policy Options ...
            </eps:Policy>
            <eps:Hash>
              ... Hash algorithm and hash of encrypted content ...
            </eps:Hash>
            <eps:CEK>
              ... Content Encryption Key ...
            </eps:CEK>
            <redact:RedactKeys>
              <redact:RedactKey>
                <redact:KeyIdentifier> Redact key #2 </redact:KeyIdentifier>
                <eps:Policy ... />
                <eps:CEK> Level 2 key</eps:CEK>
              </redact:Redactkey>
              ... Additional redaction keys ....
            </redact:RedactKeys>
          </redact:GetCMSRedactToken>
        </xacml:AttributeValue>
      </xcaml:Attribute>
    </xacml:Attributes>
  </xacml:Request>
</eps:PlasmaRequest>

The schema that describes the data type is:

  <xs:element name="GetCMSRedactToken" type="GetCMSRedactTokenType"/>
  <xs:complexType name="GetCMSRedactTokenType">
    <xs:sequence maxOccurs="unbounded">
      <xs:choice minOccurs="0">
        <xs:element ref="eps:Policy"/>
        <xs:element ref="eps:PolicySet"/>
      </xs:choice>
      <xs:element name="Hash" minOccurs="0">
        <xs:complexType>
          <xs:sequence>
            <xs:element ref="ds2:DigestMethod"/>
            <xs:element ref="ds2:DigestValue"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="LockBox" type="eps:LockBoxType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
      <xs:element name="RedactKeys">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="RedactKey" type="RedactKeyType" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="RedactKeyType">
    <xs:sequence>
      <xs:element name="KeyIdentifier" type="xs:hexBinary"/>
      <xs:choice>
        <xs:element ref="eps:Policy"/>
        <xs:element ref="eps:PolicySet"/>
      </xs:choice>
      <xs:element name="LockBox" type="eps:LockBoxType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>

When used in an xacml:Attribute, the structure is identified by:

Category = "urn:ietf:params:xml:ns:plasma:data"
AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest"
DataType = "urn:ietf:params:xml:schema:plasma:1.0#GetCMSRedactTokenType"

The elements of the structure are used as:

Policy

This element contains a the policy to be applied to the message when a single policy is used.

PolicySet

This element contains the policy to be applied to the message when a combination of policies is to be applied.

Hash

This element contains the hash of the encrypted content of the message that the policy is being applied to. The algorithm used to compute the hash is contained in the DigestMethod element and the value is contained in the DigestValue element.

LockBox

This optional element contains a pre-computed CMS recipient info structure for a message recipient. This element may be repeated when more than one lock box is pre-computed for recipients by the message sender. This element is used in those cases where the sender does not want to share the content encryption key with the Plasma server and the sender has the ability to retrieve the necessary keys for all of the recipients. If the #### obligation was returned for the role token, then a recipient info lock box MUST be created for the Plasma server and the CEK element MUST absent.

CEK

This optional element contains the content encryption key (CEK) to decrypt the message.

RedactKeys

This element contains one or more RedactKey elements. Each RedactKey element corresponds to a different redaction policy with the set of keys that are associated with that policy.

If the top level of the document is not encrypted, then both LockBox and CEK can be omitted from the request.

The elements of the RedactKeyType structure are:

KeyIdentifier

This element is contains the key identifier used in the redacted document for those sections of the document encrypted with this key. There can be more than one key associated with a single key identifier, both general group keys and specific individual keys.

Policy

This element contains a the policy to be applied to the message when a single policy is used.

PolicySet

This element contains the policy to be applied to the message when a combination of policies is to be applied.

LockBox

This optional element contains a pre-computed CMS recipient info structure for a message recipient. This element may be repeated when more than one lock box is pre-computed for recipients by the message sender. This element is used in those cases where the sender does not want to share the content encryption key with the Plasma server and the sender has the ability to retrieve the necessary keys for all of the recipients. If the #### obligation was returned for the role token, then a recipient info lock box MUST be created for the Plasma server and the CEK element MUST absent.

CEK

This optional element contains the content encryption key (CEK) to decrypt the message.

In order for a redact key to be returned to a requester, they need to pass two policy checks, on in the GetCMSRedactTokenType structure and one in the RedactKeyType structure. This is by design. However, there are circumstances where this is not a desired behavior, for this reason specification of the top policy element is optional. If either the LockBox or CEK elements are present in the GetCMSRedactTokenType, then either the Policy or PolicySet element MUST be present.

3. Decoding A Redacted Document

Requesting that a redacted document token be decrypted is started the same way as for a normal CMS object. The steps in Section X.Y of RFC XXX [plasma-token] are followed. It is up to the Plasma server to determine that the object was created, this may be done by looking for additional policy fields or the key identifier fields.

When a redacted document token has been detected, then the Plasma server returns two different types of tokens. It returns a normal CMSKeyResponse token for the keys at the top level (assuming there are any). It returns the CMSRedactKey element for all keys that are second level redaction keys. In most cases more than one redaction key will be returned, either because the client passes multiple policy checks or because multiple redaction policies are used in the document.

The schema for returning a decryption key is:

  <xs:element name="CMSRedactKey" type="CMSRedactKeyType"/>
  <xs:complexType name="CMSRedactKeyType">
    <xs:sequence>
      <xs:element name="KeyIdentifier" type="xs:hexBinary"/>
      <xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>
    </xs:sequence>
  </xs:complexType>

The fields in the schema are:

KeyIdentifier

The content of this field contains the key identifier used to identify where this key is to be used in decrypting a section of the redacted document.

CMSKey

This field contains a single key being returned. The structure of this field can be found in RFC XXX [plasma-token].

4. Security Considerations

Text to be supplied.

5. IANA Considerations

Text to be supplied.

Register the XML schema for this document.

6. Open Issues

While I have given some considerations to what needs to be done in this document as part of doing the Plasma ASN.1 document, I have not done any type of implementing to see if it is practical. This document currently should be treated more as a place holder to make sure that I don't forget anything when doing the ASN.1 document. That being said, please feel free to common on this esp. if you have a working redaction document.

7. References

7.1. Normative References

7.2. Informational REferences

Appendix A. XML Schema

This appendix represents the entirety of the XML Schema for this extension of the Plasma protocol.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns="urn:ietf:params:ns:plasma:redact1.0" targetNamespace="urn:ietf:params:ns:plasma:redact1.0" xmlns:eps="urn:ietf:params:ns:plasma:1.0" xmlns:ds2="http://www.w3.org/2000/09/xmldsig#" >
  
  <xs:element name="GetCMSRedactToken" type="GetCMSRedactTokenType"/>
  <xs:complexType name="GetCMSRedactTokenType">
    <xs:sequence maxOccurs="unbounded">
      <xs:choice minOccurs="0">
        <xs:element ref="eps:Policy"/>
        <xs:element ref="eps:PolicySet"/>
      </xs:choice>
      <xs:element name="Hash" minOccurs="0">
        <xs:complexType>
          <xs:sequence>
            <xs:element ref="ds2:DigestMethod"/>
            <xs:element ref="ds2:DigestValue"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="LockBox" type="eps:LockBoxType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
      <xs:element name="RedactKeys">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="RedactKey" type="RedactKeyType" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="RedactKeyType">
    <xs:sequence>
      <xs:element name="KeyIdentifier" type="xs:hexBinary"/>
      <xs:choice>
        <xs:element ref="eps:Policy"/>
        <xs:element ref="eps:PolicySet"/>
      </xs:choice>
      <xs:element name="LockBox" type="eps:LockBoxType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
  
  <xs:element name="CMSRedactKey" type="CMSRedactKeyType"/>
  <xs:complexType name="CMSRedactKeyType">
    <xs:sequence>
      <xs:element name="KeyIdentifier" type="xs:hexBinary"/>
      <xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

Author's Address