LAMPS Working Group                                    H. Brockhaus, Ed.
Internet-Draft                                                  S. Fries
Intended status: Standards Track                           D. von Oheimb
Expires: 28 April 2022                                           Siemens
                                                         25 October 2021


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

Abstract

   This document aims at simple, interoperable, and automated PKI
   management operations covering typical use cases of industrial and
   IoT scenarios.  This is achieved by profiling the Certificate
   Management Protocol (CMP), the related Certificate Request Message
   Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
   but sufficiently detailed and self-contained way.  To make secure
   certificate management for simple scenarios and constrained devices
   as lightweight as possible, only the most crucial types of operations
   and options are specified as mandatory.  More special and complex use
   cases are supported as well, by features specified as recommended or
   optional.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 28 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Brockhaus, et al.         Expires 28 April 2022                 [Page 1]


Internet-Draft           Lightweight CMP Profile            October 2021


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  How to Read This Document . . . . . . . . . . . . . . . .   4
     1.2.  Motivation for a lightweight profile of CMP . . . . . . .   4
     1.3.  Special requirements of industrial and IoT scenarios  . .   5
     1.4.  Existing CMP profiles . . . . . . . . . . . . . . . . . .   6
     1.5.  Use of CMP in SZTP and BRSKI environments . . . . . . . .   7
     1.6.  Compatibility with existing CMP profiles  . . . . . . . .   7
     1.7.  Scope of this document  . . . . . . . . . . . . . . . . .   9
     1.8.  Structure of this document  . . . . . . . . . . . . . . .   9
     1.9.  Convention and Terminology  . . . . . . . . . . . . . . .  10
   2.  Architecture and use cases  . . . . . . . . . . . . . . . . .  11
     2.1.  Solution architecture . . . . . . . . . . . . . . . . . .  11
     2.2.  Supported PKI management operations . . . . . . . . . . .  13
       2.2.1.  Mandatory PKI management operations . . . . . . . . .  13
       2.2.2.  Recommended PKI management operations . . . . . . . .  14
       2.2.3.  Optional PKI management operations  . . . . . . . . .  15
     2.3.  CMP message transfer  . . . . . . . . . . . . . . . . . .  16
   3.  Generic aspects of the PKI message  . . . . . . . . . . . . .  17
     3.1.  General description of the CMP message header . . . . . .  18
     3.2.  General description of the CMP message protection . . . .  20
     3.3.  General description of CMP message extraCerts . . . . . .  20
     3.4.  Generic PKI management operation prerequisites  . . . . .  21
     3.5.  Generic validation of a PKI message . . . . . . . . . . .  22
     3.6.  Error handling  . . . . . . . . . . . . . . . . . . . . .  24
       3.6.1.  Reporting error conditions upstream . . . . . . . . .  24
       3.6.2.  Reporting error conditions downstream . . . . . . . .  25
       3.6.3.  Handling error conditions on nested messages used for
               batching  . . . . . . . . . . . . . . . . . . . . . .  25
       3.6.4.  Reporting error conditions  . . . . . . . . . . . . .  26
   4.  End Entity PKI management operations  . . . . . . . . . . . .  28
     4.1.  Requesting a new certificate from a PKI . . . . . . . . .  31
       4.1.1.  Requesting a certificate from a new PKI with
               signature-based protection  . . . . . . . . . . . . .  32
       4.1.2.  Requesting an additional certificate with
               signature-based protection  . . . . . . . . . . . . .  38
       4.1.3.  Updating an existing certificate with signature
               protection  . . . . . . . . . . . . . . . . . . . . .  39



Brockhaus, et al.         Expires 28 April 2022                 [Page 2]


Internet-Draft           Lightweight CMP Profile            October 2021


       4.1.4.  Requesting a certificate from a legacy PKI using a
               PKCS#10 request . . . . . . . . . . . . . . . . . . .  40
       4.1.5.  Requesting a certificate from a PKI with MAC-based
               protection  . . . . . . . . . . . . . . . . . . . . .  42
       4.1.6.  Adding central key pair generation to a certificate
               request . . . . . . . . . . . . . . . . . . . . . . .  43
         4.1.6.1.  Using key agreement key management technique  . .  48
         4.1.6.2.  Using key transport key management technique  . .  50
         4.1.6.3.  Using password-based key management technique . .  50
     4.2.  Revoking a certificate  . . . . . . . . . . . . . . . . .  51
     4.3.  Support messages  . . . . . . . . . . . . . . . . . . . .  54
       4.3.1.  Get CA certificates . . . . . . . . . . . . . . . . .  56
       4.3.2.  Get root CA certificate update  . . . . . . . . . . .  56
       4.3.3.  Get certificate request template  . . . . . . . . . .  58
       4.3.4.  CRL update retrieval  . . . . . . . . . . . . . . . .  60
     4.4.  Handling delayed delivery . . . . . . . . . . . . . . . .  62
   5.  PKI management entity operations  . . . . . . . . . . . . . .  66
     5.1.  Responding to requests  . . . . . . . . . . . . . . . . .  66
       5.1.1.  Responding to a certificate request . . . . . . . . .  67
       5.1.2.  Initiating delayed delivery . . . . . . . . . . . . .  68
       5.1.3.  Responding to a confirmation message  . . . . . . . .  68
       5.1.4.  Responding to a revocation request  . . . . . . . . .  69
       5.1.5.  Responding to a support message . . . . . . . . . . .  69
     5.2.  Forwarding messages . . . . . . . . . . . . . . . . . . .  69
       5.2.1.  Not changing protection . . . . . . . . . . . . . . .  71
       5.2.2.  Adding protection and batching of messages  . . . . .  72
         5.2.2.1.  Adding protection to a request message  . . . . .  72
         5.2.2.2.  Batching messages . . . . . . . . . . . . . . . .  74
       5.2.3.  Replacing protection  . . . . . . . . . . . . . . . .  75
         5.2.3.1.  Not changing any included proof-of-possession . .  76
         5.2.3.2.  Breaking proof-of-possession  . . . . . . . . . .  76
     5.3.  Acting on behalf of other PKI entities  . . . . . . . . .  77
       5.3.1.  Requesting certificates . . . . . . . . . . . . . . .  77
       5.3.2.  Revoking a certificate  . . . . . . . . . . . . . . .  78
   6.  CMP message transfer mechanisms . . . . . . . . . . . . . . .  78
     6.1.  HTTP transfer . . . . . . . . . . . . . . . . . . . . . .  79
     6.2.  CoAP transfer . . . . . . . . . . . . . . . . . . . . . .  81
     6.3.  Piggybacking on other reliable transfer . . . . . . . . .  83
     6.4.  Offline transfer  . . . . . . . . . . . . . . . . . . . .  83
       6.4.1.  File-based transfer . . . . . . . . . . . . . . . . .  83
       6.4.2.  Other asynchronous transfer protocols . . . . . . . .  84
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  84
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  84
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  84
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  84
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  84
     10.2.  Informative References . . . . . . . . . . . . . . . . .  86
   Appendix A.  Example CertReqTemplate  . . . . . . . . . . . . . .  89



Brockhaus, et al.         Expires 28 April 2022                 [Page 3]


Internet-Draft           Lightweight CMP Profile            October 2021


   Appendix B.  History of changes . . . . . . . . . . . . . . . . .  91
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  95

1.  Introduction

   [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC-
   CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of
   CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
   [I-D.ietf-lamps-cmp-algorithms], when available.

   This document specifies PKI management operations supporting machine-
   to-machine and IoT use cases.  Its focus is to maximize automation
   and interoperability between all involved PKI entities, ranging from
   end entities (EE) over any number of intermediate PKI management
   entities such as Registration Authorities (RA) to the CMP endpoints
   of Certification Authority (CA) systems.  This profile makes use of
   the concepts and syntax specified in CMP [RFC4210],
   [I-D.ietf-lamps-cmp-updates], and [I-D.ietf-lamps-cmp-algorithms],
   CRMF [RFC4211] and [RFC9045], CMS [RFC5652] and [RFC8933], HTTP
   transfer for CMP [RFC6712], and CoAP transfer for CMP
   [I-D.ietf-ace-cmpv2-coap-transport].  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.
   Additionally, the standards are not always precise enough on how to
   interpret and implement the described concepts.  Therefore, this
   document aims at tailoring the available options and specifying at an
   adequate detail how to use them to make the implementation of
   interoperable automated certificate management as straightforward and
   lightweight as possible.

1.1.  How to Read This Document

   This document has become longer than the authors would have liked it
   to be.  Yet apart from studying Section 3, which contains general
   requirements, the reader does not have to work through the whole
   document but can use the guidance in Section 1.8, Section 2.2, and
   Section 2.3 to figure out which parts of Section 4 to Section 6 are
   relevant, depending on the PKI management operations and options of
   interest.

1.2.  Motivation for a lightweight profile of CMP

   CMP was standardized in 1999 and is implemented in several PKI
   products.  In 2005, a completely reworked and enhanced version 2 of
   CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a
   document specifying a transfer mechanism for CMP messages using HTTP
   [RFC6712] in 2012.




Brockhaus, et al.         Expires 28 April 2022                 [Page 4]


Internet-Draft           Lightweight CMP Profile            October 2021


   Though CMP is a solid and very capable protocol it is so far not used
   very widely.  The most important reason appears to be that the
   protocol offers a too large set of features and options.  On the one
   hand, this makes CMP applicable to a very wide range of scenarios,
   but on the other hand, a full implementation supporting all options
   is not realistic because this would take undue effort.

   Moreover, many details of the CMP protocol have been left open or
   have not been specified in full preciseness.  The profiles specified
   in Appendix D and E of [RFC4210] define some more detailed PKI
   management operations.  Yet, the specific needs of highly automated
   scenarios for a machine-to-machine communication are not covered
   sufficiently.

   As also 3GPP and UNISIG already put across, profiling is a way of
   coping with the challenges mentioned above.  To profile means to take
   advantage of the strengths of the given protocol, while explicitly
   narrowing down the options it provides to those needed for the
   purpose(s) at hand and eliminating all identified ambiguities.  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.

   Defining a profile for a new target environment takes high effort
   because the range of available options needs to be well understood
   and the selected options need to be consistent with each other and
   suitably cover the intended application scenario.  Since most
   industrial PKI management use cases typically have much in common it
   is worth sharing this effort, which is the aim of this document.
   Other standardization bodies can reference this document and do not
   need to come up with individual profiles from scratch.

1.3.  Special requirements of industrial and IoT scenarios

   The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have
   been developed particularly for managing certificates of human end
   entities.  With the evolution of distributed systems and client-
   server architectures, certificates for machines and applications on
   them have become widely used.  This trend has strengthened even more
   in emerging industrial and IoT scenarios.  CMP is sufficiently
   flexible to support them well.

   Today's IT security architectures for industrial solutions typically
   use certificates for endpoint authentication within protocols like
   IPSec, TLS, or SSH.  Therefore, the security of these architectures
   highly relies upon the security and availability of the implemented
   certificate management operations.




Brockhaus, et al.         Expires 28 April 2022                 [Page 5]


Internet-Draft           Lightweight CMP Profile            October 2021


   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.
   Consequently, the NIST Framework for Improving Critical
   Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper
   processes for issuance, management, verification, revocation, and
   audit for authorized devices, users, and processes involving identity
   and credential management.  Such PKI management operations according
   to commonly accepted best practices are also required in
   IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher.

   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.  Certificate management must be able to cope with
   such network architectures.  CMP offers the required flexibility and
   functionality, namely self-contained messages, efficient polling, and
   support for asynchronous message transfer while retaining end-to-end
   security.

1.4.  Existing CMP profiles

   As already stated, RFC 4210 [RFC4210] contains profiles with
   mandatory and optional PKI management operations in Appendix D and E.
   Those profiles focus on management of human user certificates and
   only partly address the specific needs of certificate management
   automation for unattended devices or machine-to-machine application
   scenarios.

   Both Appendixes D and E focus on EE-to-RA/CA PKI management
   operations and do not address further profiling of RA-to-CA
   communication as typically needed for full backend automation.  All
   requirements regarding algorithm support for RFC 4210 Appendix D and
   E [RFC4210] have been updated by CMP Algorithms Section 7.1
   [I-D.ietf-lamps-cmp-algorithms].

   3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310
   [ETSI-3GPP.33.310] for automatic management of IPSec certificates in
   3G, LTE, and 5G backbone networks.  Since 2010, a dedicated CMP
   profile for initial certificate enrollment and certificate update
   operations between EE and RA/CA is specified in that document.

   UNISIG has included a CMP profile for enrollment of TLS certificates
   in the Subset-137 specifying the ETRAM/ETCS on-line key management
   for train control systems [UNISIG.Subset-137] in 2015.



Brockhaus, et al.         Expires 28 April 2022                 [Page 6]


Internet-Draft           Lightweight CMP Profile            October 2021


   Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and
   HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI
   management operations for unattended devices and services.

1.5.  Use of CMP in SZTP and BRSKI environments

   In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments,
   SZTP-CSR [I-D.ietf-netconf-sztp-csr] includes certificate signing
   requests (CSR) in device bootstrapping to obtain a public-key
   certificate for a locally generated key pair.  One option is using a
   CMP p10cr message.  Such a CSR is of form ietf-sztp-types:cmp-csr
   from module ietf-sztp-csr.  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.

   In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
   environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous
   Enrollment [I-D.ietf-anima-brski-async-enroll] 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.

1.6.  Compatibility with existing CMP profiles

   The profile specified in this document is compatible with RFC 4210
   Appendixes D and E (PKI Management Message Profiles) [RFC4210], with
   the following exceptions:

   *  signature-based protection is the default protection; an initial
      PKI management operation may also use MAC-based protection,

   *  certification of a second key pair within the same PKI management
      operation is not supported,

   *  proof-of-possession (POPO) with self-signature of the certTemplate
      according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the
      recommended default POPO method (deviations are possible for EEs
      when requesting central key generation, for RAs when using
      raVerified, and if the newly generated keypair is technically not
      capable to generate digital signatures),

   *  confirmation of newly enrolled certificates may be omitted, and

   *  all PKI management operations consist of request-response message
      pairs originating at the EE, i.e., announcement messages
      (requiring a push model, a CMP server on the EE) are excluded in
      favor of a lightweight implementation on the EE.



Brockhaus, et al.         Expires 28 April 2022                 [Page 7]


Internet-Draft           Lightweight CMP Profile            October 2021


   The profile specified in this document is compatible with the CMP
   profile for 3G, LTE, and 5G network domain security and
   authentication framework [ETSI-3GPP.33.310], except that:

   *  protection of initial PKI management operations may be MAC-based,

   *  the subject field is mandatory in certificate templates, and

   *  confirmation of newly enrolled certificates may be omitted.

   The profile specified in this document is compatible with the CMP
   profile for on-line key management in rail networks as specified in
   UNISIG Subset-137 [UNISIG.Subset-137], except that:

   *  A certificate enrollment request message consists of only one
      certificate request (CertReqMsg).

   *  RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean
      Time coded as generalizedTime.

      Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly
      states that the messageTime in required to be "UTC time", it is
      not clear if this means a coding as UTCTime or generalizedTime and
      if other time zones than Greenwich Mean Time shall be allowed.
      Both time formats are described in RFC 5280 Section 4.1.2.5
      [RFC5280].

   *  The same type of protection is required to be used for all
      messages of one PKI management operation.  This means, in case the
      request message protection is MAC-based, also the response,
      certConf, and pkiConf messages must have a MAC-based protection.

   *  Use of caPubs is not required but typically allowed in combination
      with MAC-based protected PKI management operations.  On the other
      hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using
      caPubs.

      Note: It remains unclear from UNISIG Subset-137 for which
      certificate(s) the caPubs field should be used.  For security
      reasons, it cannot be used for delivering the root CA certificate
      needed for validating the signature-based protection of the given
      response message (as stated indirectly also in its UNISIG
      Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]).

   *  This profile requires that the certConf message has one CertStatus
      element where the statusInfo field is recommended.





Brockhaus, et al.         Expires 28 April 2022                 [Page 8]


Internet-Draft           Lightweight CMP Profile            October 2021


      Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137]
      requires that the certConf message has one CertStatus element
      where the statusInfo field must be absent.  This precludes sending
      a negative certConf message in case the EE rejects the newly
      enrolled certificate.  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).

1.7.  Scope of this document

   To minimize ambiguity and complexity through needless variety, this
   document specifies exhaustive requirements on generating PKI
   management messages on the sender side.  On the other hand, it gives
   only minimal requirements on checks by the receiving side and how to
   handle error cases.

   Especially on the EE side this profile aims at a lightweight
   implementation.  This means that the number of PKI management
   operations implementations are reduced to a reasonable minimum to
   support typical certificate management use cases in industrial
   machine-to-machine environments.  On the EE side only limited
   resources are expected, while on the side of the PKI management
   entities the profile accepts higher requirements.

   For the sake of interoperability and robustness, implementations
   should, as far as security is not affected, adhere to Postel's law:
   "Be conservative in what you do, be liberal in what you accept from
   others" (often reworded as: "Be conservative in what you send, be
   liberal in what you receive").

   When in Section 3, Section 4, and Section 5 a field of the ASN.1
   syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates],
   CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly
   specified, it SHOULD not be used by the sending entity.  The
   receiving entity MUST NOT require its absence and if present MUST
   gracefully handle its presence.

1.8.  Structure of this document

   Section 2 introduces the general PKI architecture and approach to
   certificate management that is assumed in this document.  Then it
   lists the PKI management operations specified in this document,
   partitioning them into mandatory, recommended, and optional ones.







Brockhaus, et al.         Expires 28 April 2022                 [Page 9]


Internet-Draft           Lightweight CMP Profile            October 2021


   Section 3 profiles the generic aspects of the PKI management
   operations specified in detail in Section 4 and Section 5 to minimize
   redundancy in the description and to ease implementation.  This
   covers the general structure and protection of messages, as well as
   generic prerequisites, validation, and error handling.

   Section 4 profiles the exchange of CMP messages between an EE and the
   PKI management entity.  There are various flavors of certificate
   enrollment requests, optionally with polling, central key generation,
   revocation, and general support PKI management operations.

   Section 5 profiles responding to requests, exchange between PKI
   management entities, and operations on behalf of other PKI entities.
   This may include delayed delivery of messages, which involves polling
   for responses, and nesting of messages.

   Section 6 outlines several mechanisms for CMP message transfer,
   including HTTP-based [RFC6712] transfer optionally using TLS, and
   [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS,
   and offline file-based transport.

1.9.  Convention and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Technical terminology is used in conformance with RFC 4210 [RFC4210],
   RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR
   [IEEE.802.1AR_2018].  The following key words are used:

   CA:   Certification authority, which issues certificates.

   RA:   Registration authority, an optional PKI component to which a CA
         delegates certificate management functions such as end entity
         authentication and authorization checks for incoming requests.
         An RA can also provide conversion between various certificate
         management protocols and other protocols providing some
         operations related to certificate management.

   LRA:  Local registration authority, a specific form of RA with
         proximity to the end entities.

         Note: For ease of reading, this document uses the term "RA"
         also for LRAs in all cases where the difference is not
         relevant.



Brockhaus, et al.         Expires 28 April 2022                [Page 10]


Internet-Draft           Lightweight CMP Profile            October 2021


   KGA:  Key generation authority, an optional system component,
         typically co-located with an RA or CA, that offers key
         generation services to end entities.

   EE:   End entity, typically a device or service that holds a public-
         private key pair for which it manages a public-key certificate.
         An identifier for the EE is given as the subject of its
         certificate.

   The following terminology is reused from RFC 4210 [RFC4210], as
   follows:

   PKI management operation:  All CMP messages belonging to a single
                              transaction.  The transaction is
                              identified by the transactionID field of
                              the message headers.

   PKI management entity:     A non-EE PKI entity, i.e., RA or CA.

   PKI entity:                An EE or PKI management entity.

2.  Architecture and use cases

2.1.  Solution architecture

   To facilitate secure automatic certificate enrollment, the device
   hosting an EE is typically equipped with a manufacturer-issued device
   certificate.  Such a certificate is typically installed during
   production and is meant to identify the device throughout its
   lifetime.  This certificate can be used to protect the initial
   enrollment of operational certificates after installation of the EE
   in its operational environment.  In contrast to the manufacturer-
   issued device certificate, operational certificates are issued by the
   owner or operator of the device to identify the device or one of its
   components for operational use, e.g., in a security protocol like
   IPSec, TLS, or SSH.  In IEEE 802.1AR [IEEE.802.1AR_2018] a
   manufacturer-issued device certificate is called IDevID certificate
   and an operational certificate is called LDevID certificate.

   Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises
   the triple of the certificate, the corresponding private key, and the
   certificate chain.

   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).  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.  This PKI



