Re: [lamps] AD Review of draft-ietf-lamps-lightweight-cmp-profile-13

["Brockhaus, Hendrik" <[e-mail]>]

Roman

Many thanks for your feedback and for the valuable comments. Below you find my responses and suggestions.
I will submit an updated version of the draft incorporating all changes proposed as soon as possible. 
If there is any proposed change that does not fit your expectation, please let me know.

Hendrik

> Von: Spasm <[e-mail]> Im Auftrag von Roman Danyliw
> 
> Hi!
> 
> I conducted an AD review on draft-ietf-lamps-lightweight-cmp-profile-13.
> Thanks for all of the hard work on this comprehensive document.  My feedback
> is as follows:
> 
> ** Abstract.  Editorial.
> 
> OLD
>    More special and complex use
>    cases are supported as well, by features specified as recommended or
>    optional.
> 
> NEW
> More specialized or complex use    cases are supported with optional features.

[HB] Thanks, change will be done.

> 
> ** Section 1.  Editorial.
> 
> OLD
>    Especially CMP, CRMF, and CMS
>    are very feature-rich standards, while in most application scenarios
>    only a limited subset of the specified functionality is needed.
> 
> NEW
> CMP, CRMF and CMS are feature-rich specifications, but most application
> scenarios use only a limited subset of the same specified functionality.

[HB] Thanks, change will be done.

> 
> ** Section 1.2.  Editorial.  Colloquial language. s/is a solid and very capable/is a
> capable/

[HB] Thanks, change will be done.

> 
> ** Section 1.2. Editorial
> 
> OLD
>   To
>    this end, when there was a choice to have necessary complexity more
>    on the EE or PKI management entity side, it has been pushed towards
>    PKI management entities, where typically more computational resources
>    are available and the development can be consolidated better
> 
> NEW
> To this end, when there was design flexibility to either have necessary
> complexity on the EE or in the PKI management entity, this profile chose to
> include it in the PKI management entities where typically more computational
> resources are available.

[HB] Thanks, change will be done.

> 
> ** Section 1.2.  "As also 3GPP and UNISIG already put across ..."
> 
> What does "put across" mean?

[HB] Proposed change:
OLD
   As also 3GPP and UNISIG already put across, profiling is a way of
   coping with the challenges mentioned above.
NEW
   Profiling is a way to reduce feature richness and complexity of
   standards to what is needed for specific use cases. 3GPP and
   UNISIG already use profiling of CMP as a way to cope with these challenges.


> 
> ** Section 1.2.
>    In
>    this way all the general and applicable aspects of the general
>    protocol are taken over ...
> 
> What does "taken over" mean here?

[HB] Proposed change:
OLD
   In
   this way all the general and applicable aspects of the general
   protocol are taken over and only the peculiarities of the target
   scenarios need to be dealt with specifically.
NEW
   In
   this way the general aspects of the protocol are utilized
   and only the special requirements of the target scenarios
   need to be dealt with using distinct features the protocol
   offers.

> 
> ** Section 1.3
> 
>   Due to increasing security needs in operational networks as well as
>    availability requirements, ...
> 
> Isn't availability an example of a security requirement?
> 
> ** Section 1.3
> 
>    Due to increasing security needs in operational networks as well as
>    availability requirements, especially on critical infrastructures and
>    systems with a high number of certificates, a state-of-the-art
>    certificate management system must be constantly available and cost-
>    efficient, which calls for high automation and reliability.
> 
> -- Since this profile is targeted at IoT and industrial solutions, shouldn't it read
> "operational technology" (instead of operational networks).  Isn't anything in
> production an "operational network"?
> 
> -- what is the set of technology which has a high number of certificates, but isn't
> OT or critical infrastructure?

[HB] Proposed change:
OLD
   Due to increasing security needs in operational networks as well as
   availability requirements, especially on critical infrastructures and
   systems with a high number of certificates, a state-of-the-art
   certificate management system must be constantly available and cost-
   efficient, which calls for high automation and reliability.
NEW
   Due to increasing security and availability needs in operational
   technology, especially when used for critical infrastructures and
   systems with a high number of certificates, a state-of-the-art
   certificate management system must be constantly available and cost-
   efficient, which calls for high automation and reliability.

> 
> ** Section 1.3
> 
>   Further challenges in many industrial systems are network
>    segmentation and asynchronous communication, while PKI management
>    entities like Certification Authorities (CA) typically are not
>    deployed on-site but in a more protected environment of a data center
>    or trust center.
> 
> -- This is a run-on sentence.  Please split it.
> 
> -- what is a "trust center"?

[HB] Proposed change:
OLD
   Further challenges in many industrial systems are network
   segmentation and asynchronous communication, while PKI management
   entities like Certification Authorities (CA) typically are not
   deployed on-site but in a more protected environment of a data center
   or trust center.
NEW
   Further challenges in many industrial systems are network
   segmentation and asynchronous communication. Also, PKI management
   entities like Certification Authorities (CA) typically are not
   deployed on-site but in a high protected data center environment, e.g.,
   operated according to ETSI Policy and security requirements for Trust
   Service Providers issuing certificates [ETSI EN 319 411-1].

> 
> ** Section 1.5
>    To allow PKI management entities to also comply
>    with this profile, the p10cr message must be formatted by the EE as
>    described in Section 4.1.4 of this profile, and it may be forwarded
>    as specified in Section 5.2.
> 
> -- Why not use a MUST and MAY since this seems to be specifying normative
> behavior.

[HB]  Right
OLD
   To allow PKI management entities to also comply
   with this profile, the p10cr message must be formatted by the EE as
   described in Section 4.1.4 of this profile, and it may be forwarded
   as specified in Section 5.2.
NEW
   To allow PKI management entities to also comply
   with this profile, the p10cr message MUST be formatted by the EE as
   described in Section 4.1.4 of this profile, and it MAY be forwarded
   as specified in Section 5.2.

> 
> -- Wouldn't it be more appropriate for draft-ietf-netconf-sztp-csr and draft-ietf-
> anima-brski-ar to normatively reference this document and specify which part of
> this document they must adhere to.

[HB] You are right, and draft-ietf-anima-brski-ae Section 5.2 is using this draft as
normative reference for this PKI management operation. But draft-ietf-netconf-
sztp-csr is already in RFC Ed Queue and the authors did not want to have a 
further dependency to this draft.

> 
> ** Section 2.  The solution architecture notes an expectation for manufacturer-
> issued device certificates (IDevID).  Is there a reference that can be used which
> covers the Security Considerations of this kind of root of trust?

[HB] We could add a note after the first paragraph to provide further information.
NEW
   Note: The owner or operator using the manufacturer-issued device
   certificate for authenticating the device during initial enrollment
   of operational certificates MUST trust the respective trust anchor
   provided by the manufacturer.

