One document matched: draft-schaad-plasma-redact-00.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:eps-redact.xml"?>
<!-- automatically generated by xml2rfc v1.35 on 2013-01-17T07:33:56Z -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- xml2rfc-processed-entity RFC2119 -->
<!-- xml2rfc-processed-entity PLASMA-WS-TRUST -->
<!-- xml2rfc-processed-entity REDACT-SCHEMA -->
<!-- xml2rfc-processed-entity REDACT-GET-SCHEMA -->
<!-- xml2rfc-processed-entity REDACT-RESPOND-SCHEMA -->
<!-- xml2rfc-processed-entity PlasmaSpace -->
<!-- xml2rfc-processed-entity PlasmaSchema -->
<!-- xml2rfc-processed-entity PlasmaCategory -->
]>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<rfc category="exp" docName="draft-schaad-plasma-redact-00" ipr="trust200902">
<front>
<title abbrev="PLASMA Redact">PLASMA and Redacted Documents</title>
<author fullname="Jim Schaad" initials="J." surname="Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<date/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
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 <xref target="plasma-token"/>.
</t>
<t>
Readers of this document are expected to have pre-existing familiarity with RFC XXX <xref target="plasma-token"/> so little of the information in that specification is presented in this one.
</t>
<section title="Requirements Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Creating a Redaction Lockbox">
<t>
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 <xref target="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.
</t>
<t>
The response generated by the server is the same response token as is documented in #sendMessage-Response in RFC XXX <xref target="plasma-token"/>.
</t>
<section title="Redact Message Request" anchor="redactMessageRequest">
<t>
This specification defines a new XML schema type to be used with the existing attribute "<?rfc linefile="12"?>urn:ietf:params:xml:ns:plasma<?rfc linefile="79"?>:data:CMSTokenRequest".
Thus the request would look something like the following:
</t>
<figure><artwork>
<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>
</artwork></figure>
<t>
The schema that describes the data type is:
</t>
<?rfc linefile="9"?>ForDraft/RedactTokenType.incl<?rfc linefile="131"?>
<t>
When used in an xacml:Attribute, the structure is identified by:
<vspace blankLines='1'/>
Category = "<?rfc linefile="14"?>urn:ietf:params:xml:ns:plasma:data<?rfc linefile="136"?>"
<vspace blankLines='0'/>
AttributeId = "<?rfc linefile="12"?>urn:ietf:params:xml:ns:plasma<?rfc linefile="138"?>:data:CMSTokenRequest"
<vspace blankLines='0'/>
DataType = "<?rfc linefile="13"?>urn:ietf:params:xml:schema:plasma:1.0<?rfc linefile="140"?>#GetCMSRedactTokenType"
</t>
<t>The elements of the structure are used as:
<list style="hanging">
<t hangText="Policy">
<vspace/>
This element contains a the policy to be applied to the message when a single policy is used.
</t>
<t hangText="PolicySet">
<vspace/>
This element contains the policy to be applied to the message when a combination of policies is to be applied.
</t>
<t hangText="Hash">
<vspace/>
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.
</t>
<t hangText="LockBox">
<vspace/>
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.
<cref source="JLS">Do we define this obligation or remove the previous sentence?</cref>
</t>
<t hangText="CEK">
<vspace/>
This optional element contains the content encryption key (CEK) to decrypt the message.
</t>
<t hangText="RedactKeys">
<vspace/>
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.
</t>
</list>
If the top level of the document is not encrypted, then both LockBox and CEK can be omitted from the request.
</t>
<t>
The elements of the RedactKeyType structure are:
<list style="hanging">
<t hangText="KeyIdentifier">
<vspace/>
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.
</t>
<t hangText="Policy">
<vspace/>
This element contains a the policy to be applied to the message when a single policy is used.
</t>
<t hangText="PolicySet">
<vspace/>
This element contains the policy to be applied to the message when a combination of policies is to be applied.
</t>
<t hangText="LockBox">
<vspace/>
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.
<cref source="JLS">Do we define this obligation or remove the previous sentence?</cref>
</t>
<t hangText="CEK">
<vspace/>
This optional element contains the content encryption key (CEK) to decrypt the message.
</t>
</list>
</t>
<t>
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.
</t>
</section>
</section>
<section title="Decoding A Redacted Document" anchor="readRedact">
<t>
Requesting that a redacted document token be decrypted is started the same way as for a normal CMS object.
The steps in <xref target="plasma-token"> Section X.Y of RFC XXX</xref> 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.
</t>
<t>
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.
</t>
<t>
The schema for returning a decryption key is:
</t>
<?rfc linefile="10"?>ForDraft/RedactTokenResponse.incl<?rfc linefile="248"?>
<t>
The fields in the schema are:
<list style="hanging">
<t hangText="KeyIdentifier">
<vspace/>
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.
</t>
<t hangText="CMSKey">
<vspace/>
This field contains a single key being returned.
The structure of this field can be found in RFC XXX <xref target="plasma-token"/>.
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>
Text to be supplied.
</t>
</section>
<section title="IANA Considerations">
<t>
Text to be supplied.
</t>
<t>
Register the XML schema for this document.
</t>
</section>
<section title="Open Issues">
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc linefile="1:bibxml/reference.RFC.2119.xml"?>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc linefile="296:eps-redact.xml"?>
<reference anchor="EPS-CMS">
<front>
<title>Email Policy Service ASN.1 Processing</title>
<author initials="J." surname='Schaad' fullname='Jim Schaad'/>
<date month='Jan' year='2011'/>
</front>
<seriesInfo name='Work In Progress' value='draft-schaad-plamsa-cms'/>
</reference>
// &PLASMA-CMS;
<reference anchor="plasma-token">
<front>
<title>Plasma Service Trust Processing</title>
<author initials="J." surname="Schaad"/>
<date month="March" year="2012"/>
</front>
<seriesInfo name="Work in progress" value="draft-schaad-plasma-service"/>
</reference>
</references>
<references title="Informational REferences">
<reference anchor="Plasma">
<front>
<title>Requirements for Message Access Control</title>
<author initials="T." surname="Freeman"/>
<author initials="J." surname="Schaad"/>
<author initials="P." surname="Patterson"/>
<date month="October" year="2011"/>
</front>
<seriesInfo name="Work in progress" value="draft-freeman-message-access-control"/>
</reference>
</references>
<section title="XML Schema">
<t>
This appendix represents the entirety of the XML Schema for this extension of the Plasma protocol.
</t>
<?rfc linefile="1:ForDraft/Plasma-redact.xsd.incl"?><figure><artwork>
<?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>
</artwork></figure>
<?rfc linefile="336:eps-redact.xml"?>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:39:43 |