Brockhaus, et al.         Expires 28 April 2022                [Page 11]


Internet-Draft           Lightweight CMP Profile            October 2021


   management entity may be a CA or more typically an RA, which checks
   the request, responds to it itself, or forwards the request upstream
   to the next PKI management entity.  In case an RA changes the CMP
   request message header or body or wants to demonstrate successful
   verification or authorization, it can apply a protection of its own.
   Especially the communication between an LRA and RA can be performed
   synchronously or asynchronously.  Synchronous communication describes
   a timely uninterrupted communication between two communication
   partners, while asynchronous communication is not performed in a
   timely consistent manner, e.g., because of a delayed message
   delivery.

   +-----+            +-----+                +-----+            +-----+
   |     |            |     |                |     |            |     |
   | EE  |<---------->| LRA |<-------------->| RA  |<---------->| CA  |
   |     |            |     |                |     |            |     |
   +-----+            +-----+                +-----+            +-----+

           synchronous        (a)synchronous       (a)synchronous
      +----connection----+------connection------+----connection----+

                                     operators          service partner
   +---------on site--------+----back-end services-----+-trust center-+

           Figure 1: Certificate management architecture example

   In operational environments the certificate management architecture
   can have multiple LRAs bundling requests from multiple EEs at
   dedicated locations and one (or more than one) central RA aggregating
   the requests from the LRAs.  Every LRA in this scenario has shared
   secret information (one per EE) for MAC-based protection or a CMP
   protection key and certificate allowing it to (re-)protect CMP
   messages it processes.  The figure above shows an architecture
   example with at least one LRA, RA, and CA.  It is also possible not
   to have an RA or LRA or that there is no CA with a CMP interface.
   Depending on the network infrastructure, the message transfer between
   PKI management entities may be based on synchronous online
   connections, asynchronous connections, or even offline (e.g., file-
   based) transfer.












Brockhaus, et al.         Expires 28 April 2022                [Page 12]


Internet-Draft           Lightweight CMP Profile            October 2021


   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.

   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.

2.2.  Supported PKI management operations

   Following the scope outlined in Section 1.7, this section gives a
   brief overview of the base PKI management operations and their
   variants specified in Section 4 and Section 5 and states whether
   implementation by compliant EEs or PKI management entities is
   mandatory, recommended, or optional.  Variants amend or change
   behavior of base PKI management operations and are therefore also
   listed here.

2.2.1.  Mandatory PKI management operations

   The set of mandatory PKI management operations in this document is
   intentionally lean to help for keeping development effort low and to
   enable use in memory-constrained devices.


   +=====================================+=========+
   | PKI management operations           | Section |
   +=====================================+=========+
   | Requesting a certificate from a new | Section |
   | PKI with signature-based protection | 4.1.1   |
   +-------------------------------------+---------+
   | Updating an existing certificate    | Section |
   | with signature-based protection     | 4.1.3   |
   +-------------------------------------+---------+

      Table 1: Mandatory End Entity PKI management
                       operations






Brockhaus, et al.         Expires 28 April 2022                [Page 13]


Internet-Draft           Lightweight CMP Profile            October 2021


   +===============================================+=================+
   | PKI management operations                     | Section         |
   +===============================================+=================+
   | Responding to a certificate request           | Section 5.1     |
   +-----------------------------------------------+-----------------+
   | Responding to a confirmation message          | Section 5.1.3   |
   +-----------------------------------------------+-----------------+
   | Forwarding messages - not changing protection | Section 5.2.1   |
   +-----------------------------------------------+-----------------+
   | Adding protection to a request message        | Section 5.2.2.1 |
   +-----------------------------------------------+-----------------+

           Table 2: Mandatory PKI management entity operations

2.2.2.  Recommended PKI management operations

   Additional recommended PKI management operations support some more
   complex scenarios, that are considered beneficial for environments
   with more specific demand or boundary conditions.


   +=================================+=========+
   | PKI management operations       | Section |
   +=================================+=========+
   | Requesting a certificate from a | Section |
   | PKI with MAC-based protection   | 4.1.5   |
   +---------------------------------+---------+
   | Revoking a certificate          | Section |
   |                                 | 4.2     |
   +---------------------------------+---------+

        Table 3: Recommended End Entity PKI
               management operations


   +====================================+===============+
   | PKI management operations          | Section       |
   +====================================+===============+
   | Responding to a revocation request | Section 5.1.4 |
   +------------------------------------+---------------+
   | Acting on behalf of other PKI      | Section 5.3.2 |
   | entities - revoking a certificate  |               |
   +------------------------------------+---------------+

   Table 4: Recommended PKI management entity operations






Brockhaus, et al.         Expires 28 April 2022                [Page 14]


Internet-Draft           Lightweight CMP Profile            October 2021


2.2.3.  Optional PKI management operations

   The optional PKI management operations support specific scenarios
   seen only in some environments with specific requirements.


   +========================================================+=========+
   | PKI management operations and variants                 | Section |
   +========================================================+=========+
   | Requesting an additional certificate with signature-   | Section |
   | based protection                                       | 4.1.2   |
   +--------------------------------------------------------+---------+
   | Requesting a certificate from a legacy PKI using a     | Section |
   | PKCS#10 request                                        | 4.1.4   |
   +--------------------------------------------------------+---------+
   | Adding central key generation to a certificate         | Section |
   | request.  (If central key generation is supported, the | 4.1.6   |
   | key agreement key management technique is REQUIRED to  |         |
   | be supported, and the key transport and password-based |         |
   | key management techniques are OPTIONAL.)               |         |
   +--------------------------------------------------------+---------+
   | Support messages                                       | Section |
   |                                                        | 4.3     |
   +--------------------------------------------------------+---------+
   | Handling delayed delivery                              | Section |
   |                                                        | 4.4     |
   +--------------------------------------------------------+---------+
   | Acting on behalf of other PKI entities - requesting    | Section |
   | certificates                                           | 5.3.1   |
   +--------------------------------------------------------+---------+

          Table 5: Optional End Entity PKI management operations



















Brockhaus, et al.         Expires 28 April 2022                [Page 15]


Internet-Draft           Lightweight CMP Profile            October 2021


   +===============================================+===============+
   | PKI management operations and variants        | Section       |
   +===============================================+===============+
   | Initiating delayed delivery                   | Section 5.1.2 |
   +-----------------------------------------------+---------------+
   | Forwarding messages - replacing protection,   | Section       |
   | not changing any included proof-of-possession | 5.2.3.1       |
   +-----------------------------------------------+---------------+
   | Forwarding messages - replacing protection,   | Section       |
   | breaking proof-of-possession                  | 5.2.3.2       |
   +-----------------------------------------------+---------------+
   | Batching messages                             | Section       |
   |                                               | 5.2.2.2       |
   +-----------------------------------------------+---------------+

           Table 6: Optional PKI management entity operations

2.3.  CMP message transfer

   On different links between PKI entities, e.g., EE-RA and RA-CA,
   different transfer mechanisms MAY be used.  CMP does not have
   specific needs regarding message transfer, except that for each
   request message sent, eventually exactly one response message should
   be received.  Thus, virtually any reliable transfer mechanism can be
   used, e.g., HTTP, CoAP, and offline file-based transfer.  Therefore,
   this document does not require any specific transfer protocol to be
   supported by conforming implementations.

   HTTP transfer is RECOMMENDED to use for all PKI entities, yet full
   flexibility is retained to choose whatever transfer mechanism is
   suitable, for instance for devices and system architectures with
   specific constraints.

   +===============+=============+
   | Transfer      | Section     |
   +===============+=============+
   | HTTP transfer | Section 6.1 |
   +---------------+-------------+

         Table 7: Recommended
         transfer mechanisms










Brockhaus, et al.         Expires 28 April 2022                [Page 16]


Internet-Draft           Lightweight CMP Profile            October 2021


   +=========================================+=============+
   | Transfer                                | Section     |
   +=========================================+=============+
   | Offline transfer                        | Section 6.4 |
   +-----------------------------------------+-------------+
   | CoAP transfer                           | Section 6.2 |
   +-----------------------------------------+-------------+
   | Piggybacking on other reliable transfer | Section 6.3 |
   +-----------------------------------------+-------------+

             Table 8: Optional transfer mechanisms

3.  Generic aspects of the PKI message

   This section covers the generic aspects of the PKI management
   operations specified in Section 4 and Section 5 as upfront general
   requirements to minimize redundancy in the description and to ease
   implementation.

   As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages
   have the following general structure:

              +--------------------------------------------+
              | PKIMessage                                 |
              | +----------------------------------------+ |
              | | header                                 | |
              | +----------------------------------------+ |
              | +----------------------------------------+ |
              | | body                                   | |
              | +----------------------------------------+ |
              | +----------------------------------------+ |
              | | protection (OPTIONAL)                  | |
              | +----------------------------------------+ |
              | +----------------------------------------+ |
              | | extraCerts (OPTIONAL)                  | |
              | +----------------------------------------+ |
              +--------------------------------------------+

                      Figure 2: CMP message structure

   The general contents of the message header, protection, and
   extraCerts fields are specified in the following three subsections.

   In case a specific PKI management operation needs different contents
   in the header, protection, or extraCerts fields, the differences are
   described in the respective subsections.





Brockhaus, et al.         Expires 28 April 2022                [Page 17]


Internet-Draft           Lightweight CMP Profile            October 2021


   The CMP message body contains the PKI management operation-specific
   information.  It is described in Section 4 and Section 5.

   The generic prerequisites needed by the PKI entities in order to be
   able to perform PKI management operations are described in
   Section 3.4.

   The generic validation steps to be performed by PKI entities on
   receiving a CMP message are described in Section 3.5.

   The generic aspects of handling and reporting errors are described in
   Section 3.6.

3.1.  General description of the CMP message header

   This section describes the generic header fields of all CMP messages
   with signature-based protection.

   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.

   Any PKI management operation-specific fields or variations are
   described in Section 4 and 5.

   header
     pvno                        REQUIRED
       -- 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
       -- MUST be 2 to indicate CMP v2 in all other cases
       -- For details on version negotiation see RFC-CMP-Updates
     sender                      REQUIRED
       -- SHOULD contain a name representing the originator of the
       -- message; otherwise, the NULL-DN (a zero-length
       -- SEQUENCE OF RelativeDistinguishedNames) MUST be used
       -- SHOULD be the subject of the CMP protection certificate, i.e.,
       -- the certificate corresponding to the private key used to sign
       -- the message
       -- In a multi-hop scenario, the receiving entity SHOULD not rely
       -- on the correctness of the sender field.
     recipient                   REQUIRED
       -- SHOULD be the name of the intended recipient; otherwise, the
       -- NULL-DN MUST be used
       -- In the first message of a PKI management operation:
       -- SHOULD be the subject DN of the CA the PKI management



Brockhaus, et al.         Expires 28 April 2022                [Page 18]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- operation is requested from
       -- In all other messages:
       -- SHOULD contain the value of the sender field of the previous
       -- message in the same PKI management operation
       -- The recipient field SHALL be handled gracefully by the
       -- receiving entity, because in a multi-hop scenario its
       -- correctness cannot be guaranteed.
     messageTime                 RECOMMENDED
       -- MUST be the time at which the message was produced, if present
     protectionAlg               REQUIRED
       -- MUST be an algorithm identifier indicating the algorithm
       -- used for calculating the protection bits
       -- If it is a signature algorithm its type MUST be a
       -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and
       -- MUST be consistent with the subjectPublicKeyInfo field of
       -- the protection certificate
       -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as
       -- specified in [RFC-CMP-Alg] Section 6.1
     senderKID                   RECOMMENDED
       -- MUST be the SubjectKeyIdentifier of the CMP protection
       -- certificate
     transactionID               REQUIRED
       -- In the first message of a PKI management operation:
       -- MUST be 128 bits of random data, to minimize the probability
       -- of having the transactionID already in use at the server
       -- In all other messages:
       -- MUST be the value from the previous message in the same
       -- PKI management operation
     senderNonce                 REQUIRED
       -- MUST be cryptographically secure and fresh 128 random bits
     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
     generalInfo                 OPTIONAL
       implicitConfirm           OPTIONAL
       -- The extension is optional in ir/cr/kur/p10cr requests and
       -- ip/cp/kup response messages and PROHIBTED in other types of
       -- messages
       -- Added to request messages to request omission of the certConf
       -- message
       -- Added to response messages to grant omission of the certConf
       -- message



Brockhaus, et al.         Expires 28 April 2022                [Page 19]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- See [RFC4210] Section 5.1.1.1.
        ImplicitConfirmValue    REQUIRED
       -- ImplicitConfirmValue MUST be NULL
       certProfile               OPTIONAL
       -- MAY be present in ir/cr/kur/p10cr and in genm messages of type
       -- id-it-certReqTemplate
       -- MUST be omitted in all other messages
       -- See [RFC-CMP-Updates]
         CertProfileValue        REQUIRED
       -- MUST contain exactly one UTF8String element
       -- MUST contain the name of a certificate profile

3.2.  General description of the CMP message protection

   This section describes the generic protection field contents of all
   CMP messages with signature-based protection.  The private key used
   to sign a CMP message is called "protection key" and the related
   certificate is called "protection certificate".  Any included
   keyUsage extension SHOULD allow digitalSignature.

   protection                    RECOMMENDED
       -- MUST contain the signature calculated using the private key
       -- of the entity protecting the message. The signature
       -- algorithm used MUST be given in the protectionAlg field.

   Generally, CMP message protection is required for CMP messages, but
   there are cases where protection of error messages specified in
   Section 3.6 is not possible and therefore MAY be omitted.

   For MAC-based protection as specified in Section 4.1.5 major
   differences apply as described there.

   The CMP message protection provides, if available, message origin
   authentication and integrity protection for the header and body.  The
   CMP message extraCerts field is not covered by this protection.

   Note: The extended key usages described in CMP Updates
   [I-D.ietf-lamps-cmp-updates] can be used for authorization of a
   sending PKI management entity.

3.3.  General description of CMP message extraCerts

   This section describes the generic extraCerts field of all CMP
   messages with signature-based protection.  Any specific requirements
   on the extraCerts are specified in the respective PKI management
   operation.





Brockhaus, et al.         Expires 28 April 2022                [Page 20]


Internet-Draft           Lightweight CMP Profile            October 2021


   extraCerts
       -- SHOULD contain the CMP protection certificate together with
       -- its chain, if needed
       -- If present, the first certificate in this field MUST be
       -- the CMP protection certificate followed by its chain
       -- where each element SHOULD directly certify the one
       -- immediately preceding it.
       -- Self-signed certificates SHOULD be omitted from extraCerts,
       -- unless they are the same as the protection certificate and
       -- MUST NOT be trusted based on their inclusion in any case

   Note: For maximum compatibility, all implementations SHOULD be
   prepared to handle potentially additional certificates and arbitrary
   orderings of the certificates.

3.4.  Generic PKI management operation prerequisites

   This subsection describes what is generally needed by the PKI
   entities to be able to perform PKI management operations.

   Identification of PKI entities:

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

   *  Each EE SHOULD know the intended recipient of its requests to fill
      the recipient field, e.g., the name of the addressed CA.

      Note: This name may be established using an enrollment voucher,
      e.g., [RFC8366], the issuer field from a CertReqTemplate response
      message content, or by other configuration means.

   Routing of CMP messages:

   *  Each PKI entity sending messages upstream MUST know the address
      needed for transferring messages to the next PKI management
      entity.

      Note: This address may depend on the recipient, the certificate
      profile, and on the used transfer mechanism.

   Authentication of PKI entities:

   *  Each PKI entity MUST have credentials to authenticate itself.  For
      signature-based protection it MUST have a private key and the
      corresponding certificate along with its chain.






Brockhaus, et al.         Expires 28 April 2022                [Page 21]


Internet-Draft           Lightweight CMP Profile            October 2021


   *  Each PKI entity MUST be able to establish trust in PKI it receives
      responses from.  When signature-based protection is used, it MUST
      have the trust anchor(s) and any certificate status information
      needed to perform path validation of CMP protection certificates
      used for signature-based protection.

      Note: A trust anchor usually is a root certificate of the PKI
      addressed by the requesting EE.  It may be established by
      configuration or in an out-of-band manner.  For an EE it may be
      established using an enrollment voucher [RFC8366] or in-band of
      CMP by the caPubs field in a certificate response message.

   Authorization of PKI management operations:

   *  Each EE or RA MUST have sufficient information to be able to
      authorize the PKI management entity for performing the upstream
      PKI management operation.

      Note: This may be achieved for example by using the cmcRA extended
      key usage in server certificates, by local configuration such as
      specific name patterns for subject DN or SAN portions that may
      identify an RA, and/or by having a dedicated PKI Infrastructure
      root CA usable only for authenticating PKI management entities.

   *  Each PKI management entity MUST have sufficient information to be
      able to authorize the downstream PKI entity requesting the PKI
      management operation.

      Note: For authorizing an RA the same examples apply as above.  The
      authorization of EEs can be very specific to the application
      domain and may involve information from configuration or inventory
      database.  It may involve, e.g., the issuer information of the EE
      certificate, specific contents of the CMP protection certificate
      used by the EE such as name patterns of subject DN or SAN
      portions, shared secret information, and other types of
      credentials and evidence potentially communicated out-of-band.

3.5.  Generic validation of a PKI message

   This section describes generic validation steps of each PKI entity
   receiving a PKI request or response message before any further
   processing or forwarding.  If a PKI management entity decides to
   terminate a PKI management operation because a check failed, it MUST
   send a negative response or an error message as described in
   Section 3.6.  The PKIFailureInfo bits given below in parentheses MAY
   be used in the failInfo field of the PKIStatusInfo as described in
   Section 3.6.4, see also RFC 4210 Appendix F [RFC4210].




Brockhaus, et al.         Expires 28 April 2022                [Page 22]


