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

[Roman Danyliw <[e-mail]>]

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://www.ietf.org/mailman/listinfo/spasm