> 
> ** Section 2.
>   The EE creates a CMP request message, protects it
>   using some asymmetric credential or shared secret information and
>    sends it to its locally reachable PKI management entity.
> 
> Per the term "locally reachable", is this implying on the "local network"?  Would
> there be a case where that isn't the case?  There is subsequent text in this
> section which suggests that "It is also possible not to have an RA or LRA or that
> there is no CA with a CMP interface."

[HB] Good point. We can generalize it to 'a PKI management entity'.
OLD
   The EE creates a CMP request message, protects it
   using some asymmetric credential or shared secret information and
   sends it to its locally reachable PKI management entity.
NEW
   The EE creates a CMP request message, protects it
   using some asymmetric credential or shared secret information and
   sends it to a PKI management entity.

> 
> ** Section 2.  Editorial?
>    Especially the communication between an LRA and RA can be performed
>    synchronously or asynchronously
> 
> I'm confused by the use of "especially".  Can't the text say "The communication
> between ...?

[HB] Right, I will change this.
OLD
   Especially the communication between an LRA and RA can be performed
   synchronously or asynchronously.
NEW
   The communication between an LRA and RA can be performed
   synchronously or asynchronously.

> 
> ** Section 2.
> 
>    Note: CMP response messages could also be used proactively to
>    implement the push model towards the EE.
> 
> I found the inclusion of this text confusing given that earlier text in this section
> explicitly said "All certificate management operations specified in this document
> follow the pull model, i.e., are initiated by an EE (or by an RA acting as an EE)."
> This aside seems to be describing something that is out of scope for this profile.
> Why is it needed?

[HB] Netconf specifies enrollment using, e.g., different request formats, including
CMP request messages, and specifies the certificate delivery message independently
from the request format. Also, ietf-anima-brski-prm specifies a push model, which can 
be implemented using CMP messages. Therefore, we thought such note on the push model 
could also be helpful here, even if it is out of scope of this document.
In the meantime, there is Section 1.5 on using CMP with SZTP and if it confuses the 
reader, we could delete this note or rephrase it to express more clearly, that the push 
model must be specified elsewhere.
OLD
   Note: CMP response messages could also be used proactively to
   implement the push model towards the EE.  In this case the EE acts as
   receiver, not initiating the interaction with the PKI.  Also, when
   using a commissioning tool or a registrar agent as described in BRSKI
   with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm],
   certificate enrollment in a push model is needed.  CMP in general and
   the messages specified in this profile offer all required
   capabilities, but the message flow and state machine as described in
   Section 4 must be adapted to implement a push model.
NEW
   Note: In contrast to the pull model used in this document, other
   specifications could use the messages specified in this document
   implementing the push model.  In this case the EE is pushed (triggered)
   by the PKI management entity to provide the CMP request, and therefore
   EE acts as the receiver, not initiating the interaction with the PKI.
   For example, when the device itself does only act as a server as
   described in BRSKI with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-
   anima-brski-prm], support of certificate enrollment in a push model is
   needed. While BRSKI-PRM currently utilizes its own format for the
   exchanges, CMP in general and the messages specified in this profile
   offer all required capabilities. Nevertheless, the message flow and
   state machine as described in Section 4 must be adapted to implement a
   push model.

> 
> ** Section 2.
> 
>    Third-party CAs may implement other variants of CMP, different
>    standardized protocols, or even proprietary interfaces for
>    certificate management.  Therefore, the RA may need to adapt the
>    exchanged CMP messages to the flavor of certificate management
>    interaction required by the CA.
> 
> How does this affect the implementation of this profile?  The matters discussed
> here seem out of scope as long as the RA and CA conform to the table in Section
> 7.1.

[HB] This is right. I will express it more clearly that this is an option that can be 
relevant in a real-life scenario, but it is out of scope of this document.
OLD
   Third-party CAs may implement other variants of CMP, different
   standardized protocols, or even proprietary interfaces for
   certificate management.  Therefore, the RA may need to adapt the
   exchanged CMP messages to the flavor of certificate management
   interaction required by the CA.
NEW
   Third-party CAs, not conforming to this document, may implement
   other variants of CMP, different standardized protocols, or even
   proprietary interfaces for certificate management.  In such cases,
   an RA needs to adapt the exchanged CMP messages to the flavor
   of certificate management interaction required by such a non-
  conformant CA.

> 
> ** Section 3.1, but broadly applicable.  This is a subjective editorial comment.
> The sections which describe the specific fields are difficult to read due to the
> indentation.  Consider:
> 
> -- Using hanging indents for the distinct bullets to improve readable.  For
> example:
> 
> OLD
>        -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
>        -- is supported and expected to be used in the current
>        -- PKI management operation
>        -- MUST be 3 to indicate CMP v3 in certConf messages when using
>        -- the hashAlg field
> 
> NEW
>        -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
>        --   is supported and expected to be used in the current
>        --   PKI management operation
>        -- MUST be 3 to indicate CMP v3 in certConf messages when using
>        --   the hashAlg field
> 
> -- Indenting the sub-elements fields and their associated text.  For example:
> 
> OLD
>    body
>        -- The request of the EE for a new certificate using a PKCS#10
>        -- certificate request
>      p10cr                       REQUIRED
>        certificationRequestInfo  REQUIRED
>          version                 REQUIRED
>        -- MUST be 0 to indicate PKCS#10 V1.7
>          subject                 REQUIRED
>        -- The EE subject name MUST be carried in the subject field
>        -- and/or the subjectAltName extension.
>        -- If subject name is present only in the subjectAltName
>        -- extension, then the subject field MUST be a NULL-DN
> NEW
>    body
>        -- The request of the EE for a new certificate using a PKCS#10
>        -- certificate request
>      p10cr                       REQUIRED
>        certificationRequestInfo  REQUIRED
>          version                 REQUIRED
>            -- MUST be 0 to indicate PKCS#10 V1.7
>          subject                 REQUIRED
>            -- The EE subject name MUST be carried in the subject field
>            --   and/or the subjectAltName extension.
>            -- If subject name is present only in the subjectAltName
>            --   extension, then the subject field MUST be a NULL-DN

[HB] Thank you for this feedback. You are right, that this will increase the readability. I will give it a try to change this.

> 
> ** Section 3.1.
>      senderKID                   RECOMMENDED
> 
> Section 5.1.1 of RFC4210 says that senderKID MUST be used if a NULL-DN is set
> for the sender.  This isn't explicitly stated here.

[HB] Good point. This profile generally requires that the senderKID is present.
OLD
     senderKID                   RECOMMENDED
       -- MUST be the SubjectKeyIdentifier of the CMP protection
       -- certificate in case of signature-based protection
NEW
     senderKID                   REQUIRED
       -- MUST be set
       -- MUST be the SubjectKeyIdentifier of the CMP protection
       --   certificate in case of signature-based protection

