Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-21

# Internet AD comments for draft-ietf-lamps-lightweight-cmp-profile-15
CC @ekline

Thanks to Niklas Widell for the IoT-DIR review.

## Nits

### S3.1

* s/signthe/sign the/

### S4.1

* "allows for providing proof-of-possession any method that a key can used for"

  ->

  "allows for providing proof-of-possession using any method that a key can be used for"

  perhaps?

### S4.1.1

* "further requests MUST be sent using separate PKI management operation"

  ->

  "further requests MUST be sent using separate PKI management operations"?

### S4.2

* "requests the revocation of an own certificate" ->
  "requests the revocation of an owned certificate"?

### S4.3.4

* "to identify a CRL for which is available" ->
  "to identify a CRL for which information is available"?

Thank you for the work on this document, which although long I found quite easy to read.

Many thanks to Robert Sparks for his ART ART review: https://mailarchive.ietf.org/arch/msg/spasm/msD0CJEIXAeQnqDNawoqS28WPKY/ and to the authors for addressing his comments. I agree with him and haven't found any ART issues. I understand and share his concern about whether the document unintentionally allows behavior that the framework it is profiling would not, but I trust the working group and the responsible AD to have that covered.

Francesca

Section 1.7 uses a SHOULD NOT before that expression is defined in Section 1.9.

The bulk of the SHOULDs in this document would benefit from review and possible tuning.  SHOULD presents a choice for the implementer; it would be helpful to include with that choice some guidance about when one might legitimately deviate from what's stated.  If SHOULD is being used as "you really oughta do this, but you don't really have to and things will interoperate just fine", it doesn't deserve SHOULD; if what you mean is "yes you have to do this from now on, but we're retaining backward compatibility here" then it should say that explicitly.  In other cases, I wonder if you don't really mean MUST.

For instance, in 3.1, you have this:

    -- SHOULD contain a name representing the originator of the
    --   message; otherwise, the NULL-DN (a zero-length
    --   SEQUENCE OF RelativeDistinguishedNames) MUST be used

Looks great; I have no wiggle room.  Then you have this:

    -- SHOULD be the subject of the CMP protection certificate, i.e.,
    --   the certificate corresponding to the private key used to
    --   sign the message

Well, what if I don't do that?  Does anything break?  Can I just put whatever in there and everything still works?  If nothing breaks, why isn't this "MAY" or something that doesn't use a BCP 14 keyword?  If something breaks, why isn't this a MUST?

In 3.4:

"Each EE SHOULD know its own identity to fill the sender field."

What happens if I don't?  And what interoperability aspect fails if I don't know my own identity?  Should this be better expressed as "Each EE SHOULD fill the sender field with its own identity?"  Why isn't that a MUST?

The two SHOULDs at the bottom of 3.5 seem suspect too.  Since you're giving me a choice, I'm within specifications to consider the input valid if all of those tests fail.  Is that what's intended? 

I'm not going to get into any of them past the bottom of Section 3, but hopefully you can see what I'm getting at.  I would typically DISCUSS this pattern, but since I'm so late to the party, I'll leave it to Roman to decide how much this observation weighs on the strength of the document.

Firstly, thank you very much to the authors for writing this -- I especially liked Section 1.1 :-)

I have a number of editorial suggestions to (hopefully) further improve the document


1: Sec 1
"Therefore, this document aims at tailoring the available options and specifying at an adequate detail how" - "at an adequate detail how" seems to be missing "level"?
Actually, I think rewriting it as: "Therefore, this document aims to tailor the available options and specify how to use them in adequate detail to make the implementation of interoperable automated certificate management as straightforward and lightweight as possible." is more readable.

2: Sec 1.3
"are not deployed on-site but in a high protected data center environment" - s/high/highly/

3: Sec 1.6
"This results in violating the general rule that a certificate request transaction must include a certConf message (since moreover, using implicitConfirm is not allowed there, neither)."
You seem to have a bunch of double-negatives here -- I think the last word should be "either" or the "not" should be dropped.

4: Sec 1.7
"To minimize ambiguity and complexity through needless variety, this document specifies exhaustive requirements on generating PKI management messages on the sender side." - "on generating" or "for generating"

5: Sec 1.8
"Section 5 profiles responding to requests, exchange between PKI management entities, ..." -- exchanges

6: Sec 1.9
"The figure above shows an architecture example with at least one LRA" -- architectural... actually, I don't know, but the current seems wrong.

7: Sec 3.6.1
"An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in upstream direction, either." -- the upstream.

Due to time pressure, I am relying completely on the Internet directorate review done by Sheng Jiang: https://datatracker.ietf.org/doc/review-ietf-lamps-lightweight-cmp-profile-15-intdir-telechat-jiang-2022-11-22/

Thank you Sheng for this review.

Hi,

Thanks for this document.  I just have a couple of comments:

(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?


(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]?

Thanks,
Rob