Internet-Draft           Lightweight CMP Profile            October 2021


   All PKI message header fields not mentioned in this section like the
   recipient and generalInfo fields SHOULD be handled gracefully on
   reception.

   The following list describes the basic set of message input
   validation steps.  Without these checks the protocol becomes
   dysfunctional.

   *  The formal ASN.1 syntax of the whole message MUST be compliant
      with the definitions given in CMP [RFC4210] and
      [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652]
      and [RFC8933]. (failInfo: badDataFormat)

   *  The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit:
      unsupportedVersion)

   *  The transactionID MUST be present. (failInfo bit: badDataFormat)

   *  The PKI message body type MUST be one of the message types
      supported by the receiving PKI entity and MUST be allowed in the
      current state of the PKI management operation identified by the
      given transactionID. (failInfo bit: badRequest)

   The following list describes the set of message input validation
   steps required to ensure secure protocol operation:

   *  The senderNonce MUST be present and MUST contain at least 128 bits
      of data. (failInfo bit: badSenderNonce)

   *  Unless the PKI message is the first message of a PKI management
      operation,

      -  the recipNonce MUST be present and MUST equal the senderNonce
         of the previous message or equal the senderNonce of the most
         recent request message for which the response was delayed, in
         case of delayed delivery as specified in Section 4.4. (failInfo
         bit: badRecipientNonce)

   *  The message protection MUST be validated:

      -  The protection MUST be signature-based except if MAC-based
         protection is used as described in Section 4.1.5 and for some
         error messages as described in Section 3.6.4. (failInfo bit:
         wrongIntegrity)

      -  The senderKID SHOULD identify the key material used for
         verifying the message protection. (failInfo bit:
         badMessageCheck)



Brockhaus, et al.         Expires 28 April 2022                [Page 23]


Internet-Draft           Lightweight CMP Profile            October 2021


      -  The protection, if present, MUST be validated successfully.  If
         signature-based protection is used, the CMP protection
         certificate MUST be successfully validated including path
         validation using a trust anchor and MUST be authorized
         according to local policies.  If the keyUsage extension is
         present in the CMP protection certificate the digitalSignature
         bit SHOULD be set. (failInfo bit: badAlg, badMessageCheck, or
         signerNotTrusted)

      -  The sender of a request message MUST be authorized for
         requesting the operation according to PKI policies. (failInfo
         bit: notAuthorized)


   Note: The requirements for checking certificates given in RFC 5280
   [RFC5280] MUST be followed for signature-based CMP message
   protection.  Unless the message is a positive ip/cp/kup where the
   issuing CA certificate of the newly enrolled certificate is the same
   as the CMP protection certificate of that message, certificate status
   checking SHOULD be performed on the CMP protection certificates.

   Depending on local policies, one or more of the input validation
   checks described below need to be implemented:

   *  If signature-based protection is used, the sender field SHOULD
      match the subject of the CMP protection certificate. (failInfo
      bit: badMessageCheck)

   *  If the messageTime is present, it SHOULD be close to the current
      time. (failInfo bit: badTime)

3.6.  Error handling

   This section describes how a PKI entity handles error conditions on
   messages it receives.  Each error condition SHOULD be logged
   appropriately.

3.6.1.  Reporting error conditions upstream

   An EE SHALL NOT send error messages.  PKI management entities SHALL
   NOT send error messages in upstream direction, either.

   In case an EE rejects a newly issued certificate contained in an ip,
   cp, or kup message and implicit confirmation has not been granted,
   the EE MUST report this using a certConf message with "rejection"
   status and await the pkiConf response as described in Section 4.1.1.





Brockhaus, et al.         Expires 28 April 2022                [Page 24]


Internet-Draft           Lightweight CMP Profile            October 2021


   On all other error conditions regarding response messages, the EE or
   PKI management entity MUST regard the current PKI management
   operation as terminated with failure.  The error conditions include

   *  invalid response message header, body type, protection, or
      extraCerts according to the checks described in Section 3.5,

   *  any issue detected with response message contents,

   *  receipt of an error message from upstream,

   *  timeout occurred while waiting for a response,

   *  rejection of a newly issued certificate while implicit
      confirmation has been granted.

   Upstream PKI management entities will not receive any CMP message to
   learn that the PKI management operation has been terminated.  In case
   they expect a further message from the EE, a connection interruption
   or timeout will occur.  Then they also MUST regard the current PKI
   management operation as terminated with failure and MUST not attempt
   to send an error message downstream.

3.6.2.  Reporting error conditions downstream

   In case the PKI management entity detects an error condition, e.g.,
   rejecting the request due to policy decision, in the body of an ir,
   cr, p10cr, kur, or rr message received from downstream, it SHOULD
   report the error in the specific response message, i.e., an ip, cp,
   kup, or rp with "rejection" status, as described in Section 4.1.1 and
   Section 4.2.  This can also happen in case of polling.

   In case the PKI management entity detects any other error condition
   on requests, including pollReq, certConf, genm, and nested messages,
   received from downstream and on responses received from upstream,
   such as invalid message header, body type, protection, or extraCerts
   according to the checks described in Section 3.5 it MUST report them
   downstream in the form of an error message as described in
   Section 3.6.4.

3.6.3.  Handling error conditions on nested messages used for batching

   Batching of messages using nested messages as described in
   Section 5.2.2.2 requires special error handling.

   If the error condition is on an upstream nested message containing
   batched requests, it MUST not attempt to respond to the individual
   requests included in it.



Brockhaus, et al.         Expires 28 April 2022                [Page 25]


Internet-Draft           Lightweight CMP Profile            October 2021


   In case a PKI management entity receives an error message in response
   to a nested message, it must propagate the error by responding with
   an error message to each of the request messages contained in the
   nested message.

   In case a PKI management entity detects an error condition on the
   downstream nested message received in response to a nested message
   sent before, it MAY ignore this error condition and handle the
   response as described in Section 5.2.2.2.  Otherwise, it MUST
   propagate the error by responding with an error message to each of
   the requests contained in the nested message it sent originally.

3.6.4.  Reporting error conditions

   When sending any kind of negative response, including error messages,
   a PKI entity MUST indicate the error condition in the PKIStatusInfo
   structure of the respective message as described below.  It then MUST
   regard the current PKI management operation as terminated with
   failure.

   The PKIStatusInfo structure is used to report errors.  It may be part
   of various message types, in particular: certConf, ip, cp, kup, and
   error.  The PKIStatusInfo structure consists of the following fields:

   *  status: Here the PKIStatus value "rejection" MUST be used.

      Note: When a PKI management entity indicates delayed delivery of a
      CMP response message to the EE with an error message as described
      in Section 4.4, the status "waiting" is used there.

   *  statusString: Here any human-readable valid value for logging or
      to display via a user interface SHOULD be added.

   *  failInfo: Here the PKIFailureInfo bits MAY be used in the way
      explained in Appendix F of RFC 4210 [RFC4210].  PKIFailureInfo
      bits regarding the validation described in Section 3.5 are
      referenced there.  The PKIFailureInfo bits referenced in
      Section 5.1 and Section 6 are described here:

      -  badCertId: A kur, certConf, or rr message references an unknown
         certificate

      -  badPOP: An ir/cr/p10cr/kur contains an invalid proof-of-
         possession

      -  certRevoked: Revocation requested for a certificate already
         revoked




Brockhaus, et al.         Expires 28 April 2022                [Page 26]


Internet-Draft           Lightweight CMP Profile            October 2021


      -  badCertTemplate: The contents of a certificate request are not
         accepted, e.g., a field is missing or has a non-acceptable
         value or the given public key is already in use in some other
         certificate (depending on policy).

      -  transactionIdInUse: This is sent by a PKI management entity in
         case the received request contains a transaction ID that has
         already been used for another transaction.  An EE receiving
         such error message SHOULD resend the request in a new
         transaction using a different transaction ID.

      -  notAuthorized: The sender of a request message is not
         authorized for requesting the operation.

      -  systemUnavail: This is sent by a PKI management entity in case
         a back-end system is not available.

      -  systemFailure: This is sent by a PKI management entity in case
         a back-end system is currently not functioning correctly.

   An EE receiving a systemUnavail or systemFailure failInfo SHOULD
   resend the request in a new transaction after some time.

   Detailed error message description:



























Brockhaus, et al.         Expires 28 April 2022                [Page 27]


Internet-Draft           Lightweight CMP Profile            October 2021


   Error Message -- error

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The message indicating the error that occurred
     error                       REQUIRED
       pKIStatusInfo             REQUIRED
         status                  REQUIRED
       -- MUST have the value "rejection"
         statusString            RECOMMENDED
       -- SHOULD be any human-readable text for debugging, logging
       -- or to display in a GUI
         failInfo                OPTIONAL
       -- MAY be present and contain the relevant PKIFailureInfo bits

   protection                    REQUIRED
       -- As described in Section 3.2

   extraCerts                    OPTIONAL
       -- As described in Section 3.3

4.  End Entity PKI management operations

   This chapter focuses on the communication of an EE with the PKI
   management entity it directly talks to.  Depending on the network and
   PKI solution, this can be an RA or directly a CA.  Handling of a
   message by a PKI management entity is described in Section 5.

   The PKI management operations specified in this section cover the
   following:

   *  Requesting a certificate with variations like initial enrollment,
      certificate updates, central key generation, and MAC-based
      protection

   *  Revoking a certificate

   *  Support messages

   These operations mainly specify the message body of the CMP messages
   and utilize the specification of the message header, protection and
   extraCerts as specified in Section 3.





Brockhaus, et al.         Expires 28 April 2022                [Page 28]


Internet-Draft           Lightweight CMP Profile            October 2021


   The following diagram shows the EE state machine covering all PKI
   management operations described in this section, including negative
   responses, error messages described in Section 3.6.4, as well as
   ip/cp/kup/error messages with status "waiting", pollReq, and pollRep
   messages described in Section 4.4.

   On receiving messages from upstream, the EE MUST perform the general
   validation checks described in Section 3.5.  The behavior in case an
   error occurs is described in Section 3.6.










































Brockhaus, et al.         Expires 28 April 2022                [Page 29]


Internet-Draft           Lightweight CMP Profile            October 2021


   State machine:
                            start
                              |
                              | send ir/cr/p10cr/kur/rr/genm
                              v
                    waiting for response
                              |
   +--------------------------+--------------------------+
   |                          |                          |
   | receives ip/cp/kup with  | received ip/cp/kup/error | received
   | status "accepted" or     | with status "waiting"    | rp/genp or
   | "grantedWithMods"        |                          | ip/cp/kup/
   |                          v                          | error
   |             +-------> polling                       | with status
   |             |            |                          | "rejection"
   |             | received   | send                     |
   |             | pollRep    | pollReq                  |
   |             |            v                          |
   |             |   waiting for response                |
   |             |            |                          |
   |             +------------+--------+                 |
   |                          |        |                 |
   |       received ip/cp/kup |        | received        |
   |   with status "accepted" |        | rp/genp or      |
   |     or "grantedWithMods" |        | ip/cp/kup/error |
   |                          |        | with status     |
   +-----------+--------------+        | "rejection"     |
               |                       |                 |
   +-----------+-----+                 |                 |
   |                 |                 |                 |
   | implicitConfirm | implicitConfirm |                 |
   | granted         | not granted     |                 |
   |                 |                 |                 |
   |                 | send certConf   |                 |
   |                 v                 |                 |
   |        waiting for pkiConf*)      |                 |
   |                 |                 |                 |
   |                 | received        |                 |
   |                 | pkiConf         |                 |
   +-----------------+-----------------+-----------------+
                              |
                              v
                             end

   *) in case of a delayed delivery of pkiConf responses the same
   polling mechanism is initiated as for rp or genp messages, by sending
    an error message with status "waiting".




Brockhaus, et al.         Expires 28 April 2022                [Page 30]


Internet-Draft           Lightweight CMP Profile            October 2021


   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.

   This section is aligned with CMP [RFC4210], CMP Updates
   [I-D.ietf-lamps-cmp-updates], and CMP Algorithms
   [I-D.ietf-lamps-cmp-algorithms].

   Guidelines as well as an algorithm use profile for this document are
   available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms].

4.1.  Requesting a new certificate from a PKI

   There are various approaches for requesting a certificate from a PKI.

   These approaches differ in the way the EE authenticates itself to the
   PKI, in the form of the request being used, and how the key pair to
   be certified is generated.  The authentication mechanisms may be as
   follows:

   *  Using a certificate from an external PKI, e.g., a manufacturer-
      issued device certificate, and the corresponding private key

   *  Using a private key and certificate issued from the same PKI that
      is addressed for requesting a certificate

   *  Using the certificate to be updated and the corresponding private
      key

   *  Using shared secret information known to the EE and the PKI
      management entity

   An EE requests a certificate indirectly or directly from a CA.  When
   the PKI management entity handles the request as described in
   Section 5.1.1 and responds with a message containing the requested
   certificate, the EE MUST reply with a confirmation message unless
   implicitConfirm was granted.  The PKI management entity then MUST
   handle it as described in Section 5.1.3 and respond with a
   confirmation, closing the PKI management operation.












Brockhaus, et al.         Expires 28 April 2022                [Page 31]


Internet-Draft           Lightweight CMP Profile            October 2021


   The message sequences described in this section allow the EE to
   request certification of a locally or centrally generated public-
   private key pair.  Typically, the EE provides a signature-based
   proof-of-possession of the private key associated with the public key
   contained in the certificate request as defined by RFC 4211
   Section 4.1 [RFC4211] case 3.  To this end it is assumed that the
   private key can technically be used for signing.  This is the case
   for the most common algorithms RSA and ECDSA, regardless of
   potentially intended restrictions of the key usage.

   Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2
   [NIST.SP.800-57p1r5] the newly generated private key MAY be used for
   self-signature, if technically possible, even if the keyUsage
   extension requested in the certificate request prohibits generation
   of digital signatures.

   The requesting EE provides the binding of the proof-of-possession to
   its identity by signature-based or MAC-based protection of the CMP
   request message containing that POP.  As detailed in Section 5.1.1
   and Section 5.1.2, an upstream PKI management entity should verify
   whether this EE is authorized to obtain a certificate with the
   requested subject and other fields and extensions.

   The EE MAY indicate the certificate profile to use in the certProfile
   extension of the generalInfo field in the PKIHeader of the
   certificate request message as described in Section 3.1.

   In case the EE receives a CA certificate in the caPubs field for
   installation as a new trust anchor, it MUST properly authenticate the
   message and authorize the sender as trusted source of the new trust
   anchor.  This authorization is typically indicated using shared
   secret information for protecting an initialization response (ir)
   message.  Authorization can also be signature-based using a
   certificate issued by another PKI that is explicitly authorized for
   this purpose.  A certificate received in caPubs MUST NOT be accepted
   as trust anchor if the CMP message has been protected using a
   certificate issued by this same CA or one of its subordinate CAs.

4.1.1.  Requesting a certificate from a new PKI with signature-based
        protection

   This PKI management operation should be used by an EE to request a
   certificate from a new PKI using an existing certificate from an
   external PKI, e.g., a manufacturer-issued IDevID certificate
   [IEEE.802.1AR_2018], to authenticate itself to the new PKI.






Brockhaus, et al.         Expires 28 April 2022                [Page 32]


Internet-Draft           Lightweight CMP Profile            October 2021


   Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI)
   [RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE)
   [I-D.ietf-anima-brski-async-enroll] describes a generalization
   regarding enrollment protocols alternative to EST [RFC7030].  As
   replacement of EST simpleenroll, BRSKI-AE uses this PKI management
   operation for bootstrapping LDevID certificates.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  The certificate of the EE MUST have been enrolled by an external
      PKI, e.g., a manufacturer-issued device certificate.

   *  The PKI management entity MUST have the trust anchor of the
      external PKI.

   *  When using the generalInfo field certProfile, the EE MUST know the
      identifier needed to indicate the requested certificate profile.

   Message flow:

   Step# EE                                  PKI management entity
     1   format ir
     2                      ->   ir      ->
     3                                        handle or
                                                forward ir
     4                                        format or receive ip
     5                                        possibly grant
                                                implicitConfirm
     6                      <-   ip      <-
     7   handle ip

   -----------------  if implicitConfirm not granted  -----------------

     8   format certConf
     9                      ->   certConf ->
    10                                        handle or
                                                forward certConf
    11                                        format or receive pkiConf
    12                      <-   pkiConf  <-
    13   handle pkiConf











Brockhaus, et al.         Expires 28 April 2022                [Page 33]


Internet-Draft           Lightweight CMP Profile            October 2021


   For this PKI management operation, the EE MUST include exactly one
   CertReqMsg in the ir.  If more certificates are required, further
   requests MUST be sent using separate PKI management operation.  If
   the EE wants to omit sending a certificate confirmation message after
   receiving the ip, e.g., to reduce the number of protocol messages
   exchanged in this PKI management operation, it MUST request this by
   including the implicitConfirm extension in the header of the ir
   message, see Section 3.1.

   If the EE did not request implicit confirmation or timplicit
   confirmation was not granted by the PKI management entity,
   certificate confirmation MUST be performed as follows.  If the EE
   successfully received the certificate, it MUST send a certConf
   message in due time.  On receiving a valid certConf message, the PKI
   management entity MUST respond with a pkiConf message.  If the PKI
   management entity does not receive the expected certConf message in
   time it MUST handle this like a rejection by the EE.  In case of
   rejection the PKI management entity SHALL terminate the PKI
   management operation, and the PKI MAY revoke the newly issued
   certificate.

   If the certificate request was rejected by the CA, the PKI management
   entity must return an ip message containing the status code
   "rejection" as described in Section 3.6 and no certifiedKeyPair
   field.  The EE MUST NOT react to such an ip message with a certConf
   message and the PKI management operation MUST be terminated.

   Detailed message description:

   Initialization Request -- ir

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The request of the EE for a new certificate
     ir                          REQUIRED
       -- MUST contain exactly one CertReqMsg
       -- If more certificates are required, further PKI management
       -- operations MUST be initiated
       certReq                   REQUIRED
         certReqId               REQUIRED
       -- MUST be 0
         certTemplate            REQUIRED
           version               OPTIONAL
       -- MUST be 2 if supplied



Brockhaus, et al.         Expires 28 April 2022                [Page 34]


Internet-Draft           Lightweight CMP Profile            October 2021


           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
           publicKey             REQUIRED
             algorithm           REQUIRED
       -- MUST include the subject public key algorithm identifier
             subjectPublicKey    REQUIRED
       -- MUST contain the public key to be certified in case of local
       -- key generation
           extensions            OPTIONAL
       -- MAY include end-entity-specific X.509 extensions of the
       -- requested certificate like subject alternative name, key
       -- usage, and extended key usage
       -- The subjectAltName extension MUST be present if the EE subject
       -- name includes a subject alternative name.
       popo                      OPTIONAL
       -- MUST be present if local key generation is used
       -- MUST be absent if central key generation is requested
         signature               RECOMMENDED
       -- MUST be used by an EE if the key can be used for signing and
       -- has the type POPOSigningKey
           poposkInput           PROHIBITED
       -- MUST NOT be used; it is not needed because subject and
       -- publicKey are both present in the certTemplate
           algorithmIdentifier   REQUIRED
       -- The signature algorithm MUST be consistent with the publicKey
       -- algorithm field of the certTemplate
           signature             REQUIRED
       -- MUST contain the signature value computed over the DER-encoded
       -- certTemplate
         raVerified              OPTIONAL
       -- MAY be used by an RA after verifying the proof-of-possession
       -- provided by the EE

   protection                    REQUIRED
       -- As described in Section 3.2

   extraCerts                    REQUIRED
       -- As described in Section 3.3


   Initialization Response -- ip

   Field                         Value

   header



