S/MIME Example Keys and Certificates
RFC 9216
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2022-04-21
|
08 | (System) | Received changes through RFC Editor sync (created alias RFC 9216, changed abstract to 'The S/MIME development community benefits from sharing samples of signed or … Received changes through RFC Editor sync (created alias RFC 9216, changed abstract to 'The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples.', changed pages to 32, changed standardization level to Informational, changed state to RFC, added RFC published event at 2022-04-21, changed IESG state to RFC Published) |
|
2022-04-21
|
08 | (System) | RFC published |
|
2022-04-07
|
08 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9216">AUTH48-DONE</a> from AUTH48 |
|
2022-03-15
|
08 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9216">AUTH48</a> |
|
2022-03-01
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2022-02-07
|
08 | (System) | RFC Editor state changed to EDIT |
|
2022-02-07
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2022-02-07
|
08 | (System) | Announcement was received by RFC Editor |
|
2022-02-07
|
08 | (System) | IANA Action state changed to No IANA Actions from In Progress |
|
2022-02-07
|
08 | (System) | IANA Action state changed to In Progress |
|
2022-02-07
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2022-02-07
|
08 | Amy Vezza | IESG has approved the document |
|
2022-02-07
|
08 | Amy Vezza | Closed "Approve" ballot |
|
2022-02-07
|
08 | Amy Vezza | Ballot approval text was generated |
|
2022-02-06
|
08 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2022-02-02
|
08 | (System) | Removed all action holders (IESG state changed) |
|
2022-02-02
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2022-02-02
|
08 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-08.txt |
|
2022-02-02
|
08 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2022-02-02
|
08 | Daniel Gillmor | Uploaded new revision |
|
2022-01-06
|
07 | (System) | Changed action holders to Daniel Gillmor (IESG state changed) |
|
2022-01-06
|
07 | Amy Vezza | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2022-01-06
|
07 | Amy Vezza | Changed consensus to Yes from Unknown |
|
2022-01-06
|
07 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
|
2022-01-06
|
07 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
|
2022-01-05
|
07 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2022-01-05
|
07 | Murray Kucherawy | [Ballot comment] I agree with Benjamin that it doesn't seem like RFC 5322 needs to be normative here. |
|
2022-01-05
|
07 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
|
2022-01-05
|
07 | Benjamin Kaduk | [Ballot comment] Thanks for producing these; they should be really useful for future development and testing. Should we say that the private keys are represented … [Ballot comment] Thanks for producing these; they should be really useful for future development and testing. Should we say that the private keys are represented as the RFC 5958/PKCS#8 structure, and that the RFC 8479 validation parameters attribute is included? At least, I think that's what it looks like... Section 13.1 It's not really clear to me that RFC 5322 needs to be classified as normative. Section 13.2 RFC 7468 seems like it ought to be classified as normative, since it specifies the formats we use. |
|
2022-01-05
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
|
2022-01-05
|
07 | Robert Wilton | [Ballot comment] Hi, Only one minor nit on the security considerations: Any application which maintains a denylist of invalid key material SHOULD include … [Ballot comment] Hi, Only one minor nit on the security considerations: Any application which maintains a denylist of invalid key material SHOULD include these keys in its list. Having this as a SHOULD seemed very broad to me, I would suggest "recommended to" instead. Regards, Rob |
|
2022-01-05
|
07 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2022-01-03
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2022-01-03
|
07 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Congrats to use UTF-8 charset for some nice graphics and for the example names. … [Ballot comment] Thank you for the work put into this document. Congrats to use UTF-8 charset for some nice graphics and for the example names. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tim Hollebeek for the shepherd's write-up including the section about the WG consensus (even if very terse). I hope that this helps to improve the document, Regards, -éric -- Section 2.2 & 2.3 -- Would it be useful to include expired certificates ? And/or a CRL for those examples ? Would providing those additional examples make possible more extensive testing? -- Section 4 -- <joke>Please s/Alice Lovelace/Ada Lovelace/ ;-) </joke> (to be ignored of course but I could not resist) Alas not applicable to Charles/Bob Babbage or Alan/Carlos Turing or Grace/Dana Hopper :-) |
|
2022-01-03
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
|
2022-01-03
|
07 | Lars Eggert | [Ballot comment] Thanks to Stewart Bryant for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/mflhoJqZWKiXwKjyiy2xzxTsVj4). ------------------------------------------------------------------------------- All comments below are about very minor … [Ballot comment] Thanks to Stewart Bryant for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/mflhoJqZWKiXwKjyiy2xzxTsVj4). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.3. , paragraph 3, nit: - (see the CRL Disttribution Points X.509 extension as defined in - - |
|
2022-01-03
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
|
2021-12-30
|
07 | Barry Leiba | Closed request for Last Call review by ARTART with state 'Overtaken by Events': No reviewer response |
|
2021-12-30
|
07 | Barry Leiba | Assignment of request for Last Call review by ARTART to Matthew Miller was marked no-response |
|
2021-12-23
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2021-12-13
|
07 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-07.txt |
|
2021-12-13
|
07 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2021-12-13
|
07 | Daniel Gillmor | Uploaded new revision |
|
2021-12-13
|
06 | Cindy Morgan | Placed on agenda for telechat - 2022-01-06 |
|
2021-12-13
|
06 | Roman Danyliw | Ballot has been issued |
|
2021-12-13
|
06 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
|
2021-12-13
|
06 | Roman Danyliw | Created "Approve" ballot |
|
2021-12-13
|
06 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2021-12-13
|
06 | Roman Danyliw | Ballot writeup was changed |
|
2021-12-13
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2021-12-13
|
06 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-06.txt |
|
2021-12-13
|
06 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2021-12-13
|
06 | Daniel Gillmor | Uploaded new revision |
|
2021-11-26
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2021-11-16
|
05 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list. |
|
2021-11-16
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
|
2021-11-16
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
|
2021-11-12
|
05 | Derrell Piper | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derrell Piper. Sent review to list. |
|
2021-11-11
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2021-11-11
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-lamps-samples-05, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-lamps-samples-05, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
|
2021-11-09
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
|
2021-11-09
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
|
2021-11-08
|
05 | Barry Leiba | Request for Last Call review by ARTART is assigned to Matthew Miller |
|
2021-11-08
|
05 | Barry Leiba | Request for Last Call review by ARTART is assigned to Matthew Miller |
|
2021-11-05
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derrell Piper |
|
2021-11-05
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derrell Piper |
|
2021-11-05
|
05 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2021-11-05
|
05 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-11-26):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-lamps-samples@ietf.org, housley@vigilsec.com, … The following Last Call announcement was sent out (ends 2021-11-26):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-lamps-samples@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org, tim.hollebeek@digicert.com Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-lamps-samples-05.txt> (S/MIME Example Keys and Certificates) to Informational RFC The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'S/MIME Example Keys and Certificates' <draft-ietf-lamps-samples-05.txt> as 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 last-call@ietf.org mailing lists by 2021-11-26. 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 The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-samples/ No IPR declarations have been submitted directly on this I-D. |
|
2021-11-05
|
05 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2021-11-05
|
05 | Cindy Morgan | Last call announcement was changed |
|
2021-11-05
|
05 | Cindy Morgan | Last call announcement was changed |
|
2021-11-04
|
05 | Roman Danyliw | Last call was requested |
|
2021-11-04
|
05 | Roman Danyliw | Last call announcement was generated |
|
2021-11-04
|
05 | Roman Danyliw | Ballot approval text was generated |
|
2021-11-04
|
05 | Roman Danyliw | Ballot writeup was generated |
|
2021-11-04
|
05 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
|
2021-11-04
|
05 | Roman Danyliw | IESG state changed to Last Call Requested from Publication Requested |
|
2021-11-04
|
05 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/spasm/pZy4Se2G9XSQUc0uUzckn_SGl1E/ |
|
2021-10-29
|
05 | Tim Hollebeek | Shepherd Write-up for draft-ietf-lamps-samples-05 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … Shepherd Write-up for draft-ietf-lamps-samples-05 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. As the RFC simply provides examples, this is appropriate. (2) 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: The S/MIME ([RFC8551]) development community, in particular the e-mail development community, benefits from sharing samples of signed and/or encrypted data. Often the exact key material used does not matter because the properties being tested pertain to implementation correctness, completeness or interoperability of the overall system. However, without access to the relevant secret key material, a sample is useless. This document defines a small set of X.509v3 certificates ([RFC5280]) and secret keys for use when generating or operating on such samples. Working Group Summary: There is consensus for this document in the LAMPS WG. Document Quality: The document is well-written and easy to understand. Personnel: Tim Hollebeek is the document shepherd. Roman Danyliw is the responsible area director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd and other LAMPS WG participants reviewed the document during WG Last Call. All issues raised have been resolved. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No special review needed. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The author has explicitly stated that he is unaware of any additional IP that was introduced in the updates to the document. The author has explicitly stated that he does not hold any IPR related to the document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been submitted against this Internet-Draft. (9) 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? There is consensus for this document in the LAMPS WG. (10) 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 publicly available.) No one has threatened an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IDNits review reports a few long lines due to ASCII tables around line 260. They look fine in a text editor, and I'm unsure if this is a false positive or something that needs to be fixed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None needed. (13) Have all references within this document been identified as either normative or informative? Yes, the references are divided into normative and informative. (14) 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 plan for their completion? All references are already published. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. It will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not require any work from IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries are needed. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document does not contain formal language. The correctness of the samples has been reviewed by the working group. |
|
2021-10-29
|
05 | Tim Hollebeek | Responsible AD changed to Roman Danyliw |
|
2021-10-29
|
05 | Tim Hollebeek | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2021-10-29
|
05 | Tim Hollebeek | IESG state changed to Publication Requested from I-D Exists |
|
2021-10-29
|
05 | Tim Hollebeek | IESG process started in state Publication Requested |
|
2021-10-29
|
05 | Tim Hollebeek | Shepherd Write-up for draft-ietf-lamps-samples-05 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … Shepherd Write-up for draft-ietf-lamps-samples-05 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. As the RFC simply provides examples, this is appropriate. (2) 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: The S/MIME ([RFC8551]) development community, in particular the e-mail development community, benefits from sharing samples of signed and/or encrypted data. Often the exact key material used does not matter because the properties being tested pertain to implementation correctness, completeness or interoperability of the overall system. However, without access to the relevant secret key material, a sample is useless. This document defines a small set of X.509v3 certificates ([RFC5280]) and secret keys for use when generating or operating on such samples. Working Group Summary: There is consensus for this document in the LAMPS WG. Document Quality: The document is well-written and easy to understand. Personnel: Tim Hollebeek is the document shepherd. Roman Danyliw is the responsible area director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd and other LAMPS WG participants reviewed the document during WG Last Call. All issues raised have been resolved. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No special review needed. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The author has explicitly stated that he is unaware of any additional IP that was introduced in the updates to the document. The author has explicitly stated that he does not hold any IPR related to the document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been submitted against this Internet-Draft. (9) 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? There is consensus for this document in the LAMPS WG. (10) 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 publicly available.) No one has threatened an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IDNits review reports a few long lines due to ASCII tables around line 260. They look fine in a text editor, and I'm unsure if this is a false positive or something that needs to be fixed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None needed. (13) Have all references within this document been identified as either normative or informative? Yes, the references are divided into normative and informative. (14) 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 plan for their completion? All references are already published. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. It will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not require any work from IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries are needed. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document does not contain formal language. The correctness of the samples has been reviewed by the working group. |
|
2021-10-29
|
05 | Tim Hollebeek | Notification list changed to housley@vigilsec.com, tim.hollebeek@digicert.com from housley@vigilsec.com because the document shepherd was set |
|
2021-10-29
|
05 | Tim Hollebeek | Document shepherd changed to Tim Hollebeek |
|
2021-10-04
|
05 | Russ Housley | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2021-08-17
|
05 | Russ Housley | Notification list changed to housley@vigilsec.com because the document shepherd was set |
|
2021-08-17
|
05 | Russ Housley | Document shepherd changed to Russ Housley |
|
2021-08-17
|
05 | Russ Housley | IETF WG state changed to In WG Last Call from WG Document |
|
2021-08-17
|
05 | Russ Housley | Intended Status changed to Informational from None |
|
2021-08-05
|
05 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-05.txt |
|
2021-08-05
|
05 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2021-08-05
|
05 | Daniel Gillmor | Uploaded new revision |
|
2021-07-06
|
04 | Russ Housley | Added to session: IETF-111: lamps Thu-1500 |
|
2021-05-19
|
04 | Roman Danyliw | Changed document external resources from: to: repo https://gitlab.com/dkg/lamps-samples.git tracker https://gitlab.com/dkg/lamps-samples/-/issues |
|
2021-05-18
|
04 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-04.txt |
|
2021-05-18
|
04 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2021-05-18
|
04 | Daniel Gillmor | Uploaded new revision |
|
2021-05-14
|
03 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-03.txt |
|
2021-05-14
|
03 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2021-05-14
|
03 | Daniel Gillmor | Uploaded new revision |
|
2021-05-12
|
02 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-02.txt |
|
2021-05-12
|
02 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2021-05-12
|
02 | Daniel Gillmor | Uploaded new revision |
|
2021-05-07
|
01 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-01.txt |
|
2021-05-07
|
01 | (System) | New version accepted (logged-in submitter: Daniel Gillmor) |
|
2021-05-07
|
01 | Daniel Gillmor | Uploaded new revision |
|
2021-05-03
|
00 | Russ Housley | This document now replaces draft-dkg-lamps-samples instead of None |
|
2021-05-03
|
00 | Daniel Gillmor | New version available: draft-ietf-lamps-samples-00.txt |
|
2021-05-03
|
00 | (System) | WG -00 approved |
|
2021-05-03
|
00 | Daniel Gillmor | Set submitter to "Daniel Kahn Gillmor <dkg@fifthhorseman.net>", replaces to draft-dkg-lamps-samples and sent approval email to group chairs: lamps-chairs@ietf.org |
|
2021-05-03
|
00 | Daniel Gillmor | Uploaded new revision |