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

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

Roman

Many thanks for your review and your valuable comments.
I will provide feedback and suggestions to all your comments in the next days.

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.
> 
> ** 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
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fspasm&amp;data=05%7C01%7Chendrik.brockha
> us%40siemens.com%7Cac112d3823c8458d22f808da9829761c%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637989601109018032%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=PW2jQ3KMdwzpGpgrXobRPV
> wFndzYHfnZF2UWzuhGYhI%3D&amp;reserved=0