Re: [lamps] Robert Wilton's No Objection on draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)

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

Robert

Thank you for your review and comments.
See my responses below.

Hendrik

> Von: Robert Wilton via Datatracker <[e-mail]>
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (1) p 7, sec 1.5.  Use of CMP in SZTP and BRSKI Environments
> 
>    In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other
>    environments using NETCONF/YANG modules, SZTP-CSR
>    [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes
>    different types of certificate requests to obtain a public-key
>    certificate for a locally generated key pair.  One option is using a
>    CMP p10cr message.  Such a message is of the form ietf-ztp-types:cmp-
>    csr from module ietf-ztp-csr and offers both proof-of-possession and
>    proof-of-identity.  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.
> 
> Given the MUST statement above, should this document "update"
> ietf-netconf-sztp-csr?

[HB] Back then ietf-netconf-sztp-csr the authors did not want to refer to the Lightweight CMP Profile draft, as it was still draft and they did not what to have any additional dependencies. I personally would have appreciated a reference to this document.
Our goal was to say, 'if you are using ietf.ztp-types:cmp-csr and also want to comply with this profile, you MUST ...'

Answering your comment, I remembered that there was a last-minute change to the ietf-netconf-sztp-csr draft.
In the latest version it says:
     identity cmp-csr {
       base certificate-request-format;
       description
         "Indicates that the ZTP-client supports generating
          requests using a profiled version of the PKIMessage
          that MUST contain a PKIHeader followed by a PKIBody
          containing only the ir, cr, kur, or p10cr structure
          defined in RFC 4210.";
       reference
         "RFC 4210: Internet X.509 Public Key Infrastructure
                    Certificate Management Protocol (CMP)";
     }

This means, that sztp-csr not only supports p10cr, but also ir, cr, and kur certificate request messages.
Therefore, I propose the following change:
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 that use the module ietf-ztp-csr and 
   also wish to comply with this profile, the ir, cr, kur, or p10cr message 
   MUST be formatted by the EE as described in Section 4.1, and it MAY
   be forwarded as specified in Section 5.2.

> 
> (2) p 7, sec 1.5.  Use of CMP in SZTP and BRSKI Environments
> 
>    In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
>    environments, BRSKI-AE: Alternative Enrollment Protocols in BRSKI
>    [I-D.ietf-anima-brski-ae] describes a generalization regarding the
>    employed enrollment protocols to allow alternatives to EST [RFC7030].
>    For the use of CMP, it requires adherence to this profile.
> 
> Similar to my comment above, should the "requires adherence" be "MUST
> adhere",
> and should this document "update" (BRSKI) [RFC8995]?

[HB] Good Point. Finally, the normative sentence saying that this profile is
applicable is in BRSKI-AE Section 5.2. Therefore, the usage of non-normative 
language here is on purpose.