> 
> Related, a recipient is REQUIRED, but there is no mention of the recipientKID
> field.  If recipient is NULL, should it be used?

[HB] recipKID is supposed to be used only when DH keys are used for
message protection. Currently the profile only support MAC- and signature-based
protection and does not offer protection using KEM keys.
RFC4210 Section 5.1.1. stats:
   senderKID and recipKID are usable to indicate which keys have been
   used to protect the message (recipKID will normally only be required
   where protection of the message uses Diffie-Hellman (DH) keys).

As draft-ietf-lamps-rfc4210bis plans to extend the document to support 
of KEM keys, recipKID may also be required.

> 
> ** Section 3.1.
>      recipNonce                  RECOMMENDED
>        -- If this is the first message of a transaction: SHOULD be
>        -- absent
>        -- If this is a delayed response message: MUST be present and
>        -- contain the value of the senderNonce of the respective request
>        -- message in the same transaction
>        -- In all other messages: MUST be present and contain the value
>        -- of the senderNonce of the previous message in the same
>        -- transaction
> 
> I'm struggling with the top-line "RECOMMENDED" guidance.  The subsequent
> text says that it is "MUST" for asynchronous ("delayed response") messages.
> This is true in a number of other cases where the top-level field is defined as
> OPTIONAL or RECOMMENED, but the underlying guidance says that it is required
> (MUST) under certain circumstances.  Perhaps explain that approach.

[HB] This looks like a contradiction. In Section 3 we want to express the main 
line. In Sections 4 and 5 there may be further requirements specified that apply 
in a specific case together with some general guidance.
We will add a paragraph explaining this to Section 3.

NEW
Note:  In the description of CMP messages, the presence of some fields is stated 
as OPTIONAL or RECOMMENDED.  The following text may state requirements on the 
same fields apply only if the field is present.

Change to Section 3.1
OLD
     recipNonce                  RECOMMENDED
       -- If this is the first message of a transaction: SHOULD be
       -- absent
NEW
     recipNonce                  RECOMMENDED
       -- If this is the first message of a transaction: MUST be
       -- absent

> 
> ** Section 3.2.
>    Any
>    included keyUsage extension SHOULD allow digitalSignature.
> 
> What would be the situation where the keyUsage couldn't include
> digitalSignature?  Why can't this be a MUST?

[HB] Right
OLD
   Any
   included keyUsage extension SHOULD allow digitalSignature.
NEW
   If
   the keyUsage extension is present, it MUST include digitalSignature.

> 
> ** Section 3.2.
> 
>    Generally, CMP messages MUST be protected, but there are cases where
>    protection of error messages specified in Section 3.6.4 is not
>    possible and therefore MAY be omitted.
> 
> Recommend restating this text so it doesn't mix a MUST and MAY.  Perhaps:
> 
> All CMP messages but those carrying error messages MUST be protected.  CMP
> error messages SHOULD be protected when possible.  See Section 3.6.4 for use
> cases where this would not be possible.

[HB] Thank you for this proposal. I take your proposal.

> 
> ** Section 3.5.  Given that error messages might not be protected:
> 
> OLD
> The message protection MUST be validated:
> 
> NEW
> The message protection MUST be validated when present:

[HB] Proposal:
OLD
   *  The message protection MUST be validated:
      -  The protection MUST be signature-based except if
         o  MAC-based protection is used as described in Section 4.1.5
            and Section 4.1.6.3 or
         o  protection is omitted in certain error messages as described
            in Section 3.6.4.
NEW
   *  Messages without protection MUST be rejected except for error
      messages as described in Section 3.6.4.
   *  The message protection MUST be validated when present and messages
      with an invalid protection MUST be rejected.
      - The protection MUST be signature-based except if MAC-based
        protection is used as described in Section 4.1.5 and Section
        4.1.6.3.

> 
> ** Section 3.5.  The text in Section 3.1. says that the senderKID MUST point to the
> key material (but the presence of that field is optional under many
> circumstances).
> 
> OLD
> The senderKID SHOULD identify the key material used for
>          verifying the message protection.
> 
> NEW
> If present, the senderKID MUST identify the key material used for verifying the
> message protection.

[HB] Thanks, will be changed
OLD
      -  The senderKID SHOULD identify the key material used for
         verifying the message protection.
NEW
      -  If present, the senderKID MUST identify the key material
         needed for verifying the message protection.

> 
> ** Section 3.5.  Should validation guidance around the implicitConfirm value be
> stated?

[HB] This section only covers the generic validation aspects, while generalInfo 
field contents (to which implicitConfirm belongs) are typically dependent on the 
message type.  Therefore, guidance on handling these fields are given in the 
respective sections below.  Moreover, we already state that contents of this 
field should be handled gracefully.

> 
> ** Section 3.5.
> 
>       If the messageTime is present, it SHOULD be close to the current
>       time. (failInfo bit: badTime)
> 
> Can any generic guidance be given for what this threshold of "close" should be?
> If not, add that the value set for this time threshold will be vary by use case.

[HB] Good point. RFC4210 says that
   The messageTime field contains the time at which the sender created
   the message.  This may be useful to allow end entities to correct/
   check their local time for consistency with the time on a central
   system.
and
   messageTime           time of production of message
     -- current time at requesting CA 

Therefore, I propose the following change:
OLD
   *  If the messageTime is present, it SHOULD be close to the current
      time. (failInfo bit: badTime)
NEW
   *  If the messageTime is present and
       - the receiving system has a reliable system time, the messageTime
         SHOULD be close to the current time of the receiving system,
         where the threshold will vary by use case. (failInfo bit: badTime)
       - the receiving system does not have a reliable system time, the
         messageTime MAY be used for time synchronization.

> 
> ** Section 3.6.1
> 
>    In case
>    they expect a further message from the EE, a connection interruption
>    or timeout will occur.
> 
> Are timeouts timed to standardized protocol behavior or will they be
> application/use case specific in the case of asynchronous exchanges?

[HB] Timeouts will be application/use case specific. 
OLD
   In case
   they expect a further message from the EE, a connection interruption
   or timeout will occur.
NEW
   In case
   they expect a further message from the EE, a connection interruption
   or timeout will occur.  The value set for such timeouts will vary by
   use case.

> 
> ** Section 4.1.1
> 
>   If the EE
>    successfully received the certificate, it MUST send a certConf
>    message in due time.
> 
> What is a recommended timer for "due time"?  If this if application or use case
> specific, please say that.

