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