Brockhaus, et al.         Expires 28 April 2022                [Page 35]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- As described in Section 3.1

   body
       -- The response of the CA to the request as appropriate
     ip                          REQUIRED
       caPubs                    OPTIONAL
       -- MAY be used if the certifiedKeyPair field is present
       -- If used it MUST contain only a trust anchor, e.g. root
       -- certificate, of the certificate contained in certOrEncCert
       response                  REQUIRED
       -- MUST contain exactly one CertResponse
         certReqId               REQUIRED
       -- MUST be 0
         status                  REQUIRED
       -- PKIStatusInfo structure MUST be present
           status                REQUIRED
       -- positive values allowed: "accepted", "grantedWithMods"
       -- negative values allowed: "rejection"
       -- "waiting" only allowed with polling use case as described in
       -- Section 4.4
           statusString          OPTIONAL
       -- MAY be any human-readable text for debugging, logging or to
       -- display in a GUI
           failInfo              OPTIONAL
       -- MAY be present if status is "rejection"
       -- MUST be absent if status is "accepted" or "grantedWithMods"
         certifiedKeyPair        OPTIONAL
       -- MUST be present if status is "accepted" or "grantedWithMods"
       -- MUST be absent if status is "rejection"
           certOrEncCert         REQUIRED
       -- MUST be present if status is "accepted" or "grantedWithMods"
             certificate         REQUIRED
       -- MUST be present when certifiedKeyPair is present
       -- MUST contain the newly enrolled X.509 certificate
           privateKey            OPTIONAL
       -- MUST be absent in case of local key generation or "rejection"
       -- MUST contain the encrypted private key in an EnvelopedData
       -- structure as specified in Section 4.1.6 in case the private
       -- key was generated centrally

   protection                    REQUIRED
       -- As described in Section 3.2

   extraCerts                    REQUIRED
       -- As described in Section 3.3
       -- MUST contain the chain of the certificate present in
       -- certOrEncCert
       -- Self-signed certificates SHOULD be omitted



Brockhaus, et al.         Expires 28 April 2022                [Page 36]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- Duplicate certificates MAY be omitted


   Certificate Confirmation -- certConf

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The message of the EE sends as confirmation to the PKI
       -- management entity to accept or reject the issued certificates
     certConf                    REQUIRED
       -- MUST contain exactly one CertStatus
       CertStatus                REQUIRED
         certHash                REQUIRED
       -- MUST be the hash of the certificate, using the hash algorithm
       -- indicated in hashAlg, see below, or the same one as used to
       -- create the certificate signature
         certReqId               REQUIRED
       -- MUST be 0
         statusInfo              RECOMMENDED
       -- PKIStatusInfo structure SHOULD be present
       -- Omission indicates acceptance of the indicated certificate
           status                REQUIRED
       -- positive values allowed: "accepted"
       -- negative values allowed: "rejection"
           statusString          OPTIONAL
       -- MAY be any human-readable text for debugging, logging, or to
       -- display in a GUI
           failInfo              OPTIONAL
       -- MAY be present if status is "rejection"
       -- MUST be absent if status is "accepted"
         hashAlg                 OPTIONAL
       -- The hash algorithm to use for calculating certHash
       -- SHOULD NOT be used in all cases where the AlgorithmIdentifier
       -- of the certificate signature specifies a hash algorithm
       -- If used, the pvno field in the header MUST be cmp2021 (3)

   protection                    REQUIRED
       -- As described in Section 3.2
       -- MUST use the same credentials as in the first request message
       -- of this PKI management operation

   extraCerts                    RECOMMENDED
       -- As described in Section 3.3
       -- MAY be omitted if the message size is critical and



Brockhaus, et al.         Expires 28 April 2022                [Page 37]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- the PKI management entity caches the extraCerts from the
       -- first request message of this PKI management operation


   PKI Confirmation -- pkiConf

   Field                         Value

   header
       -- As described in Section 3.1

   body
     pkiconf                     REQUIRED
       -- The content of this field MUST be NULL

   protection                    REQUIRED
       -- As described in Section 3.2
       -- MUST use the same credentials as in the first response
       -- message of this PKI management operation

   extraCerts                    RECOMMENDED
       -- As described in Section 3.3
       -- MAY be omitted if the message size is critical and the EE has
       -- cached the extraCerts from the first response message of
       -- this PKI management operation

4.1.2.  Requesting an additional certificate with signature-based
        protection

   This PKI management operation should be used by an EE to request an
   additional certificate of the same PKI it already has certificates
   from.  The EE uses one of these existing certificates to authenticate
   itself by signing its request messages using the respective private
   key.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  The certificate used by the EE MUST have been enrolled by the PKI
      it requests another certificate from.

   *  When using the generalInfo field certProfile, the EE MUST know the
      identifier needed to indicate the requested certificate profile.

   The message sequence for this PKI management operation is identical
   to that given in Section 4.1.1, with the following changes:

   1  The body of the first request and response SHOULD be cr and cp,
      respectively.



Brockhaus, et al.         Expires 28 April 2022                [Page 38]


Internet-Draft           Lightweight CMP Profile            October 2021


      Note: Since the difference between ir/ip and cr/cp is
      syntactically not essential, an ir/ip MAY be used in this PKI
      management operation.

   2  The caPubs field in the certificate response message SHOULD be
      absent.

4.1.3.  Updating an existing certificate with signature protection

   This PKI management operation should be used by an EE to request an
   update for one of its certificates that is still valid.  The EE uses
   the certificate it wishes to update as the protection certificate.
   Both for authenticating itself and for proving ownership of the
   certificate to be updated, it signs the request messages with the
   corresponding private key.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  The certificate the EE wishes to update MUST NOT be expired or
      revoked and MUST have been issued by the addressed CA.

   *  A new public-private key pair SHOULD be used.

   *  When using the generalInfo field certProfile, the EE MUST know the
      identifier needed to indicate the requested certificate profile.

   The message sequence for this PKI management operation is identical
   to that given in Section 4.1.1, with the following changes:

   1  The body of the first request and response MUST be kur and kup,
      respectively.

   2  Protection of the kur MUST be performed using the certificate to
      be updated.

   3  The subject field and/or the subjectAltName extension of the
      certTemplate MUST contain the EE subject name of the existing
      certificate to be updated, without modifications.

   4  The certTemplate SHOULD contain the subject and/or subjectAltName
      extension and publicKey of the EE only.

   5  The oldCertId control MAY be used to make clear which certificate
      is to be updated.

   6  The caPubs field in the kup message MUST be absent.





Brockhaus, et al.         Expires 28 April 2022                [Page 39]


Internet-Draft           Lightweight CMP Profile            October 2021


   As part of the certReq structure of the kur the oldCertId control is
   added after the certTemplate field.


       controls
         type                    RECOMMENDED
       -- MUST be the value id-regCtrl-oldCertID, if present
         value
           issuer                REQUIRED
           serialNumber          REQUIRED
       -- MUST contain the issuer and serialNumber of the certificate
       -- to be updated

4.1.4.  Requesting a certificate from a legacy PKI using a PKCS#10
        request

   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].  This offers a variation of the PKI management operations
   specified in Section 4.1.2.

   In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments,
   SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr
   message as a form of certificate signing request (CSR) to optionally
   include in device bootstrapping to obtain an identity certificate as
   part of the onboarding information.  Such a CSR is of form ietf-sztp-
   types:cmp-csr from module ietf-sztp-csr.  The requirements given
   below on p10cr message MUST be adhered to.

   In this PKI management operation, the public key and all further
   certificate template data MUST be contained in the subjectPKInfo and
   other certificationRequestInfo fields of the PKCS#10 structure.

   The prerequisites are the same as given in Section 4.1.2.

   The message sequence for this PKI management operation is identical
   to that given in Section 4.1.2, with the following changes:

   1  The body of the first request and response MUST be p10cr and cp,
      respectively.

   2  The certReqId in the cp message MUST be -1.

   3  The caPubs field in the cp message SHOULD be absent.

   Detailed description of the p10cr message:





Brockhaus, et al.         Expires 28 April 2022                [Page 40]


Internet-Draft           Lightweight CMP Profile            October 2021


   Certification Request -- p10cr

   Field                         Value

   header
       -- As described in Section 3.1

   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
         subjectPKInfo           REQUIRED
           algorithm             REQUIRED
       -- MUST include the subject public key algorithm identifier
           subjectPublicKey      REQUIRED
       -- MUST include the public key to be certified
         attributes              OPTIONAL
       -- MAY include end-entity-specific X.509 extensions of the
       -- requested certificate like subject alternative name,
       -- key usage, and extended key usage
       -- The subjectAltName extension MUST be present if the EE
       -- subject name includes a subject alternative name.
       signatureAlgorithm        REQUIRED
       -- The signature algorithm MUST be consistent with the
       -- subjectPKInfo field.
       signature                 REQUIRED
       -- MUST contain the self-signature for proof-of-possession

   protection                    REQUIRED
       -- As described for the underlying PKI management operation

   extraCerts                    REQUIRED
       -- As described for the underlying PKI management operation










Brockhaus, et al.         Expires 28 April 2022                [Page 41]


Internet-Draft           Lightweight CMP Profile            October 2021


4.1.5.  Requesting a certificate from a PKI with MAC-based protection

   This is a variant of the PKI management operations described in
   Section 4.1.1 to Section 4.1.4.  It should be used by an EE to
   request a certificate of a new PKI in case it does not have a
   certificate to prove its identity to the target PKI, but has some
   secret information shared with the PKI management entity.  Therefore,
   the request and response messages are MAC-protected using this shared
   secret information.  The distribution of this shared secret is out of
   scope for this document.  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.

   Note: The entropy of the shared secret information is crucial for the
   level of protection when using MAC-based protection.  Further
   guidance is available in the security considerations of CMP updated
   by [I-D.ietf-lamps-cmp-updates].

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  Rather than using private keys, certificates, and trust anchors,
      the EE and the PKI management entity MUST share secret
      information.

      Note: The shared secret information MUST be established out-of-
      band, e.g., by a service technician during initial local
      configuration.

   *  When using the generalInfo field certProfile, the EE MUST know the
      identifier needed to indicate the requested certificate profile.

   The message sequence for this PKI management operation is identical
   to that given in Section 4.1.1, with the following changes:

   1  The protection of all messages MUST be MAC-based.

   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.

   3  The extraCerts of all messages does not contain CMP protection
      certs and associated chains.








Brockhaus, et al.         Expires 28 April 2022                [Page 42]


Internet-Draft           Lightweight CMP Profile            October 2021


   See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for
   details on message authentication code algorithms (MSG_MAC_ALG) to
   use.  Typically, parameters are part of the protectionAlg field,
   e.g., used for key derivation, like a salt and an iteration count.
   Such fields SHOULD remain constant for message protection throughout
   this PKI management operation to reduce the computational overhead.

4.1.6.  Adding central key pair generation to a certificate request

   This is a variant of the PKI management operations described in
   Section 4.1.1 to Section 4.1.4 and the variant described in
   Section 4.1.5.  It needs to be used in case an EE is not able to
   generate its new public-private key pair itself or central generation
   of the EE key material is preferred.  It is a matter of the local
   implementation which PKI management entity will act as Key Generation
   Authority (KGA) and perform the key generation.  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.

   As described in Section 5.3.1, the KGA can use one of the PKI
   management operations described in the sections above to request the
   certificate for this key pair on behalf of the EE.

   Generally speaking, in machine-to-machine scenarios it is strongly
   preferable to generate public-private key pairs locally at the EE.
   Together with proof-of-possession of the private key in the
   certificate request, this is advisable to make sure that the entity
   identified in the newly issued certificate is the only entity that
   knows the private key.

   Reasons for central key generation may include the following:

   *  Lack of sufficient initial entropy.

      Note: Good random numbers are needed not only for key generation
      but also for session keys and nonces in any security protocol.
      Therefore, a decent security architecture should anyways support
      good random number generation on the EE side or provide enough
      initial entropy for the RNG seed to guarantee good pseudo-random
      number generation.  Yet maybe this is not the case at the time of
      requesting an initial certificate during manufacturing.

   *  Lack of computational resources, in particular for RSA key
      generation.






Brockhaus, et al.         Expires 28 April 2022                [Page 43]


Internet-Draft           Lightweight CMP Profile            October 2021


      Note: Since key generation could be performed in advance to the
      certificate enrollment communication, it is often not time
      critical.

   Note: As mentioned in Section 2.1, central key generation may be
   required in a push model, where the certificate response message is
   transferred by the PKI management entity to the EE without a previous
   request message.

   The EE requesting central key generation MUST omit the publicKey
   field from the certTemplate or, in case it has a preference on the
   key type to be generated, provide it in the algorithm sub-field and
   fill the subjectPublicKey sub-field with a zero-length BIT STRING.
   Both variants indicate to the PKI management entity that a new key
   pair shall be generated centrally on behalf of the EE.

   Note: As the protection of centrally generated keys in the response
   message has been extended to EncryptedKey by CMP Updates
   [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred
   alternative to EncryptedValue.  In CRMF Section 2.1.9 [RFC4211] the
   use of EncryptedValue has been deprecated in favor of the
   EnvelopedData structure.  Therefore, this profile requires using
   EnvelopedData as specified in CMS Section 6 [RFC5652].  When
   EnvelopedData is to be used in a PKI management operation, CMP v3
   MUST be indicated in the message header already for the initial
   request message, see Section 7 of CMP Updates
   [I-D.ietf-lamps-cmp-updates].

                   +----------------------------------+
                   | EnvelopedData                    |
                   | [RFC5652] section 6              |
                   | +------------------------------+ |
                   | | SignedData                   | |
                   | | [RFC5652] section 5          | |
                   | | +--------------------------+ | |
                   | | | AsymmetricKeyPackage     | | |
                   | | | [RFC5958]                | | |
                   | | | +----------------------+ | | |
                   | | | | privateKey           | | | |
                   | | | | OCTET STRING         | | | |
                   | | | +----------------------+ | | |
                   | | +--------------------------+ | |
                   | +------------------------------+ |
                   +----------------------------------+

                 Figure 3: Encrypted private key container





Brockhaus, et al.         Expires 28 April 2022                [Page 44]


Internet-Draft           Lightweight CMP Profile            October 2021


   The PKI management entity delivers the private key in the privateKey
   field in the certifiedKeyPair structure of the response message also
   containing the newly issued certificate.

   The private key MUST be provided as an AsymmetricKeyPackage structure
   as defined in RFC 5958 [RFC5958].

   This AsymmetricKeyPackage structure MUST be wrapped in a SignedData
   structure, as specified in CMS Section 5 [RFC5652] and [RFC8933],
   signed by the KGA generating the key pair.  The signature MUST be
   performed using a private key related to a certificate asserting the
   extended key usage id-kp-cmKGA as described in CMP Updates
   [I-D.ietf-lamps-cmp-updates] to demonstrate authorization to generate
   key pairs on behalf of an EE.  The EE SHOULD verify the presence of
   this extended key usage in the SignedData structure.

   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 in the SignedData structure since shared
   secret information is used for initial authentication.  In this case
   the EE MAY omit this signature validation.

   The SignedData structure MUST be wrapped in an EnvelopedData
   structure, as specified in CMS Section 6 [RFC5652], encrypting it
   using a newly generated symmetric content-encryption key.

   This content-encryption key MUST be securely provided as part of the
   EnvelopedData structure to the EE using one of three key management
   techniques.  The choice of the key management technique to be used by
   the PKI management entity depends on the authentication mechanism the
   EE chose to protect the request message.  See CMP Updates section 2.8
   [I-D.ietf-lamps-cmp-updates] for more details on which key management
   technique to use.

   *  Signature-based protection of the request message:

      -  The content-encryption key SHALL be protected using the key
         agreement key management technique, see Section 4.1.6.1, if the
         certificate used by the EE for protecting the request message
         allows the key usage keyAgreement.  If the certificate also
         allows the key usage keyEncipherment, the key transport key
         management technique SHALL NOT be used.

      -  The content-encryption key SHALL be protected using the key
         transport key management technique, see Section 4.1.6.2, if the
         certificate used by the EE for protecting the respective
         request message allows the key usage keyEncipherment but not
         keyAgreement.



Brockhaus, et al.         Expires 28 April 2022                [Page 45]


Internet-Draft           Lightweight CMP Profile            October 2021


   *  MAC-based protected of the request message:

      -  The content-encryption key SHALL be protected using the
         password-based key management technique, see Section 4.1.6.3,
         if and only if the EE used MAC-based protection for the request
         message.

   If central key generation is supported, support of the key agreement
   key management technique is REQUIRED and support of key transport and
   password-based key management techniques are OPTION, for two reasons:
   The key agreement key management technique is supported by most
   asymmetric algorithms, while the key transport key management
   technique is supported only by a very few of them.  The password-
   based key management technique shall only be used in combination with
   MAC-based protection, which is a sideline in this document.

   Specific prerequisites augmenting those of the respective certificate
   enrollment PKI management operations:

   *  If signature-based protection is used, the EE MUST be able to
      authenticate and authorize the KGA, using suitable information,
      which includes a trust anchor.

   *  If MAC-based protection is used, the KGA MUST also know the shared
      secret information to protect the encrypted transport of the newly
      generated key pair.  Consequently, the EE can also authorize the
      KGA.

   *  The PKI management entity MUST have a certificate containing the
      additional extended key usage extension id-kp-cmKGA for signing
      the SignedData structure containing the private key package.

   *  For encrypting the SignedData structure a fresh content-encryption
      key to be used by the symmetric encryption algorithm MUST be
      generated with sufficient entropy.

      Note: The security strength of the protection of the generated
      private key should be similar or higher than the security strength
      of the generated private key.

   The detailed description of the privateKey field as follows:

           privateKey            OPTIONAL
       -- MUST be an EnvelopedData structure as specified in CMS
       -- Section 6 [RFC5652]
             version             REQUIRED
       -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
       -- KeyTransRecipientInfo



Brockhaus, et al.         Expires 28 April 2022                [Page 46]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- MUST be 0 for recipientInfo type PasswordRecipientInfo
             recipientInfos      REQUIRED
       -- MUST contain exactly one RecipientInfo, which MUST be
       -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1),
       -- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or
       -- pwri of type PasswordRecipientInfo (see section 4.1.6.3)
             encryptedContentInfo
                                 REQUIRED
               contentType       REQUIRED
       -- MUST be id-signedData
               contentEncryptionAlgorithm
                                 REQUIRED
       -- MUST be the algorithm identifier of the algorithm used for
       -- content encryption
       -- The algorithm type MUST be a PROT_SYM_ALG as specified in
       -- RFC-CMP-Alg Section 5
               encryptedContent  REQUIRED
       -- MUST be the SignedData structure as specified in CMS
       -- Section 5 [RFC5652] and [RFC8933] in encrypted form
                 version         REQUIRED
       -- MUST be 3
                 digestAlgorithms
                                 REQUIRED
       -- MUST contain exactly one AlgorithmIdentifier element
       -- MUST be the algorithm identifier of the digest algorithm
       -- used for generating the signature and match the signature
       -- algorithm specified in signatureAlgorithm, see and [RFC8933]
                 encapContentInfo
                                 REQUIRED
       -- MUST contain the content that is to be signed
                   eContentType  REQUIRED
       -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
                   eContent      REQUIRED
       -- MUST be of type AsymmetricKeyPackage and
       -- MUST contain exactly one OneAsymmetricKey element
                         version REQUIRED
       -- MUST be 1 (indicating v2)
                         privateKeyAlgorithm
                                 REQUIRED
       -- The privateKeyAlgorithm field MUST contain the algorithm
       -- identifier of the asymmetric key pair algorithm
                         privateKey
                                 REQUIRED
                         publicKey
                                 REQUIRED
       -- MUST contain the public key corresponding to the private key
       -- for simplicity and consistency with v2 of OneAsymmetricKey
                 certificates    REQUIRED



