Redaction of Potentially Sensitive Data from Mail Abuse Reports
RFC 6590
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
08 | (System) | Notify list changed from marf-chairs@ietf.org, draft-ietf-marf-redaction@ietf.org to (None) |
|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2012-04-07
|
08 | (System) | RFC published |
|
2012-02-22
|
08 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2012-02-22
|
08 | (System) | IANA Action state changed to No IC |
|
2012-02-21
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2012-02-21
|
08 | Amy Vezza | IESG has approved the document |
|
2012-02-21
|
08 | Amy Vezza | Closed "Approve" ballot |
|
2012-02-21
|
08 | Amy Vezza | Approval announcement text regenerated |
|
2012-02-17
|
08 | Pete Resnick | State changed to Approved-announcement to be sent from Waiting for AD Go-Ahead. |
|
2012-02-15
|
08 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Julien Laganier. |
|
2012-02-13
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2012-02-04
|
08 | David Black | Request for Last Call review by GENART Completed. Reviewer: David Black. |
|
2012-02-02
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2012-02-02
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2012-01-30
|
08 | Amy Vezza | Last call sent |
|
2012-01-30
|
08 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <marf@ietf.org> Reply-To: ietf@ietf.org Subject: Additional Last Call: <draft-ietf-marf-redaction-08.txt> (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Proposed Standard The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' <draft-ietf-marf-redaction-08.txt> as a Proposed Standard During Last Call and IESG Evaluation, a significant change was made to the document to address the comments of reviewers, removing a recommended transformation mechanism and instead detailing how to select any of the acceptable transformation mechanisms. This additional last call is to solicit any comments on this change. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ No IPR declarations have been submitted directly on this I-D. |
|
2012-01-30
|
08 | Amy Vezza | Last Call text changed |
|
2012-01-28
|
08 | Pete Resnick | Last Call was requested |
|
2012-01-28
|
08 | Pete Resnick | State changed to Last Call Requested from IESG Evaluation::AD Followup. |
|
2012-01-28
|
08 | Pete Resnick | Last Call text changed |
|
2012-01-27
|
08 | (System) | New version available: draft-ietf-marf-redaction-08.txt |
|
2012-01-24
|
07 | (System) | New version available: draft-ietf-marf-redaction-07.txt |
|
2012-01-24
|
08 | Stephen Farrell | [Ballot comment] I'm still not fond of the example in the appendix (a hmac one would be less likely to encourage bad practice) but thanks … [Ballot comment] I'm still not fond of the example in the appendix (a hmac one would be less likely to encourage bad practice) but thanks for taking my issue into account. |
|
2012-01-24
|
08 | Stephen Farrell | [Ballot discuss] (Updated-discuss - thought about it a bit more;-) (1) The construct here is output=H(redaction-key|sensitve-value). I don't think that's ok. I think you want … [Ballot discuss] (Updated-discuss - thought about it a bit more;-) (1) The construct here is output=H(redaction-key|sensitve-value). I don't think that's ok. I think you want HMAC() and not H(). If I could supply a redactor with a zero length "private" string, e.g. message with a header field like "To: @example.org" then the redactor will send H(redaction-key) which can then allow (via hash-continuation) checking if any value matches a value from an output here. If the alphabet for sensitive values has N characters then I can also send "To: "+char[i]+"@example.org" for each i and then play the continuation game on that. Same for two character prefixes etc. (2) I can also use this to validate guesses of the redaction key value. I need to think about how one might avoid that or if its possible to avoid that. |
|
2012-01-24
|
08 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
|
2012-01-23
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2012-01-23
|
06 | (System) | New version available: draft-ietf-marf-redaction-06.txt |
|
2012-01-20
|
08 | David Black | Request for Last Call review by GENART Completed. Reviewer: David Black. |
|
2012-01-19
|
08 | Cindy Morgan | Removed from agenda for telechat |
|
2012-01-19
|
08 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
|
2012-01-19
|
08 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-18
|
08 | Pete Resnick | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2012-01-18
|
08 | Russ Housley | [Ballot comment] Please reference RFC 4648, Section 4 for [Base64]. More than one alphabet is available in RFC 4648. |
|
2012-01-18
|
08 | Russ Housley | [Ballot discuss] The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns. There has been some discussion of those concerns, but the document … [Ballot discuss] The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns. There has been some discussion of those concerns, but the document has not been updated yet to address them. The Gen-ART Review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07043.html |
|
2012-01-18
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss |
|
2012-01-18
|
08 | Sean Turner | [Ballot comment] Updated (add the last two) I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC. You probably don't … [Ballot comment] Updated (add the last two) I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC. You probably don't need to specify an algorithm because it's not an interoperability issue, but it might be nice to point to RFC 6151 and 6194 for recent info on HMAC-MD5 and HMAC-SHA1. It would stop people from trying to do something over kill like HMAC-SHA256. If you're going to stick with the plain ole hash then pointing to 6151 and 6914 still is worth considering (i.e., MD5 bad). Probably worth a reference to RFC 4086 for the pseudo-random # issues. |
|
2012-01-18
|
08 | Sean Turner | [Ballot comment] I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC. You probably don't need to specify an algorithm … [Ballot comment] I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC. You probably don't need to specify an algorithm because it's not an interoperability issue, but it might be nice to point to RFC 6151 and 6914 for recent info on HMAC-MD5 and HMAC-SHA1. It would stop people from trying to do something over kill like HMAC-SHA256. |
|
2012-01-18
|
08 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-18
|
05 | (System) | New version available: draft-ietf-marf-redaction-05.txt |
|
2012-01-18
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2012-01-17
|
08 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-17
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-17
|
08 | Peter Saint-Andre | [Ballot comment] I agree with other IESG members that this document seems informational, not standards track. |
|
2012-01-17
|
08 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-17
|
08 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-17
|
08 | Russ Housley | [Ballot discuss] The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns. There has been some discussion of those concerns, but the document … [Ballot discuss] The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns. There has been some discussion of those concerns, but the document has not been updated yet to address them. The Gen-ART Review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07043.html |
|
2012-01-17
|
08 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded |
|
2012-01-17
|
08 | Dan Romascanu | [Ballot comment] This is a rather short and aparently straight-forward document, but it raised a couple of questions. None of them is that critical to … [Ballot comment] This is a rather short and aparently straight-forward document, but it raised a couple of questions. None of them is that critical to deserve a blocking DISCUSS, but yet I would be glad if these were answered and clarified before approval and publication. 1. It is not clear why this document is on standards track. I do not know how to establish interoperability of implementations and thus what the critieria would be for advancement from Proposed Standard to Standard. Moreover the Abstract describes the scope in a rather non-commital manner (suggests one method for ... the report generator ... to redact or elide the sensitive portions of the message) - so this looks like a recommendation about one (good way) to perform redaction, but not the <standard way> of doing it. 2. I know too little about the operational model of configuring a report generator, so I was left wondering how are the first two recommendations implemented in practice: > 1. Select an arbitrary string that will be used by an Administrative Management Domain (ADMD) that generates reports. This string will not be changed except according to a key rotation policy or similar. Call this the "redaction key". > 2. Identify string(s) (such as local-parts of email addresses) in a message that need to be redacted. Call these strings the "private data". Some text that clarifies how this is supposed to be implemented and configured in practice would be useful. |
|
2012-01-17
|
08 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-16
|
08 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-15
|
08 | Stephen Farrell | [Ballot comment] - I don't get why this is not informational - where's the interop consequence? - While the idea of only listing JD is … [Ballot comment] - I don't get why this is not informational - where's the interop consequence? - While the idea of only listing JD is laudable, I think having a concactable author is best so I'd suggest Murray be kept as an author. - Last para of section 1 - such correlation is not theoretical, delete that word. |
|
2012-01-15
|
08 | Stephen Farrell | [Ballot discuss] (Updated-discuss - thought about it a bit more;-) (1) The construct here is output=H(redaction-key|sensitve-value). I don't think that's ok. I think you want … [Ballot discuss] (Updated-discuss - thought about it a bit more;-) (1) The construct here is output=H(redaction-key|sensitve-value). I don't think that's ok. I think you want HMAC() and not H(). If I could supply a redactor with a zero length "private" string, e.g. message with a header field like "To: @example.org" then the redactor will send H(redaction-key) which can then allow (via hash-continuation) checking if any value matches a value from an output here. If the alphabet for sensitive values has N characters then I can also send "To: "+char[i]+"@example.org" for each i and then play the continuation game on that. Same for two character prefixes etc. (2) I can also use this to validate guesses of the redaction key value. I need to think about how one might avoid that or if its possible to avoid that. |
|
2012-01-15
|
08 | Stephen Farrell | [Ballot comment] - I don't get why this is not informational - where's the interop consequence? - While the idea of only listing JD is … [Ballot comment] - I don't get why this is not informational - where's the interop consequence? - While the idea of only listing JD is laudable, I think having a concactable author is best so I'd suggest Murray be kept as an author. - Last para of section 1 - such correlation is not theoretical, delete that word. |
|
2012-01-15
|
08 | Stephen Farrell | [Ballot discuss] The construct here is output=H(redaction-key|sensitve-value). I don't think that's ok. I think you want HMAC() and not H(). If I could supply a … [Ballot discuss] The construct here is output=H(redaction-key|sensitve-value). I don't think that's ok. I think you want HMAC() and not H(). If I could supply a redactor with a zero length "private" string, e.g. message with a header field like "To: @example.org" then the redactor will send H(redaction-key) which can then allow (via hash-continuation) checking if any value matches a value from an output here. |
|
2012-01-15
|
08 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
|
2012-01-15
|
08 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded |
|
2012-01-13
|
08 | Stewart Bryant | [Ballot comment] I am not a crypto expert, and thus do not know the severity of the attack vector in this case, but isn't there … [Ballot comment] I am not a crypto expert, and thus do not know the severity of the attack vector in this case, but isn't there a plain text attack when encrypted material has a constant string included as seems to be the case here. |
|
2012-01-13
|
08 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-12
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2012-01-12
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2012-01-12
|
08 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
|
2012-01-11
|
08 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-01-11
|
08 | David Black | Request for Last Call review by GENART Completed. Reviewer: David Black. |
|
2012-01-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2012-01-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
|
2012-01-06
|
08 | Mary Barnes | Assignment of request for Last Call review by GENART to Allyn Romanow was rejected |
|
2012-01-04
|
08 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <marf@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-marf-redaction-04.txt> (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Proposed Standard The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' <draft-ietf-marf-redaction-04.txt> as a Proposed Standard Note: This document was previously considered for Informational, but it is now being considered as a Proposed Standard after comments from the previous Last Call. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. [NOTE TO EDITOR: Murray Kucherawy is listed as an author only to enable him to complete the publication process on behalf of J.D. Falk. Please remove Murray from the author list prior to publication.] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ No IPR declarations have been submitted directly on this I-D. |
|
2012-01-04
|
08 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
|
2012-01-04
|
08 | Pete Resnick | Ballot has been issued |
|
2012-01-04
|
08 | Pete Resnick | Created "Approve" ballot |
|
2012-01-04
|
08 | Pete Resnick | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I (Murray Kucherawy) am a co-chair of the MARF working group and the shepherd for this document. I have reviewed all versions of it, and I believe it is ready for IESG review. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document was developed both inside and outside the IETF, mainly within the membership of the Messaging Anti-Abuse Working Group (MAAWG) where the work of the MARF working group originated. I have no concerns about the review it has received, especially as it is not a Standards Track document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? It will receive an automatic SECDIR review, which should complete the reviews I feel are necessary and appropriate. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There is a need for what's in this document to be published as it documents current practice of some members of the feedback loop community. I have no concerns about any part of the document. There are no IPR disclosures. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? MARF is not a large working group, but it has received adequate review from its participants enough that I believe rough consensus has been achieved. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeals have been threatened. The material is non-controversial. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I have personally verified that no ID nits are raised. No pre-IESG formal review criteria need to be met. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references have been so divided. There are no downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This memo has no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No formal languages are used in this memo. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Email messages often contain information which might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was little controversy. This is obviously something needed and is in current use within production feedback loops. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are some existing implementations of feedback loops that follow this process, and others that vary a little because they are earlier implementations which informed this specification. There is certainly consensus within industry that this is an appopropriate specification upon which to converge. |
|
2012-01-04
|
08 | Pete Resnick | Last Call was requested |
|
2012-01-04
|
08 | Pete Resnick | State changed to Last Call Requested from Waiting for AD Go-Ahead. |
|
2012-01-04
|
08 | Pete Resnick | Last Call text changed |
|
2012-01-04
|
08 | Pete Resnick | Intended Status has been changed to Proposed Standard from Informational |
|
2012-01-03
|
04 | (System) | New version available: draft-ietf-marf-redaction-04.txt |
|
2011-12-29
|
08 | Pete Resnick | Telechat date has been changed to 2012-01-19 from 2012-01-05 |
|
2011-12-15
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-12-14
|
08 | Pete Resnick | Placed on agenda for telechat - 2012-01-05 |
|
2011-12-09
|
08 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
|
2011-12-08
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Allyn Romanow |
|
2011-12-08
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Allyn Romanow |
|
2011-12-04
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Julien Laganier |
|
2011-12-04
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Julien Laganier |
|
2011-12-01
|
08 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <marf@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-marf-redaction-03.txt> (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' <draft-ietf-marf-redaction-03.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Email messages often contain information which might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ No IPR declarations have been submitted directly on this I-D. |
|
2011-12-01
|
08 | Pete Resnick | Last Call was requested |
|
2011-12-01
|
08 | Pete Resnick | State changed to Last Call Requested from Publication Requested. |
|
2011-12-01
|
08 | Pete Resnick | Last Call text changed |
|
2011-12-01
|
08 | (System) | Ballot writeup text was added |
|
2011-12-01
|
08 | (System) | Last call text was added |
|
2011-12-01
|
08 | (System) | Ballot approval text was added |
|
2011-11-21
|
08 | Pete Resnick | State changed to Publication Requested from AD is watching. |
|
2011-11-21
|
08 | Murray Kucherawy | IETF state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
|
2011-11-21
|
08 | Murray Kucherawy | Publication requested. |
|
2011-11-21
|
08 | Murray Kucherawy | Annotation tag Doc Shepherd Follow-Up Underway cleared. |
|
2011-11-21
|
03 | (System) | New version available: draft-ietf-marf-redaction-03.txt |
|
2011-11-19
|
08 | Murray Kucherawy | Wrong state |
|
2011-11-19
|
08 | Murray Kucherawy | IETF state changed to Waiting for WG Chair Go-Ahead from Adopted by a WG |
|
2011-11-19
|
08 | Murray Kucherawy | IETF state changed to Adopted by a WG from In WG Last Call |
|
2011-11-19
|
08 | Murray Kucherawy | WGLC completed; review of changes pending |
|
2011-11-19
|
08 | Murray Kucherawy | Annotation tag Doc Shepherd Follow-Up Underway set. |
|
2011-11-19
|
02 | (System) | New version available: draft-ietf-marf-redaction-02.txt |
|
2011-11-17
|
08 | Murray Kucherawy | Changed protocol writeup |
|
2011-11-04
|
08 | Cindy Morgan | WG Last Call Ends 2011-11-18. |
|
2011-11-04
|
08 | Cindy Morgan | IETF state changed to In WG Last Call from WG Document |
|
2011-10-25
|
01 | (System) | New version available: draft-ietf-marf-redaction-01.txt |
|
2011-10-16
|
08 | (System) | Document has expired |
|
2011-10-16
|
08 | (System) | State changed to Dead from AD is watching. |
|
2011-06-10
|
08 | Pete Resnick | Area acronym has been changed to app from gen |
|
2011-06-10
|
08 | Pete Resnick | State changed to AD is watching from Publication Requested. |
|
2011-06-10
|
08 | Pete Resnick | Draft added in state Publication Requested |
|
2011-04-14
|
00 | (System) | New version available: draft-ietf-marf-redaction-00.txt |