[HB] this is a good point. Finally, it is an application / use case specific time 
the CA is intended to wait.
Using the confirmWaitTime the CA could add to the header of the response message to 
let the EE know for how long it intends to wait for a certConf.
To reduce complexity, we did not specify this option, but potentially we should do so.
We could add in Section 3.1 to the generalInfo in the PKIHeader:
NEW
       confirmWaitTime           OPTIONAL
       -- RECOMENDED in ip/cp/kup messages if implicitConfirm is
       --   not included
       -- PROHIBITED if implicitConfirm is included
       -- See [RFC4210] Section 5.1.1.2.
        ConfirmWaitTimeValue     REQUIRED
       -- ConfirmWaitTimeValue MUST be a GeneralizedTime value specifying
       --   the point in time up to which the PKI management entity will
       --   wait for the certConf message. The accepted length of the
       --   waiting period will vary by use case.

In addition to this change I propose the following changes:

Section 4.1.1
OLD
   In case the PKI management entity does not need any explicit
   confirmation from the EE, it MUST include the extension as described
   in Section 3.1.  This prevents explicit certificate confirmation and
   saves the overhead of a further message round-trip.
NEW
   In case the PKI management entity does not need any explicit
   confirmation from the EE, it MUST include the generalInfo field
   implicitConfirm. Otherwise, it SHOULD include confirmWaitTime as
   described in Section 3.1.  This prevents explicit certificate
   confirmation and saves the overhead of a further message round-trip.

Section 5.1.1
OLD
   Note: If the EE requested omission of the certConf message, the PKI
   management entity SHOULD handle it as described in Section 4.1.1 and
   therefore MAY grant this by including the implicitConfirm extension
   in the response header.
NEW
   Note: If the EE requested omission of the certConf message, the PKI
   management entity SHOULD handle it as described in Section 4.1.1.
   Therefore, it MAY grant this by including the implicitConfirm
   generalInfo field or include the confirmWaitTime in the response header.

> 
> ** Section 4.1.4.
> ... using a legacy PKCS#10 [RFC2986] request
> 
> Why is RFC2986 characterized as "legacy"?  In IETF standards parlance, it is not.

[HB] You are right, this is not precise. RFC4210 states in Section 5.3.3
   Alternatively, the PKIBody MAY be a CertificationRequest (this
   structure is fully specified by the ASN.1 structure
   CertificationRequest given in [PKCS10]).  This structure may be
   required for certificate requests for signing key pairs when
   interoperation with legacy systems is desired, but its use is
   strongly discouraged whenever not absolutely necessary.
This means that p10cr may be used to interoperate to legacy CA.
OLD
   This PKI management operation can be used by an EE to request a
   certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF
   [RFC4211].
NEW
   This PKI management operation can be used by an EE to request a
   certificate using PKCS#10 [RFC2986] format to interoperate with
   CAs not supporting CRMF [RFC4211].

> 
> ** Section 4.1.5.  The CMP Message Header guidance in Section 3.1. says that
> "In case a message has MAC-based protection the changes are described in
> Section 4.1.5.  The variations will affect the fields sender, protectionAlg, and
> senderKID.".  This section provides guidance on senderKID.
> 
> It is silent on how to populate sender.

[HB] Good point.
OLD
   2  The senderKID MUST contain a reference the recipient can use to
      identify the shared secret information used for the protection,
      e.g., the username of the EE.
NEW
   2  In case the sending entity does not know its own name by now, it MUST
      put the NULL-DN into the sender field. The senderKID MUST contain a
      reference the recipient can use to identify the shared secret
      information used for the protection, e.g., the username of the EE.

> 
> Per protectionAlg, it says:
> 
> See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for
>    details on message authentication code algorithms (MSG_MAC_ALG) to
>    use.
> 
> I was expecting something stronger:  The value of protectionAlg MUST be an
> MSG_MAC_ALG algorithm specified in [I-D.ietf-lamps-cmp-algorithms]?

[HB] As CMP Algorithms is not supposed to be a complete list of allowed 
algorithms, I think this wording is fine.
See CMP Algorithms Section 7.2
   The following table contains definitions of algorithms which MAY be
   supported by implementations of the Lightweight CMP Profile
   [I-D.ietf-lamps-lightweight-cmp-profile].

   As the set of algorithms to be used for implementations of the
   Lightweight CMP Profile heavily depends on the PKI management
   operations implemented, the certificates used for message
   protection, and the certificates to be managed, this document will
   not specify a specific set that is mandatory to support for
   conforming implementations.

> 
> ** Section 4.1.5.
> 
>    The PKI management entity checking the MAC-
>    based protection SHOULD replace this protection according to
>    Section 5.2.3 in case the next hop does not know the shared secret
>    information.
> 
> What is the alternative suggested by the SHOULD on following the procedures
> of Section 5.2.3?  Is it failing and sending back an error?

[HB] We use SHOULD because the PKI management entity may not know whether the
next hop knows the shared secret. If the next hop does not know the needed
shared secret, it will send back an error.

> 
> ** Section 4.1.6.
> 
>    This PKI management
>    entity MUST use a certificate containing the additional extended key
>    usage extension id-kp-cmKGA in order to be accepted by the EE as a
>    legitimate key generation authority.
> 
> Should the EE consider the response invalid if it doesn't see the id-kpcmKGA
> EKU?

[HB] Further guidance for the EE on KGA certificate validation comes later in
the text:
   The EE SHOULD validate the
   signer certificate contained in the SignedData structure and verify
   the presence of this extended key usage in the signer certificate.

   Note: When using password-based key management technique as described
   in Section 4.1.6.3 it may not be possible or meaningful to the EE to
   validate the KGA signature and the related certificate in the
   SignedData structure since shared secret information is used for
   initial authentication.  In this case the EE MAY omit this
   validation.

But we could change accepted-> acceptable her
OLD
   This PKI management
   entity MUST use a certificate containing the additional extended key
   usage extension id-kp-cmKGA in order to be accepted by the EE as a
   legitimate key generation authority.
NEW
   This PKI management
   entity MUST use a certificate containing the additional extended key
   usage extension id-kp-cmKGA in order to be acceptable by the EE as a
   legitimate key generation authority.

> 
> ** Section 4.1.6
> 
>    Note: When performing central key generation for a certificate
>    update, the KGA cannot use the old EE credentials for protection.
>    Therefore, the PKI management operation described in Section 4.1.2
>    SHOULD be used instead of Section 4.1.3 to request a certificate for
>   the newly generated key pair on behalf of the EE.
> 
> Should the use of procedure in Section 4.1.3 be explicitly prohibited in this KGA
> use case?

[HB] When changing the text, I would also propose not to declare it as 'Note'.
OLD
   Note: When performing central key generation for a certificate
   update, the KGA cannot use the old EE credentials for protection.
   Therefore, the PKI management operation described in Section 4.1.2
   SHOULD be used instead of Section 4.1.3 to request a certificate for
   the newly generated key pair on behalf of the EE.