Brockhaus, et al.         Expires 28 April 2022                [Page 47]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- MUST contain the certificate for the private key used to sign
       -- the signedData content, together with its chain
       -- The first certificate in this field MUST be the KGA
       -- certificate used for protecting this content
       -- Self-signed certificates SHOULD NOT be included and MUST NOT
       -- be trusted based on their inclusion in any case
                   signerInfos   REQUIRED
       -- MUST contain exactly one SignerInfo element
                   version       REQUIRED
       -- MUST be 3
                   sid           REQUIRED
                     subjectKeyIdentifier
                                 REQUIRED
       -- MUST be the subjectKeyIdentifier of the KGA certificate
                   digestAlgorithm
                                 REQUIRED
       -- MUST be the same as in digestAlgorithms
                   signedAttrs   REQUIRED
       -- MUST contain an id-contentType attribute containing the value
       -- id-ct-KP-aKeyPackage
       -- MUST contain an id-messageDigest attribute containing the
       -- message digest of eContent
       -- MAY contain an id-signingTime attribute containing the time
       -- of signature
       -- For details on the signed attributes see CMS Section 5.3 and
       -- Section 11 [RFC5652] and [RFC8933]
                   signatureAlgorithm
                                 REQUIRED
       -- MUST be the algorithm identifier of the signature algorithm
       -- used for calculation of the signature bits
       -- The signature algorithm type MUST be a MSG_SIG_ALG as
       -- specified in RFC-CMP-Alg Section 3 and MUST be consistent
       -- with the subjectPublicKeyInfo field of the KGA certificate
                   signature     REQUIRED
       -- MUST be the digital signature of the encapContentInfo

   NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that
   are defined in RFC 5652 [RFC5652] but are not explicitly specified
   here SHOULD NOT be used.

4.1.6.1.  Using key agreement key management technique

   This variant can be applied in combination with the PKI management
   operations specified in Section 4.1.1 to Section 4.1.3 using
   signature-based protection of CMP messages.  The EE certificate used
   for the signature-based protection of the request message MUST allow
   for the key usage "keyAgreement" and therefore, the related key pair
   MUST be used for establishment of the content-encryption key.  For



Brockhaus, et al.         Expires 28 April 2022                [Page 48]


Internet-Draft           Lightweight CMP Profile            October 2021


   this key management technique the KeyAgreeRecipientInfo structure
   MUST be used in the contentInfo field.

   The KeyAgreeRecipientInfo structure included into the EnvelopedData
   structure is specified in CMS Section 6.2.2 [RFC5652].

   The detailed description of the KeyAgreeRecipientInfo structure looks
   like this:

               kari              REQUIRED
       -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section
       -- 6.2.2 [RFC5652]
                 version         REQUIRED
       -- MUST be 3
                 originator      REQUIRED
       -- MUST contain the originatorKey choice
                   algorithm     REQUIRED
       -- MUST be the algorithm identifier of the key agreement
       -- algorithm
       -- The algorithm type MUST be a KM_KA_ALG as specified in
       -- RFC-CMP-Alg Section 4.1
                   publicKey     REQUIRED
       -- MUST be the ephemeral public key of the sending party
                 ukm             RECOMMENDED
       -- MUST be used when 1-pass ECMQV is used
       -- SHOULD be present to ensure uniqueness of the key
       -- encryption key, see [RFC8419]
                 keyEncryptionAlgorithm
                                 REQUIRED
       -- MUST be the algorithm identifier of the key wrap algorithm
       -- The algorithm type MUST be a KM_KW_ALG as specified in
       -- RFC-CMP-Alg Section 4.3
                 recipientEncryptedKeys
                                 REQUIRED
       -- MUST contain exactly one RecipientEncryptedKey element
                   rid           REQUIRED
       -- MUST contain the rKeyId choice
                     rKeyId      REQUIRED
                       subjectKeyIdentifier
                                 REQUIRED
       -- MUST contain the same value as the senderKID in the
       -- respective request message header
                     encryptedKey
                                 REQUIRED
       -- MUST be the encrypted content-encryption key






Brockhaus, et al.         Expires 28 April 2022                [Page 49]


Internet-Draft           Lightweight CMP Profile            October 2021


4.1.6.2.  Using key transport key management technique

   This variant can be applied in combination with the PKI management
   operations specified in Section 4.1.1 to Section 4.1.3 using
   signature-based protection of CMP messages.  The EE certificate used
   for the signature-based protection of the request message MUST allow
   for the key usage "keyEncipherment" and not for "keyAgreement".
   Therefore, the related key pair MUST be used for encipherment of the
   content-encryption key.  For this key management technique, the
   KeyTransRecipientInfo structure MUST be used in the contentInfo
   field.

   The KeyTransRecipientInfo structure included into the EnvelopedData
   structure is specified in CMS Section 6.2.1 [RFC5652].

   The detailed description of the KeyTransRecipientInfo structure looks
   like this:

               ktri              REQUIRED
       -- MUST be a KeyTransRecipientInfo as specified in CMS
       -- Section 6.2.1 [RFC5652]
                 version         REQUIRED
       -- MUST be 2
                 rid             REQUIRED
       -- MUST contain the subjectKeyIdentifier choice
                   subjectKeyIdentifier
                                 REQUIRED
       -- MUST contain the same value as the senderKID in the
       -- respective request message header
                 keyEncryptionAlgorithm
                                 REQUIRED
       -- MUST be the algorithm identifier of the key transport
       -- algorithm
       -- The algorithm type MUST be a KM_KT_ALG as specified in
       -- RFC-CMP-Alg Section 4.2
                 encryptedKey    REQUIRED
       -- MUST be the encrypted content-encryption key

4.1.6.3.  Using password-based key management technique

   This variant can be applied in combination with the PKI management
   operation specified in Section 4.1.5 using MAC-based protection of
   CMP messages.  The shared secret information used for the MAC-based
   protection MUST also be used for the encryption of the content-
   encryption key but with a different salt value applied in the key
   derivation algorithm.  For this key management technique, the
   PasswordRecipientInfo structure MUST be used in the contentInfo
   field.



Brockhaus, et al.         Expires 28 April 2022                [Page 50]


Internet-Draft           Lightweight CMP Profile            October 2021


   Note: The entropy of the shared secret information is crucial for the
   level of protection when using a password-based key management
   technique.  For centrally generated key pairs, the entropy of the
   shared secret information SHALL not be less than the security
   strength of the centrally generated key pair.  Further guidance is
   available in Section 8.

   The PasswordRecipientInfo structure included into the EnvelopedData
   structure is specified in CMS Section 6.2.4 [RFC5652].

   The detailed description of the PasswordRecipientInfo structure looks
   like this:

               pwri              REQUIRED
       -- MUST be a PasswordRecipientInfo as specified in CMS
       -- Section 6.2.4 [RFC5652]
                 version         REQUIRED
       -- MUST be 0
                 keyDerivationAlgorithm
                                 REQUIRED
       -- MUST be the algorithm identifier of the key derivation
       -- algorithm
       -- The algorithm type MUST be a KM_KD_ALG as specified in
       -- RFC-CMP-Alg Section 4.4
                 keyEncryptionAlgorithm
                                 REQUIRED
       -- MUST be the algorithm identifier of the key wrap algorithm
       -- The algorithm type MUST be a KM_KW_ALG as specified in
       -- RFC-CMP-Alg Section 4.3
                 encryptedKey    REQUIRED
       -- MUST be the encrypted content-encryption key

4.2.  Revoking a certificate

   This PKI management operation should be used by an entity to request
   revocation of a certificate.  Here the revocation request is used by
   an EE to revoke one of its own certificates.

   The revocation request message MUST be signed using the certificate
   that is to be revoked to prove the authorization to revoke.  The
   revocation request message is signature-protected using this
   certificate.  This requires, that the EE still possesses the private
   key.  If this is not the case the revocation has to be initiated by
   other means, e.g., revocation by the RA as specified in
   Section 5.3.2.






Brockhaus, et al.         Expires 28 April 2022                [Page 51]


Internet-Draft           Lightweight CMP Profile            October 2021


   An EE requests the revocation of an own certificate at the CA that
   issued this certificate.  The PKI management entity handles the
   request as described in Section 5.1.4 and responds with a message
   that contains the status of the revocation from the CA.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  The certificate the EE wishes to revoke is not yet expired or
      revoked.

   Message flow:

   Step# EE                                  PKI management entity
    1   format rr
    2                      ->   rr      ->
    3                                        handle or forward rr
    4                                        format or receive rp
    5                      <-   rp      <-
    6   handle rp

   For this PKI management operation, the EE MUST include exactly one
   RevDetails structure in the rr message body.  In case no generic
   error occurred the response to the rr MUST be an rp message
   containing a single status field.

   Detailed message description:

   Revocation Request -- rr

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The request of the EE to revoke its certificate
     rr                          REQUIRED
       -- MUST contain exactly one element of type RevDetails
       -- If more revocations are desired, further PKI management
       -- operations MUST be initiated
       certDetails               REQUIRED
       -- MUST be present and is of type CertTemplate
         serialNumber            REQUIRED
       -- MUST contain the certificate serialNumber attribute of the
       -- certificate to be revoked
         issuer                  REQUIRED
       -- MUST contain the issuer attribute of the certificate to be
       -- revoked



Brockhaus, et al.         Expires 28 April 2022                [Page 52]


Internet-Draft           Lightweight CMP Profile            October 2021


       crlEntryDetails           REQUIRED
       -- MUST contain exactly one reasonCode of type CRLReason (see
       -- [RFC5280] section 5.3.1)
       -- If the reason for this revocation is not known or shall not
       -- be published the reasonCode MUST be 0 = unspecified

   protection                    REQUIRED
       -- As described in Section 3.2 and using the private key related
       -- to the certificate to be revoked

   extraCerts                    REQUIRED
       -- As described in Section 3.3


   Revocation Response -- rp

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The responds of the PKI management entity to the request as
       -- appropriate
     rp                          REQUIRED
       status                    REQUIRED
       -- MUST contain exactly one element of type PKIStatusInfo
         status                  REQUIRED
       -- positive value allowed: "accepted"
       -- negative value allowed: "rejection"
         statusString            OPTIONAL
       -- MAY be any human-readable text for debugging, logging or to
       -- display in a GUI
         failInfo                OPTIONAL
       -- MAY be present if status is "rejection"
       -- MUST be absent if the status is "accepted"

   protection                    REQUIRED
       -- As described in section 3.2

   extraCerts                    REQUIRED
       -- As described in section 3.3









Brockhaus, et al.         Expires 28 April 2022                [Page 53]


Internet-Draft           Lightweight CMP Profile            October 2021


4.3.  Support messages

   The following support messages offer on demand in-band delivery of
   content relevant to the EE provided by a PKI management entity.  CMP
   general messages and general response are used for this purpose.
   Depending on the environment, these requests may be answered by an RA
   or CA (see also Section 5.1.5).

   The general messages and general response messages contain
   InfoTypeAndValue structures.  In addition to those infoType values
   defined in RFC 4210 [RFC4210] and CMP Updates
   [I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new
   PKI management operations or new general-purpose support messages as
   needed in specific environments.

   The following contents are specified in this document:

   *  Get CA certificates

   *  Get root CA certificate update

   *  Get certificate request template

   *  Get new CRLs

   In the following the aspects common to all general messages (genm)
   and general response (genp) messages are described.

   Message flow:

   Step# EE                                   PKI management entity
    1   format genm
    2                      ->   genm    ->
    3                                        handle or forward genm
    4                                        format or receive genp
    5                      <-   genp    <-
    6   handle genp

   Detailed message description:












Brockhaus, et al.         Expires 28 April 2022                [Page 54]


Internet-Draft           Lightweight CMP Profile            October 2021


   General Message -- genm

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- A request by the EE for information
     genm                        REQUIRED
       -- MUST contain exactly one element of type InfoTypeAndValue
       infoType                  REQUIRED
       -- MUST be the OID identifying one of the specific PKI
       -- management operations described below
       infoValue                 OPTIONAL
       -- MUST be as specified for the specific PKI management operation

   protection                    REQUIRED
       -- As described in Section 3.2

   extraCerts                    REQUIRED
       -- As described in Section 3.3


   General Response -- genp

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The response of the PKI management entity providing
       -- information
     genp                        REQUIRED
       -- MUST contain exactly one element of type InfoTypeAndValue
       infoType                  REQUIRED
       -- MUST be the OID identifying the specific PKI management
       -- operation described below
       infoValue                 OPTIONAL
       -- MUST be as specified for the specific PKI management operation

   protection                    REQUIRED
       -- As described in Section 3.2

   extraCerts                    REQUIRED
       -- As described in Section 3.3




Brockhaus, et al.         Expires 28 April 2022                [Page 55]


Internet-Draft           Lightweight CMP Profile            October 2021


4.3.1.  Get CA certificates

   This PKI management operation can be used by an EE to request CA
   certificates from the PKI management entity.

   An EE requests CA certificates, e.g., for chain construction, from an
   PKI management entity by sending a general message with OID id-it-
   caCerts as specified in CMP Updates [I-D.ietf-lamps-cmp-updates].
   The PKI management entity responds with a general response with the
   same OID that either contains a SEQUENCE of certificates populated
   with the available intermediate and issuing CA certificates or with
   no content in case no CA certificate is available.

   No specific prerequisites apply in addition to those specified in
   Section 3.4.

   The message sequence for this PKI management operation is as given
   above, with the following specific content:

   1  the infoType OID to use is id-it-caCerts

   2  the infoValue of the request MUST be absent

   3  if present, the infoValue of the response MUST contain a sequence
      of certificates

   The infoValue field of the general response containing the id-it-
   caCerts OID looks like this:

         infoValue               OPTIONAL
       -- MUST be absent if no CA certificate is available
       -- MUST be present if CA certificates are available
       -- MUST be a sequence of CMPCertificate

4.3.2.  Get root CA certificate update

   This PKI management operation can be used by an EE to request an
   updated root CA Certificate as described in Section 4.4 of RFC 4210
   [RFC4210].












Brockhaus, et al.         Expires 28 April 2022                [Page 56]


Internet-Draft           Lightweight CMP Profile            October 2021


   An EE requests an update of a root CA certificate from the PKI
   management entity by sending a general message with OID id-it-
   oldTrustAnchor, which SHOULD include this root CA certificate in the
   message body, as specified in CMP Updates
   [I-D.ietf-lamps-cmp-updates].  Optionally, the trust anchor MAY be
   provided as public key only.  The PKI management entity responds with
   a general response with the same OID that either contains the update
   of the root CA certificate consisting of up to three certificates, or
   with no content in case no update is available.

   Note: This mechanism can also be used in case the trust anchor to be
   updated is not provided as a self-signed certificate, but, e.g., as a
   certificate issued by a different CA.

   The newWithNew certificate is the new root CA certificate and is
   REQUIRED to be present if available.  The newWithOld certificate is
   REQUIRED to be present in the response message because it is needed
   for the receiving entity trusting the old root CA certificate to gain
   trust in the new root CA certificate.  The oldWithNew certificate is
   OPTIONAL because it is only needed in rare scenarios where entities
   do not already trust the old root CA.

   No specific prerequisites apply in addition to those specified in
   Section 3.4.

   The message sequence for this PKI management operation is as given
   above, with the following specific content:

   1  the infoType OID to use is id-it-oldTrustAnchor in the request and
      id-it-trustAnchorUpdate in the response

   2  the infoValue of the request MUST be an OldTrustAnchor structure
      referencing the trust anchor the update is requested for

   3  if present, the infoValue of the response MUST be a
      TrustAnchorUpdate structure

   The infoValue field of the general request containing the id-it-
   oldTrustAnchor OID looks like this:

         infoValue               RECOMMENDED
       -- MUST contain an OldTrustAnchor structure referencing the
       -- trust anchor to be updated
       -- SHOULD be the root CA certificate, if available
       -- MAY be the publicKey of the trust anchor otherwise

   The infoValue field of the general response containing the id-it-
   trustAnchorUpdate OID looks like this:



Brockhaus, et al.         Expires 28 April 2022                [Page 57]


Internet-Draft           Lightweight CMP Profile            October 2021


         infoValue               OPTIONAL
       -- MUST be absent if no update of the root CA certificate is
       -- available
       -- MUST be present if an update of the root CA certificate
       -- is available and MUST be of type TrustAnchorUpdate
           newWithNew            REQUIRED
       -- MUST be present if infoValue is present
       -- MUST contain the new root CA certificate
           newWithOld            REQUIRED
       -- MUST be present if infoValue is present
       -- MUST contain a certificate containing the new public
       -- root CA key signed with the old private root CA key
           oldWithNew            OPTIONAL
       -- MAY be present if infoValue is present
       -- MUST contain a certificate containing the old public
       -- root CA key signed with the new private root CA key

4.3.3.  Get certificate request template

   This PKI management operation can be used by an EE to request a
   template with parameters for future certificate requests.

   An EE requests certificate request parameters from the PKI management
   entity by sending a general message with OID id-it-certReqTemplate as
   specified in CMP Updates [I-D.ietf-lamps-cmp-updates].  The EE MAY
   indicate the certificate profile to use in the id-it-certProfile
   extension of the generalInfo field in the PKIHeader of the general
   message as described in Section 3.1.  The PKI management entity
   responds with a general response with the same OID that either
   contains requirements on the certificate request template, or with no
   content in case no specific requirements are imposed by the PKI.  The
   CertReqTemplateValue contains requirements on certificate fields and
   extensions in a certTemplate.  Optionally it contains a keySpec field
   containing requirements on algorithms acceptable for key pair
   generation.

   The EE SHOULD follow the requirements from the received CertTemplate,
   by including in the certificate requests all the fields requested,
   taking over all the field values provided and filling in any
   remaining fields values.  The EE SHOULD NOT add further fields, name
   components, and extensions or their (sub-)components.

   Note: We deliberately do not use "MUST" or "MUST NOT" here in order
   to allow more flexibility in case the rules given here are not
   sufficient for specific scenarios.  The EE can populate the
   certificate request as wanted and ignore any of the requirements
   contained in the CertReqTemplateValue.  On the other hand, a PKI
   management entity is free to ignore or replace any parts of the



Brockhaus, et al.         Expires 28 April 2022                [Page 58]


Internet-Draft           Lightweight CMP Profile            October 2021


   content of the certificate request provided by the EE.  The
   CertReqTemplate PKI management operation offers means to ease a joint
   understanding which fields and/or which field values should be used.
   An example is provided in Appendix A.

   In case a field of type Name, e.g., subject, is present in the
   CertTemplate but has the value NULL-DN (i.e., has an empty list of
   RDN components), the field SHOULD be included in the certificate
   request and filled with content provided by the EE.  Similarly, in
   case an X.509v3 extension is present but its extnValue is empty, this
   means that the extension SHOULD be included and filled with content
   provided by the EE.  In case a Name component, for instance a common
   name or serial number, is given but has an empty string value, the EE
   SHOULD fill in a value.  Similarly, in case an extension has sub-
   components (e.g., an IP address in a SubjectAltName field) with empty
   value, the EE SHOULD fill in a value.

   The EE MUST ignore (i.e., not include and fill in) empty fields,
   extensions, and sub-components that it does not understand or does
   not know suitable values to be filled in.

   The publicKey field of type SubjectPublicKeyInfo in the CertTemplate
   of the CertReqTemplateValue MUST be omitted.  In case the PKI
   management entity wishes to make stipulation on algorithms the EE may
   use for key generation, this MUST be specified using the keySpec
   field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates].

   The keySpec field, if present, specifies the public key types
   optionally with parameters, and/or RSA key lengths for which a
   certificate may be requested.

   The value of a keySpec element with the OID id-regCtrl-algId, as
   specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of
   type AlgorithmIdentifier and give an algorithm other than RSA.  For
   EC keys the curve information MUST be specified as described in the
   respective standard documents.

   The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as
   specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be a
   positive integer value and give an RSA key length.

   In the CertTemplate of the CertReqTemplateValue the serialNumber,
   signingAlg, issuerUID, and subjectUID fields MUST be omitted.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  When using the generalInfo field certProfile, the EE MUST know the
      identifier needed to indicate the requested certificate profile.



