Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
draft-ietf-lamps-rfc4210bis-18
Yes
Deb Cooley
No Objection
Jim Guichard
Murray Kucherawy
Note: This ballot was opened for revision 15 and is now closed.
Deb Cooley
Yes
Paul Wouters
(was Discuss)
Yes
Comment
(2025-01-30)
Sent
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)
Erik Kline
No Objection
Comment
(2024-12-15 for -15)
Sent
# 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?
Gunter Van de Velde
No Objection
Comment
(2024-12-16 for -15)
Sent
# 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
Jim Guichard
No Objection
John Scudder
No Objection
Comment
(2024-12-19 for -15)
Sent
Thanks for following through on the commitment to produce this monumental update!
Murray Kucherawy
No Objection
Orie Steele
No Objection
Comment
(2024-12-17 for -15)
Sent
# 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.
Roman Danyliw
No Objection
Comment
(2024-12-14 for -15)
Not sent
Thank you to Linda Dunbar for the GENART review.
Zaheduzzaman Sarker
No Objection
Comment
(2024-12-18 for -15)
Sent
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.
Éric Vyncke
No Objection
Comment
(2024-12-16 for -15)
Sent
# É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 / ?