NEW
   When an EE requests central key generation for a certificate update
   using a kur message, the KGA cannot use a kur message to request the
   certificate on behalf of the EE as the old EE credential is not
   available to the KGA for protecting this message.  Therefore, if the
   EE uses the PKI management operation described in Section 4.1.3, the
   KGA MUST use Section 4.1.2 to request the certificate for the newly
   generated key pair on behalf of the EE from the CA.

> 
> ** Section 4.1.6.  Typo.
> 
> OLD
>    and support of key transport and
>    password-based key management techniques are OPTION
> 
> NEW
> and support of key transport and password-based key management techniques
> are OPTIONAL

[HB] Thank you, will change it

> 
> ** Section 4.1.6
> 
>   The password-
>    based key management technique shall only be used in combination with
>    MAC-based protection, which is a sideline in this document.
> 
> What does it mean for MAC-based protection to be "a sideline"?

[HB] In Section 1.6 we state
    *  signature-based protection is the default protection; an initial
      PKI management operation may also use MAC-based protection,
If it confuses the reader, we can easily delete 'which is a sideline in
this document' and use normative language.
OLD
   The password-
   based key management technique shall only be used in combination with
   MAC-based protection, which is a sideline in this document.
NEW
   The password-
   based key management technique SHALL only be used in combination with
   MAC-based protection.

> 
> ** Section 4.1.6.  Why is "privateKey" OPTIONAL"?

[HB] Right. In a general response message, as define in Section 4.1.1 it
is OPTIONAL, but here it is REQUIRED.
OLD
           privateKey            OPTIONAL
NEW
           privateKey            REQUIRED

> 
> ** Section 4.1.6.  Editorial.
> 
>              encryptedContentInfo
>                                  REQUIRED
> ...
>                contentEncryptionAlgorithm
>                                  REQUIRED
> 
> The cardinality of these fields is on a separate line from the field name

[HB] I used indentation and the field names are long. Therefore, I could not 
place the cardinality into the same line without further indentation.
This is a similar solution as in the ASN.1 module in RFC4210 Appendix F, e.g.,
      PKIMessage ::= SEQUENCE {
         header           PKIHeader,
         body             PKIBody,
         protection   [0] PKIProtection OPTIONAL,
         extraCerts   [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL
     }
or
     CertRepMessage ::= SEQUENCE {
         caPubs       [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL,
         response         SEQUENCE OF CertResponse
     }
But I am open for a different formatting if it eases reading.

> 
> ** Section 4.1.6.  Typo. s/ see and [RFC8933]/see [RFC8933]/

[HB] Thank you
OLD
       -- algorithm specified in signatureAlgorithm, see and [RFC8933]
NEW
       -- algorithm specified in signatureAlgorithm, see [RFC8933]

> 
> ** Section 4.1.6.
> 
>                    digestAlgorithm
>                                  REQUIRED
>        -- MUST be the same as in digestAlgorithms
> 
> 
> Perhaps "MUST be the same as in the digestAlgorithms field of
> encryptedContent"

[HB] Good point
OLD
       -- MUST be the same as in digestAlgorithms
NEW
       -- MUST be the same as in the digestAlgorithms field of
       --   encryptedContent

> 
> ** Section 4.1.6.1.  Per "-- MUST be used when 1-pass ECMQV is used", please
> cite RFC3278.

[HB] OK
OLD
       -- MUST be used when 1-pass ECMQV is used
NEW
       -- MUST be used when 1-pass ECMQV is used, see [RFC3278]

> 
> ** Section 4.2.  Editorial. s/In case no generic error occurred/In the case that no
> generic error occurred,/

[HB] Yes
OLD
   In case no generic
   error occurred the response to the rr MUST be an rp message
   containing a single status field.
NEW
   In the case no generic
   error occurred, the response to the rr MUST be an rp message
   containing a single status field.

> 
> ** Section 4.3.  Editorial.
> 
> OLD
>    In the following the aspects common to all general messages (genm)
>    and general response (genp) messages are described.
> 
> NEW
> The following message flow is common to all general messages (genm) and
> general response (genp) messages.

[HB] With adaptations
OLD
   In the following the aspects common to all general messages (genm)
   and general response (genp) messages are described.
NEW
   The following message flow and contents are common to all general
   message (genm) and general response (genp) messages.

> 
> ** Section 4.3.1
> 
> OLD
>        -- MUST be present if CA certificates are available
>        -- MUST be a sequence of CMPCertificate
> 
> NEW
>        -- MUST be present if CA certificates are available
>        -- if present, MUST be a sequence of CMPCertificate

[HB] Good point, will change it accordingly

> 
> ** Section 4.3.4.
> 
>    if available, the
>    thisUpdate time of the most current CRL instance it already has, as
>    specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates].
> 
> The reference should be Section 2.17 of cmp-updates.

[HB] Thank you for spotting this!

> 
> ** Section 4.3.4
> 
> (a) If no thisUpdate value was given by the EE, the PKI
>    management entity MUST return the latest CRL available.
> 
> (b) If a
>    thisUpdate value was given, the PKI management entity MUST return the
>    latest available CRL in case this CRL is more recent, otherwise the
>    infoValue in the response message MUST be absent.
> 
> Given the above guidance, the role of the thisUpdate field isn't clear.  The
> guidance around (a) is clear - if the requestor doesn't have a thisUpdate, send
> back the latest CRL.  However, my read of the text for  (b) is that the PKI
> management entity will check the thisUpdate is received but still return the
> latest CRL just in case.  That seems identical to the behavior in (a), so why the
> distinction and why bother even sending the thisUpdate if the new CRL is always
> returned?  I was expecting that if the last updated version of the CRL is before
> the thisUpdate in the request, the PKI management entity wouldn't send
> anything back.

[HB] Your expectation is right, the PKI management entity should only send the 
latest CRL, if it is younger than thisUpdate. I tried to express this with 'in 
case this CRL is more recent'.
Is my below proposal more clear?
OLD
   If a
   thisUpdate value was given, the PKI management entity MUST return the
   latest available CRL in case this CRL is more recent, otherwise the
   infoValue in the response message MUST be absent.
NEW
   If a
   thisUpdate value was given, the PKI management entity MUST return the
   latest available CRL if this CRL has a more recent thisUpdate time.
   Otherwise, the infoValue in the response message MUST be absent.

> 
> ** Section 4.3.4.  Typo. s/provided form the/provided from the/

[HB] Thank you for spotting this.

> 
> ** Section 4.3.4.  What is the difference between the normative guidance in
> these two sentences of this section?
> 
> -- The EE MUST identify the requested CRL either by its CRL distribution
>    point name or issuer name.
> 
> -- In addition to the prerequisites specified in Section 3.4, the EE
>    MUST know which CRL to request.
> 
> Are both needed?

[HB] You are right, it is partly redundant. 
A paragraph like the second sentence you listed, is present in every 
sub-section of Section 4 to express the deviations to the generic PKI 
management operations prerequisites specified in Section 3.4.

> 
> ** Section 4.3.4.  In considering how the EE gets the value of the thisUpdate
> timestamp to use in the transaction described in this section -- if the PKI
> management entity does NOT return a thisUpdate, what should the EE do?
> Does the EE store a timestamp of when it got it response and declare that the
> thisUpdate value, or does it store this empty value?

[HB] The EE is supposed to provide the thisUpdate time of the latest CRL it 
has.
If it does not have any instance of that CRL, it omits the field.

This should have been expressed by this sentence:
   The EE MUST include
   the CRL source identifying the requested CRL and, if available, the
   thisUpdate time of the most current CRL instance it already has, as
   specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates].