Brockhaus, et al.         Expires 28 April 2022                [Page 59]


Internet-Draft           Lightweight CMP Profile            October 2021


   The message sequence for this PKI management operation is as given
   above, with the following specific content:

   1  the infoType OID to use is id-it-certReqTemplate

   2  the id-it-certProfile generalInfo field in the header of the
      request MAY contain the name of the requested certificate request
      template

   3  the infoValue of the request MUST be absent

   4  if present, the infoValue of the response MUST be a
      CertReqTemplateValue containing a CertTemplate structure and an
      optional keySpec field

   The infoValue field of the general response containing the id-it-
   certReqTemplate OID looks like this:

         InfoValue               OPTIONAL
       -- MUST be absent if no requirements are available
       -- MUST be present if the PKI management entity has any
       -- requirements on the contents of the certificate template
           certTemplate          REQUIRED
       -- MUST be present if infoValue is present
       -- MUST contain the required CertTemplate structure elements
       -- The SubjectPublicKeyInfo field MUST be absent
           keySpec               OPTIONAL
       -- MUST be absent if no requirements on the public key are
       -- available
       -- MUST be present if the PKI management entity has any
       -- requirements on the keys generated
       -- MUST contain one AttributeTypeAndValue per supported
       -- algorithm with attribute id-regCtrl-algId or
       -- id-regCtrl-rsaKeyLen

4.3.4.  CRL update retrieval

   This PKI management operation can be used by an EE to request a new
   CRL.  If a CA offers methods to access a CRL they are often provided
   by the CA through the CRLDP or AuthorityInfoAccess as specified in
   [RFC5280] components in the issued certificates.  In addition, CMP
   offers this functionality as part of the PKI management operation.

   An EE requests a CRL update from the PKI management entity by sending
   a general message with OID id-it-crlStatusList.  This MUST include
   the CRL source and, if available, the thisUpdate time of the most
   current CRL instance it already has, as specified in CMP Updates
   [I-D.ietf-lamps-cmp-updates].  The PKI management entity MUST respond



Brockhaus, et al.         Expires 28 April 2022                [Page 60]


Internet-Draft           Lightweight CMP Profile            October 2021


   with a general response with OID id-it-crls.  If no thisUpdate value
   was given by the EE, it MUST return the latest CRL available.  If a
   thisUpdate value was given, it MUST return the latest available CRL
   in case this CRL is more recent, otherwise the infoValue in the
   response message MUST be absent.

   In addition to the prerequisites specified in Section 3.4, the EE
   MUST know for the requested CRL either its CRL distribution point
   name or the name of the CRL issuer.

   Note: If the EE does not want to request a specific CRL it MAY use
   instead a general message with OID id-it-currentCrl as specified in
   RFC 4210 Section 5.3.19.6 [I-D.ietf-lamps-cmp-updates].

   The message sequence for this PKI management operation is as given
   above, with the following specific content:

   1  the infoType OID to use is id-it-crlStatusList in the request and
      id-it-crls in the response

   2  the infoValue of the request MUST be present and contain a
      CRLStatus structure

   3  if present, the infoValue of the response MUST contain a CRL

   The infoValue field of the general request containing the id-it-
   crlStatusList OID looks like this:

         CRLSourceListValue                  REQUIRED
       -- MUST contain a CRLSource structure
       -- MUST contain the dpn choice if the CRL distribution point name
       -- is available
       -- MUST contain the issuer choice otherwise, naming the CA that
       -- issues the CRL.
         thisUpdate              OPTIONAL
       -- SHOULD contain the thisUpdate field of the latest CRL form
       -- the given dpn or issuer, in case such a CRL is already known
       -- by the EE

   The infoValue field of the general response containing the id-it-crls
   OID looks like this:

         infoValue               REQUIRED
       -- MUST contain a CRL update from the referenced source, if a
       -- thisUpdate value was not given or a more recent CRL is
       -- available





Brockhaus, et al.         Expires 28 April 2022                [Page 61]


Internet-Draft           Lightweight CMP Profile            October 2021


4.4.  Handling delayed delivery

   This is a variant of all PKI management operations described in
   described in this document.  It is initiated in case a PKI management
   entity cannot respond to a request message in a timely manner,
   typically due to offline or asynchronous upstream communication, or
   due to delays in handling the request.  The polling mechanism has
   been specified in RFC 4210 Section 5.3.22 [RFC4210] and updated by
   [I-D.ietf-lamps-cmp-updates].

   Depending on the PKI architecture, the entity initiating delayed
   delivery is not necessarily the PKI management entity directly
   addressed by the EE.

   When initiating delayed delivery of a message received from an EE,
   the PKI management entity MUST respond with an ip/cp/kup/error
   message including the status "waiting".  On receiving this response,
   the EE MUST store in its transaction context the senderNonce of the
   preceding request message because this value will be needed for
   checking the recipNonce of the final response to be received after
   polling.  It sends a poll request with certReqId 0 if referring to
   the CertResponse element contained in the ip/cp/kup message, else -1
   to refer to the whole message.  In case the final response is not yet
   available, the PKI management entity that initiated the delayed
   delivery MUST answer with a poll response, with the same certReqId.
   The included checkAfter time value indicates the minimum number of
   seconds that SHOULD elapse before the EE sends a new pollReq message
   to the PKI management entity.  This is repeated until a final
   response is available or any party involved gives up on the current
   PKI management operation, i.e., a timeout occurs.

   When the PKI management entity that initiated delayed delivery can
   provide the final response for the original request message of the
   EE, it MUST send this response to the EE.  Using this response, the
   EE can continue the current PKI management operation as usual.

   No specific prerequisites apply in addition to those of the
   respective PKI management operation.

   Message flow:











Brockhaus, et al.         Expires 28 April 2022                [Page 62]


Internet-Draft           Lightweight CMP Profile            October 2021


   Step# EE                                  PKI management entity
    1   format request
          message
    2                  ->     request     ->
    3                                        handle or forward
                                               request
    4                                        format ip/cp/kup/error
                                               with status "waiting"
                                               response in case no
                                               immediate final response
                                               is available,
    5                   <- ip/cp/kup/error <-
    6   handle
          ip/cp/kup/error
          with status
          "waiting"

   --------------------------  start polling  --------------------------

    7   format pollReq
    8                     ->    pollReq   ->
    9                                        handle or forward pollReq
   10                                        in case the final response
                                               for the original request
                                               is available, continue
                                               with step 14
                                             otherwise, format or
                                               receive pollRep with
                                               checkAfter value
   11                     <-    pollRep   <-
   12   handle pollRep
   13   let checkAfter
          time elapse and
          continue with
          step 7

   -----------------  end polling, continue as usual  ------------------

   14                                        format or receive
                                               final response on
                                               original request
   15                     <-   response   <-
   16   handle final
          response

   Detailed description of the ip/cp/kup/error response, pollReq, and
   pollRep:




Brockhaus, et al.         Expires 28 April 2022                [Page 63]


Internet-Draft           Lightweight CMP Profile            October 2021


   Response with status "waiting" -- ip/cp/kup/error

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- as described for the respective PKI management operation, with
       -- the following adaptations:
         status                  REQUIRED -- in case of ip/cp/kup
         pKIStatusInfo           REQUIRED -- in case of error response
       -- PKIStatusInfo structure MUST be present
           status                REQUIRED
       -- MUST be status "waiting"
           statusString          OPTIONAL
       -- MAY be any human-readable text for debugging, logging or to
       -- display in a GUI
           failInfo              PROHIBITED

   protection                    REQUIRED
       -- As described in Section 3.2

   extraCerts                    OPTIONAL
       -- As described in Section 3.3


   Polling Request -- pollReq

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The message of the EE asking for the final response or for a
       -- time to check again
     pollReq                     REQUIRED
       certReqId                 REQUIRED
    -- MUST be 0 if referring to a CertResponse element, else -1

   protection                    REQUIRED
       -- As described in Section 3.2
       -- MUST use the same credentials as in the first request message
       -- of the PKI management operation

   extraCerts                    RECOMMENDED
       -- As described in Section 3.3



Brockhaus, et al.         Expires 28 April 2022                [Page 64]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- MAY be omitted if the message size is critical and
       -- the PKI management entity caches the extraCerts from the
       -- first request message of the PKI management operation


   Polling Response -- pollRep

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- The message indicates the delay after which the EE SHOULD
       -- send another pollReq message for this transaction
     pollRep                     REQUIRED
       certReqId                 REQUIRED
    -- MUST be 0 if referring to a CertResponse element, else -1
       checkAfter                REQUIRED
       -- time in seconds to elapse before a new pollReq SHOULD be sent
       reason                    OPTIONAL
       -- MAY be any human-readable text for debugging, logging or to
       -- display in a GUI

   protection                    REQUIRED
       -- As described in Section 3.2
       -- MUST use the same credentials as in the first response
       -- message of the PKI management operation

   extraCerts                    RECOMMENDED
       -- As described in Section 3.3
       -- MAY be omitted if the message size is critical and the EE has
       -- cached the extraCerts from the first response message of
       -- the PKI management operation


   Final response – any type of response message

   Field                         Value

   header

       -- MUST be the header as described for the response message
       -- of the respective PKI management operation

   body
       -- The response of the PKI management entity to the initial
       -- request as described in the respective PKI management



Brockhaus, et al.         Expires 28 April 2022                [Page 65]


Internet-Draft           Lightweight CMP Profile            October 2021


       -- operation

   protection                    REQUIRED
       -- MUST be as described for the response message of the
       -- respective PKI management operation

   extraCerts                    REQUIRED
       -- MUST be as described for the response message of the
       -- respective PKI management operation

5.  PKI management entity operations

   This section focuses on request processing by a PKI management
   entity.  Depending on the network and PKI solution design, this can
   be an RA or CA, any of which may include protocol conversion or
   central key generation (i.e., acting as a KGA).

   A PKI management entity may directly respond to request messages from
   downstream and report errors.  In case the PKI management entity is
   an RA it typically forwards the received request messages upstream
   after checking them and forwards respective response messages
   downstream.  Besides responding to messages or forwarding them, a PKI
   management entity may request or revoke certificates on behalf of
   EEs.  A PKI management entity may also need to manage its own
   certificates and thus act as an EE using the PKI management
   operations specified in Section 4.

5.1.  Responding to requests

   The PKI management entity terminating the PKI management operation at
   CMP level MUST respond to all received requests by returning a
   related CMP response message or an error.  Any intermediate PKI
   management entity MAY respond depending on the PKI configuration and
   policy.

   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 useThe failInfo bit value to use on reporting failure as
   described in Section 3.6.4 is transactionIdInUse.  If any of these
   verification steps or any of the essential checks described in the
   following subsections fails, the PKI management entity MUST proceed
   as described in Section 3.6.

   The responding PKI management entity SHOULD copy the sender field of
   the request to the recipient field of the response, MUST copy the
   senderNonce of the request to the recipNonce of the response, and
   MUST use the same transactionID for the response.



Brockhaus, et al.         Expires 28 April 2022                [Page 66]


Internet-Draft           Lightweight CMP Profile            October 2021


5.1.1.  Responding to a certificate request

   An ir/cr/p10cr/kur message is used to request a certificate as
   described in Section 4.1.  The responding PKI management entity MUST
   proceed as follows unless it initiates delayed delivery as described
   in Section 5.1.2.

   The PKI management entity SHOULD check the message body according to
   the applicable requirements from Section 4.1.  Possible failInfo bit
   values used for error reporting in case a check failed include
   badCertId and badCertTemplate.  It MUST verify the presence and value
   of the proof-of-possession (failInfo bit: badPOP), unless central key
   generation is requested.  In case the special POP value "raVerified"
   is given, it SHOULD check that the request message was signed using a
   certificate containing the cmcRA extended key usage (failInfo bit:
   notAuthorized).  The PKI management entity SHOULD perform also any
   further checks on the certTemplate contents (failInfo:
   badCertTemplate) according to any applicable PKI policy and
   certificate profile.

   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.

   Note: If central key generation is performed by the responding PKI
   management entity, the responding PKI management entity MUST include
   in the response the privateKey field as specified in Section 4.1.6.
   It may have issued the certificate for the newly generated key pair
   itself if it is a CA, or have requested the certificate on behalf of
   the EE as described in Section 5.3.1, or have received it by other
   means from a CA.

   The prerequisites of the respective PKI management operation as
   specified in Section 4.1 apply.

   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.












Brockhaus, et al.         Expires 28 April 2022                [Page 67]


Internet-Draft           Lightweight CMP Profile            October 2021


5.1.2.  Initiating delayed delivery

   This functional extension can be used by a PKI management entity in
   case the response to a request takes longer than usual.  In this case
   the PKI management entity MUST completely validate the request as
   usual and then start preparing the response or forward the request
   further upstream as soon as possible.  In the meantime, it MUST
   respond with an ip/cp/kup/error message including the status
   "waiting" and handle subsequent polling as described in Section 4.4.

   Note: Typically, as stated in Section 5.2.3, an intermediate PKI
   management entity should not change the sender and recipient nonces
   even in case it modifies a request or a response message.  In the
   special case of delayed delivery initiated by an intermediate PKI
   management entity, there is an exception.  Between the EE and this
   PKI management entity, pollReq and pollRep messages are exchanged
   handling the nonces as usual.  Yet when the final response from
   upstream has arrived at the PKI management entity, this response
   contains the recipNonce copied (as usual) from the senderNonce in the
   original request message.  The PKI management entity that initiated
   the delayed delivery may replace the recipNonce in the response
   message with the senderNonce of the last received pollReq because the
   downstream entities, including the EE, might expect it in this way.
   Yet the check specified in Section 3.5 allows to alternatively use
   the senderNonce of the original request.

   No specific prerequisites apply in addition to those of the
   respective PKI management operation.

5.1.3.  Responding to a confirmation message

   A PKI management entity MUST handle a certConf message if it has
   responded before with a positive ip/cp/kup message not granting
   implicit confirmation.  It SHOULD check the message body according to
   the requirements given in Section 4.1.1 (failInfo bit: badCertId) and
   react as described there.

   The prerequisites of the respective PKI management operation as
   specified in Section 4.1 apply.












Brockhaus, et al.         Expires 28 April 2022                [Page 68]


Internet-Draft           Lightweight CMP Profile            October 2021


5.1.4.  Responding to a revocation request

   An rr message is used to request revocation of a certificate.  The
   responding PKI management entity SHOULD check the message body
   according to the requirements in Section 4.2.  It MUST make sure that
   the referenced certificate exists (failInfo bit: badCertId), has been
   issued by the addressed CA, and is not already expired or revoked
   (failInfo bit: certRevoked).  On success it MUST respond with a
   positive rp message as described in Section 4.2.

   No specific prerequisites apply in addition to those specified in
   Section 3.4.

5.1.5.  Responding to a support message

   A genm message is used to retrieve extra content.  The responding PKI
   management entity SHOULD check the message body according to the
   applicable requirements in Section 4.3 and perform any further checks
   depending on the PKI policy.  On success it MUST respond with a genp
   message as described there.

   Note: The responding PKI management entity may generate the response
   from scratch or reuse the contents of previous responses.  Therefore,
   it may be worth caching the body of the response message as long as
   the contained information is still valid, such that further requests
   for the same contents can be answered immediately.

   No specific prerequisites apply in addition to those specified in
   Section 3.4.

5.2.  Forwarding messages

   In case the PKI solution consists of intermediate PKI management
   entities (i.e., LRA or RA), each CMP request message coming from an
   EE or any other downstream PKI management entity SHOULD be forwarded
   to the next (upstream) PKI management entity as described in this
   section and otherwise MUST be answered as described in Section 5.1.
   Any received response message or error message MUST be forwarded to
   the next (downstream) PKI entity.

   In addition to the checks described in Section 3.5, the forwarding
   PKI management entity MAY verify the proof-of-possession for
   ir/cr/p10cr/kur messages.  If one of these verification procedures
   fails, the RA proceeds as described in Section 3.6.







Brockhaus, et al.         Expires 28 April 2022                [Page 69]


Internet-Draft           Lightweight CMP Profile            October 2021


   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.

   This is particularly relevant in the upstream communication of a
   request message.

   Each forwarding PKI management entity has one or more
   functionalities.  It may

   *  verify the identities of EEs and make authorization decisions for
      certification request processing based on specific knowledge of
      the local setup, e.g., by consulting an inventory or asset
      management system,

   *  add or modify fields of certificate request messages,

   *  store data from a message in a database for later usage or audit
      purposes,

   *  provide traversal of a network boundary,

   *  replace a MAC-based protection by a signature-based protection
      that can be verified also further upstream,

   *  double-check if the messages transferred back and forth are
      properly protected and well-formed,

   *  provide an authentic indication that it has performed all required
      checks,

   *  initiate a delayed delivery due to delays transferring messages or
      handling requests, or

   *  collect messages from multiple RAs and forward them jointly.

   The decision if a message should be forwarded

   *  unchanged with the original protection,

   *  unchanged with a new protection, or

   *  changed with a new protection

   depends on the PKI solution design and the associated security policy
   (CP/CPS [RFC3647]).



Brockhaus, et al.         Expires 28 April 2022                [Page 70]


Internet-Draft           Lightweight CMP Profile            October 2021


   A PKI management entity MUST replace or add a protection of a message
   if it

   *  needs to securely indicate that it has done checks or validations
      on the message to one of the next (upstream) PKI management entity
      or

   *  needs to protect the message using a key and certificate from a
      different PKI.

   A PKI management entity MUST replace a protection of a message if it

   *  performs changes to the header or the body of the message or

   *  needs to convert from or to a MAC-based protection.

   This is particularly relevant in the upstream communication of
   certificate request messages.

   Note that the message protection covers only the header and the body
   and not the extraCerts.  The PKI management entity MAY change the
   extraCerts in any of the following message adaptations, e.g., to
   sort, add, or delete certificates to support subsequent PKI entities.
   This may be particularly helpful to augment upstream messages with
   additional certificates or to reduce the number of certificates in
   downstream messages when forwarding to constrained devices.

5.2.1.  Not changing protection

   This variant means that a PKI management entity forwards a CMP
   message without changing the header, body, or protection.  In this
   case the PKI management entity acts more like a proxy, e.g., on a
   network boundary, implementing no specific RA-like security
   functionality that requires an authentic indication to the PKI.
   Still the PKI management entity might implement checks that result in
   refusing to forward the request message and instead responding as
   specified in Section 3.6.

   This variant of forwarding a message or the one described in
   Section 5.2.2.1 SHOULD be used for kur messages and for central key
   generation.

   No specific prerequisites apply in addition to those specified in
   Section 3.4.







Brockhaus, et al.         Expires 28 April 2022                [Page 71]


Internet-Draft           Lightweight CMP Profile            October 2021


