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 Role Token goes here GetSendCMSToken AABBCCDD ... Policy Options ... ... Hash algorithm and hash of encrypted content ... ... Content Encryption Key ... Redact key #2 Level 2 key ... Additional redaction keys .... The schema that describes the data type is: Schaad Expires August 18, 2014 [Page 4] Internet-Draft PLASMA Redact February 2014 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: 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. Schaad Expires August 18, 2014 [Page 9] Internet-Draft PLASMA Redact February 2014 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]