To make it even more explicit, I propose the following change.
OLD
         thisUpdate              OPTIONAL
       -- SHOULD contain the thisUpdate field of the latest CRL form
       -- the issuer specified in the given dpn or issuer field,
       -- in case such a CRL is already known by the EE
NEW
         thisUpdate              OPTIONAL
       -- SHOULD contain the thisUpdate field of the latest CRL the EE
       --   has got from the issuer specified in the given dpn or
       --   issuer field,
       -- MUST be omitted if the EE does not have any instance of the requested CRL

> 
> ** Section 5.1
> 
>    In addition to the checks described in Section 3.5, the responding
>    PKI management entity SHOULD check that a request that initiates a
>    new PKI management operation does not use a transactionID that is
>    currently in use.
> 
> Should this be a MUST?  Why would reuse of the transactionID be acceptable?

[HB] RFC4210 does not strictly require uniqueness of transactionIDs, but it 
makes sense that this profile does.
OLD
   PKI management entity SHOULD check that a request that initiates a
NEW
   PKI management entity MUST check that a request that initiates a

> 
> ** Section 5.1.
> 
> The responding PKI management entity SHOULD copy the sender field of
>    the request to the recipient field of the response ...
> 
> Again, should this be a MUST?  Is this because the RA might use the CA's value
> for the sender field?

[HB] the sender and recipient fields in the PKIHeader are of no practical use. 
They are required mainly for backward compatibility with CMP V1.
Therefore, this profile provides guidance how to populate them using a SHOULD 
but not a MUST, see also Section 3.1.

> 
> ** Section 5.1.1.  Similar comment to Section 5.1.2 and 5.1.3.
> 
>    The PKI management entity SHOULD check the message body according to
>    the applicable requirements from Section 4.1.
> 
> Are you should you need normative language here?  It seems confusing to say
> that implementers "SHOULD" only (but not MUST) check that the protocol data
> is following the normative language already described.

[HB] You are right, it should be a MUST here
OLD
   The PKI management entity SHOULD check the message body according to
   the applicable requirements from Section 4.1.
NEW
   The PKI management entity MUST check the message body according to
   the applicable requirements from Section 4.1.

> 
> ** Section 5.1.1.  Editorial.
> 
> OLD
> The PKI management entity SHOULD perform also ...
> 
> NEW
> The PKI management entity SHOULD also perform ...

[HB] I will update that

> 
> ** Section 5.1.1.
> 
>    If the requested certificate is available, the PKI management entity
>    MUST respond with a positive ip/cp/kup message as described in
>    Section 4.1.
> 
> Isn't this a normative restatement of what was normatively already said in
> Section 5.1.1?

[HB] I do not fully understand this comment. Do you mean 'normatively already 
said in Section 4.1'?
The point here is that in case the cert is available, the PKI management entity 
must not send anything else, such as a negative response.

> 
> ** Section 5.2
> 
>    A PKI management entity SHOULD NOT change the received message unless
>    necessary.  The PKI management entity SHOULD only update the message
>    protection and the certificate template in a certificate request
>    message if this is technically necessary.
> 
> Can the intent to implementors be made clear.  "Necessary" or "technically
> necessary" judged by whom?  It's unlikely that a PKI management would
> randomly change something in the message so the changes it would make
> would be intentional.

[HB] OK, we should make the intention clearer.
OLD
   A PKI management entity SHOULD NOT change the received message unless
   necessary.  The PKI management entity SHOULD only update the message
   protection and the certificate template in a certificate request
   message if this is technically necessary.  Concrete PKI system
   specifications may define in more detail when to do so.
NEW
   A PKI management entity SHOULD NOT change the received message unless
   its role in the PKI system requires it.  This is because changes to
   the message header or body imply re-protection and changes to the
   protection breaks end-to-end authentication of the message source,
   and changes to the certificate template in a certificate request
   breaks proof-of-possession.  More details are available in the
   following sub-sections. Concrete PKI system specifications may define
   in more detail when to do so.

> 
> ** Section 5.2.2.1
> 
>    The PKI management entity wrapping the original request message in a
>    nested message structure MUST take over the recipient, recipNonce,
>    and transactionID of the original message to the nested message and
>    apply signature-based protection.
> 
> Can the actions involved in "take over" these fields be described?  Does this
> amount to the PKI management entity terminating the transaction and issuing a
> new transaction upstream?

[HB] What about this rephrasing
OLD
   The PKI management entity wrapping the original request message in a
   nested message structure MUST take over the recipient, recipNonce,
   and transactionID of the original message to the nested message and
   apply signature-based protection.
NEW
   The PKI management entity wrapping the original request message in a
   nested message structure MUST copy the values of the recipient,
   recipNonce, and transactionID header fields of the original message to
   the respective header fields of the nested message and apply
   signature-based protection.

> 
> ** Section 5.2.2.2.  Element of this use case description seem to conflict.
> 
> (a) In this use case,
>    nested messages are used both on the upstream interface towards the
>    next PKI management entity and on the downstream interface from the
>    PKI management entity towards the EE.
> 
> (b) If the RA needs different routing
>    information per nested PKI management message a suitable mechanism
>    may need to be implemented.
> 
> The text in (a) seems to suggest that if an RA accepts a batch downstream is will
> then batch upstream.  However, (b) seems to suggest that each message will be
> unpacked and routed as is appropriate.

[HB] I will rephrase the text. 

OLD
   In this use case,
   nested messages are used both on the upstream interface towards the
   next PKI management entity and on the downstream interface from the
   PKI management entity towards the EE.
NEW
   In this use case,
   nested messages are used both on the upstream interface towards the
   next PKI management entity and by that entity on its downstream
   interface.

and

OLD
   If the RA needs different routing
   information per nested PKI management message a suitable mechanism
   may need to be implemented.
NEW
   If the RA needs different routing
   information per nested PKI management message provided upstream, a
   suitable mechanism may need to be implemented to ensure that the
   downstream delivery of the response is done to the right requester.

