Skip to main content

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

* "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