Skip to main content

Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
draft-ietf-lamps-rfc4210bis-18

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 / ?