> 
> ** Section 5.2.2.2
> 
>    While building the upstream nested message the PKI management entity
>    SHOULD store the sender, transactionID, and senderNonce fields of all
>    bundled messages together with the transactionID of the upstream
>    nested message.
> 
> If it doesn't store this information how could it support polling?  Shouldn't this
> be a MUST?

[HB] Right
OLD
   While building the upstream nested message the PKI management entity
   SHOULD store the sender, transactionID, and senderNonce fields of all
   bundled messages together with the transactionID of the upstream
   nested message.
NEW
   While building the upstream nested message the PKI management entity
   MUST store the sender, transactionID, and senderNonce fields of all
   bundled messages together with the transactionID of the upstream
   nested message.

And an editorial correct in the next paragraph:
OLD
   When it forwards the unbundled responses, any
   extra messages SHOULD be dropped, and any missing response message
   (failInfo bit: systemUnavail) MUST be answered with an error message
   to inform the respective requester about the failed certificate
   management operation.
NEW
   When it forwards the unbundled responses, any
   extra messages MUST be dropped, and any missing response message
   MUST be answered with an error message (failInfo bit: systemUnavail)
   to inform the respective requester about the failed certificate
   management operation.

> 
> ** Section 5.2.3.
> 
>    Before replacing the existing protection by a new protection, the PKI
>    management entity MUST verify the protection provided and approve its
>    content,
> 
> Will an intermediate PKI management entity always be in a position to "approve
> the content"?  What kind of verification satisfies "approval"?  Is this is the same
> as the prerequisites noted in Section 5.2.3.1?

[HB] Finally the required approval steps are solution specific. When replacing 
the protection by an RA, the original data origin authentication gets lost. 
Therefore, the RA must be in the position to do the approval. May be this 
rephrasing helps.
OLD
   Before replacing the existing protection by a new protection, the PKI
   management entity MUST verify the protection provided and approve its
   content, including any modifications that it may perform.  It MUST
   also check that the sender, as authenticated by the message
   protection, is authorized for the given operation.
NEW
   Before replacing the existing protection by a new protection, the PKI
   management entity MUST 
   *  validate the protection of the received message,
   *  check the content of the message,
   *  do any modifications that it may want to perform, and 
   *  check, that the sender of the original message, as
      authenticated by the message protection, is authorized for
      the given operation.

> 
> ** Section 5.2.3
> 
>    When an intermediate PKI management entity modifies a message, it
>    SHOULD NOT change the transactionID nor the sender and recipient
>    nonces.
> 
> This guidance doesn't seem to square against Section 4 explicitly saying that
> (i.e., that they MUST NOT):
> 
>    Note: All CMP messages belonging to the same PKI management operation
>    MUST have the same transactionID because the message receiver
>    identifies the elements of the operation in this way.
> 
> Are the transactions between the EE-to-Intermediate-PKI considered different
> than Intermediate-PKI-to-Next-PKI-element?

[HB] Good Point. It should be MUST NOT here.
To properly forward the response, it is crucial that the transactionID, sender
nonce, and recipient nonce are identical.

OLD
   When an intermediate PKI management entity modifies a message, it
   SHOULD NOT change the transactionID nor the sender and recipient
   nonces.
NEW
   When an intermediate PKI management entity modifies a message, it
   MUST NOT change the transactionID, the senderNonce, or the
   recipNonce - apart from the exception for the recipNonce
   given in Section 5.1.5.

> 
> ** Section 5.2.3.1.  It would have been useful to see the examples of what it
> means to "break a proof of possession" in this session where the idea is first
> introduced rather than in Section 5.2.3.2.

[HB]
OLD
   This variant of forwarding a message means that a PKI management
   entity forwards a CMP message with or without modifying the message
   header or body while preserving any included proof-of-possession.
NEW
   This variant of forwarding a message means that a PKI management
   entity forwards a CMP message with or without modifying the message
   header or body while preserving any included proof-of-possession.

   Note: A signature-based proof-of-possession of a certificate request
   will be broken if any field in the certTemplate structure is changed.

> 
> ** Section 5.3.1.  Typo. s/A PKI management entity may use on of/A PKI
> management entity may use one of/

[HB] Thank you

> 
> ** Section 5.3.1
> 
>    In the latter
>    case it SHOULD verify the received proof-of-possession.
> 
> Under what circumstances would one not want to verify the PoP?

[HB] Good point. As long as the PoP in the new request message sent upstream is
intact, e.g., the format (PKCS#10 or CRMF) and certificate request content is not 
changed, the RA is not necessarily required to verify the PoP. In case the PoP gets 
broken, e.g., by transcoding from a PKCS#10 request to a CRMF request, the PoP MUST 
be verified. 
OLD
   It either generates the key pair itself and
   inserts the new public key in the subjectPublicKey field of the
   request certTemplate, or it uses a certificate request received from
   downstream, e.g., by means of a different protocol.  In the latter
   case it SHOULD verify the received proof-of-possession.
NEW
   It either generates the key pair itself and
   inserts the new public key in the subjectPublicKey field of the
   request certTemplate, or it uses a certificate request received from
   downstream, e.g., by means of a different protocol.  In the latter
   case it MUST verify the received proof-of-possession if this proof
   breaks, e.g., due to transformation from PKCS#10 to CRMF certificate
   request format.

> 
> ** Section 6.  If there a formal definition of a "CMP client component" and
> "CMP server component"?  If not, perhaps "CMP client component (e.g., an EE
> or an RA communicating with a CA)".

[HB] We made the wording more explicit.

OLD 
   To
   prevent waiting indefinitely, each CMP client component SHOULD use a
   configurable per-request timeout, and each CMP server component
   SHOULD use a configurable per-response timeout in case a further
   Request message is to be expected from the client side within the
   same transaction.
NEW
   To
   prevent waiting indefinitely, each CMP client SHOULD use a
   configurable per-request timeout, and each PKI entity that sends CMP
   requests SHOULD use a configurable per-request timeout, and each PKI
   management entity that handles CMP requests SHOULD use a configurable
   per-response timeout in case a further request message is to be
   expected from the client side within the same transaction.

> 
> ** Section 6.
> 
>    The transport layer itself may cause delays, for instance due to
>    offline transport, network segmentation, or intermittent network
>    connectivity.  Part of these issues can be detected and handled at
>    CMP level using pollReq and pollRep messages as described in
>    Section 4.4, while others are better handled at transfer level.
> 
> The first sentence says "transport layer" but the second sentence says "transfer
> level."  Is there a meaningful distinction being made?  If not, please use the
> same term.  Otherwise, define the difference.

[HB] Maybe we are wrong, but we refer to TCP and UDP as transport layer protocols 
and, e.g., HTTP as an example for a transfer level protocol on application layer.
RFC6712 uses the term transfer level or transfer protocols. Therefore, we usually 
use this term in the draft as well. 
Where I use transport protocol or transport layer, I specifically refer to it.
For more clarity we will update the following sentence.

