Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
draft-ietf-lamps-rfc4210bis-18
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-02-06
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2025-02-05
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2025-02-05
|
18 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2025-02-05
|
18 | Barry Leiba | Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing |
2025-02-05
|
18 | Barry Leiba | Assignment of request for Last Call review by ARTART to Sean Turner was marked no-response |
2025-02-04
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-01-31
|
18 | (System) | IANA Action state changed to In Progress |
2025-01-31
|
18 | (System) | RFC Editor state changed to EDIT |
2025-01-31
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2025-01-31
|
18 | (System) | Announcement was received by RFC Editor |
2025-01-30
|
18 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2025-01-30
|
18 | Cindy Morgan | IESG has approved the document |
2025-01-30
|
18 | Cindy Morgan | Closed "Approve" ballot |
2025-01-30
|
18 | Cindy Morgan | Ballot writeup was changed |
2025-01-30
|
18 | Cindy Morgan | Ballot approval text was generated |
2025-01-30
|
18 | (System) | Removed all action holders (IESG state changed) |
2025-01-30
|
18 | Deb Cooley | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2025-01-30
|
18 | Paul Wouters | [Ballot comment] Thanks for your patience with addressing my issues. I've updated my ballot to 'Yes' (I do hope we can talk at IETF-123 about … [Ballot comment] Thanks for your patience with addressing my issues. I've updated my ballot to 'Yes' (I do hope we can talk at IETF-123 about the confusion of that one paragraph) |
2025-01-30
|
18 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss |
2025-01-30
|
18 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-18.txt |
2025-01-30
|
18 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2025-01-30
|
18 | Hendrik Brockhaus | Uploaded new revision |
2025-01-28
|
17 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-17.txt |
2025-01-28
|
17 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2025-01-28
|
17 | Hendrik Brockhaus | Uploaded new revision |
2025-01-09
|
16 | (System) | Changed action holders to Deb Cooley (IESG state changed) |
2025-01-09
|
16 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2025-01-09
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2025-01-09
|
16 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-16.txt |
2025-01-09
|
16 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2025-01-09
|
16 | Hendrik Brockhaus | Uploaded new revision |
2024-12-19
|
15 | (System) | Changed action holders to Mike Ounsworth, John Gray, Hendrik Brockhaus, David von Oheimb (IESG state changed) |
2024-12-19
|
15 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2024-12-19
|
15 | Paul Wouters | [Ballot discuss] I have one DISCUSS that should be easy to resolve This term is not meant to imply that a … [Ballot discuss] I have one DISCUSS that should be easy to resolve This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. I thought a "root CA" by definition is a self-signed cert, and not signed by another entity. Such a CA would be called an "intermediate CA" that can still be a trust anchor in a local trust store. Throughout the document later on, "Root CA" is assumed to have a self-signature, so I believe other than this definition, the document is handling this okay. |
2024-12-19
|
15 | Paul Wouters | [Ballot comment] but also applications themselves (e.g., for IP security) Do you mean IPsec? If so, technically you mean IKE not … [Ballot comment] but also applications themselves (e.g., for IP security) Do you mean IPsec? If so, technically you mean IKE not IPsec. Maybe write IKE/IPsec instead of "IP security"? Is it worth updating "Personal Security Environment (PSE)" with "Trusted Execution Environment (TEE)" which is the term the IETF seems to be using now for these? Section 4.3 (e.g., a key that may be used for signing, as well as other purposes, MUST NOT be sent to the CA/RA in order to prove possession unless archival of the private key is explicitly desired). Can the text "that may be used for signing, as well as other purposes," be removed? Even if the key is ONLY used for signing, it MUST NOT be sent as POP. Security Considerations: It is not entirely clear what security guarantees are lost if an end entity is able to obtain a certificate containing a public key that they do not possess the corresponding private key for. Maybe change "obtain" to "cause to be generated and receive" ? Because peers "obtain" other peer's certificate containing public keys all the time. Section 8.6 could say something about enforcing this with EKUs? First paragraph of 8.7 should perhaps be replaced with a link to RFC4086 |
2024-12-19
|
15 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2024-12-19
|
15 | John Scudder | [Ballot comment] Thanks for following through on the commitment to produce this monumental update! |
2024-12-19
|
15 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-12-18
|
15 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2024-12-18
|
15 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. Thanks to Colin Perkins for his TSVART review. I have following comments, which I believe will improve … [Ballot comment] Thanks for working on this specification. Thanks to Colin Perkins for his TSVART review. I have following comments, which I believe will improve this specificaition if addressed - # Section 5.1.1 : can we enumerate the "transport-level information"? What are the specific transport-level information of interest? # Section 3.1.3 : it says - "Appropriate transfer protocols MUST be capable of delivering the CMP messages reliably". This is good that we are imposing transport requirements here. Since, this is imposing a MUST on reliablity, the RFC6712-bis need to reflect on this. I will put my comments related to this point in the RFC6712-bis ballot. |
2024-12-18
|
15 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2024-12-17
|
15 | Orie Steele | [Ballot comment] # Orie Steele, ART AD, comments for draft-ietf-lamps-rfc4210bis-15 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc4210bis-15.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * … [Ballot comment] # Orie Steele, ART AD, comments for draft-ietf-lamps-rfc4210bis-15 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc4210bis-15.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### might? ``` 423 authority (i.e., the entity that issues the certificate). A 424 registration authority MAY also be involved in PKI management. ``` Not sure what the interop impact of maybe being involved is. ### copy paste error? Or is this a reference to Section 5.3.4 ? ``` 458 Though PSE formats are beyond the scope of this document (they are 459 very dependent on equipment, et cetera), a generic interchange format 460 for PSEs is defined here: a certification response message MAY be 461 used. ``` ### Language Tags ``` 3093 5.3.19.13. Supported Language Tags 3095 This MAY be used to determine the appropriate language tag to use in 3096 subsequent messages. The sender sends its list of supported 3097 languages (in order, most preferred to least); the receiver returns 3098 the one it wishes to use. (Note: each UTF8String MUST include a 3099 language tag.) If none of the offered tags are supported, an error 3100 MUST be returned. 3102 GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String 3103 GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String ``` Please add a reference for language tags, to RFC 5646. I wonder why, when language support is required, this is not a MUST / SHOULD. |
2024-12-17
|
15 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2024-12-16
|
15 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-12-16
|
15 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-lamps-rfc4210bis-15 CC @evyncke Thank you for the work put into this document. As it is a … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-lamps-rfc4210bis-15 CC @evyncke Thank you for the work put into this document. As it is a -bis document, I have only reviewed the diffs. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Russ Housley for the shepherd's detailed write-up including the pre-RFC 5378 copyright, the WG consensus, and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Deprecated values Several elements are marked as 'deprecated' (e.g., section 5.2.8.[3|4]), but the text specifies nothing about the behaviour of the recipient of such deprecated element. I am not familiar enough with CMP to ballot a DISCUSS on this point (moreover it may well be specified somewhere in the I-D), but I would like to receive some explanations. ### Title Please add the CMP version number in the title, I had to read the abstract and *guess* that this is version 3. ### Abstract Please expand "KEM". ### Acronyms As this I-D is acronym heavy, suggest adding a terminology section with all the expanded acronyms. ### Section 1 As for the title, please add the CMP version number. ### Sections 1.1, 1.2, 1.3 It is probably a matter of taste, but why not moving the 'changes' in an appendix ? These sections are not critical to understand the CMP protocol. ### Section 2 Unsure whether the section title `requirements` is the most suitable one. ### Section 3.1.3 Please expand BRKSI, SZTP, MQTT, CoAP at first use even if references are present. ### Section 5.1.1 Mainly out of curiosity, was `cmp2021` introduced by a draft 2021 version of this document ? ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-) ### Section 4.3 Another matter of taste whether authors' opinion belong in a RFC `the question of whether, and in what circumstances, POPs add value to a PKI is a debate as old as PKI itself!` ### Section 7 s/with the following exception. Version cmp2021 SHOULD only be used /with the following exception: version cmp2021 SHOULD only be used / ? |
2024-12-16
|
15 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2024-12-16
|
15 | Gunter Van de Velde | [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-ietf-lamps-rfc4210bis-15 # the referenced line numbers are derived from the idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc4210bis-15.txt # … [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-ietf-lamps-rfc4210bis-15 # the referenced line numbers are derived from the idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc4210bis-15.txt # Many thanks for this write-up. The document is well written. I did not understand some of the procedures, hence only a high level review from my side. # When looking at idnits there were some idnits warnings # I mainly looked at the diff between rfc4210 & rfc4210bis. In general the i found the bis content to clear associated with good clarifying texts. #DETAILED COMMENTS #================= 954 4.2.2.2. Basic Authenticated Scheme 955 956 In terms of the classification above, this scheme is where: 957 958 * initiation occurs at the end entity; 959 960 * message authentication is required; 961 962 * "key generation" occurs at the end entity (see Section 4.2.1.3); 963 964 * a confirmation message is recommended. GV> In the original rfc4210 there was BCP14 language that was removed. Was that considered a typo because it is not specifically defining procedure? o initiation occurs at the end entity; o message authentication is REQUIRED; o "key generation" occurs at the end entity (see Section 4.2.1.3); o a confirmation message is REQUIRED. 1488 Note: The recommendation of using senderKID was changed since 1489 [RFC4210], where it was recommended to be omitted if not needed to 1490 identify the protection key. GV> s/of using senderKID was changed since/of using senderKID **is** changed since/ Gunter Van de Velde Routing Area Director |
2024-12-16
|
15 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2024-12-16
|
15 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-12-15
|
15 | Erik Kline | [Ballot comment] # Internet AD comments for draft-ietf-lamps-rfc4210bis-15 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments … [Ballot comment] # Internet AD comments for draft-ietf-lamps-rfc4210bis-15 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S3.1.3 * "IPSEC [RFC7296]" It's possible that IKEv2 isn't the best IPsec reference here. Since confidential transport is the topic, perhaps ESP (4303) might be a better reference? |
2024-12-15
|
15 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-12-14
|
15 | Roman Danyliw | [Ballot comment] Thank you to Linda Dunbar for the GENART review. |
2024-12-14
|
15 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2024-11-21
|
15 | Cindy Morgan | Placed on agenda for telechat - 2024-12-19 |
2024-11-21
|
15 | Deb Cooley | Ballot has been issued |
2024-11-21
|
15 | Deb Cooley | [Ballot Position Update] New position, Yes, has been recorded for Deb Cooley |
2024-11-21
|
15 | Deb Cooley | Created "Approve" ballot |
2024-11-21
|
15 | Deb Cooley | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-11-21
|
15 | Deb Cooley | Ballot writeup was changed |
2024-11-18
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-11-18
|
15 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-15.txt |
2024-11-18
|
15 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2024-11-18
|
15 | Hendrik Brockhaus | Uploaded new revision |
2024-10-28
|
14 | Linda Dunbar | Request for Last Call review by GENART Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. Submission of review completed at an earlier date. |
2024-10-28
|
14 | Linda Dunbar | Request for Last Call review by GENART Completed: Ready. Reviewer: Linda Dunbar. |
2024-10-27
|
14 | Scott Kelly | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Scott Kelly. Sent review to list. |
2024-10-24
|
14 | David Dong | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2024-10-24
|
14 | David Dong | The SMI Security for PKIX Module Identifier and SMI Security for PKIX CMP Information Types registrations have been approved. |
2024-10-24
|
14 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-10-23
|
14 | Ran Chen | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Ran Chen. Sent review to list. |
2024-10-23
|
14 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-10-21
|
14 | David Dong | IANA Experts State changed to Reviews assigned from Expert Reviews OK |
2024-10-21
|
14 | David Dong | IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lamps-rfc4210bis-14. If any part of this review is inaccurate, please let us know. IANA has a question … IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lamps-rfc4210bis-14. If any part of this review is inaccurate, please let us know. IANA has a question about one of the actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there are two actions which we must complete. First, in the SMI Security for PKIX Module Identifier registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at: https://www.iana.org/assignments/smi-numbers/ a single new registration will be made as follows: Decimal: [ TBD-at-Registration ] Description: id-mod-cmp2023-02 Reference: [ RFC-to-be ] 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, in the SMI Security for PKIX CMP Information Types registry also in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at: https://www.iana.org/assignments/smi-numbers/ a single new registration will be made as follows: Decimal: [ TBD-at-Registration ] Description: id-it-KemCiphertextInfo Reference: [ RFC-to-be ] As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request. Third, in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at: https://www.iana.org/assignments/smi-numbers/ All existing references to [RFC2510], [RFC4210], and [RFC9480] except those in the "SMI Security for PKIX Module Identifier" registry should be replaced with references to this document ( [ RFC-to-be ] ). IANA Question --> Section 9 of the current draft has the following text: "The new OID 1.2.840.113533.7.66.16 was registered by Entrust for id-KemBasedMac in the arch 1.2.840.113533.7.66. Entrust registered also the OIDs for id-PasswordBasedMac and id-DHBasedMac there." IANA understands that text to be documentation and not requesting any action from IANA upon approval of the document for publication. Is this correct? 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-10-21
|
14 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2024-10-18
|
14 | Colin Perkins | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Colin Perkins. Sent review to list. |
2024-10-10
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2024-10-10
|
14 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-10-10
|
14 | David Dong | IANA Experts State changed to Reviews assigned |
2024-10-10
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
2024-10-10
|
14 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Colin Perkins |
2024-10-10
|
14 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Ran Chen |
2024-10-10
|
14 | Barry Leiba | Request for Last Call review by ARTART is assigned to Sean Turner |
2024-10-09
|
14 | Liz Flynn | IANA Review state changed to IANA - Review Needed |
2024-10-09
|
14 | Liz Flynn | The following Last Call announcement was sent out (ends 2024-10-23): From: The IESG To: IETF-Announce CC: debcooley1@gmail.com, draft-ietf-lamps-rfc4210bis@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, spasm@ietf.org … The following Last Call announcement was sent out (ends 2024-10-23): From: The IESG To: IETF-Announce CC: debcooley1@gmail.com, draft-ietf-lamps-rfc4210bis@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, spasm@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)) 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: - 'Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)' 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-10-23. 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 This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document obsoletes RFC 4210 by including the updates specified by CMP Updates RFC 9480 Section 2 and Appendix A.2 maintaining backward compatibility with CMP version 2 wherever possible and obsoletes both documents. Updates to CMP version 2 are: improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. Introducing CMP version 3 to be used only for changes to the ASN.1 syntax, which are: support of EnvelopedData instead of EncryptedValue, hashAlg for indicating a hash AlgorithmIdentifier in certConf messages, and RootCaKeyUpdateContent in ckuann messages. In addition to the changes specified in CMP Updates RFC 9480 this document adds support for management of KEM certificates. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc4210bis/ No IPR declarations have been submitted directly on this I-D. |
2024-10-09
|
14 | Liz Flynn | IESG state changed to In Last Call from Last Call Requested |
2024-10-09
|
14 | Deb Cooley | Last call was requested |
2024-10-09
|
14 | Deb Cooley | Last call announcement was generated |
2024-10-09
|
14 | Deb Cooley | Ballot approval text was generated |
2024-10-09
|
14 | Deb Cooley | Ballot writeup was generated |
2024-10-09
|
14 | Deb Cooley | Can we please make this a 3 week IETF Last Call? |
2024-10-09
|
14 | Deb Cooley | IESG state changed to Last Call Requested from Publication Requested |
2024-10-09
|
14 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-14.txt |
2024-10-09
|
14 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2024-10-09
|
14 | Hendrik Brockhaus | Uploaded new revision |
2024-09-02
|
13 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-13.txt |
2024-09-02
|
13 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2024-09-02
|
13 | Hendrik Brockhaus | Uploaded new revision |
2024-08-28
|
12 | Russ Housley | Shepherd Write-up for draft-ietf-lamps-rfc4210bis-12 (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-rfc4210bis-12 (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? Proposed Standard. Yes, the header calls for Standards Track. When RFC 9480 was approved by the IESG, the LAMPS WG was asked to make a bis document instead of a complicated update document. Here it is... (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: This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP) version 3. This document includes the updates to CMP that are specified by RFC 9480, and support for key encapsulation mechanism (KEM) algorithms is provided. This document will obsolete RFC 4210 and RFC 9480. Working Group Summary: There is consensus for this document in the LAMPS WG. Document Quality: Vendors with CMP implementations have indicated that they intend to support the updated syntax, and at least one open source effort is underway. Personnel: Russ Housley is the document shepherd. Deb Cooley 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 LAMPS WG supported the updates in RFC 9480 and the additional support for KEM algorithms. The document shepherd did a thorough review of the document during WG Last Call. All issues were resolved. Also, the ASN.1 module compiles without errors. (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. Several people that were involved in the PKIX WG were part of the review that took place during LAMPS WG Last Call. (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 authors have explicitly stated that they are unaware of any additional IP that was introduced in the updates to RFC 4210. The authors have explicitly stated that they do not hold any IPR related to the updates to RFC 4210. Note that RFC 4210 was written prior to the publication of RFC 5378. However, each of the authors of RFC 4210 have been contacted and each of them has explicitly released rights to the IETF Trust. A document for signature has been sent to the authors by the IETF Trust, and we expect that it will be signed before IETF Last Call completes. Therefore, the pre5378Trust200902 IPR Boilerplate is not used. (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 were issued against this document. (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. This document will obsolete RFC 4210 and RFC 9480. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No special reviews are needed. (13) Have all references within this document been identified as either normative or informative? Yes. (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? [I-D.ietf-lamps-cms-kemri] is a normative reference, but it is already in the RFC Editor queue. [MvOV97] is listed as a normative reference in this document. It was also listed as a normative reference in RRC 4210. It is not totally clear that it needs to be a normative reference. (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. There are downward normative references to Informational RFC 2985 and Informational RFC 2985. Both of these RFCs are already in the downref registry, so no special action is needed. (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. This document will obsolete RFC 4210 and RFC 9480, which is clearly stated on the title page and the Abstract. (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). Updates to some IANA registries are needed. In addition, the IANA registry entries that point to RFC 4210 should be updated to point to this document. (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 ASN.1 modules compile without errors. |
2024-08-28
|
12 | Russ Housley | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-08-28
|
12 | Russ Housley | IESG state changed to Publication Requested from I-D Exists |
2024-08-28
|
12 | (System) | Changed action holders to Deb Cooley (IESG state changed) |
2024-08-28
|
12 | Russ Housley | Responsible AD changed to Deb Cooley |
2024-08-28
|
12 | Russ Housley | Document is now in IESG state Publication Requested |
2024-08-28
|
12 | Russ Housley | Intended Status changed to Proposed Standard from None |
2024-08-28
|
12 | Russ Housley | Shepherd Write-up for draft-ietf-lamps-rfc4210bis-12 (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-rfc4210bis-12 (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? Proposed Standard. Yes, the header calls for Standards Track. When RFC 9480 was approved by the IESG, the LAMPS WG was asked to make a bis document instead of a complicated update document. Here it is... (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: This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP) version 3. This document includes the updates to CMP that are specified by RFC 9480, and support for key encapsulation mechanism (KEM) algorithms is provided. This document will obsolete RFC 4210 and RFC 9480. Working Group Summary: There is consensus for this document in the LAMPS WG. Document Quality: Vendors with CMP implementations have indicated that they intend to support the updated syntax, and at least one open source effort is underway. Personnel: Russ Housley is the document shepherd. Deb Cooley 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 LAMPS WG supported the updates in RFC 9480 and the additional support for KEM algorithms. The document shepherd did a thorough review of the document during WG Last Call. All issues were resolved. Also, the ASN.1 module compiles without errors. (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. Several people that were involved in the PKIX WG were part of the review that took place during LAMPS WG Last Call. (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 authors have explicitly stated that they are unaware of any additional IP that was introduced in the updates to RFC 4210. The authors have explicitly stated that they do not hold any IPR related to the updates to RFC 4210. Note that RFC 4210 was written prior to the publication of RFC 5378. However, each of the authors of RFC 4210 have been contacted and each of them has explicitly released rights to the IETF Trust. A document for signature has been sent to the authors by the IETF Trust, and we expect that it will be signed before IETF Last Call completes. Therefore, the pre5378Trust200902 IPR Boilerplate is not used. (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 were issued against this document. (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. This document will obsolete RFC 4210 and RFC 9480. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No special reviews are needed. (13) Have all references within this document been identified as either normative or informative? Yes. (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? [I-D.ietf-lamps-cms-kemri] is a normative reference, but it is already in the RFC Editor queue. [MvOV97] is listed as a normative reference in this document. It was also listed as a normative reference in RRC 4210. It is not totally clear that it needs to be a normative reference. (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. There are downward normative references to Informational RFC 2985 and Informational RFC 2985. Both of these RFCs are already in the downref registry, so no special action is needed. (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. This document will obsolete RFC 4210 and RFC 9480, which is clearly stated on the title page and the Abstract. (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). Updates to some IANA registries are needed. In addition, the IANA registry entries that point to RFC 4210 should be updated to point to this document. (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 ASN.1 modules compile without errors. |
2024-08-28
|
12 | Russ Housley | Notification list changed to housley@vigilsec.com because the document shepherd was set |
2024-08-28
|
12 | Russ Housley | Document shepherd changed to Russ Housley |
2024-08-28
|
12 | Russ Housley | Changed consensus to Yes from Unknown |
2024-07-24
|
12 | Russ Housley | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2024-07-08
|
12 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-12.txt |
2024-07-08
|
12 | (System) | New version approved |
2024-07-08
|
12 | (System) | Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , John Gray , Mike Ounsworth |
2024-07-08
|
12 | Hendrik Brockhaus | Uploaded new revision |
2024-07-01
|
11 | Russ Housley | Asked for more time to make sure that CMPv3 and CMCbis are handling KEM public keys the same way. |
2024-06-20
|
11 | Russ Housley | WG Last Call extended for another week because so few people commented on the mail list. |
2024-06-06
|
11 | Russ Housley | IETF WG state changed to In WG Last Call from WG Document |
2024-06-05
|
11 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-11.txt |
2024-06-05
|
11 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2024-06-05
|
11 | Hendrik Brockhaus | Uploaded new revision |
2024-05-06
|
10 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-10.txt |
2024-05-06
|
10 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2024-05-06
|
10 | Hendrik Brockhaus | Uploaded new revision |
2024-03-20
|
09 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-09.txt |
2024-03-20
|
09 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2024-03-20
|
09 | Hendrik Brockhaus | Uploaded new revision |
2024-03-01
|
08 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-08.txt |
2024-03-01
|
08 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2024-03-01
|
08 | Hendrik Brockhaus | Uploaded new revision |
2023-12-29
|
07 | (System) | Document has expired |
2023-06-19
|
07 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-07.txt |
2023-06-19
|
07 | (System) | New version approved |
2023-06-19
|
07 | (System) | Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , John Gray , Mike Ounsworth |
2023-06-19
|
07 | Hendrik Brockhaus | Uploaded new revision |
2023-03-21
|
06 | Russ Housley | Added to session: IETF-116: lamps Wed-0030 |
2023-03-13
|
06 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-06.txt |
2023-03-13
|
06 | (System) | New version approved |
2023-03-13
|
06 | (System) | Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , John Gray , Mike Ounsworth |
2023-03-13
|
06 | Hendrik Brockhaus | Uploaded new revision |
2023-03-08
|
05 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-05.txt |
2023-03-08
|
05 | (System) | New version approved |
2023-03-08
|
05 | (System) | Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , John Gray , Mike Ounsworth |
2023-03-08
|
05 | Hendrik Brockhaus | Uploaded new revision |
2023-03-03
|
04 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-04.txt |
2023-03-03
|
04 | (System) | New version approved |
2023-03-03
|
04 | (System) | Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , John Gray , Mike Ounsworth |
2023-03-03
|
04 | Hendrik Brockhaus | Uploaded new revision |
2022-10-24
|
03 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-03.txt |
2022-10-24
|
03 | Hendrik Brockhaus | New version accepted (logged-in submitter: Hendrik Brockhaus) |
2022-10-24
|
03 | Hendrik Brockhaus | Uploaded new revision |
2022-08-11
|
02 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-02.txt |
2022-08-11
|
02 | (System) | New version approved |
2022-08-11
|
02 | (System) | Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , John Gray , Mike Ounsworth |
2022-08-11
|
02 | Hendrik Brockhaus | Uploaded new revision |
2022-08-11
|
01 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-01.txt |
2022-08-11
|
01 | (System) | New version approved |
2022-08-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , John Gray , Mike Ounsworth |
2022-08-11
|
01 | Hendrik Brockhaus | Uploaded new revision |
2022-08-10
|
00 | Hendrik Brockhaus | New version available: draft-ietf-lamps-rfc4210bis-00.txt |
2022-08-10
|
00 | Russ Housley | WG -00 approved |
2022-08-10
|
00 | Hendrik Brockhaus | Set submitter to "Hendrik Brockhaus ", replaces to (none) and sent approval email to group chairs: lamps-chairs@ietf.org |
2022-08-10
|
00 | Hendrik Brockhaus | Uploaded new revision |