5.2.2.  Adding protection and batching of messages

   This variant of forwarding a message means that a PKI management
   entity adds another protection to PKI management messages before
   forwarding them.

   The nested message is a PKI management message containing a
   PKIMessages sequence as its body containing one or more CMP messages.

   As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see
   CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases
   for adding another protection by a PKI management entity.  Specific
   procedures are described in more detail in the following sections.

   Detailed message description:

   Nested Message - nested

   Field                         Value

   header
       -- As described in Section 3.1

   body
       -- Container to provide additional protection to original
       -- messages and to bundle request messages or alternatively
       -- response messages
     PKIMessages                 REQUIRED
       -- MUST be a sequence of one or more CMP messages

   protection                    REQUIRED
       -- As described in Section 3.2 using the CMP protection key of
       -- the PKI management entity

   extraCerts                    REQUIRED
       -- As described in Section 3.3

5.2.2.1.  Adding protection to a request message

   A PKI management entity may authentically indicate successful
   validation and approval of a request message by adding an extra
   signature to the original message.

   By adding a protection using its own CMP protecting key the PKI
   management entity provides a proof of verifying and approving the
   message as described above.  Thus, the PKI management entity acts as
   an actual Registration Authority (RA), which implements important
   security functionality of the PKI.  Applying an additional protection



Brockhaus, et al.         Expires 28 April 2022                [Page 72]


Internet-Draft           Lightweight CMP Profile            October 2021


   is specifically relevant when forwarding a message that requests a
   certificate update or central key generation.  This is because the
   original protection of the EE must be preserved while adding an
   indication of approval by the PKI management entity.

   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.  The additional signature serves as
   proof of verification and authorization by this PKI management
   entity.

   The PKI management entity receiving such a nested message that
   contains a single request message MUST validate the additional
   protection signature on the nested message and check the
   authorization for the approval it implies.

   The PKI management entity responding to the request contained in the
   nested message sends the response message as described in
   Section 5.1, without wrapping it in a nested message.

   Note: This form of nesting messages is characterized by the fact that
   the transactionID in the header of the nested message is the same as
   the one used in the included message.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  The PKI management entity MUST have the authorization to perform
      the validation and approval of the respective request according to
      the PKI policies.

   Message flow:

   Step# PKI management entity               PKI management entity
    1   format nested
    2                      ->  nested   ->
    3                                        handle or forward nested
    4                                        format or receive response
    5                      <-  response <-
    6   forward response











Brockhaus, et al.         Expires 28 April 2022                [Page 73]


Internet-Draft           Lightweight CMP Profile            October 2021


5.2.2.2.  Batching messages

   A PKI management entity MAY bundle any number of PKI management
   messages for batch processing or to transfer a bulk of PKI management
   messages using the nested message structure.  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.

   This PKI management operation is typically used on the interface
   between an LRA and an RA to bundle several messages for offline
   delivery.  In this case the LRA needs to initiate delayed delivery as
   described in Section 5.1.2.  If the RA needs different routing
   information per nested PKI management message a suitable mechanism
   may need to be implemented.  Since this mechanism strongly depends on
   the requirements of the target architecture, it is out of scope of
   this document.

   A nested message containing requests is generated locally at the PKI
   management entity.  For the upstream nested message, the PKI
   management entity acts as a protocol end point and therefore a fresh
   transactionID and a fresh senderNonce MUST be used in the header of
   the nested message.  An upstream nested message may contain request
   messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm.
   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.

   Such an upstream nested message is sent to the next PKI management
   entity.  The upstream PKI management entity that unbundles it MUST
   handle each of the included request messages as usual.  It MUST
   answer with a downstream nested message.  This downstream nested
   message MUST use the transactionID of the upstream nested message and
   return the senderNonce of the upstream nested message as the
   recipNonce of the downstream nested message.  The downstream nested
   message SHOULD bundle the individual response messages (e.g., ip, cp,
   kup, pollRep, pkiConf, rp, genp, error) for all original request
   messages of the upstream nested message.  While unbundling the
   downstream nested message, the former PKI management entity can
   determine lost and unexpected responses based on the previously
   stored transactionIDs.  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.





Brockhaus, et al.         Expires 28 April 2022                [Page 74]


Internet-Draft           Lightweight CMP Profile            October 2021


   Note: This form of nesting messages is characterized by the fact that
   the transactionID in the header of the nested message is different to
   those used in the included messages.

   The protection of the nested messages SHOULD NOT be regarded as an
   indication of verification or approval of the bundled PKI request
   messages.

   No specific prerequisites apply in addition to those specified in
   Section 3.4.

   Message flow:

   Step# PKI management entity               PKI management entity
    1   format nested
    2                      ->  nested   ->
    3                                        handle or forward nested
    4                                        format or receive nested
    5                      <-  nested   <-
    6   handle nested

5.2.3.  Replacing protection

   The following two alternatives can be used by any PKI management
   entity forwarding a CMP message with or without changes while
   providing its own protection and in this way asserting approval of
   the message.

   By replacing the existing protection using its own CMP protecting key
   the PKI management entity provides a proof of verifying and approving
   the message as described above.  Thus, the PKI management entity acts
   as an actual Registration Authority (RA), which implements important
   security functionality of the PKI.

   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.

   These message adaptations MUST NOT be applied to kur messages
   described in Section 4.1.3 since their original protection using the
   key and certificate to be updated needs to be preserved, unless the
   regCtrl OldCertId is used to strongly identify the certificate to be
   updated.






Brockhaus, et al.         Expires 28 April 2022                [Page 75]


Internet-Draft           Lightweight CMP Profile            October 2021


   These message adaptations MUST NOT be applied to certificate request
   messages described in for central key generation Section 4.1.6 since
   their original protection needs to be preserved up to the Key
   Generation Authority, which needs to use it for encrypting the new
   private key for the EE.

   In both the kur and central key generation cases, if a PKI management
   entity needs to state its approval of the original request message it
   MUST provide this using a nested message as specified in
   Section 5.2.2.1.

   When an intermediate PKI management entity modifies a message, it
   SHOULD NOT change the transactionID nor the sender and recipient
   nonces.

5.2.3.1.  Not changing any included proof-of-possession

   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.

   In case the PKI management entity breaks an existing proof-of-
   possession, the message adaptation described in Section 5.2.3.2 needs
   to be applied instead.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  The PKI management entity MUST have the authorization to perform
      the validation and approval of the respective request according to
      the PKI policies.

5.2.3.2.  Breaking proof-of-possession

   This variant of forwarding a message needs to be used if a PKI
   management entity breaks a signature-based proof-of-possession in a
   certificate request message, for instance because it forwards an ir
   or cr message with modifications of the certTemplate, i.e.,
   modification, addition, or removal of fields.

   The PKI management entity MUST verify the proof-of-possession
   contained in the original message using the included public key.  If
   successful, the PKI management entity MUST change the popo field
   value to raVerified.

   Specific prerequisites augmenting the prerequisites in Section 3.4:

   *  The PKI management entity MUST have the authorization to verify
      the proof-of-possession.



Brockhaus, et al.         Expires 28 April 2022                [Page 76]


Internet-Draft           Lightweight CMP Profile            October 2021


   *  The PKI management entity MUST have the authorization to perform
      the validation and approval of the respective request according to
      the PKI policies.

   The new popo field MUST contain the raVerified choice in the certReq
   structure of the modified message as follows:

       popo
         raVerified              REQUIRED
       -- MUST have the value NULL and indicates that the PKI
       -- management entity verified the popo of the original message

5.3.  Acting on behalf of other PKI entities

   A PKI management entity may need to request a PKI management
   operation on behalf of another PKI entity.  In this case the PKI
   management entity initiates the respective PKI management operation
   as described in Section 4 acting in the role of the EE.

5.3.1.  Requesting certificates

   A PKI management entity may use on of the PKI management operations
   described in Section 4.1 to request a certificate on behalf of
   another PKI entity.  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.

   No specific prerequisites apply in addition to those specified in
   Section 4.1.

   Note: An upstream PKI management entity will not be able to
   differentiate this PKI management operation from the one described in
   Section 5.2.3.

   The message sequence for this PKI management operation is identical
   to the respective PKI management operation given in Section 4.1, with
   the following changes:

   1  The request messages MUST be signed using the CMP protection key
      of the PKI management entity taking the role of the EE in this
      operation.

   2  If inclusion of a proper proof-of-possession is not possible the
      PKI management entity MUST verify the POP provided from downstream
      and use "raVerified" in its upstream request.




Brockhaus, et al.         Expires 28 April 2022                [Page 77]


Internet-Draft           Lightweight CMP Profile            October 2021


5.3.2.  Revoking a certificate

   A PKI management entity may use the PKI management operation
   described in Section 4.2 to revoke a certificate of another PKI
   entity.  This revocation request message MUST be signed by the PKI
   management entity using its own CMP protection key to prove to the
   PKI authorization to revoke the certificate on behalf of that PKI
   entity.

   No specific prerequisites apply in addition to those specified in
   Section 4.2.

   Note: An upstream PKI management entity will not be able to
   differentiate this PKI management operation from the ones described
   in Section 5.2.3.

   The message sequence for this PKI management operation is identical
   to that given in Section 4.2, with the following changes:

   1  The rr message MUST be signed using the CMP protection key of the
      PKI management entity taking the role of the EE in this operation.

6.  CMP message transfer mechanisms

   CMP messages are designed to be self-contained, such that in
   principle any reliable transfer mechanism can be used.  HTTP SHOULD
   and CoAP MAY be used for online transfer.  CMP messages MAY also be
   piggybacked on any other reliable transfer protocol.  File-based
   transfer MAY be used in case offline transfer is required.

   Independently of the means of transfer, it can happen that messages
   are lost or that a communication partner does not respond.  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.  In this way a hanging transaction can be closed
   cleanly with an error as described in Section 3.6 (failInfo bit:
   systemUnavail) and related resources (for instance, any cached
   extraCerts) can be freed.

   Moreover, there are various situations where the delivery of messages
   gets delayed.  For instance, a serving PKI management entity might
   take longer than expected to form a response due to administrative
   processes, resource constraints, or upstream message delivery delays.
   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



Brockhaus, et al.         Expires 28 April 2022                [Page 78]


