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

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

Hi Roman

Thank you for this feedback and for your effort supporting the draft!

Hendrik 

> -----Ursprüngliche Nachricht-----
> Von: Roman Danyliw <[e-mail]>
> Gesendet: Montag, 10. Oktober 2022 17:56
> An: Brockhaus, Hendrik (T CST SEA-DE) <[e-mail]>
> Cc: [e-mail]; von Oheimb, David (T CST SEA-DE)
> <[e-mail]>; Fries, Steffen (T CST)
> <[e-mail]>
> Betreff: RE: AD Review of draft-ietf-lamps-lightweight-cmp-profile-13
> 
> Hi Hendrik!
> 
> Thanks for the detailed response and all of the effort to produce the revisions in
> -14.   Consider my feedback below resolved.  I've requested IETF Last Call on the
> document.
> 
> Regards,
> Roman
> 
> > -----Original Message-----
> > From: Spasm <[e-mail]> On Behalf Of Brockhaus, Hendrik
> > Sent: Thursday, September 29, 2022 4:29 AM
> > To: Roman Danyliw <[e-mail]>
> > Cc: [e-mail]; von Oheimb, David <[e-mail]>;
> > Fries, Steffen <[e-mail]>
> > Subject: Re: [lamps] AD Review of draft-ietf-lamps-lightweight-cmp-profile-13
> >
> > 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?
> >
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fspasm&amp;data=05%7C01%7Chendrik.brockha
> us%40siemens.com%7C4640bccb045c4c85eba908daaad7e63a%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C638010141518252199%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=vhY1Fhvdhz2D0exgUC8wbI
> XhZE9dcp5755rnvN7VbAQ%3D&amp;reserved=0