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

[Roman Danyliw <[e-mail]>]

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.

** 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 specification, but most application scenarios use only a limited subset of the same specified functionality.

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

** 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.

** Section 1.2.  "As also 3GPP and UNISIG already put across ..."

What does "put across" mean?

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

** 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, ...

Isn't a 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?

** 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"?

** 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.

-- 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.

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

** 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."

** 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 ...?

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

** 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.

** 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

** 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.

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

** 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.

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

** 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.

** 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:

** Section 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.

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

** Section 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.

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

** 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.

** Section 4.1.4.
... using a legacy PKCS#10 [RFC2986] request

Why is RFC2986 characterized as "legacy"?  In IETF standards parlance, it is not.

** 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.

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

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

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

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

** 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

** 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"?

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

** Section 4.1.6.  Editorial.

             encryptedContentInfo
                                 REQUIRED
...
               contentEncryptionAlgorithm
                                 REQUIRED

The cardinality of these fields is on a separate line from the field name

** Section 4.1.6.  Typo. s/ see and [RFC8933]/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"

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

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

** 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.

** 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

** 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.

** 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.

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

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

** Section 4.3.  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?

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

** Section 5.

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?

** 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.

** Section 5.1.1.  Editorial.

OLD
The PKI management entity SHOULD perform also ...

NEW
The PKI management entity SHOULD also perform ...

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

** 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.

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

** 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.

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

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

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

** 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.

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

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

** 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)".

** 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.

** 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.

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

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

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

-- should the provisioning of client certifications and PSKs be declared out of scope

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

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

** Per IDNits:

  -- Obsolete informational reference (is this intentional?): RFC 2818
     (Obsoleted by RFC 9110)

I believe that RFC2818 can be safely replaced with RFC9110.

Regards,
Roman