Internet-Draft           Lightweight CMP Profile            October 2021


   CMP level using pollReq and pollRep messages as described in
   Section 4.4, while others are better handled at transfer level.
   Depending on the transfer protocol and system architecture, solutions
   for handling delays at transfer level may be present and can be used
   for CMP connections, for instance connection re-establishment and
   message retransmission.

   Note: Long timeout periods are helpful to minimize the need for
   polling and maximize chances to handle transfer issues at lower
   levels.

   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.

   When conveying CMP messages in HTTP, CoAP, or MIME-based transfer
   protocols, the internet media type "application/pkixcmp" MUST be set
   for transfer encoding as specified in Section 5.3 of RFC 2510
   [RFC2510], Section 2.4 of CMP over CoAP
   [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP
   [RFC6712].

6.1.  HTTP transfer

   This transfer mechanism can be used by a PKI entity to transfer CMP
   messages over HTTP.  If HTTP transfer is used the specifications as
   described in [RFC6712] and updated by CMP Updates
   [I-D.ietf-lamps-cmp-updates] MUST be followed.

   PKI management operations SHOULD use URI paths consisting of '/.well-
   known/cmp/' followed by an operation label depending on the type of
   PKI management operation.

















Brockhaus, et al.         Expires 28 April 2022                [Page 79]


Internet-Draft           Lightweight CMP Profile            October 2021


   +=======================================+=================+=========+
   | PKI management operation              |  operationLabel | Details |
   +=======================================+=================+=========+
   | Enroll client to new PKI              | /initialization | Section |
   |                                       |                 | 4.1.1   |
   +---------------------------------------+-----------------+---------+
   | Enroll client to existing             |  /certification | Section |
   | PKI                                   |                 | 4.1.2   |
   +---------------------------------------+-----------------+---------+
   | Update client certificate             |    /keyupdate   | Section |
   |                                       |                 | 4.1.3   |
   +---------------------------------------+-----------------+---------+
   | Enroll client using                   |       /p10      | Section |
   | PKCS#10                               |                 | 4.1.4   |
   +---------------------------------------+-----------------+---------+
   | Revoke client certificate             |   /revocation   | Section |
   |                                       |                 | 4.2     |
   +---------------------------------------+-----------------+---------+
   | Get CA certificates                   |   /getcacerts   | Section |
   |                                       |                 | 4.3.1   |
   +---------------------------------------+-----------------+---------+
   | Get root CA certificate               |  /getrootupdate | Section |
   | update                                |                 | 4.3.2   |
   +---------------------------------------+-----------------+---------+
   | Get certificate request               |   /getcacerts   | Section |
   | template                              |                 | 4.3.1   |
   +---------------------------------------+-----------------+---------+
   | Get CRL updates                       |     /getcrls    | Section |
   |                                       |                 | 4.3.4   |
   +---------------------------------------+-----------------+---------+
   | Batching messages                     |     /nested     | Section |
   |                                       |                 | 5.2.2.2 |
   | Note: This path element is            |                 |         |
   | applicable only between               |                 |         |
   | PKI management entities.              |                 |         |
   +---------------------------------------+-----------------+---------+

                          Table 9: HTTP endpoints

   Independently of any variants used (see Section 4.1.5, Section 4.1.6,
   and Section 4.4) the operation label corresponding to the PKI
   management operation SHALL be used.

   Any certConf or pollReq messages are sent to the same endpoint as
   determined by the PKI management operation.






Brockhaus, et al.         Expires 28 April 2022                [Page 80]


Internet-Draft           Lightweight CMP Profile            October 2021


   When a single request message is nested as described in
   Section 5.2.2.1, the label to use is the same as for the underlying
   PKI management operation.

   By sending a request to its preferred endpoint, the PKI entity will
   recognize via the HTTP response status code whether a configured URI
   is supported by the PKI management entity.

   In case a PKI management entity receives an unexpected HTTP status
   code from upstream, it MUST respond downstream with an error message
   as described in Section 3.6 using a failInfo bit corresponding to the
   status code, e.g., systemFailure.

   For certificate management the major security goal is integrity and
   data origin authentication.  For delivery of centrally generated
   keys, also confidentiality is a must.  These goals are sufficiently
   achieved by CMP itself, also in an end-to-end fashion.  If a second
   line of defense is required or general privacy concerns exist, TLS
   can be used to provide confidentiality on a hop-by-hop basis.

   TLS SHOULD be used with certificate-based authentication to further
   protect the HTTP transfer as described in [RFC2818].  The CMP
   transfer via HTTPS MUST use TLS server authentication and SHOULD use
   TLS client authentication.

   Note: The requirements for checking certificates given in [RFC5280],
   [RFC5246], and [RFC8446] MUST be followed for the TLS layer.
   Certificate status checking SHOULD be used for the TLS certificates
   of all communication partners.

   TLS with mutual authentication based on shared secret information MAY
   be used in case no suitable certificates for certificate-based
   authentication are available, e.g., a PKI management operation with
   MAC-based protection is used.

   Note: The entropy of the shared secret information is crucial for the
   level of protection available using shard secret information-based
   TLS authentication.  A pre-shared key (PSK) mechanism is acceptable
   using shared secret information with an entropy of at least 128 bits.
   Otherwise, a password-authenticated key exchange (PAKE) protocol is
   RECOMMENDED.

6.2.  CoAP transfer

   This transfer mechanism can be used by a PKI entity to transfer CMP
   messages over CoAP [RFC7252], e.g., in constrained environments.  If
   CoAP transfer is used the specifications as described in CMP over
   CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed.



Brockhaus, et al.         Expires 28 April 2022                [Page 81]


Internet-Draft           Lightweight CMP Profile            October 2021


   PKI management operations SHOULD use URI paths consisting of '/.well-
   known/cmp/' followed by an operation label depending on the type of
   PKI management operation.

   +=======================================+================+=========+
   | PKI management operation              | operationLabel | Details |
   +=======================================+================+=========+
   | Enroll client to new PKI              |      /ir       | Section |
   |                                       |                | 4.1.1   |
   +---------------------------------------+----------------+---------+
   | Enroll client to existing PKI         |      /cr       | Section |
   |                                       |                | 4.1.2   |
   +---------------------------------------+----------------+---------+
   | Update client certificate             |      /kur      | Section |
   |                                       |                | 4.1.3   |
   +---------------------------------------+----------------+---------+
   | Enroll client using PKCS#10           |      /p10      | Section |
   |                                       |                | 4.1.4   |
   +---------------------------------------+----------------+---------+
   | Revoke client certificate             |      /rr       | Section |
   |                                       |                | 4.2     |
   +---------------------------------------+----------------+---------+
   | Get CA certificates                   |     /crts      | Section |
   |                                       |                | 4.3.1   |
   +---------------------------------------+----------------+---------+
   | Get root CA certificate update        |      /rcu      | Section |
   |                                       |                | 4.3.2   |
   +---------------------------------------+----------------+---------+
   | Get certificate request template      |      /att      | Section |
   |                                       |                | 4.3.3   |
   +---------------------------------------+----------------+---------+
   | Get CRL updates                       |     /crls      | Section |
   |                                       |                | 4.3.4   |
   +---------------------------------------+----------------+---------+
   | Batching messages                     |     /nest      | Section |
   |                                       |                | 5.2.2.2 |
   | Note: This path element is applicable |                |         |
   | only between PKI management entities. |                |         |
   +---------------------------------------+----------------+---------+

                         Table 10: CoAP endpoints

   Independently of any variants used (see Section 4.1.5, Section 4.1.6,
   and Section 4.4) the operation label corresponding to the PKI
   management operation SHALL be used.

   Any certConf or pollReq messages are sent to the same endpoint as
   determined by the PKI management operation.



Brockhaus, et al.         Expires 28 April 2022                [Page 82]


Internet-Draft           Lightweight CMP Profile            October 2021


   When a single request message is nested as described in
   Section 5.2.2.1, the label to use is the same as for the underlying
   PKI management operation.

   By sending a request to its preferred endpoint, the PKI entity will
   recognize via the CoAP response status code whether a configured URI
   is supported by the PKI management entity.  The CoAP-inherent
   discovery mechanisms MAY also be used.

   In case a PKI management entity receives an unexpected CoAP status
   code from upstream, it MUST respond downstream with an error message
   as described in Section 3.6 using a failInfo bit corresponding to the
   status code, e.g., systemFailure.

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

6.3.  Piggybacking on other reliable transfer

   CMP messages MAY also be transfer on some other reliable protocol.
   Connection, delay, and error handling mechanisms similar to those
   specified for HTTP in Section 6.1 need to be implemented.

   A more detailed specification is out of scope of this document and
   would need to be given for instance in the scope of the transfer
   protocol used.

6.4.  Offline transfer

   For transferring CMP messages between PKI entities, any mechanism can
   be used that is able to store and forward binary objects of
   sufficient length and with sufficient reliability while preserving
   the order of messages for each transaction.

   The transfer mechanism SHOULD be able to indicate message loss,
   excessive delay, and possibly other transmission errors.  In such
   cases the PKI entities SHOULD report an error as specified in
   Section 3.6 as far as possible.

6.4.1.  File-based transfer

   CMP messages MAY be transferred between PKI entities using file-based
   mechanisms, for instance when an offline EE or a PKI management
   entity performs delayed delivery.  Each file MUST contain the ASN.1
   DER encoding of one CMP message only, where the message may be
   nested.  There MUST be no extraneous header or trailer information in
   the file.  The file name extension ".pki" MUST be used.



Brockhaus, et al.         Expires 28 April 2022                [Page 83]


Internet-Draft           Lightweight CMP Profile            October 2021


6.4.2.  Other asynchronous transfer protocols

   Other asynchronous transfer protocols, e.g., email or website
   up-/download, MAY transfer CMP messages between PKI entities.  A MIME
   wrapping is defined for those environments that are MIME-native.  The
   MIME wrapping in this section is specified in RFC 8551 Section 3.1
   [RFC8551].

   The ASN.1 DER encoding of the CMP messages MUST be transferred using
   the "application/pkixcmp" content type and base64-encoded content
   transfer encoding as specified in [RFC2510], section 5.3.  A filename
   MUST be included either in a "content-type" or a "content-
   disposition" statement.  The file name extension ".pki" MUST be used.

7.  IANA Considerations

8.  Security Considerations

   The security considerations as laid out in CMP [RFC4210] updated by
   CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
   [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm
   Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over
   CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply.

   For TLS using shared secret information-based authentication, both
   PSK and PAKE provide the same amount of protection against a real-
   time authentication attack which is directly the amount of entropy in
   the shared secret.  The difference between a pre-shared key (PSK) and
   a password-authenticated key exchange (PAKE) protocols is in the
   level of long-term confidentiality of the TLS messages against brute-
   force decryption, where a PSK-based cipher suite only provides
   security according to the entropy of the shared secret, while a PAKE-
   based cipher suite provides full security independent of the entropy
   of the shared secret.

9.  Acknowledgements

   We thank the various reviewers of this document.

10.  References

10.1.  Normative References









Brockhaus, et al.         Expires 28 April 2022                [Page 84]


Internet-Draft           Lightweight CMP Profile            October 2021


   [I-D.ietf-ace-cmpv2-coap-transport]
              Sahni, M. and S. Tripathi, "CoAP Transfer for the
              Certificate Management Protocol", Work in Progress,
              Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-03, 1
              October 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ace-cmpv2-coap-transport-03>.

   [I-D.ietf-lamps-cmp-algorithms]
              Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
              "Certificate Management Protocol (CMP) Algorithms", Work
              in Progress, Internet-Draft, draft-ietf-lamps-cmp-
              algorithms-07, 22 August 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              cmp-algorithms-07>.

   [I-D.ietf-lamps-cmp-updates]
              Brockhaus, H. and D. V. Oheimb, "Certificate Management
              Protocol (CMP) Updates", Work in Progress, Internet-Draft,
              draft-ietf-lamps-cmp-updates-12, 9 July 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              cmp-updates-12>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              DOI 10.17487/RFC2986, November 2000,
              <https://www.rfc-editor.org/info/rfc2986>.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210,
              DOI 10.17487/RFC4210, September 2005,
              <https://www.rfc-editor.org/info/rfc4210>.

   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
              Certificate Request Message Format (CRMF)", RFC 4211,
              DOI 10.17487/RFC4211, September 2005,
              <https://www.rfc-editor.org/info/rfc4211>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.



Brockhaus, et al.         Expires 28 April 2022                [Page 85]


Internet-Draft           Lightweight CMP Profile            October 2021


   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

   [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958,
              DOI 10.17487/RFC5958, August 2010,
              <https://www.rfc-editor.org/info/rfc5958>.

   [RFC6712]  Kause, T. and M. Peylo, "Internet X.509 Public Key
              Infrastructure -- HTTP Transfer for the Certificate
              Management Protocol (CMP)", RFC 6712,
              DOI 10.17487/RFC6712, September 2012,
              <https://www.rfc-editor.org/info/rfc6712>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8933]  Housley, R., "Update to the Cryptographic Message Syntax
              (CMS) for Algorithm Identifier Protection", RFC 8933,
              DOI 10.17487/RFC8933, October 2020,
              <https://www.rfc-editor.org/info/rfc8933>.

   [RFC9045]  Housley, R., "Algorithm Requirements Update to the
              Internet X.509 Public Key Infrastructure Certificate
              Request Message Format (CRMF)", RFC 9045,
              DOI 10.17487/RFC9045, June 2021,
              <https://www.rfc-editor.org/info/rfc9045>.

10.2.  Informative References

   [ETSI-3GPP.33.310]
              3GPP, "Network Domain Security (NDS); Authentication
              Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020.

   [I-D.ietf-anima-brski-async-enroll]
              Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear,
              "Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)",
              Work in Progress, Internet-Draft, draft-ietf-anima-brski-
              async-enroll-04, 25 October 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
              brski-async-enroll-04>.









Brockhaus, et al.         Expires 28 April 2022                [Page 86]


Internet-Draft           Lightweight CMP Profile            October 2021


   [I-D.ietf-anima-brski-prm]
              Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
              with Pledge in Responder Mode (BRSKI-PRM)", Work in
              Progress, Internet-Draft, draft-ietf-anima-brski-prm-00,
              25 October 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-anima-brski-prm-00>.

   [I-D.ietf-netconf-sztp-csr]
              Watsen, K., Housley, R., and S. Turner, "Conveying a
              Certificate Signing Request (CSR) in a Secure Zero Touch
              Provisioning (SZTP) Bootstrapping Request", Work in
              Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-09,
              22 October 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-netconf-sztp-csr-09>.

   [IEC.62443-3-3]
              IEC, "Industrial communication networks - Network and
              system security - Part 3-3: System security requirements
              and security levels", IEC 62443-3-3, August 2013,
              <https://webstore.iec.ch/publication/7033>.

   [IEEE.802.1AR_2018]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks - Secure Device Identity", IEEE 802.1AR-2018,
              DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,
              <https://ieeexplore.ieee.org/document/8423794>.

   [NIST.CSWP.04162018]
              National Institute of Standards and Technology (NIST),
              "Framework for Improving Critical Infrastructure
              Cybersecurity, Version 1.1", NIST NIST.CSWP.04162018,
              DOI 10.6028/NIST.CSWP.04162018, April 2018,
              <http://nvlpubs.nist.gov/nistpubs/CSWP/
              NIST.CSWP.04162018.pdf>.

   [NIST.SP.800-57p1r5]
              Barker, E B., "Recommendation for key management, part 1
              :general", NIST NIST.SP.800-57pt1r5,
              DOI 10.6028/NIST.SP.800-57pt1r5, 2020,
              <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.

   [RFC2510]  Adams, C. and S. Farrell, "Internet X.509 Public Key
              Infrastructure Certificate Management Protocols",
              RFC 2510, DOI 10.17487/RFC2510, March 1999,
              <https://www.rfc-editor.org/info/rfc2510>.






Brockhaus, et al.         Expires 28 April 2022                [Page 87]


Internet-Draft           Lightweight CMP Profile            October 2021


   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <https://www.rfc-editor.org/info/rfc2818>.

   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
              Wu, "Internet X.509 Public Key Infrastructure Certificate
              Policy and Certification Practices Framework", RFC 3647,
              DOI 10.17487/RFC3647, November 2003,
              <https://www.rfc-editor.org/info/rfc3647>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
              Touch Provisioning (SZTP)", RFC 8572,
              DOI 10.17487/RFC8572, April 2019,
              <https://www.rfc-editor.org/info/rfc8572>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.



Brockhaus, et al.         Expires 28 April 2022                [Page 88]


Internet-Draft           Lightweight CMP Profile            October 2021


   [UNISIG.Subset-137]
              UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management
              FFFIS; V1.0.0", December 2015,
              <https://www.era.europa.eu/filebrowser/download/542_en>.

Appendix A.  Example CertReqTemplate

   Suppose the server requires that the certTemplate contains

   *  the issuer field with a value to be filled in by the EE,

   *  the subject field with a common name to be filled in by the EE and
      two organizational unit fields with given values "myDept" and
      "myGroup",

   *  the publicKey field contains an ECC key on curve secp256r1 or an
      RSA public key of length 2048,

   *  the subjectAltName extension with DNS name "www.myServer.com" and
      an IP address to be filled in,

   *  the keyUsage extension marked critical with the value
      digitalSignature and keyAgreement, and

   *  the extKeyUsage extension with values to be filled in by the EE.

   Then the infoValue with certTemplate and keySpec fields returned to
   the EE will be encoded as follows:


   SEQUENCE {
     SEQUENCE {
       [3] {
         SEQUENCE {}
         }
       [5] {
         SEQUENCE {
           SET {
             SEQUENCE {
               OBJECT IDENTIFIER commonName (2 5 4 3)
               UTF8String ""
               }
             }
           SET {
             SEQUENCE {
               OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
               UTF8String "myDept"
               }



Brockhaus, et al.         Expires 28 April 2022                [Page 89]


Internet-Draft           Lightweight CMP Profile            October 2021


             }
           SET {
             SEQUENCE {
               OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
               UTF8String "myGroup"
               }
             }
           }
         }
       [9] {
         SEQUENCE {
           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
           OCTET STRING, encapsulates {
             SEQUENCE {
               [2] "www.myServer.com"
               [7] ""
               }
             }
           }
         SEQUENCE {
           OBJECT IDENTIFIER keyUsage (2 5 29 15)
           BOOLEAN TRUE
           OCTET STRING, encapsulates {
             BIT STRING 3 unused bits
               "10001"B
             }
           }
         SEQUENCE {
           OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
           OCTET STRING, encapsulates {
             SEQUENCE {}
             }
           }
         }
       }
     SEQUENCE {
       SEQUENCE {
         OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 11)
           SEQUENCE {
             OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
             OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
             }
         }
       SEQUENCE {
         OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)
         INTEGER 2048
         }
       }



Brockhaus, et al.         Expires 28 April 2022                [Page 90]


Internet-Draft           Lightweight CMP Profile            October 2021


     }

Appendix B.  History of changes

   Note: This appendix will be deleted in the final version of the
   document.

   From version 06 -> 07:

   *  Added references to [draft-ietf-netconf-sztp-csr] in new
      Section 1.5 and Section 4.1.4
   *  Added reference to [I-D.ietf-anima-brski-async-enroll] in new
      Section 1.5 and Section 4.1.1
   *  Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as
      the PUSH use case is continued to be discussed in this draft after
      the split of BRSKI-AE
   *  Improved note regarding UNISIG Subset-137 in Section 1.6
   *  Removed "rootCaCert" in Section 3.1 and updated the structure of
      the genm request for root CA certificate updates in Section 4.3.2.
   *  Simplified handling of sender and recipient nonces in case of
      delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2
   *  Changed the order of Sections 4.1.4 and 4.1.5
   *  Added reference on RFC 8933 regarding CMS signedAttrs to
      Section 4.1.6
   *  Added Section 4.3.4 on CRL update retrieval
   *  Generalized delayed enrollment to delayed delivery in Section 4.4
      and 5.1.2, updated the state machine in the introduction of
      Section 4
   *  Updated Section 6 regarding delayed message transfer
   *  Changed file name extension from ".PKI" to ".pki", deleted
      operational path for central key generation, and added an
      operational path for CRL update retrieval in Sections 6.1 and 6.2
   *  Shifted many security considerations to CMP Updates
   *  Replaced the term "transport" by "transfer" where appropriate to
      prevent confusion regarding TCP vs. HTTP and CoAP
   *  Various editorial changes and language corrections

   From version 05 -> 06:

   *  Changed in Section 2.3 the normative requirement in of adding
      protection to a single message to mandatory and replacing
      protection to optional
   *  Added Section 3.4 specifying generic prerequisites to PKI
      management operations
   *  Added Section 3.5 specifying generic message validation
   *  Added Section 3.6 on generic error reporting.  This section
      replaces the former error handling section from Section 4 and 5.
   *  Added reference to using hashAlg



Brockhaus, et al.         Expires 28 April 2022                [Page 91]


Internet-Draft           Lightweight CMP Profile            October 2021


   *  Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates
   *  Added Section 5.1 specifying the behavior of PKI management
      entities when responding to requests
   *  Reworked Section 5.2.3. on usage of nested messages
   *  Updates Section 5.3 on performing PKI management operation on
      behalf of another entity
   *  Updates Section 6.2 on HTTPS transport of CMP messages as
      discusses at IETF 110 and email thread "I-D Action: draft-ietf-
      lamps-lightweight-cmp-profile-05.txt"
   *  Added CoAP endpoints to Section 6.4
   *  Added security considerations on usage of shared secret
      information
   *  Updated the example in Appendix A
   *  Added newly registered OIDs to the example in Appendix A
   *  Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs
   *  Multiple language corrections, clarifications, and changes in
      wording

   From version 04 -> 05:

   *  Changed to XML V3
   *  Added algorithm names introduced in CMP Algorithms Section 7.3 to
      Section 4 of this document
   *  Updates Syntax in Section 4.4.3 due to changes made in CMP Updates
   *  Deleted the text on HTTP-based discovery as discussed in
      Section 6.1
   *  Updates Appendix A due to change syntax in Section 4.4.3
   *  Many clarifications and changes in wording thanks to David's
      extensive review

   From version 03 -> 04:

   *  Deleted normative text sections on algorithms and refer to CMP
      Algorithms and CRMF Algorithm Requirements Update instead
   *  Some clarifications and changes in wording

   From version 02 -> 03:

   *  Updated the interoperability with [UNISIG.Subset-137] in
      Section 1.4.
   *  Changed Section 2.3 to a tabular layout to enhanced readability
   *  Added a ToDo to section 3.1 on aligning with the CMP Algorithms
      draft that will be set up as decided in IETF 108
   *  Updated section 4.1.6 to add the AsymmetricKey Package structure
      to transport a newly generated private key as decided in IETF 108
   *  Added a ToDo to section 4.1.7 on required review of the nonce
      handling in case an offline LRA responds and not forwards the
      pollReq messages



Brockhaus, et al.         Expires 28 April 2022                [Page 92]


Internet-Draft           Lightweight CMP Profile            October 2021


   *  Updated Section 4 due to the definition of the new ITAV OIDs in
      CMP Updates
   *  Updated Section 4.4.4 to utilize controls instead of rsaKeyLen
      (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen")
   *  Deleted the section on definition and discovery of HTTP URIs and
      copied the text to the HTTP transport section and to CMP Updates
      section 3.2
   *  Added some explanation to Section 5.1.2 and Section 5.1.3 on using
      nested messages when a protection by the RA is required.
   *  Deleted the section on HTTP URI definition and discovery as some
      content was moved to CMP Updates.  The rest of the content was
      moved back to the HTTP transport section
   *  Deleted the ASN.1 module after moving the new OIDs id-it-caCerts,
      id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates
   *  Minor changes in wording and addition of some open ToDos

   From version 01 -> 02:

   *  Extend Section 1.6 with regard to conflicts with UNISIG Subset-
      137.
   *  Minor clarifications on extraCerts in Section 3.3 and
      Section 4.1.1.
   *  Complete specification of requesting a certificate from a trusted
      PKI with signature protection in Section 4.1.2.
   *  Changed from symmetric key-encryption to password-based key
      management technique in section Section 4.1.6.3 as discussed on
      the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
      profile-01, section 5.1.6.1")
   *  Changed delayed enrollment described in Section 4.4 from
      recommended to optional as decided at IETF 107
   *  Introduced the new RootCAKeyUpdate structure for root CA
      certificate update in Section 4.3.2 as decided at IETF 107 (also
      see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
      section 5.4.3")
   *  Extend the description of the CertReqTemplate PKI management
      operation, including an example added in the Appendix.  Keep
      rsaKeyLen as a single integer value in Section 4.3.3 as discussed
      on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
      profile-01, section 5.4.4")
   *  Deleted Sections "Get certificate management configuration" and
      "Get enrollment voucher" as decided at IETF 107
   *  Complete specification of adding an additional protection by an
      PKI management entity in Section 5.2.2.
   *  Added a section on HTTP URI definition and discovery and extended
      Section 6.1 on definition and discovery of supported HTTP URIs and
      content types, add a path for nested messages as specified in
      Section 5.2.2 and delete the paths for /getCertMgtConfig and
      /getVoucher



Brockhaus, et al.         Expires 28 April 2022                [Page 93]


Internet-Draft           Lightweight CMP Profile            October 2021


   *  Changed Section 6.4 to address offline transport and added more
      detailed specification file-based transport of CMP
   *  Added a reference to the new I-D of Mohit Sahni on "CoAP Transport
      for CMPV2" in Section 6.2; thanks to Mohit supporting the effort
      to ease utilization of CMP
   *  Moved the change history to the Appendix
   *  Minor changes in wording

   From version 00 -> 01:

   *  Harmonize terminology with CMP [RFC4210], e.g.,
      -  transaction, message sequence, exchange, use case -> PKI
         management operation
      -  PKI component, (L)RA/CA -> PKI management entity
   *  Minor changes in wording

   From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf-
   lamps-lightweight-cmp-profile-00:

   *  Changes required to reflect WG adoption
   *  Minor changes in wording

   From version 02 -> 03:

   *  Added a short summary of [RFC4210] Appendix D and E in
      Section 1.4.
   *  Clarified some references to different sections and added some
      clarification in response to feedback from Michael Richardson and
      Tomas Gustavsson.
   *  Added an additional label to the operational path to address
      multiple CAs or certificate profiles in Section 6.1.

   From version 01 -> 02:

   *  Added some clarification on the key management techniques for
      protection of centrally generated keys in Section 4.1.6.
   *  Added some clarifications on the certificates for root CA
      certificate update in Section 4.3.2.
   *  Added a section to specify the usage of nested messages for RAs to
      add an additional protection for further discussion, see
      Section 5.2.2.
   *  Added a table containing endpoints for HTTP transport in
      Section 6.1 to simplify addressing PKI management entities.
   *  Added some ToDos resulting from discussion with Tomas Gustavsson.
   *  Minor clarifications and changes in wording.

   From version 00 -> 01:




Brockhaus, et al.         Expires 28 April 2022                [Page 94]


Internet-Draft           Lightweight CMP Profile            October 2021


   *  Added a section to specify the enrollment with an already trusted
      PKI for further discussion, see Section 4.1.2.
   *  Complete specification of requesting a certificate from a legacy
      PKI using a PKCS#10 [RFC2986] request in Section 4.1.4.
   *  Complete specification of adding central generation of a key pair
      on behalf of an end entity in Section 4.1.6.
   *  Complete specification of handling delayed enrollment due to
      asynchronous message delivery in Section 4.4.
   *  Complete specification of additional support messages, e.g., to
      update a Root CA certificate or to request an RFC 8366 [RFC8366]
      voucher, in Section 4.3.
   *  Minor changes in wording.

   From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft-
   brockhaus-lamps-lightweight-cmp-profile-00:

   *  Change focus from industrial to more multi-purpose use cases and
      lightweight CMP profile.
   *  Incorporate the omitted confirmation into the header specified in
      Section 3.1 and described in the standard enrollment use case in
      Section 4.1.1 due to discussion with Tomas Gustavsson.
   *  Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's
      entities certificate' in Section 5.3.2, because it is regarded as
      important functionality in many environments to enable the
      management station to revoke EE certificates.
   *  Complete the specification of the revocation message flow in
      Section 4.2 and Section 5.3.2.
   *  The CoAP based transport mechanism and piggybacking of CMP
      messages on top of other reliable transport protocols is out of
      scope of this document and would need to be specified in another
      document.
   *  Further minor changes in wording.

Authors' Addresses

   Hendrik Brockhaus (editor)
   Siemens AG

   Email: hendrik.brockhaus@siemens.com


   Steffen Fries
   Siemens AG

   Email: steffen.fries@siemens.com






Brockhaus, et al.         Expires 28 April 2022                [Page 95]


Internet-Draft           Lightweight CMP Profile            October 2021


   David von Oheimb
   Siemens AG

   Email: david.von.oheimb@siemens.com















































Brockhaus, et al.         Expires 28 April 2022                [Page 96]