OLD
   HTTP SHOULD
   and CoAP MAY be used for online transfer.
NEW
   HTTP SHOULD
   be used and CoAP MAY be used for online transfer of CMP messages
   on application layer.

> 
> ** Section 6.
> 
>    Long timeout periods are helpful to minimize the need for
>    polling and maximize chances to handle transfer issues at lower
>    levels.
> 
> Is this assertion true because an EE would not poll if the connection making the
> request is still open?  If so, that isn't clear from the profile.

[HB] What we wanted to say is, that if long timeout periods are used, the chance 
is higher that the response will be received, even if there are technical issues 
to deliver the message.
With a short timeout, the client may terminate the PKI management operation. Polling 
will anyhow only be initiated if the client receives a response containing the status 
"waiting". This could happen if the server realizes the connection has timed out but 
there is no response from upstream. But this is not the important point here.
With regard to your previous comment, I anyhow propose this change:
OLD
   Note: Long timeout periods are helpful to minimize the need for
   polling and maximize chances to handle transfer issues at lower
   levels.
NEW
   Note: Long timeout periods are helpful to maximize chances to
   handle minor delays at lower layers without the need for polling.

> 
> ** Section 6.
> 
>    Note: When using TCP and similar reliable connection-oriented
>    transport protocols, which is typical in conjunction with HTTP, there
>    is the option to keep the connection alive over multiple request-
>    response message pairs.  This may improve efficiency, though is not
>    required from a security point of view.
> 
> I don't follow the security argument for doing multiple request-response pairs in
> a single connection vs. multiple ones.  It's clear that it doesn't apply here but the
> text is cautioning that it might apply someplace else and the reader shouldn't be
> confused.  What is that other use case?

[HB] You are right. It is unrelated here.
OLD
   This may improve efficiency, though is not
   required from a security point of view.
NEW
   This may improve efficiency.

> 
> ** Section 6.1.
> 
>    PKI management operations SHOULD use URI paths consisting of '/.well-
>    known/cmp/' or '/.well-known/cmp/p/<name>/' as specified in CMP
>    Updates Section 3.3 [I-D.ietf-lamps-cmp-updates]...
> 
> Is the guidance here on well-known intentionally different than draft-ietf-lamps-
> cmp-updates.  In that document CMP implementations "MUST support the use
> of the path prefix '/.well-known/' ..." - that is, there is an MTI of using .well-
> known.  Here the text allows for using something other than .well-known (but
> implicitly a compliant CMP implementation would still have to support .well-
> known).  What is the outcome desired - an MTI or .well-known but potentially
> using something else?

[HB] Right 
OLD
   PKI management operations SHOULD use URI paths consisting of '/.well-
   known/cmp/' or '/.well-known/cmp/p/<name>/' as specified in CMP
   Updates Section 3.3 [I-D.ietf-lamps-cmp-updates] followed by an
   operation label depending on the type of PKI management operation.
NEW
   PKI management operations MUST use URI paths consisting of '/.well-
   known/cmp/' or '/.well-known/cmp/p/<name>/' as specified in CMP
   Updates Section 3.3 [I-D.ietf-lamps-cmp-updates]. It SHOULD be followed
   by an operation label depending on the type of PKI management operation.

> 
> ** Section 6.1.  Per the discussion on using TLS
> -- would the recommendations of draft-ietf-uta-rfc7525bis apply?

[HB] Yes
OLD
   TLS SHOULD be used with certificate-based authentication to further
   protect the HTTP transfer as described in [RFC2818].
NEW
   TLS SHOULD be used with certificate-based authentication to further
   protect the HTTP transfer as described in [RFC9110]. In addition,
   the recommendations provided in [draft-ietf-uta-rfc7525bis] SHOULD
   be considered.

I also propose to perform similar changes to Section 6.2OLD
   Like for HTTP transfer , to offer a second line of defense or to
   provide hop-by-hop privacy protection, DTLS MAY be utilized as
   described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport].
NEW
   Like for HTTP transfer, to offer a second line of defense or to
   provide hop-by-hop privacy protection, DTLS MAY be utilized as
   described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport].
   If DTLS is utilized, the same boundary conditions (peer
   authentication, etc.) as stated for TLS to protect HTTP transfer
   in Section 6.1 apply to DTLS likewise.
> 
> -- should the provisioning of client certifications and PSKs be declared out of
> scope

[HB] Yes, I will add a note not at the end of Section 6.1 and 6.2.
NEW
   Note: The provisioning of client certificates and PSKs is out of
   scope of this document.

> 
> ** Section 7.1.  Per RevROnB, should one be concerned that a RA and CA might
> not support revocation.  Let's presuppose a system was compromised, and
> incident response is being performed and the device is not involved.  The
> procedures in Section 5.3.2 would need to be invoked.  If they aren't an option,
> what would be the alternative?

[HB] The alternative would be to do revocation on the CA without using CMP, 
for instance, using a local admin interface. But this is out of scope of this 
document and therefore not explicitly listed. We will ad an additional footnote 
to clarify this.

NEW
   3) An alternative would be to perform revocation at the CA
   without using CMP, for instance using a local administration
   interface.

> 
> ** Section 7.2.  Normative guidance on HTTP.
> 
> (a) Table 4: HTTP is a SHOULD for EE, RA, and CA
> 
> (b) Section 7.2: HTTP transfer is RECOMMENDED to use for all PKI entities
> 
> (c) Section 6: HTTP SHOULD and CoAP MAY be used for online transfer.
> 
> Can these be harmonized?

[HB] I do not see a contradiction. But I propose the following changes.

Delete 'HTTP SHOULD and CoAP MAY be used for online transfer.' in Section 6.

Section 7.2
OLD
   HTTP transfer is RECOMMENDED to use for all PKI entities for
   maximizing general interoperability at transfer level, yet full
   flexibility is retained to choose whatever transfer mechanism is
   suitable, for instance for devices and system architectures with
   specific constraints.
NEW
   HTTP SHOULD be supported and CoAP MAY be supported at all PKI
   entities for maximizing general interoperability at transfer
   level. Yet full flexibility is retained to choose whatever
   transfer mechanism is suitable, for instance for devices and
   system architectures with specific constraints.

> 
> ** Per IDNits:
> 
>   -- Obsolete informational reference (is this intentional?): RFC 2818
>      (Obsoleted by RFC 9110)
> 
> I believe that RFC2818 can be safely replaced with RFC9110.

[HB] RFC9110 explicitly specifies use of TLS 1.3. For backward compatibility 
Section 6.1 also allows for TLS 1.2. But I think this should not hinder switching 
from RFC2818 to RFC9110, right?