idnits 2.17.1 draft-schaad-plasma-redact-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 237 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 14, 2014) is 3721 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CREF1' is mentioned on line 438, but not defined == Missing Reference: 'CREF2' is mentioned on line 441, but not defined == Unused Reference: 'EPS-CMS' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'Plasma' is defined on line 377, but no explicit reference was found in the text -- No information found for draft-schaad-plamsa-cms - is the name correct? -- No information found for draft-freeman-message-access-control - is the name correct? Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Experimental February 14, 2014 5 Expires: August 18, 2014 7 PLASMA and Redacted Documents 8 draft-schaad-plasma-redact-01 10 Abstract 12 Redacted documents are designed to have a single document which 13 allows different individuals to view different portions of the 14 document basd on the attributes of the individual. In this document, 15 a protocol extension to the basic PLASMA protocol is described that 16 allows for multiple keys, each with a different policy, to be used in 17 a single electronic document for enforcement of redaction levels. 18 This document is agnostic relative to the actual format of the 19 redacted document, the only requirement being that the redacted 20 document be able to carry the PLASMA defined lock box. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 18, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 57 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2. Creating a Redaction Lockbox . . . . . . . . . . . . . . . . 3 59 2.1. Redact Message Request . . . . . . . . . . . . . . . . . 3 60 3. Decoding A Redacted Document . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 7.2. Informational REferences . . . . . . . . . . . . . . . . 9 67 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 While many documents have a single policy for examination of the 73 content, there are some documents where different sections of the 74 document will have different policies for who should be able to read 75 the document and who should not be able to read this specific 76 section. In this specification, these documents are called Redacted 77 Documents. 79 One method that the redaction of a document can be enforced is by 80 providing different encryption keys for each section of a document 81 based on the policy to be enforced on the individuals that can read 82 the document. Both Word and PDF files have some method of doing 83 redaction within a document that provides for a single that can 84 conditionally display the protected sections, although the normal 85 method is to create a new document that contains just the 86 unrestricted text. This specification does not describe a method of 87 creating an electronic redacted document, instead it provides a 88 protocol that allows one to use cryptographic keys to protect 89 different sections of a document and then to assign different 90 policies to each of the cryptographic keys used. A PLASMA server is 91 then used to wrap all of the information about the keys into a single 92 lock box which can be distributed with the document and then the 93 PLASMA server will be used to enforce the policies for release of 94 each of the keys to readers of the document. The protocol provided 95 here is an extension to the protocol defined in [plasma-token]. 97 Readers of this document are expected to have pre-existing 98 familiarity with RFC XXX [plasma-token] so little of the information 99 in that specification is presented in this one. 101 1.1. Requirements Terminology 103 When capitalized, the key words "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 105 and "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 2. Creating a Redaction Lockbox 110 Prior to requesting a redact token lock box, the client needs to 111 obtain a role token from the Plasma server as documented in RFC XXX 112 [plasma-token]. As part of the preparatory process, the client will 113 construct all of the labels and keys to be used in the redacted 114 document, each key will have associated with it a label that controls 115 access to a section of the document. However, it should be noted 116 that any section of the document can have multiple keys associated 117 with it. A single key can be used to control access to multiple 118 sections of the document, as long as all of the sections have the 119 same access policy. 121 The response generated by the server is the same response token as is 122 documented in #sendMessage-Response in RFC XXX [plasma-token]. 124 2.1. Redact Message Request 126 This specification defines a new XML schema type to be used with the 127 existing attribute 128 "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest". Thus the 129 request would look something like the following: 131 132 133 134 Role Token goes here 135 136 137 138 139 140 141 GetSendCMSToken 142 143 144 145 146 147 148 149 AABBCCDD 150 151 ... Policy Options ... 152 153 154 ... Hash algorithm and hash of encrypted content ... 155 156 157 ... Content Encryption Key ... 158 159 160 161 Redact key #2 162 163 Level 2 key 164 165 ... Additional redaction keys .... 166 167 168 169 170 171 172 174 The schema that describes the data type is: 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 203 204 205 206 207 208 209 210 211 212 213 215 When used in an xacml:Attribute, the structure is identified by: 217 Category = "urn:ietf:params:xml:ns:plasma:data" 218 AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest" 219 DataType = 220 "urn:ietf:params:xml:schema:plasma:1.0#GetCMSRedactTokenType" 222 The elements of the structure are used as: 224 Policy 225 This element contains a the policy to be applied to the message 226 when a single policy is used. 228 PolicySet 229 This element contains the policy to be applied to the message when 230 a combination of policies is to be applied. 232 Hash 233 This element contains the hash of the encrypted content of the 234 message that the policy is being applied to. The algorithm used 235 to compute the hash is contained in the DigestMethod element and 236 the value is contained in the DigestValue element. 238 LockBox 239 This optional element contains a pre-computed CMS recipient info 240 structure for a message recipient. This element may be repeated 241 when more than one lock box is pre-computed for recipients by the 242 message sender. This element is used in those cases where the 243 sender does not want to share the content encryption key with the 244 Plasma server and the sender has the ability to retrieve the 245 necessary keys for all of the recipients. If the #### obligation 246 was returned for the role token, then a recipient info lock box 247 MUST be created for the Plasma server and the CEK element MUST 248 absent. [CREF1] 250 CEK 251 This optional element contains the content encryption key (CEK) to 252 decrypt the message. 254 RedactKeys 255 This element contains one or more RedactKey elements. Each 256 RedactKey element corresponds to a different redaction policy with 257 the set of keys that are associated with that policy. 259 If the top level of the document is not encrypted, then both LockBox 260 and CEK can be omitted from the request. 262 The elements of the RedactKeyType structure are: 264 KeyIdentifier 265 This element is contains the key identifier used in the redacted 266 document for those sections of the document encrypted with this 267 key. There can be more than one key associated with a single key 268 identifier, both general group keys and specific individual keys. 270 Policy 271 This element contains a the policy to be applied to the message 272 when a single policy is used. 274 PolicySet 275 This element contains the policy to be applied to the message when 276 a combination of policies is to be applied. 278 LockBox 279 This optional element contains a pre-computed CMS recipient info 280 structure for a message recipient. This element may be repeated 281 when more than one lock box is pre-computed for recipients by the 282 message sender. This element is used in those cases where the 283 sender does not want to share the content encryption key with the 284 Plasma server and the sender has the ability to retrieve the 285 necessary keys for all of the recipients. If the #### obligation 286 was returned for the role token, then a recipient info lock box 287 MUST be created for the Plasma server and the CEK element MUST 288 absent. [CREF2] 290 CEK 291 This optional element contains the content encryption key (CEK) to 292 decrypt the message. 294 In order for a redact key to be returned to a requester, they need to 295 pass two policy checks, on in the GetCMSRedactTokenType structure and 296 one in the RedactKeyType structure. This is by design. However, 297 there are circumstances where this is not a desired behavior, for 298 this reason specification of the top policy element is optional. If 299 either the LockBox or CEK elements are present in the 300 GetCMSRedactTokenType, then either the Policy or PolicySet element 301 MUST be present. 303 3. Decoding A Redacted Document 305 Requesting that a redacted document token be decrypted is started the 306 same way as for a normal CMS object. The steps in Section X.Y of RFC 307 XXX [plasma-token] are followed. It is up to the Plasma server to 308 determine that the object was created, this may be done by looking 309 for additional policy fields or the key identifier fields. 311 When a redacted document token has been detected, then the Plasma 312 server returns two different types of tokens. It returns a normal 313 CMSKeyResponse token for the keys at the top level (assuming there 314 are any). It returns the CMSRedactKey element for all keys that are 315 second level redaction keys. In most cases more than one redaction 316 key will be returned, either because the client passes multiple 317 policy checks or because multiple redaction policies are used in the 318 document. 320 The schema for returning a decryption key is: 322 323 324 325 326 327 328 330 The fields in the schema are: 332 KeyIdentifier 333 The content of this field contains the key identifier used to 334 identify where this key is to be used in decrypting a section of 335 the redacted document. 337 CMSKey 338 This field contains a single key being returned. The structure of 339 this field can be found in RFC XXX [plasma-token]. 341 4. Security Considerations 343 Text to be supplied. 345 5. IANA Considerations 347 Text to be supplied. 349 Register the XML schema for this document. 351 6. Open Issues 353 While I have given some considerations to what needs to be done in 354 this document as part of doing the Plasma ASN.1 document, I have not 355 done any type of implementing to see if it is practical. This 356 document currently should be treated more as a place holder to make 357 sure that I don't forget anything when doing the ASN.1 document. 358 That being said, please feel free to common on this esp. if you have 359 a working redaction document. 361 7. References 363 7.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [EPS-CMS] Schaad, J., "Email Policy Service ASN.1 Processing", Work 369 In Progress draft-schaad-plamsa-cms, Jan 2011. 371 [plasma-token] 372 Schaad, J., "Plasma Service Trust Processing", Work in 373 progress draft-schaad-plasma-service, March 2012. 375 7.2. Informational REferences 377 [Plasma] Freeman, T., Schaad, J., and P. Patterson, "Requirements 378 for Message Access Control", Work in progress draft- 379 freeman-message-access-control, October 2011. 381 Appendix A. XML Schema 383 This appendix represents the entirety of the XML Schema for this 384 extension of the Plasma protocol. 386 387 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 427 428 429 430 431 432 433 434 436 Editorial Comments 438 [CREF1] JLS: Do we define this obligation or remove the previous 439 sentence? 441 [CREF2] JLS: Do we define this obligation or remove the previous 442 sentence? 444 Author's Address 446 Jim Schaad 447 Soaring Hawk Consulting 449 Email: ietf@augustcellars.com