Internet DRAFT - draft-schaad-plasma-redact
draft-schaad-plasma-redact
Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting
Intended status: Experimental February 14, 2014
Expires: August 18, 2014
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
Schaad Expires August 18, 2014 [Page 1]
Internet-Draft PLASMA Redact February 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2. Creating a Redaction Lockbox . . . . . . . . . . . . . . . . 3
2.1. Redact Message Request . . . . . . . . . . . . . . . . . 3
3. Decoding A Redacted Document . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informational REferences . . . . . . . . . . . . . . . . 9
Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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].
Schaad Expires August 18, 2014 [Page 2]
Internet-Draft PLASMA Redact February 2014
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:
Schaad Expires August 18, 2014 [Page 3]
Internet-Draft PLASMA Redact February 2014
<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:
Schaad Expires August 18, 2014 [Page 4]
Internet-Draft PLASMA Redact February 2014
<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:
Schaad Expires August 18, 2014 [Page 5]
Internet-Draft PLASMA Redact February 2014
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. [CREF1]
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
Schaad Expires August 18, 2014 [Page 6]
Internet-Draft PLASMA Redact February 2014
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. [CREF2]
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.
Schaad Expires August 18, 2014 [Page 7]
Internet-Draft PLASMA Redact February 2014
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Schaad Expires August 18, 2014 [Page 8]
Internet-Draft PLASMA Redact February 2014
[EPS-CMS] Schaad, J., "Email Policy Service ASN.1 Processing", Work
In Progress draft-schaad-plamsa-cms, Jan 2011.
[plasma-token]
Schaad, J., "Plasma Service Trust Processing", Work in
progress draft-schaad-plasma-service, March 2012.
7.2. Informational REferences
[Plasma] Freeman, T., Schaad, J., and P. Patterson, "Requirements
for Message Access Control", Work in progress draft-
freeman-message-access-control, October 2011.
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>
Schaad Expires August 18, 2014 [Page 9]
Internet-Draft PLASMA Redact February 2014
<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>
Editorial Comments
[CREF1] JLS: Do we define this obligation or remove the previous
sentence?
[CREF2] JLS: Do we define this obligation or remove the previous
sentence?
Author's Address
Jim Schaad
Soaring Hawk Consulting
Email: ietf@augustcellars.com
Schaad Expires August 18, 2014 [Page 10]
