Header Protection for Cryptographically Protected E-mail
draft-ietf-lamps-header-protection-25
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-01-22
|
25 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2025-01-22
|
25 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2025-01-22
|
25 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2025-01-14
|
25 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-01-10
|
25 | (System) | RFC Editor state changed to EDIT |
2025-01-10
|
25 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2025-01-10
|
25 | (System) | Announcement was received by RFC Editor |
2025-01-10
|
25 | (System) | IANA Action state changed to In Progress |
2025-01-09
|
25 | (System) | Removed all action holders (IESG state changed) |
2025-01-09
|
25 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2025-01-09
|
25 | Cindy Morgan | IESG has approved the document |
2025-01-09
|
25 | Cindy Morgan | Closed "Approve" ballot |
2025-01-09
|
25 | Cindy Morgan | Ballot approval text was generated |
2025-01-09
|
25 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2025-01-06
|
25 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-25.txt |
2025-01-06
|
25 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2025-01-06
|
25 | Daniel Gillmor | Uploaded new revision |
2024-11-21
|
24 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2024-11-21
|
24 | Paul Wouters | [Ballot comment] Thanks for this document. I hope the length of it does not deter people from implementing it properly by skimming it (as in, … [Ballot comment] Thanks for this document. I hope the length of it does not deter people from implementing it properly by skimming it (as in, I wish it had been shorter) I just have a few comments/nits: Such a Legacy Display Element need not be rendered to the user of an MUA that implements this specification, because the MUA already knows the correct Header Field information, and can render it to the user in the appropriate part of the MUA's user interface rather than in the body of the message. "need not" is not 2119 language. Since the legacy display element can be forged, should this not be a MUST NOT be rendered on non-legacy clients? If a non-structural Header Field name Z is present in Header Section of the Cryptographic Payload, but doesn't appear in an HP-Outer Header Field value at all, then the sender is effectively asserting that every instance of Z was made confidential Should this say something that thus, if a Header Field name Z is present in the outer Header Section, that it means it is forged and/or added by an MTA, not the MUA? And maybe MUST NOT be rendered in any way? (section 4 states this somewhat) If the signature fails validation, the MUA lowers the affected state to unprotected or encrypted-only without warning the user, as specified by Section 3.1 of [I-D.ietf-lamps-e2e-mail-guidance]. I wonder why a signature failure is not a "warn the user" event? It is not the same as "unprotected", but this document tells people to treat it as such? Section 4.4.2: why not MUSTs instead of SHOULDs ? The algorithm returns a MIME object that is ready to be injected into the mail system. mail message instead of mail system? [I-D.ietf-openpgp-crypto-refresh-13] needs to be updated to RFC 9580 Section 10: Why shouldn't a MUA always alert with a big warning when there is a From mismatch in any way (inner, outer, HP-outer) ? Or could it display something like "Paul Forged Wouters on behave of someone_else@foo.com" Section 12.2 could be written much shorter - the target audience is IANA after all and they are experts in what they do :P NITS: Some combination terms are partially bolded, eg "SPECIFICATION REQUIRED". |
2024-11-21
|
24 | Paul Wouters | [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters |
2024-11-21
|
24 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. |
2024-11-21
|
24 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker |
2024-11-21
|
24 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 Thank you for the work put into this document. It is very well written with … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 Thank you for the work put into this document. It is very well written with an easy to read and useful introduction (the whole section 1). Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Russ Housley for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status (especially in the absence of implementations). I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 1.4 MUA acronym is expanded before first use but not MTA. ## Section 1.8 s/This document describes/This document specifies/ (as its intended status is PS). ## Section 3 A text explaining *WHY* there must be a HCP registry (rather than giving some HPC examples) would be welcome. I fail to see the purpose of the registry. Even section 12.3 does not help a lot. ## Section 3.2.1 Does the use of '[...]' in hcp_baseline() make it trivial to detect (hence potentially block/monitor) protected e-mail messages ? ## Section 8 What is `e-mail ecosystem` ? I.e., some examples or a definition would help the reader. ## Section 8.2 Thanks for hinting to the operational considerations in `Many MTA operators today would ask for additional guarantees about such a message to limit the risks associated with abusive or spammy mail.`. |
2024-11-21
|
24 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2024-11-21
|
24 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2024-11-20
|
24 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2024-11-20
|
24 | David Dong | The expert has approved the Permanent Message Header Field Names registrations with the following comment: Looks fine to me. I’m assuming that the security and … The expert has approved the Permanent Message Header Field Names registrations with the following comment: Looks fine to me. I’m assuming that the security and other detailed technical aspects have been adequately considered by the WG and IESG. |
2024-11-20
|
24 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-11-20
|
24 | Deb Cooley | [Ballot comment] This is not a comment that requires addressing. It is more of an opinion: While this is a complex topic, the authors have … [Ballot comment] This is not a comment that requires addressing. It is more of an opinion: While this is a complex topic, the authors have done a fantastic job to make it clear and understandable. Protected email (signed or signed and encrypted) is sadly a pretty niche idea, let alone protecting the headers that go with it. I would love for this to change, maybe the e2e email guidance draft and this draft will help. |
2024-11-20
|
24 | Deb Cooley | Ballot comment text updated for Deb Cooley |
2024-11-20
|
24 | Deb Cooley | [Ballot comment] While this is a complex topic, the authors have done a fantastic job to make it clear and understandable. Protected email (signed or … [Ballot comment] While this is a complex topic, the authors have done a fantastic job to make it clear and understandable. Protected email (signed or signed and encrypted) is sadly a pretty niche idea, let alone protecting the headers that go with it. I would love for this to change, maybe the e2e email guidance draft and this draft will help. |
2024-11-20
|
24 | Deb Cooley | [Ballot Position Update] New position, Yes, has been recorded for Deb Cooley |
2024-11-19
|
24 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-11-18
|
24 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-11-18
|
24 | Warren Kumari | [Ballot comment] Thank you for this document; much of this is outside my areas of expertise, but it seems reasonable from the bits that I … [Ballot comment] Thank you for this document; much of this is outside my areas of expertise, but it seems reasonable from the bits that I was able to understand :-) I have a few nits to offer: 1: These stumbling blocks with Legacy MUAs, missing mechanisms, and missing guidance create a strong disincentive for existing MUAs generate messages using RFC8551HP. P: "to generate" 2: "A sending implementation MUST NOT produce a Cryptographic Payload with parameter hp="cipher" for an non-encrypted message" P: "for a non-encrypted" 3: "We call such converted version (or the original domain, if it didn't contain any U-label) "the ASCII version of the domain part". P: "We call such a converted" -- I still don't like this. Perhaps "We call a version converted like this (..." ? Sorry I don't have more to offer... |
2024-11-18
|
24 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2024-11-16
|
24 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-11-14
|
24 | Orie Steele | [Ballot comment] I had previously a discuss that was changed to no objection: https://mailarchive.ietf.org/arch/msg/spasm/2jaMNrdHPYFd-Ck-tH9DZrvewIQ/ I reviewed the diff since then: https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-header-protection-21&url2=draft-ietf-lamps-header-protection-24&difftype=--hwdiff I note the IANA … [Ballot comment] I had previously a discuss that was changed to no objection: https://mailarchive.ietf.org/arch/msg/spasm/2jaMNrdHPYFd-Ck-tH9DZrvewIQ/ I reviewed the diff since then: https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-header-protection-21&url2=draft-ietf-lamps-header-protection-24&difftype=--hwdiff I note the IANA review is still needed. |
2024-11-14
|
24 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2024-11-14
|
24 | Gunter Van de Velde | [Ballot comment] There is an IANA not OK statement which i assume will be addressed timely |
2024-11-14
|
24 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2024-11-12
|
24 | David Dong | IANA Experts State changed to Reviews assigned from Expert Reviews OK |
2024-11-11
|
24 | Roman Danyliw | Placed on agenda for telechat - 2024-11-21 |
2024-11-11
|
24 | Roman Danyliw | Ballot has been issued |
2024-11-11
|
24 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2024-11-11
|
24 | Roman Danyliw | Ballot writeup was changed |
2024-11-11
|
24 | Roman Danyliw | Ballot approval text was generated |
2024-11-11
|
24 | Roman Danyliw | Created "Approve" ballot |
2024-11-11
|
24 | Roman Danyliw | Closed "Approve" ballot |
2024-11-11
|
24 | Roman Danyliw | Ballot has been issued |
2024-11-11
|
24 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-11-11
|
24 | Roman Danyliw | Ballot writeup was changed |
2024-11-11
|
24 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-11-09
|
24 | Russ Mundy | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Russ Mundy. Sent review to list. Submission of review completed at an earlier date. |
2024-11-09
|
24 | Russ Mundy | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Russ Mundy. |
2024-11-08
|
24 | David Dong | IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lamps-header-protection-24. If any part of this review is inaccurate, please let us know. IANA understands that, upon … IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lamps-header-protection-24. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are three actions which we must complete. First, in the Permanent Message Header Field Names registry in the Message Headers registry group located at: https://www.iana.org/assignments/message-headers/ one new Header Field will be registered as follows: Header Field Name: HP-Outer Template: Protocol: mail Status: standard Reference: [ RFC-to-be; Section 2.2.1 ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, also in the Permanent Message Header Field Names registry in the Message Headers registry group located at: https://www.iana.org/assignments/message-headers/ the existing registration for: Header Field Name: Content-Type Template: Protocol: MIME Status: Reference: [ RFC4021 ] will have [ RFC-to-be ] added to the reference as follows: Header Field Name: Content-Type Template: Protocol: MIME Status: Reference: [ RFC4021 ][ RFC-to-be ] Third, a new registry is to be created called the Mail Header Confidentiality Policies registry. The new registry will be located in the MAIL Parameters registry group located at: https://www.iana.org/assignments/mail-parameters/ The new registry will be managed via the following registry policy: Adding an entry to this registry with an N in the "Recommended" column follows the registration policy of Specification Required. Adding an entry to this registry with a Y in the "Recommended" column or changing the "Recommended" column in an existing entry (from N to Y or vice versa) requires IETF Review. During IETF Review, the designated expert must also be consulted. A note will be added to the registry as follows: The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 2.4.4.1 of [ RFC-to-be ]. There are initial registrations in the new registry as follows: Header Confidentiality Policy Name Description Reference Recommended -------------+----------+----------+--------------- hcp_no_confidentiality No header confidentiality Section 3.2.3 of [RFC-to-be] N hcp_baseline Confidentiality for Informational Header Fields: Subject Header Field is obscured, Keywords and Comments are removed Section 3.2.1 of [RFC-to-be] Y hcp_shy Obscure Subject, remove Keywords and Comments, remove the time zone from Date, and obscure display-names Section 3.2.2 of [RFC-to-be] N We understand that these are the only actions required to be completed upon approval of this document. NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-11-08
|
24 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2024-10-21
|
24 | Liz Flynn | The following Last Call announcement was sent out (ends 2024-11-11): From: The IESG To: IETF-Announce CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org … The following Last Call announcement was sent out (ends 2024-11-11): From: The IESG To: IETF-Announce CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Header Protection for Cryptographically Protected E-mail) to Proposed Standard The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Header Protection for Cryptographically Protected E-mail' as Proposed Standard 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 last-call@ietf.org mailing lists by 2024-11-11. 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 S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. The Header Protection scheme defined here is also applicable to messages with PGP/MIME cryptographic protections. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-lamps-e2e-mail-guidance: Guidance on End-to-End E-mail Security (None - Internet Engineering Task Force (IETF) stream) |
2024-10-21
|
24 | Liz Flynn | IESG state changed to In Last Call from Last Call Requested |
2024-10-21
|
24 | Liz Flynn | Last call announcement was changed |
2024-10-21
|
24 | Liz Flynn | Last call announcement was generated |
2024-10-18
|
24 | Roman Danyliw | Last call was requested |
2024-10-18
|
24 | Roman Danyliw | IESG state changed to Last Call Requested from Publication Requested |
2024-10-16
|
24 | Cindy Morgan | # Shepherd Write-up for draft-ietf-lamps-header-protection-18 ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with … # Shepherd Write-up for draft-ietf-lamps-header-protection-18 ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There is support in the LAMPS WG for this document. It was developed over many years, with discussion at almost every IETF meeting during that period. There were several points where people were aske to try things at home, but only a few active LAMPS WG participants were willing to do the homework. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was little controversy, and suggested improvements were readily accepted by the authors. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There has been some code written, but so far, vendors of major email user agents have not said whether they will implement. One did offer insightful review of the Internet-Draft during WG Last Call. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. We are expecting more review from the email community during IETF Last Call, including the ART-ART review. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No special reviews are needed. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? This document does not include a YANG module. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. ABNF is used. It was checked with BAP. The definition for obs-utext is imported from RFC 5322, but BAP does not like the NULL (0x00) that is allowed in the obsolete definition. Other tools might tolerate NULL that is embedded in the string to be parsed. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? No concerns were noticed. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? As reflected in the Datatracker: Proposed Standard on the IETF Stream. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. No IPR disclosures were issued against this document. The authors have explicitly stated that he is unaware of any IPR that needs to be declared. The authors have explicitly stated that he do not hold any IPR related to this document. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are many lines with non-ASCII characters. This is intentional, and the authors are prepared to work with the RFC Editor to ensure that the publication formats produce appropriate output. IDnits complains about the authors initials in square brackets in Appendix E. This will not appear in the RFC, so these warnings were ignored. IDnits recommends ' ' and ' |
2024-10-16
|
24 | Cindy Morgan | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-10-16
|
24 | Cindy Morgan | IESG state changed to Publication Requested from Waiting for AD Go-Ahead |
2024-10-16
|
24 | Russ Housley | Tag External Party cleared. |
2024-10-16
|
24 | Russ Housley | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2024-09-09
|
24 | Roman Danyliw | Waiting for WGLC to finish: https://mailarchive.ietf.org/arch/msg/spasm/WDNlqYxh1v0Ixj_KW7idKRiAgCo/ |
2024-09-09
|
24 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead |
2024-09-09
|
24 | Roman Danyliw | Additional WGLC: https://mailarchive.ietf.org/arch/msg/spasm/WDNlqYxh1v0Ixj_KW7idKRiAgCo/ |
2024-09-05
|
24 | Russ Housley | Tags Revised I-D Needed - Issue raised by IESG, External Party cleared. |
2024-09-04
|
24 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-24.txt |
2024-09-04
|
24 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2024-09-04
|
24 | Daniel Gillmor | Uploaded new revision |
2024-07-24
|
23 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-23.txt |
2024-07-24
|
23 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2024-07-24
|
23 | Daniel Gillmor | Uploaded new revision |
2024-07-23
|
22 | Roman Danyliw | WG is conducting an LC. This will determine the next step. |
2024-07-23
|
22 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead |
2024-07-15
|
22 | Carlos Pignataro | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2024-07-15
|
22 | Carlos Pignataro | Assignment of request for Last Call review by OPSDIR to Ron Bonica was marked no-response |
2024-07-09
|
22 | Russ Housley | Tag Revised I-D Needed - Issue raised by IESG set. Tag External Party cleared. |
2024-07-09
|
22 | Russ Housley | IETF WG state changed to In WG Last Call from Submitted to IESG for Publication |
2024-07-04
|
22 | Roman Danyliw | Removed from agenda for telechat |
2024-07-04
|
22 | Roman Danyliw | Post PubReq/IETF LC check with the WG: https://mailarchive.ietf.org/arch/msg/spasm/eCq92sAyLrk1sauMnXwo2g11mqY/ |
2024-07-04
|
22 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::External Party from IESG Evaluation |
2024-07-01
|
22 | Orie Steele | [Ballot comment] draft -22 addressed my discuss, the remaining comments are non blocking so I have changed my position to no objection. |
2024-07-01
|
22 | Orie Steele | [Ballot Position Update] Position for Orie Steele has been changed to No Objection from Discuss |
2024-06-27
|
22 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-22.txt |
2024-06-27
|
22 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2024-06-27
|
22 | Daniel Gillmor | Uploaded new revision |
2024-06-25
|
21 | Orie Steele | [Ballot discuss] # Orie Steele, ART AD, comments for draft-ietf-lamps-header-protection-21 CC @OR13 https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-header-protection-21.txt&submitcheck=True Thanks to Bron Gondwana for the ART ART review. I would like … [Ballot discuss] # Orie Steele, ART AD, comments for draft-ietf-lamps-header-protection-21 CC @OR13 https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-header-protection-21.txt&submitcheck=True Thanks to Bron Gondwana for the ART ART review. I would like to see his comments regarding multi-valued headers answered. Does this document not apply to structural headers, and perhaps therefore not apply to multi-valued headers? The term "non-structural" headers is repeated several times, perhaps a brief comment on this in the introduction could be helpful. |
2024-06-25
|
21 | Orie Steele | [Ballot comment] ## Comments ### What does mistake mean here? ``` 734 A receiving implementation MUST NOT mistake the presence of an 735 … [Ballot comment] ## Comments ### What does mistake mean here? ``` 734 A receiving implementation MUST NOT mistake the presence of an 735 hp="cipher" parameter in the Cryptographic Payload for the actual 736 presence of a Cryptographic Layer that provides encryption. ``` Its not clear (to me) what this sentence does for interoperability. ### Can we be more PRECIS regarding what is allowed in val_out? ``` 872 The HCP can compute val_out using any technique describable in 873 pseudocode, such as copying a fixed string or invocations of other 874 pseudocode functions. If it alters the value, it MUST NOT include 875 control or NUL characters in val_out. val_out SHOULD match the 876 expected ABNF for the Header Field identified by name. ``` Consider if a references to https://datatracker.ietf.org/doc/rfc8264/ would be helpful here. ### Clearer phrasing? ``` 904 If a non-structural Header Field name A doesn't appear in an HP-Outer 905 Header Field value, then the sender is effectively asserting it was 906 not set on the outside of the message's Cryptographic Envelope by the 907 original message sender at the time the message was injected into the 908 mail system. ``` I think this could be rephrased to be clearer, starting with "By ommiting an HP-Outer Header Field, the sender asserts no protection for ... at the time the message is injected into the mail system. ### Add a section reference "unstructured" ``` 919 Note that hp-outer-value is the same as unstructured from [RFC5322], 920 but without the obsolete obs-unstructured option. ``` I can't find a reference to "obs-unstructured" in RFC5322, or RFC6854. ## Nits ### Should this be normative? ``` 1453 Note that the Header Confidentiality Policy hcp parameter is 1454 effectively ignored if crypto does not contain encryption. This is 1455 by design, because a signed-only message cannot provide 1456 confidentiality. ``` MUST be ignored when ... ? ### Define MUA on first use ``` 286 This document describes two different schemes for how message headers 287 can be cryptographically protected, and provides guidance for 288 implementers of MUAs that generate and interpret such messages. It ``` ### missing "the" ? ``` 388 extent possible. In some cases, like when a user-visible header like 389 the Subject is cryptographically hidden, a Legacy MUA will not be 390 able to render or reply to the message exactly same way as a 391 conformant MUA would. But accommodations are described here that ``` ### better word than yanked? ``` 2222 [...]. Or the message might be yanked out of its current thread if 2223 the MUA loses access to a removed References or In-Reply-To header. ``` ### better word than mooted? ``` 2836 hcp_example_hide_cc is mooted as an example in Section 2.5.2 but is 2837 not formally registered by this document. ``` |
2024-06-25
|
21 | Orie Steele | [Ballot Position Update] New position, Discuss, has been recorded for Orie Steele |
2024-06-13
|
21 | Roman Danyliw | Placed on agenda for telechat - 2024-07-11 |
2024-06-13
|
21 | Roman Danyliw | Ballot has been issued |
2024-06-13
|
21 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2024-06-13
|
21 | Roman Danyliw | Created "Approve" ballot |
2024-06-13
|
21 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2024-06-13
|
21 | Roman Danyliw | Ballot writeup was changed |
2024-06-13
|
21 | Roman Danyliw | Ballot approval text was generated |
2024-06-03
|
21 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-06-03
|
21 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-06-03
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-06-03
|
21 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-21.txt |
2024-06-03
|
21 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2024-06-03
|
21 | Daniel Gillmor | Uploaded new revision |
2024-04-12
|
20 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. |
2024-03-25
|
20 | Roman Danyliw | Please review and revise per ARTART IETC LC review. |
2024-03-25
|
20 | (System) | Changed action holders to Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov (IESG state changed) |
2024-03-25
|
20 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2024-03-25
|
20 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-03-18
|
20 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2024-03-18
|
20 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-03-17
|
20 | Bron Gondwana | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. Sent review to list. Submission of review completed at an earlier … Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. Sent review to list. Submission of review completed at an earlier date. |
2024-03-17
|
20 | Bron Gondwana | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. |
2024-03-13
|
20 | David Dong | IANA Experts State changed to Reviews assigned |
2024-03-13
|
20 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2024-03-13
|
20 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lamps-header-protection-20. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lamps-header-protection-20. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are three actions which we must complete. First, in the Permanent Message Header Field Names registry in the Message Headers registry group located at: https://www.iana.org/assignments/message-headers/ two new Header Fields will be registered as follows: Header Field Name: HP-Removed Template: Protocol: mail Status: standard Reference: [ RFC-to-be; Section 2.3.3 ] Header Field Name: HP-Obscured Template: Protocol: mail Status: standard Reference: [ RFC-to-be; Section 2.3.3 ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, also in the Permanent Message Header Field Names registry in the Message Headers registry group located at: https://www.iana.org/assignments/message-headers/ the existing registration for: Header Field Name: Content-Type Template: Protocol: MIME Status: Reference: [ RFC4021 ] will have [ RFC-to-be ] added to the reference as follows: Header Field Name: Content-Type Template: Protocol: MIME Status: Reference: [ RFC4021 ][ RFC-to-be ] Third, a new registry is to be created called the Mail Header Confidentiality Policies registry. The new registry will be located in the MAIL Parameters registry group located at: https://www.iana.org/assignments/mail-parameters/ The new registry will be managed via the following registry policy: Adding an entry to this registry with an N in the "Recommended" column follows the registration policy of Specification Required. Adding an entry to this registry with a Y in the "Recommended" column or changing the "Recommended" column in an existing entry (from N to Y or vice versa) requires IETF Review. During IETF Review, the designated expert must also be consulted. A note will be added to the registry as follows: The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 2.4.4.1 of [ RFC-to-be ]. There are initial registrations in the new registry as follows: Header Confidentiality Policy Name Description Reference Recommended ------------+-----------+----------+------------ hcp_null No header confidentiality [ RFC-to-be ] N hcp_minimal Subject Header Field is obscured [ RFC-to-be ] Y hcp_strong Remove or obscure everything but From, Date, To, and Cc [ RFC-to-be ] N hcp_hide_cc Obscure Subject, remove Cc [ RFC-to-be ] N We understand that these are the only actions required to be completed upon approval of this document. NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-03-08
|
20 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2024-03-07
|
20 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2024-03-06
|
20 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Ron Bonica |
2024-03-05
|
20 | Barry Leiba | Request for Last Call review by ARTART is assigned to Bron Gondwana |
2024-03-04
|
20 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2024-03-04
|
20 | Cindy Morgan | The following Last Call announcement was sent out (ends 2024-03-25): From: The IESG To: IETF-Announce CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org … The following Last Call announcement was sent out (ends 2024-03-25): From: The IESG To: IETF-Announce CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Header Protection for Cryptographically Protected E-mail) to Proposed Standard The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Header Protection for Cryptographically Protected E-mail' as Proposed Standard 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 last-call@ietf.org mailing lists by 2024-03-25. 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 S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification ([RFC8551]) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. The Header Protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-lamps-e2e-mail-guidance: Guidance on End-to-End E-mail Security (None - Internet Engineering Task Force (IETF)) draft-ietf-lamps-header-protection-requirements: Problem Statement and Requirements for Header Protection (None - Internet Engineering Task Force (IETF)) |
2024-03-04
|
20 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-03-04
|
20 | Cindy Morgan | Last call announcement was changed |
2024-03-04
|
20 | Roman Danyliw | Last call was requested |
2024-03-04
|
20 | Roman Danyliw | Last call announcement was generated |
2024-03-04
|
20 | Roman Danyliw | Ballot approval text was generated |
2024-03-04
|
20 | Roman Danyliw | Ballot writeup was generated |
2024-03-04
|
20 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2024-03-01
|
20 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-20.txt |
2024-03-01
|
20 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2024-03-01
|
20 | Daniel Gillmor | Uploaded new revision |
2024-02-13
|
19 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-02-13
|
19 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-02-13
|
19 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-19.txt |
2024-02-13
|
19 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2024-02-13
|
19 | Daniel Gillmor | Uploaded new revision |
2024-01-26
|
18 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/spasm/sXJmFS5w7EQy-Y-SNWx_j4nxnic/ |
2024-01-26
|
18 | (System) | Changed action holders to Roman Danyliw, Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov (IESG state changed) |
2024-01-26
|
18 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2023-12-08
|
18 | Russ Housley | # Shepherd Write-up for draft-ietf-lamps-header-protection-18 ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with … # Shepherd Write-up for draft-ietf-lamps-header-protection-18 ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There is support in the LAMPS WG for this document. It was developed over many years, with discussion at almost every IETF meeting during that period. There were several points where people were aske to try things at home, but only a few active LAMPS WG participants were willing to do the homework. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was little controversy, and suggested improvements were readily accepted by the authors. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There has been some code written, but so far, vendors of major email user agents have not said whether they will implement. One did offer insightful review of the Internet-Draft during WG Last Call. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. We are expecting more review from the email community during IETF Last Call, including the ART-ART review. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No special reviews are needed. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? This document does not include a YANG module. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. ABNF is used. It was checked with BAP. The definition for obs-utext is imported from RFC 5322, but BAP does not like the NULL (0x00) that is allowed in the obsolete definition. Other tools might tolerate NULL that is embedded in the string to be parsed. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? No concerns were noticed. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? As reflected in the Datatracker: Proposed Standard on the IETF Stream. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. No IPR disclosures were issued against this document. The authors have explicitly stated that he is unaware of any IPR that needs to be declared. The authors have explicitly stated that he do not hold any IPR related to this document. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are many lines with non-ASCII characters. This is intentional, and the authors are prepared to work with the RFC Editor to ensure that the publication formats produce appropriate output. IDnits complains about the authors initials in square brackets in Appendix E. This will not appear in the RFC, so these warnings were ignored. IDnits recommends ' ' and ' |
2023-12-08
|
18 | Russ Housley | Responsible AD changed to Roman Danyliw |
2023-12-08
|
18 | Russ Housley | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2023-12-08
|
18 | Russ Housley | IESG state changed to Publication Requested from I-D Exists |
2023-12-08
|
18 | Russ Housley | Document is now in IESG state Publication Requested |
2023-12-08
|
18 | Russ Housley | # Shepherd Write-up for draft-ietf-lamps-header-protection-18 ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with … # Shepherd Write-up for draft-ietf-lamps-header-protection-18 ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There is support in the LAMPS WG for this document. It was developed over many years, with discussion at almost every IETF meeting during that period. There were several points where people were aske to try things at home, but only a few active LAMPS WG participants were willing to do the homework. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was little controversy, and suggested improvements were readily accepted by the authors. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There has been some code written, but so far, vendors of major email user agents have not said whether they will implement. One did offer insightful review of the Internet-Draft during WG Last Call. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. We are expecting more review from the email community during IETF Last Call, including the ART-ART review. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No special reviews are needed. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? This document does not include a YANG module. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. ABNF is used. It was checked with BAP. The definition for obs-utext is imported from RFC 5322, but BAP does not like the NULL (0x00) that is allowed in the obsolete definition. Other tools might tolerate NULL that is embedded in the string to be parsed. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? No concerns were noticed. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? As reflected in the Datatracker: Proposed Standard on the IETF Stream. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. No IPR disclosures were issued against this document. The authors have explicitly stated that he is unaware of any IPR that needs to be declared. The authors have explicitly stated that he do not hold any IPR related to this document. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are many lines with non-ASCII characters. This is intentional, and the authors are prepared to work with the RFC Editor to ensure that the publication formats produce appropriate output. IDnits complains about the authors initials in square brackets in Appendix E. This will not appear in the RFC, so these warnings were ignored. IDnits recommends ' ' and ' |
2023-12-08
|
18 | Russ Housley | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2023-11-30
|
18 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-18.txt |
2023-11-30
|
18 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-11-30
|
18 | Daniel Gillmor | Uploaded new revision |
2023-10-17
|
17 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-17.txt |
2023-10-17
|
17 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-10-17
|
17 | Daniel Gillmor | Uploaded new revision |
2023-09-13
|
16 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-16.txt |
2023-09-13
|
16 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-09-13
|
16 | Daniel Gillmor | Uploaded new revision |
2023-07-23
|
15 | Russ Housley | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2023-07-03
|
15 | Russ Housley | Tag Revised I-D Needed - Issue raised by WGLC set. |
2023-04-26
|
15 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-15.txt |
2023-04-26
|
15 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-04-26
|
15 | Daniel Gillmor | Uploaded new revision |
2023-04-07
|
14 | Russ Housley | Changed consensus to Yes from Unknown |
2023-04-07
|
14 | Russ Housley | Intended Status changed to Proposed Standard from None |
2023-04-07
|
14 | Russ Housley | Notification list changed to housley@vigilsec.com because the document shepherd was set |
2023-04-07
|
14 | Russ Housley | Document shepherd changed to Russ Housley |
2023-04-07
|
14 | Russ Housley | IETF WG state changed to In WG Last Call from WG Document |
2023-04-06
|
14 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-14.txt |
2023-04-06
|
14 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-04-06
|
14 | Daniel Gillmor | Uploaded new revision |
2023-03-21
|
13 | Russ Housley | Added to session: IETF-116: lamps Wed-0030 |
2023-03-10
|
13 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-13.txt |
2023-03-10
|
13 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-03-10
|
13 | Daniel Gillmor | Uploaded new revision |
2023-03-08
|
12 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-12.txt |
2023-03-08
|
12 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-03-08
|
12 | Daniel Gillmor | Uploaded new revision |
2023-01-24
|
11 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-11.txt |
2023-01-24
|
11 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2023-01-24
|
11 | Daniel Gillmor | Uploaded new revision |
2022-12-20
|
10 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-10.txt |
2022-12-20
|
10 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2022-12-20
|
10 | Daniel Gillmor | Uploaded new revision |
2022-11-22
|
09 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-09.txt |
2022-11-22
|
09 | Daniel Gillmor | New version accepted (logged-in submitter: Daniel Gillmor) |
2022-11-22
|
09 | Daniel Gillmor | Uploaded new revision |
2022-09-08
|
08 | (System) | Document has expired |
2022-03-07
|
08 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-08.txt |
2022-03-07
|
08 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
2022-03-07
|
08 | Daniel Gillmor | Uploaded new revision |
2022-02-02
|
07 | Russ Housley | Changed document external resources from: None to: mailing_list https://www.ietf.org/mailman/listinfo/spasm mailing_list_archive https://mailarchive.ietf.org/arch/browse/spasm/ repo https://gitlab.com/dkg/lamps-header-protection.git tracker https://gitlab.com/dkg/lamps-header-protection/-/issues |
2022-02-02
|
07 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-07.txt |
2022-02-02
|
07 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
2022-02-02
|
07 | Daniel Gillmor | Uploaded new revision |
2022-01-27
|
06 | (System) | Document has expired |
2021-07-26
|
06 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-06.txt |
2021-07-26
|
06 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
2021-07-26
|
06 | Daniel Gillmor | Uploaded new revision |
2021-07-06
|
05 | Russ Housley | Added to session: IETF-111: lamps Thu-1500 |
2021-05-27
|
05 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-05.txt |
2021-05-27
|
05 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
2021-05-27
|
05 | Daniel Gillmor | Uploaded new revision |
2021-05-21
|
04 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-04.txt |
2021-05-21
|
04 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
2021-05-21
|
04 | Daniel Gillmor | Uploaded new revision |
2021-02-22
|
03 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-03.txt |
2021-02-22
|
03 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
2021-02-22
|
03 | Daniel Gillmor | Uploaded new revision |
2020-11-10
|
02 | Russ Housley | Added to session: IETF-109: lamps Tue-1600 |
2020-11-02
|
02 | Bernie Hoeneisen | New version available: draft-ietf-lamps-header-protection-02.txt |
2020-11-02
|
02 | (System) | New version approved |
2020-11-02
|
02 | (System) | Request for posting confirmation emailed to previous authors: Daniel Gillmor , Alexey Melnikov , Bernie Hoeneisen |
2020-11-02
|
02 | Bernie Hoeneisen | Uploaded new revision |
2020-11-02
|
01 | Daniel Gillmor | New version available: draft-ietf-lamps-header-protection-01.txt |
2020-11-02
|
01 | (System) | New version approved |
2020-11-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: Alexey Melnikov , lamps-chairs@ietf.org, Bernie Hoeneisen |
2020-11-02
|
01 | Daniel Gillmor | Uploaded new revision |
2020-07-13
|
00 | Bernie Hoeneisen | New version available: draft-ietf-lamps-header-protection-00.txt |
2020-07-13
|
00 | (System) | New version accepted (logged-in submitter: Bernie Hoeneisen) |
2020-07-13
|
00 | Bernie Hoeneisen | Uploaded new revision |