[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                             H. Brockhaus
Internet-Draft                                                  S. Fries
Updates: 4210 (if approved)                                D. von Oheimb
Intended status: Standards Track                                 Siemens
Expires: September 12, 2019                               March 11, 2019


                   Lightweight Industrial CMP Profile
            draft-brockhaus-lamps-industrial-cmp-profile-00

Abstract

   The goal of this document is to facilitate interoperability and
   automation by profiling the Certificate Management Protocol (CMP)
   [RFC4210] and the related Certificate Request Message Format (CRMF)
   [RFC4211].  It specifies a subset of CMP and CRMF focusing on typical
   uses cases relevant for managing certificates of devices in
   industrial and IoT scenarios.  To limit the overhead of certificate
   management for constrained devices only the most crucial types of
   transactions are specified as mandatory.  To foster interoperability
   also in more complex scenarios, other types of transactions are
   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 September 12, 2019.

Copyright Notice

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

   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



Brockhaus, et al.      Expires September 12, 2019               [Page 1]


Internet-Draft               Lightweight CMP                  March 2019


   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation for profiling CMP  . . . . . . . . . . . . . .   3
     1.2.  Motivation for an industrial profile for CMP  . . . . . .   4
     1.3.  Existing CMP profiles . . . . . . . . . . . . . . . . . .   5
     1.4.  Compatibility with existing CMP profiles  . . . . . . . .   5
     1.5.  Scope of this document  . . . . . . . . . . . . . . . . .   6
     1.6.  Structure of this document  . . . . . . . . . . . . . . .   7
     1.7.  Convention and Terminology  . . . . . . . . . . . . . . .   7
   2.  Architecture and use cases  . . . . . . . . . . . . . . . . .   8
     2.1.  Solution architecture . . . . . . . . . . . . . . . . . .   8
     2.2.  Basic generic CMP message content . . . . . . . . . . . .   9
     2.3.  Supported use cases . . . . . . . . . . . . . . . . . . .   9
       2.3.1.  Mandatory use cases . . . . . . . . . . . . . . . . .  10
       2.3.2.  Recommended Use Cases . . . . . . . . . . . . . . . .  10
       2.3.3.  Optional use cases  . . . . . . . . . . . . . . . . .  11
     2.4.  CMP message transport . . . . . . . . . . . . . . . . . .  11
   3.  Generic parts of the PKI message  . . . . . . . . . . . . . .  12
     3.1.  General description of the CMP message header . . . . . .  13
     3.2.  General description of the CMP message protection . . . .  15
     3.3.  General description of CMP message extraCerts . . . . . .  15
   4.  End Entity focused certificate management use cases . . . . .  15
     4.1.  Requesting a new certificate from a PKI . . . . . . . . .  16
       4.1.1.  A certificate from a new PKI with signature
               protection  . . . . . . . . . . . . . . . . . . . . .  17
       4.1.2.  Update an existing certificate with signature
               protection  . . . . . . . . . . . . . . . . . . . . .  22
       4.1.3.  A certificate from a PKI with MAC protection  . . . .  24
       4.1.4.  A certificate from a legacy PKI using PKCS#10 request  25
       4.1.5.  Generate the key pair centrally at the (L)RA/CA . . .  26
       4.1.6.  Delayed enrollment  . . . . . . . . . . . . . . . . .  26
       4.1.7.  Omitted confirmation  . . . . . . . . . . . . . . . .  27
     4.2.  Revoking a certificate  . . . . . . . . . . . . . . . . .  27
     4.3.  Error reporting . . . . . . . . . . . . . . . . . . . . .  28
     4.4.  Support messages  . . . . . . . . . . . . . . . . . . . .  29
       4.4.1.  Root CA certificate update  . . . . . . . . . . . . .  30
       4.4.2.  Get enrollment voucher  . . . . . . . . . . . . . . .  30
   5.  LRA and RA focused certificate management use cases . . . . .  30
     5.1.  Forwarding of messages  . . . . . . . . . . . . . . . . .  31
       5.1.1.  Not changing protection . . . . . . . . . . . . . . .  33



Brockhaus, et al.      Expires September 12, 2019               [Page 2]


Internet-Draft               Lightweight CMP                  March 2019


       5.1.2.  Replacing protection  . . . . . . . . . . . . . . . .  33
         5.1.2.1.  Keeping proof-of-possession . . . . . . . . . . .  33
         5.1.2.2.  Breaking proof-of-possession  . . . . . . . . . .  34
       5.1.3.  Initiating delayed enrollment . . . . . . . . . . . .  34
       5.1.4.  Granting omitted confirmation . . . . . . . . . . . .  34
     5.2.  Revoking certificates of other entities . . . . . . . . .  35
     5.3.  Error reporting . . . . . . . . . . . . . . . . . . . . .  35
   6.  CMP message transport variants  . . . . . . . . . . . . . . .  35
     6.1.  HTTP transport  . . . . . . . . . . . . . . . . . . . . .  36
     6.2.  HTTPS transport using certificates  . . . . . . . . . . .  36
     6.3.  HTTPS transport using shared secrets  . . . . . . . . . .  37
     6.4.  File-based transport  . . . . . . . . . . . . . . . . . .  37
     6.5.  CoAP transport  . . . . . . . . . . . . . . . . . . . . .  37
     6.6.  Piggybacking on other reliable transport  . . . . . . . .  37
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  38
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  38
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  38
     10.2.  Informative References . . . . . . . . . . . . . . . . .  39
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1.  Introduction

   This document specifies certificate management transactions
   implementing industrial machine-to-machine and IoT use cases.  The
   focus lies on maximum automation and interoperable implementation of
   all involved components from end entities (EE) through an optional
   Local Registration Authority (LRA) and the RA up to the CA.  The
   profile makes use of the concepts and syntax specified in CMP
   [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712].
   Especially CMP and CRMF are very feature-rich standards, while only a
   limited subset of the specified functionality is needed in the target
   environment of this document.  Additionally, both standards are not
   always precise enough on how to interpret and implement the described
   concepts.  Therefore, we aim at tailoring and specifying in more
   detail how to use these concepts to implement automated certificate
   management in industrial target environments.

1.1.  Motivation for profiling CMP

   CMP was standardized in 1999 and is implemented in several CA
   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 using http [RFC6712] in
   2012.




Brockhaus, et al.      Expires September 12, 2019               [Page 3]


Internet-Draft               Lightweight CMP                  March 2019


   Though CMP is a very solid and capable protocol it could be used more
   widely.  The most important reason for not more intense application
   of CMP appears to be that the protocol is offering a large set of
   features and options but being not always precise enough and leaving
   room for interpretation.  On the one hand, this makes CMP applicable
   to a very wide range of scenarios, but on the other hand a full
   implementation of all options is unrealistic because this would take
   enormous 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] offer some more detailed certificate
   use cases.  But the specific needs of highly automated industrial
   scenarios are not covered sufficiently.

   As also 3GPP, and UNISG 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 exactly those needed for
   the purpose(s) at hand and eliminating all identified ambiguities.
   In this way all the general and applicable aspects of the protocol
   can be taken over and only the peculiarities of the target scenario
   need to be dealt with specifically.

   Doing such a profiling for a new target environment can be a 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 with the intended usage scenario.  Since industrial use
   cases typically have much in common it is worth sharing this effort,
   which is the aim of this document.  Other standardization bodies can
   then reference the profile from this document and do not need to come
   up with individual profiles.

1.2.  Motivation for an industrial profile for CMP

   The profiles specified in Appendix D and E of CMP have been developed
   in particular to manage 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 these
   very 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 procedures.



Brockhaus, et al.      Expires September 12, 2019               [Page 4]


Internet-Draft               Lightweight CMP                  March 2019


   Due to increasing security in operational networks as well as
   availability requirements, especially on critical infrastructures and
   systems with a high volume of certificates, a state-of-the-art
   certificate management must be constantly available and cost-
   efficient, which calls for high automation and reliability.  Such PKI
   operation according to commonly accepted best practices is also
   required in IEC 62443-3-3 [IEC62443-3-3] for security level 2 up to
   security level 4.

   Further challenges in industrial systems are network segmentation and
   asynchronous communication, where PKI operation is often 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 with end-to-end security.

1.3.  Existing CMP profiles

   As already stated, CMP contains profiles with mandatory and optional
   transactions in the Appendixes D and E of [RFC4210].  Those profiles
   focus on management of human user certificates and do not address the
   specific needs of industrial use cases.

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

   UNISIG has included a CMP profile for certificate enrollment in the
   subset 137 specifying the ETRAM/ECTS on-line key management for train
   control systems [UNISIG] in 2015.

   Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and
   HTTP transfer for CMP [RFC6712] to add tailored means for automated
   certificate management in an industrial setting.

1.4.  Compatibility with existing CMP profiles

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

   o  signature-based protection is the default protection; initial
      transactions may also use HMAC,





Brockhaus, et al.      Expires September 12, 2019               [Page 5]


Internet-Draft               Lightweight CMP                  March 2019


   o  certification of a second key pair within the same transaction is
      not supported,

   o  proof-of-possession (POPO) with self-signature of the certTemplate
      according to [RFC4211] section 4.1 clause 3 is the only supported
      POPO method,

   o  confirmation of newly enrolled certificates may be omitted, and

   o  all transactions consist of request-response message pairs
      originating at the EE, i.e., announcement messages are omitted.

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

   o  protection of initial transactions may be HMAC-based,

   o  the subject name is mandatory in certificate templates, and

   o  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], except that:

   o  the messageTime format is required to be generalizedTime (Note:
      While requiring UTC, UNISIG is in conflicts with CMP [RFC4210]
      that requires the messageTime format to be generalizedTime), and

   o  in case the request message is MAC protected, also the response,
      certConf, and PKIconf messages have a MAC-based protection (Note:
      if changing to signature protection of the response the caPubs
      field cannot be used securely anymore.).

1.5.  Scope of this document

   This document specifies requirements on generating messages on the
   sender side.  It does not specify strictness of verification on the
   receiving side and how in detail to handle error cases.

   Especially on the EE side this profile aims at a lightweight protocol
   that can be implemented on constrained devices.  On the side of the
   central PKI components the profile accepts higher resource needs.

   For the sake of robustness and preservation of security properties
   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



Brockhaus, et al.      Expires September 12, 2019               [Page 6]


Internet-Draft               Lightweight CMP                  March 2019


   accept from others" (often reworded as: "Be conservative in what you
   send, be liberal in what you accept").

   When in chapter 3, 4, and 5 a field of the ASN.1 syntax as defined in
   RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly
   specified, it SHOULD not be used by the sending entity.  The
   receiving entity MUST NOT require its absence and if present SHOULD
   ignore it.

1.6.  Structure of this document

   Chapter 2 introduces the general PKI architecture and approach to
   certificate management using CMP that is assumed in this document.
   Then it enlists the industrial certificate management use cases
   specified in this document and describes them in general words.  The
   list of supported certificate management use cases is divided into
   mandatory, recommended, and optional ones.

   Chapter 3 profiles the CMP message header, protection, and extraCerts
   section as they are general elements of CMP messages.

   Chapter 4 profiles the exchange of CMP messages between an EE and the
   first PKI component.  There are various flavors of certificate
   enrollment requests optionally with polling, revocation, error
   handling, and general support transactions.

   Chapter 5 profiles the exchange between further PKI components.
   These are in the first place the forwarding of messages coming from
   or going to an EE.  This includes also initiating delayed delivery of
   messages, which involves polling.  Additionally, it specifies
   transactions where the PKI component manages certificates on behalf
   of an EE or for itself.

   Chapter 6 outlines different mechanisms for CMP message transfer,
   namely http-based transfer as already specified in [RFC6712], using
   an additional TLS layer, offline file-based transport, CoAP
   [RFC7252], or piggybacking CMP messages on other protocols.

1.7.  Convention and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying significance described in RFC 2119.




Brockhaus, et al.      Expires September 12, 2019               [Page 7]


Internet-Draft               Lightweight CMP                  March 2019


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

   CA:     Certification authority, which issues certificates.

   RA:     Registration authority, an optional system component to which
           a CA delegates certificate management functions such as
           authorization checks.

   LRA:    Local registration authority, an optional RA system component
           with proximity to end entities.

   EE:     End entity, a user or device or service that holds a PKI
           certificate.  An identifier for the EE is given as the
           subject of the certificate.

2.  Architecture and use cases

2.1.  Solution architecture

   Typically, an industrial EE will be equipped with a manufacturer
   certificate during production.  A manufacturer certificate is
   installed during production to identify the device throughout its
   lifetime.  This manufacturer certificate can be used to protect the
   initial enrollment of operational certificates after installation of
   the EE in a plant or industrial network.  An operational certificate
   is issued by the owner or operator of the device to identify the
   device during operation, e.g., within a security protocol like IPSec,
   TLS, or SSH.  In IEEE 802.1AR [IEEE802.1AR] a manufacturer
   certificate is called IDevID certificate and an operational
   certificate is called LDevID certificate.

   All certificate management transactions are initiated by the EE.  The
   EE creates a CMP request message, protects it using its manufacturer
   or operational certificate, if available, and sends it to its locally
   reachable PKI component.  This PKI component may be an LRA, RA, or
   the CA, which checks the request, responds to it itself, or forwards
   the request upstream to the next PKI component.  In case an (L)RA
   changes the CMP request message header or body or wants to prove a
   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, as asynchronous communication is not
   performed in a timely consistent manner, e.g., because of a delayed
   message delivery.




Brockhaus, et al.      Expires September 12, 2019               [Page 8]


Internet-Draft               Lightweight CMP                  March 2019


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

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

           on site at                operators          service partner
   +----industrial plant----+-----backend services-----+-trust center-+

                 Figure 1: Certificate management on site

   In operation environments a layered LRA-RA-CA architecture can be
   deployed, e.g., with LRAs bundling requests from multiple EEs at
   dedicated locations and one (or more than one) central RA aggregating
   the requests from multiple LRAs.  Every (L)RA in this scenario will
   have its own dedicated certificate and private key allowing it to
   protect CMP messages it processes (CMP signing key/certificate).  The
   figure above shows an architecture using one LRA and one RA.  It is
   also possible to have only an RA or multiple LRAs and/or RAs.
   Depending on the network infrastructure, the communication between
   different PKI components may be synchronous online-communication,
   delayed asynchronous communication, or even offline file transfer.

   Third-party CAs typically implement different variants of CMP or even
   use proprietary interfaces for certificate management.  Therefore,
   the LRA or the RA may need to adapt the exchanged CMP messages to the
   flavor of communication required by the CA.

2.2.  Basic generic CMP message content

   Section 3 specifies the generic parts of the CMP messages as used
   later in Section 4 and Section 5.

   o  Header of a CMP message; see Section 3.1.

   o  Protection of a CMP message; see Section 3.2.

   o  ExtraCerts field of a CMP message; see Section 3.3.

2.3.  Supported use cases

   Following the outlined scope from Section 1.5, this section gives a
   brief overview of the certificate management use cases specified in
   Section 4 and Section 5 and points out, if a implementation by
   compliant EE or PKI component is mandatory, recommended or optional.



Brockhaus, et al.      Expires September 12, 2019               [Page 9]


Internet-Draft               Lightweight CMP                  March 2019


2.3.1.  Mandatory use cases

   The mandatory uses case in this document shall limit the overhead of
   certificate management for constrained devices to the most crucial
   types of transactions.

   Section 4 - End Entity focused certificate management use cases

   o  Request a certificate from a new PKI with signature protection;
      see Section 4.1.1.

   o  Request to update an existing certificate with signature
      protection; see Section 4.1.2.

   o  Error reporting; see Section 4.3.

   Section 5 - LRA and RA focused certificate management use cases

   o  Forward messages without changes; see Section 5.1.1.

   o  Forward messages with replaced protection and raVerified as proof-
      of-possession; see Section 5.1.2.2.

   o  Error reporting; see Section 5.3.

2.3.2.  Recommended Use Cases

   Additional recommended use cases shall support some more complex
   scenarios, that are considered as beneficial for industrial
   environments.

   Section 4 - End Entity focused certificate management use cases

   o  Request a certificate from a PKI with MAC protection; see
      Section 4.1.3.

   o  Handle delayed enrollment due to asynchronous message delivery.

   < Motivation see Section 4.1.6, specification TBD >

   Section 5 - LRA and RA focused certificate management use cases

   o  Revoke a certificate on LRA or RA side.

   < Motivation see Section 4.2, specification TBD >






Brockhaus, et al.      Expires September 12, 2019              [Page 10]


Internet-Draft               Lightweight CMP                  March 2019


2.3.3.  Optional use cases

   The optional use cases support specific requirements seen only in a
   subset of industrial environments.

   Section 4 - End Entity focused certificate management use cases

   o  Request a certificate from a legacy PKI using a PKCS#10 [RFC2986]
      request.

   < Motivation see Section 4.1.4, specification TBD >

   o  Add central generation of a key pair to a certificate request.

   < Motivation see Section 4.1.5, specification TBD >

   o  Request to omit confirmation messages; see Section 4.1.7.

   o  Request to revoke a certificate from EE side.

   < Motivation see Section 4.2, specification TBD >

   o  Additional support messages, e.g., to update a Root CA certificate
      or to request an RFC 8366 [RFC8366] voucher.

   < Motivation see Section 4.4, specification TBD >

   Section 5 - LRA and RA focused certificate management use cases

   o  Initiate delayed enrollment due to asynchronous message delivery.

   < Motivation see Section 5.1.3, specification TBD >

   o  Grant an EE's request to omit confirmation messages; see
      Section 5.1.4.

   o  Revoke a certificate of another entity.

   < Motivation see Section 5.2, specification TBD >

2.4.  CMP message transport

   Recommended transport

   o  Transfer CMP messages using HTTP; see Section 6.1.

   Optional transport




Brockhaus, et al.      Expires September 12, 2019              [Page 11]


Internet-Draft               Lightweight CMP                  March 2019


   o  Transfer CMP messages using HTTPS with certificate-based
      authentication; see Section 6.2.

   o  Transfer CMP messages using HTTPS with shared-secret based
      protection; see Section 6.3.

   o  File-based CMP message transport.

   < Motivation see Section 6.4, specification TBD >

   o  Transfer CMP messages using CoAP.

   < Motivation see Section 6.5, specification TBD >

   o  Piggyback CMP messages on other reliable transport protocols.

   < Motivation see Section 6.6, specification TBD >

3.  Generic parts of the PKI message

   To reduce redundancy in the text and to ease implementation, the
   contents of the header, protection, and extraCerts fields of the CMP
   messages used in the transactions specified in Section 4 and
   Section 5 are standardized to the maximum extent possible.
   Therefore, the generic parts of a CMP message are described centrally
   in this section.

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

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

                      Figure 2: CMP message structure




Brockhaus, et al.      Expires September 12, 2019              [Page 12]


Internet-Draft               Lightweight CMP                  March 2019


   The general contents of the message header, protection, and
   extraCerts fields are specified in the Section 3.1 to Section 3.3.

   In case a specific CMP message needs different contents in the
   header, protection, or extraCerts fields, the differences are
   described in the respective message.

   The CMP message body contains the message-specific information.  It
   is described in the context of Section 4 and Section 5.

   The behavior in case an error occurs while handling a CMP message is
   described in Section 5.3.

3.1.  General description of the CMP message header

   This section describes the generic header field of all CMP messages
   with signature-based protection.  The only variations described here
   are in the fields recipient, transactionID, and recipNonce of the
   first message of a transaction.

   In case a message has MAC-based protection the changes are described
   in the respective section.  The variations will affect the fields
   sender, protectionAlg, and senderKID.

   For requirements about proper random number generation please refer
   to [RFC4086].  Any message-specific fields or variations are
   described in the respective sections of this chapter.
























Brockhaus, et al.      Expires September 12, 2019              [Page 13]


Internet-Draft               Lightweight CMP                  March 2019


   header
     pvno                        REQUIRED
       -- MUST be set to 2 to indicate CMP V2
     sender                      REQUIRED
       -- MUST be the subject of the signing certificate used for
       -- protection of this message
     recipient                   REQUIRED
       -- MUST be the name of the intended recipient
       -- If this is the first message of a transaction: SHOULD be the
       -- subject of the issuing CA certificate
       -- In all other messages: SHOULD be the same name as in the
       -- sender field of the previous message in this transaction
     messageTime                 RECOMMENDED
       -- MUST be the time at which the message was produced, if
       -- present
     protectionAlg               REQUIRED
       -- MUST be the algorithm identifier of the signature algorithm
       -- used for calculation of the protection bits
       -- The signature algorithm MUST be consistent with the
       -- SubjectPublicKeyInfo field of the signer's certificate
       -- The hash algorithm used SHOULD be SHA-256
       algorithm                 REQUIRED
       -- MUST be the OID of the signature algorithm, like
       -- sha256WithRSAEncryption or ecdsa-with-SHA256
       parameters                PROHIBITED
       -- MUST be absent
     senderKID                   RECOMMENDED
       -- MUST be the SubjectKeyIdentifier, if available, of the
       -- certificate used for protecting this message
     transactionID               REQUIRED
       -- If this is the first message of a transaction:
       -- MUST be 128 bits of random data for the start of a
       -- transaction to reduce 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
       -- transaction
     senderNonce                 REQUIRED
       -- MUST be fresh 128 random bits
     recipNonce                  RECOMMENDED
       -- If this is the first message of a transaction: SHOULD be
       -- absent
       -- In all other messages: MUST be present and contain the value
       -- from senderNonce of the previous message in the same
       -- transaction






Brockhaus, et al.      Expires September 12, 2019              [Page 14]


Internet-Draft               Lightweight CMP                  March 2019


3.2.  General description of the CMP message protection

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

   protection                    REQUIRED
       -- MUST contain the signature calculated using the signature
       -- algorithm specified in protectionAlg

   Only for MAC-based protection major differences apply as described in
   the respective message.

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

   NOTE: The requirements for checking certificates given in [RFC5280]
   MUST be followed for the CMP message protection.  OCSP or CRLs SHOULD
   be used for status checking of the CMP signer certificates of
   communication partners.

3.3.  General description of CMP message extraCerts

   This section describes the generic extraCerts field of all CMP
   messages with signature-based protection.

   extraCerts                    RECOMMENDED
       -- SHOULD contain the signing certificate together with its
       -- chain, if needed
       -- If present, the first certificate in this field MUST
       -- be the certificate used for signing this message
       -- Self-signed certificates SHOULD NOT be included in
       -- extraCerts and MUST NOT be trusted based on the listing in
       -- extraCerts in any case

4.  End Entity focused certificate management use cases

   This chapter focuses on the communication of the EE and the first PKI
   component it talks to.  Depending on the network and PKI solution,
   this will either be the LRA, the RA or the CA.

   Profiles of the Certificate Management Protocol (CMP) [RFC4210]
   handled in this chapter cover the following certificate management
   use cases:






Brockhaus, et al.      Expires September 12, 2019              [Page 15]


Internet-Draft               Lightweight CMP                  March 2019


   o  Requesting a certificate from a PKI with variations like initial
      requests and updating, central key generation <TBD> and different
      protection means

   o  Revocation of a certificate <TBD>

   o  General messages for further support functions <TBD>

   The use cases mainly specify the message body of the CMP messages and
   utilize the specification of the message header, protection and
   extraCerts as specified in Section 4.

   The behavior in case an error occurs is described in Section 4.3.

   This chapter is aligned to Appendix D and Appendix E of [RFC4210].
   The general rules for interpretation stated in Appendix D.1 in
   [RFC4210] need to be applied here, too.

   This document does not mandate any specific supported algorithms like
   Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do.  Using the
   message sequences described here require agreement upon the
   algorithms to support and thus the algorithm identifiers for the
   specific target environment.

4.1.  Requesting a new certificate from a PKI

   There are different approaches to request a certificate from a PKI.

   These approaches differ on the one hand in the way the EE can
   authenticate itself to the PKI it wishes to get a new certificate
   from and on the other hand in its capabilities to generate a proper
   new key pair.  The authentication means may be as follows:

   o  Using a certificate from a trusted PKI and the corresponding
      private key, e.g., a manufacturer certificate

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

   o  Using a shared secret known to the EE and the PKI

   Typically, such EE requests a certificate from a CA.  When the (L)RA/
   CA responds with a message containing a certificate, the EE MUST
   reply with a confirmation message.  The (L)RA/CA then MUST send
   confirmation back, closing the transaction.

   The message sequences in this section allow the EE to request
   certification of a locally generated public-private key pair. (< The



Brockhaus, et al.      Expires September 12, 2019              [Page 16]


Internet-Draft               Lightweight CMP                  March 2019


   functional extension for central key generation is TBD if needed. >)
   For requirements about proper random number and key generation please
   refer to [RFC4086].  The EE MUST provide a signature-based proof-of-
   possession of the private key associated with the public key
   contained in the certificate request as defined by [RFC4211] section
   4.1 case 3.  To this end it is assumed that the private key can
   technically be used as signing key.  The most commonly used
   algorithms in industrial use cases are RSA and ECDSA, which can
   technically be used for signature calculation regardless of
   potentially intended restrictions of the key usage.

   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 POPO.  The (L)RA/CA needs to verify
   whether this EE is authorized to obtain a certificate with the
   requested subject and other attributes and extensions.  Especially
   when removing the protection provided by the EE and applying a new
   protection the (L)RA MUST verify in particular the included proof-of-
   possession self-signature of the certTemplate using the public key of
   the requested certificate and MUST check that the EE, as
   authenticated by the message protection, is authorized to request a
   certificate with the subject as specified in the certTemplate (see
   Section 5.1.2).

   There are several ways to install the Root CA certificate of a new
   PKI on an EE.  The installation can be performed in an out-of-band
   manner, using a voucher [RFC8366] for enrolment, or by the caPubs
   field in the certificate response message.  In case the installation
   of the new Root CA certificate is performed using the caPubs field,
   the certificate response message MUST be properly authenticated, and
   the sender of this message MUST be authorized to install new Root CA
   certificates on the EE, e.g., by using a specific extendedKeyUsage in
   the RA certificate.

4.1.1.  A certificate from a new PKI with signature protection

   This message sequence should be used by an EE to request a
   certificate of a new PKI using an existing certificate from an
   external PKI, e.g. a manufacturer certificate, to prove its identity
   to the new PKI.  The EE already has established trust in this new PKI
   it is about to enroll to, e.g., by configuration means.  The
   initialization request message is signature-protected using the
   existing certificate.

   Preconditions:

   1  The EE MUST have a certificate enrolled by an external PKI in
      advance to this transaction to authenticate itself to the (L)RA/CA



Brockhaus, et al.      Expires September 12, 2019              [Page 17]


Internet-Draft               Lightweight CMP                  March 2019


      using signature-based protection, e.g., using a manufacturer
      certificate.

   2  The EE SHOULD know the subject name of the new CA it requests a
      certificate from; this name MAY be established using an enrollment
      voucher or other configuration means.  If the EE does not know the
      name of the CA, the (L)RA/CA MUST know where to route this request
      to.

   3  The EE MUST authenticate responses from the (L)RA/CA; trust MAY be
      established using an enrollment voucher or other configuration
      means

   4  The (L)RA/CA MUST trust the external PKI the EE uses to
      authenticate itself; trust MAY be established using some
      configuration means

   This message sequenceis like that given in [RFC4210] Appendix E.7.

   Message flow:

   Step# EE                                  (L)RA/CA
     1   format ir
     2                      ->   ir      ->
     3                                        handle, re-protect or
                                                forward ir
     4                                        format or receive ip
     5                      <-   ip      <-
     6   handle ip
     7                                        In case of status
                                                "rejection" in the
                                                ip message, no certConf
                                                and pkiConf are sent
     8   format certConf
     9                      ->   certConf ->
    10                                        handle, re-protect or
                                                forward certConf
    11                                        format or receive PKIConf
    12                      <-   pkiConf  <-
    13   handle pkiConf

   For this message sequence the EE MUST include exactly one single
   CertReqMsg in the ir.  If more certificates are required, further
   requests MUST be sent using separate CMP Messages.

   If the CA accepts the request it MUST return the new certificate in
   the certifiedKeyPair field of the ip message.  If the EE successfully
   receives the certificate and accepts it, the EE MUST send a certConf



Brockhaus, et al.      Expires September 12, 2019              [Page 18]


Internet-Draft               Lightweight CMP                  March 2019


   message, which MUST be answered by the (L)RA/CA with a pkiConf
   message.  If the (L)RA/CA does not receive the expected certConf
   message in time it MUST handle this like a rejection by the EE.

   If the certificate request was refused by the CA, the (L)RA/CA must
   return an ip message containing the status code "rejection" and no
   certifiedKeyPair field.  Such an ip message MUST NOT be followed by
   the certConf and pkiConf messages.

   Detailed message description:

   Certification Request -- ir

   Field                         Value

   header
       -- As described in section 3.1

   body
       -- The request of the EE for a new certificate
     ir                          REQUIRED
       -- MUST be exactly one CertReqMsg
       -- If more certificates are required, further requests MUST be
       -- packaged in separate PKI Messages
       certReq                   REQUIRED
         certReqId               REQUIRED
       -- MUST be set to 0
         certTemplate            REQUIRED
           version               OPTIONAL
       -- MUST be 2 if supplied.
           subject               REQUIRED
       -- MUST contain the suggested subject name of the EE
       -- certificate
           publicKey             REQUIRED
       -- MUST include the subject public key algorithm ID and value
           extensions            OPTIONAL
       -- MAY include end-entity-specific X.509 extensions of the
       -- requested certificate like subject alternative name,
       -- key usage, and extended key usage
       Popo                      REQUIRED
         POPOSigningKey          REQUIRED
           poposkInput           PROHIBITED
       -- MUST NOT be used because subject and publicKey are both
       -- present in the certTemplate
           algorithmIdentifier   REQUIRED
       -- The signature algorithm MUST be consistent with the
       -- publicKey field of the certTemplate
       -- The hash algorithm used SHOULD be SHA-256



Brockhaus, et al.      Expires September 12, 2019              [Page 19]


Internet-Draft               Lightweight CMP                  March 2019


           signature             REQUIRED
       -- MUST be the signature computed over the DER-encoded
       -- certTemplate

   protection                    REQUIRED
       -- As described in section 3.2

   extraCerts                    REQUIRED
       -- As described in section 3.3


   Certification Response -- ip

   Field                         Value

   header
       -- 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 used it MUST contain only the root certificate of the
       -- certificate contained in certOrEncCert
       response                  REQUIRED
       -- MUST be exactly one CertResponse
         certReqId               REQUIRED
       -- MUST be set to 0
         status                  REQUIRED
       -- PKIStatusInfo structure MUST be present
           status                REQUIRED
       -- positive values allowed: "accepted", "grantedWithMods"
       -- negative values allowed: "rejection"
       -- In case of rejection no certConf and pkiConf messages will
       -- be sent
           statusString          OPTIONAL
       -- MAY be any human-readable text for debugging, logging or to
       -- display in a GUI
           failInfo              OPTIONAL
       -- MUST be present if status is "rejection" and in this case
       -- the transaction MUST be terminated
       -- MUST be absent if the 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



Brockhaus, et al.      Expires September 12, 2019              [Page 20]


Internet-Draft               Lightweight CMP                  March 2019


       -- MUST be present when certifiedKeyPair is present
             certificate         REQUIRED
       -- MUST be present when certifiedKeyPair is present
       -- MUST contain the newly enrolled X.509 certificate

   protection                    REQUIRED
       -- As described in section 3.2

   extraCerts                    REQUIRED
       -- As described in section 3.3
       -- MUST contain the chain of the issued certificate
       -- Duplicate certificates MAY be omitted


   Certificate Confirmation -- certConf

   Field                         Value

   header
       -- As described in section 3.1

   body
       -- The message of the EE sends confirmation to the (L)RA/CA
       -- to accept or reject the issued certificates
     certConf                    REQUIRED
       -- MUST be exactly one CertStatus
       CertStatus                REQUIRED
         certHash                REQUIRED
       -- MUST be the hash of the certificate, using the same hash
       -- algorithm as used to create the certificate signature
         certReqId               REQUIRED
       -- MUST be set to 0
         status                  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 or logging
           failInfo              OPTIONAL
       -- MUST be present if status is "rejection"
       -- MUST be absent if the status is "accepted"

   protection                    REQUIRED
       -- As described in section 3.2
       -- MUST use the same certificate as for protection of the ir




Brockhaus, et al.      Expires September 12, 2019              [Page 21]


Internet-Draft               Lightweight CMP                  March 2019


   extraCerts                    RECOMMENDED
       -- SHOULD contain the protection certificate together with its
       -- chain
       -- If present, the first certificate in this field MUST be the
       -- certificate used for signing this message
       -- Self-signed certificates SHOULD NOT be included in
       -- extraCerts and
       -- MUST NOT be trusted based on the listing in extraCerts in
       -- any case


   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
       -- SHOULD use the same certificate as for protection of the ip

   extraCerts                    RECOMMENDED
       -- SHOULD contain the protection certificate together with its
       -- chain
       -- If present, the first certificate in this field MUST be the
       -- certificate used for signing this message
       -- Self-signed certificates SHOULD NOT be included in extraCerts
       -- and
       -- MUST NOT be trusted based on the listing in extraCerts in
       -- any case

4.1.2.  Update an existing certificate with signature protection

   This message sequence should be used by an EE to request an update of
   one of the certificates it already has and that is still valid.  The
   EE uses the certificate it wishes to update to prove its identity and
   possession of the private key for the certificate to be updated to
   the PKI.  Therefore, the key update request message is signed using
   the certificate that is to be updated.

   The general message flow for this message sequence is the same as
   given in Section 4.1.1.




Brockhaus, et al.      Expires September 12, 2019              [Page 22]


Internet-Draft               Lightweight CMP                  March 2019


   Preconditions:

   1  The certificate the EE wishes to update MUST NOT be expired or
      revoked.

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

   The message sequence for this exchange is like that given in
   [RFC4210] Appendix D.6.

   The message sequence for this exchange 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 of the CertTemplate MUST contain the subject
      name of the existing certificate to be updated, without
      modifications.

   4  The CertTemplate MUST contain the subject, issuer and publicKey
      fields only.

   5  The regCtrl OldCertId SHOULD be used to make clear, even in case
      an (L)RA changes the message protection, which certificate is to
      be.

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

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

       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








Brockhaus, et al.      Expires September 12, 2019              [Page 23]


Internet-Draft               Lightweight CMP                  March 2019


4.1.3.  A certificate from a PKI with MAC protection

   This message sequence should be used by an EE to request a
   certificate of a new PKI without having a certificate to prove its
   identity to the target PKI, but there is a shared secret established
   between the EE and the PKI.  Therefore, the initialization request is
   MAC-protected using this shared secret.  The (L)RA checking the MAC-
   protection SHOULD replace this protection according to Section 5.1.2
   in case the next hop does not know the shared secret too.

   For requirements with regard to proper random number and key
   generation please refer to [RFC4086].

   The general message flow for this message sequence is the same as
   given in Section 4.1.1.

   Preconditions:

   1  The EE and the (L)RA/CA MUST share a symmetric key, this MAY be
      established by a service technician during initial local
      configuration.

   2  The EE SHOULD know the subject name of the new CA it requests a
      certificate from; this name MAY be established using an enrollment
      voucher or other configuration means.  If the EE does not know the
      name of the CA, the (L)RA/CA MUST know where to route this request
      to.

   3  The EE MUST authenticate responses from the (L)RA/CA; trust MAY be
      established using the shared symmetric key.

   The message sequence for this exchange is like that given in
   [RFC4210] Appendix D.4.

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

   1  The protection of all messages MUST be calculated using Message
      Authentication Code (MAC); the protectionAlg field MUST be id-
      PasswordBasedMac as described in section 5.1.3.1 of [RFC4210].

   2  The sender MUST contain a name representing the originator of the
      message.  The senderKID MUST contain a reference all participating
      entities can use to identify the symmetric key used for the
      protection.

   3  The extraCerts of the ir, certConf, and PKIConf messages MUST be
      absent.



Brockhaus, et al.      Expires September 12, 2019              [Page 24]


Internet-Draft               Lightweight CMP                  March 2019


   4  The extraCerts of the ip message MUST contain the chain of the
      issued certificate and root certificates SHOULD not be included
      and MUST NOT be trusted in any case.

   Part of the protectionAlg structure, where the algorithm identifier
   MUST be id-PasswordBasedMac, is a PBMParameter sequence.  The fields
   of PBMParameter SHOULD remain constant throughout this certificate
   management transaction to reduce the computational overhead.

       PBMParameter              REQUIRED
         salt                    REQUIRED
       -- MUST be the random value to salt the secret key
         owf                     REQUIRED
       -- MUST be the algorithm identifier for the one-way function
       -- used
       -- The one-way function SHA-1 MUST be supported due to
       -- [RFC4211] requirements, but SHOULD NOT be used any more
       -- SHA-256 SHOULD be used instead
         iterationCount          REQUIRED,
       -- MUST be a limited number of times the OWF is applied
       -- To prevent brute force and dictionary attacks a reasonable
       -- high number SHOULD be used
         mac                     REQUIRED
       -- MUST be the algorithm identifier of the MAC algorithm used
       -- The MAC function HMAC-SHA1 MUST be supported due to
       -- [RFC4211] requirements, but SHOULD NOT be used any more
       -- HMAC-SHA-256 SHOULD be used instead

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

   This message sequence should be used by an EE to request a
   certificate of a legacy PKI only capable to process PKCS#10 [RFC2986]
   certification requests.  The EE can prove its identity to the target
   PKI by using various protection means as described in Section 4.1.1
   or Section 4.1.3.

   In contrast to the other transactions described in Section 4.1, this
   transaction uses PKCS#10 [RFC2986] instead of CRMF [RFC4211] for the
   certificate request for compatibility reasons with legacy CA systems
   that require a PKCS#10 certificate request and cannot process CMP
   [RFC4210] or CRMF [RFC4211] messages.  In such case the (L)RA can
   extract the PKCS#10 certificate request from the p10cr and provide it
   separately to the CA.

   < Details need to be defined later >






Brockhaus, et al.      Expires September 12, 2019              [Page 25]


Internet-Draft               Lightweight CMP                  March 2019


4.1.5.  Generate the key pair centrally at the (L)RA/CA

   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 certification request, this is to make sure that only the
   entity identified in the newly issued certificate has the private
   key.

   There are some rare cases where an EE is not able or not willing to
   locally generate the new key pair.  Reasons for this may be the
   following:

   o  Lack of sufficient initial entropy.

   Note: Good random numbers are not only needed for key generation, but
   also for session keys and nonces in any security protocol.
   Therefore, we believe that a decent security architecture should
   anyway support good random number generation on the EE side or
   provide enough entropy for the RNG seed during manufacturing to
   guarantee good initial pseudo-random number generation.

   o  Due to lack of computational resources, e.g., in case of RSA keys.

   Note: As key generation can be performed in advance to the
   certificate enrollment communication, it is typical not time
   critical.

   Note: Besides the initial enrollment right after the very first
   bootup of the device, where entropy available on the device may be
   insufficient, we do not see any good reason for central key
   generation.

   < Details need to be defined later >

4.1.6.  Delayed enrollment

   This functional extension can be applied in combination with
   certificate enrollment as described in Section 4.1.1 to
   Section 4.1.4.  The functional extension can be used in case a (L)RA/
   CA cannot respond to the certificate request in a timely manner, e.g.
   due to offline upstream communication or registration officer
   interaction.  Depending on the PKI architecture, it is not
   necessarily the PKI component directly communicating with the EE that
   initiates the delayed enrollment.  In this case this PKI component
   MUST include the status waiting in the response and this response
   MUST not contain a newly issued certificate.  When receiving a
   response with status waiting the EE MUST send a poll request to the
   (L)RA/CA.  The (L)RA/CA MUST answers with a poll response containing



Brockhaus, et al.      Expires September 12, 2019              [Page 26]


Internet-Draft               Lightweight CMP                  March 2019


   a checkAfter time.  This value indicates the minimum number of
   seconds that must elapse before the EE sends another poll request.
   As soon as the (L)RA/CA can provide the final response message for
   the initial request of the EE, it MUST provide this in response to a
   poll request.  After receiving this response, the EE can continue the
   original message sequence as described in the respective section of
   this document, e.g. send a certConf message.

   < Details need to be defined later >

4.1.7.  Omitted confirmation

   This functional extension can be applied in combination with
   certificate enrollment as described in sections Section 4.1.1 to
   Section 4.1.4.  The functional extension can be used in case an EE
   does not want to send certificate confirmation messages to reduce the
   number of protocol messages exchanged in a transaction, it can
   indicate this by including the implicitConfirm extension in the
   header of a certificate request message.  Only if the (L)RA/CA
   confirms this request using the same mechanism, the EE SHOULD omit
   sending the certificate confirmation message.  Depending on the PKI
   architecture, it is not necessarily that the PKI component directly
   communicating with the EE replies to the request to omit sending
   confirmation messages, see also Section 5.1.4.

   The EE MUST use the implicitConfirm extension as part of the
   generalInfo field in the header of the ir/cr/p10cr/kur to indicate
   its wish to not send a CertConf message.  If the (L)RA/CA confirms
   this request, it MUST include the implicitConfirm extension as part
   of the generalInfo field in the header of the ip/cp/kup message as
   well.  If the EE does not find the implicitConfirm extension in the
   response message, it MUST send the certificate confirmation.

   The generalInfo field containing the implicitConfirm extension looks
   like this:

     generalInfo                 REQUIRED
       implicitConfirm           REQUIRED
       -- The value MUST be NULL

4.2.  Revoking a certificate

   This message sequence should be used by an EE to revoke one of its
   certificates.  The revocation request message MUST be signed using
   the certificate that is to be revoked to prove the authorization to
   revoke to the PKI.  The certificate request message is signature-
   protected using this certificate.




Brockhaus, et al.      Expires September 12, 2019              [Page 27]


Internet-Draft               Lightweight CMP                  March 2019


   < Details need to be defined later >

4.3.  Error reporting

   This functionality should be used by an EE to report any error
   conditions upstream to the (L)RA/CA.  Error reporting by the (L)RA
   downstream to the EE is described in Section 5.3.

   In case the error condition is related to specific details of an ip,
   cp, or kup response message and a confirmation is expected the error
   condition MUST be reported in the respective certConf message with
   negative contents.

   General error conditions, e.g., problems with the message header,
   protection, or extraCerts, and negative feedback on rp, pollRep, or
   pkiConf messages MAY be reported in the form of an error message.

   In both situations the error is reported in the PKIStatusInfo
   structure of the respective message.

   The (L)RA/CA MUST respond to an error message with a pkiConf message,
   or with another error message if any part of the header is not valid.
   Both sides MUST treat this message as the end of the current
   transaction.

   The PKIStatusInfo structure is used to report errors.  The
   PKIStatusInfo structure SHOULD consist of the following fields:

   o  status: Here the PKIStatus value rejection is the only one
      allowed.

   o  statusString: Here any human-readable valid value for logging or
      to display in a GUI SHOULD be added.

   o  failInfo: Here the PKIFailureInfo values MAY be used in the
      following way.  For explanation of the reason behind a specific
      value, please refer to [RFC4210] Appendix F.

      *  transactionIdInUse: This is sent in case the received request
         contains a transaction ID that is already in use for another
         transaction.  An EE receiving such error message SHOULD resend
         the request in a new transaction using a different transaction
         ID.

      *  systemUnavail or systemFailure: This is sent in case a back-end
         system is not available or currently not functioning correctly.
         An EE receiving such error message SHOULD resend the request in
         a new transaction after some time.



Brockhaus, et al.      Expires September 12, 2019              [Page 28]


Internet-Draft               Lightweight CMP                  March 2019


   Detailed error message description:

   Error Message -- error

   Field                         Value

   header
       -- As described in section 3.1

   body
       -- The message sent by the EE or the (L)RA/CA to indicate an
       -- 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

   protection                    REQUIRED
       -- As described in section 3.2

   extraCerts                    OPTIONAL
       -- As described in section 3.3

4.4.  Support messages

   The following support messages offer on demand in-band transport of
   content that may be relevant to the EE.  The general request messages
   and general response messages are used for this purpose.

   The general message and general response transport InfoTypeAndValue
   structures.  In addition to those infoType values defined in CMP
   [RFC4210] further OIDs MAY be defined to define new certificate
   management transactions, or general-purpose messages as needed in a
   specific environment.

   Possible content described here address:

   o  Update of Root CA certificates

   o  Parameters needed for a planned certificate request message <TBD>

   o  Request an enrollment voucher




Brockhaus, et al.      Expires September 12, 2019              [Page 29]


Internet-Draft               Lightweight CMP                  March 2019


   < Details need to be defined later >

4.4.1.  Root CA certificate update

   This message sequence can be used by an EE to request an update of a
   Root CA Certificate by the EE.  It utilizes the root CA key update
   announcement message as described in [RFC4210] Appendix E.4 as
   response to a respective general request message.

   An EE requests a root CA certificate update from the (L)RA/CA by
   sending a general message with OID id-it-caKeyUpdateInfo.  The (L)RA/
   CA responds with a general response with the same OID that either
   contains the update of the root CA certificate consisting of three
   certificates, or with no content in case no update is available.
   These three certificates are described in more detail in section
   4.4.1, section 6.2, and Appendix E.3 of [RFC4210].

   < Details need to be defined later >

4.4.2.  Get enrollment voucher

   This message sequence can be used by an EE to request an enrollment
   voucher containing the root certificate of a new PKI to establish
   trust in this PKI, e.g., in case no out-of-band transport is
   available.  Such an enrollment voucher can be used in advance to an
   enrollment to this new environment.  It may contain further
   information depending on the use case.

   An EE requests an enrollment voucher from the (L)RA/CA by sending a
   general message.  The (L)RA/CA responds with a general response with
   the same OID that contains the voucher.

   < Details need to be defined later >

5.  LRA and RA focused certificate management use cases

   This chapter focuses on the communication of PKI backend components
   with each other.  Depending on the network and PKI solution design,
   these will either be an LRA, RA or CA.

   Typically, an (L)RA forwards messages from downstream, but it may
   also reply to them itself.  Besides forwarding of received messages
   an (L)RA could also need to revoke certificates of EEs, report
   errors, or may need to manage its own certificates.

   < Like in the CMC Updates [RFC6402] additional Extended Key Usages
   like id-kp-cmpRA may be defined to indicate that a key pair is




Brockhaus, et al.      Expires September 12, 2019              [Page 30]


Internet-Draft               Lightweight CMP                  March 2019


   entitled to be used for signature-based protection of a CMP message
   by an (L)RA/CA. >

5.1.  Forwarding of messages

   Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or
   certConf) or error message coming from an EE or the previous
   (downstream) PKI component MUST be sent to the next (upstream) PKI
   component.  This PKI component MUST forward response messages to the
   next (downstream) PKI component or EE.

   The (L)RA SHOULD verify the protection, the syntax, the required
   message fields, the message type, and if applicable the authorization
   and the proof-of-possession of the message.  Additional checks or
   actions MAY be applied depending on the PKI solution requirements and
   concept.  If one of these verification procedures fails, the (L)RA
   SHOULD respond with a negative response message and SHOULD not
   forward the message further upstream.  General error conditions
   should be handled as described in Section 4.3 and Section 5.3.

   An (L)RA SHOULD not change the received message if not necessary.
   The (L)RA SHOULD only update the message protection if it is
   technically necessary.  Concrete PKI system specifications may define
   in more detail if and when to do so.

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

   Each hop in a chain of PKI components has one or more
   functionalities, e.g.:

   o  An (L)RA may need to verify the identities of EEs or base
      authorization decisions for certification request processing on
      specific knowledge of the local setup, e.g., by consulting an
      inventory or asset management system.

   o  An (L)RA may need to add fields to certificate request messages.

   o  An (L)RA may need to store data from a message in a database for
      later usage or documentation purposes.

   o  An (L)RA may provide traversal of a network boundary.

   o  An (L)RA may need to double-check if the messages transferred back
      and forth are properly protected and well formed.

   o  An RA can collect messages from different LRAs and forward them to
      the CA.



Brockhaus, et al.      Expires September 12, 2019              [Page 31]


Internet-Draft               Lightweight CMP                  March 2019


   o  An (L)RA may provide a proof that it has performed all required
      checks.

   o  An (L)RA may initiate a delayed enrollment due to offline upstream
      communication or registration officer interaction.

   o  An (L)RA may grant the request of an EE to omit sending a
      confirmation message.

   Therefore, the decision if a message should be forwarded

   o  unchanged with the original protection,

   o  unchanged with a new protection, or

   o  changed with a new protection

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

   This section specifies the different options an (L)RA may implement
   and use.

   An (L)RA MAY update the protection of a message

   o  if the (L)RA performs changes to the header or the body of the
      message,

   o  if the (L)RA needs to prove checks or validations performed on the
      message to one of the next (upstream) PKI components,

   o  if the (L)RA needs to protect the message using a key and
      certificate from a different PKI, or

   o  if the (L)RA needs to replace a MAC based-protection.

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

   The message protection covers only the header and the body and not
   the extraCerts.  The (L)RA MAY change the extraCerts in any of the
   following message adaptations, e.g., to sort or add needed or to
   delete needless certificates to support the next hop.  This may be
   particularly helpful to extend upstream messages with additional
   certificates or to reduce the number of certificates in downstream
   messages when forwarding to constrained devices.





Brockhaus, et al.      Expires September 12, 2019              [Page 32]


Internet-Draft               Lightweight CMP                  March 2019


5.1.1.  Not changing protection

   This message adaptation can be used by any (L)RA to forward an
   original CMP message without changing the header, body or protection.
   In any of these cases the (L)RA acts more like a proxy, e.g., on a
   network boundary, implementing no specific RA-like security
   functionality to the PKI.

   This message adaptation MUST be used for forwarding kur messages that
   must not be approved by the respective (L)RA.

5.1.2.  Replacing protection

   The following two message adaptations can be used by any (L)RA to
   forward a CMP message with or without changes, but providing its own
   protection using its CMP signer key providing approval of this
   message.  In this case the (L)RA 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
   (L)RA MUST verify the protection provided by the EE or by the
   previous PKI component and approve its content including any own
   modifications.  For certificate requests the (L)RA MUST verify in
   particular the included proof-of-possession self-signature of the
   certTemplate using the public key of the requested certificate and
   MUST check that the EE, as authenticated by the message protection,
   is authorized to request a certificate with the subject as specified
   in the certTemplate.

   In case the received message has been protected by a CA or another
   (L)RA, the current (L)RA MUST verify its protection and approve its
   content including any own modifications.  For certificate requests
   the (L)RA MUST check that the other (L)RA, as authenticated by the
   message protection, is authorized to issue or forward the request.

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

5.1.2.1.  Keeping proof-of-possession

   This message adaptation can be used by any (L)RA to forward a CMP
   message with or without modifying the message header or body while
   preserving any included proof-of-possession.




Brockhaus, et al.      Expires September 12, 2019              [Page 33]


Internet-Draft               Lightweight CMP                  March 2019


   By replacing the existing using its own CMP signer key the (L)RA
   provides a proof of verifying and approving of the message as
   described above.

   In case the (L)RA modifies the certTemplate of an ir or cr message,
   the message adaptation in Section 5.1.2.2 needs to be applied
   instead.

5.1.2.2.  Breaking proof-of-possession

   This message adaptation can be used by any (L)RA to forward an ir or
   cr message with modifications of the certTemplate i.e., modification,
   addition, or removal of fields.  Such changes will break the proof-
   of-possession provided by the EE in the original message.

   By replacing the existing or applying an initial protection using its
   own CMP signer key the (L)RA provides a proof of verifying and
   approving the new message as described above.

   In addition to the above the (L)RA MUST verify in particular the
   proof-of-possession contained in the original message as described
   above.  If these checks were successfully performed the (L)RA MUST
   change the popo to raVerified.

   The 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 (L)RA
       -- verified the popo of the original message.

5.1.3.  Initiating delayed enrollment

   This message adaptation can be used by an (L)RA to initiate delayed
   enrollment.  In this case a (L)RA/CA MUST add the status waiting in
   the response message.  The (L)RA/CA MUST then reply to the pollReq
   messages as described in Section 4.1.6.

5.1.4.  Granting omitted confirmation

   This message adaptation can be applied for omitted confirmation in
   case a (L)RA/CA grants the request to omit sending confirmation
   messages.  This (L)RA/CA includes the implicitConfirm extension in
   the header of an ip, cp, or kup response message as described in
   Section 4.1.7.





Brockhaus, et al.      Expires September 12, 2019              [Page 34]


Internet-Draft               Lightweight CMP                  March 2019


5.2.  Revoking certificates of other entities

   This message sequence can be used by an (L)RA to revoke a certificate
   of any other entity.  The revocation request message MUST be signed
   by the (L)RA using its own CMP signer key to prove to the PKI
   authorization to revoke the certificate on behalf of the EE.

   < Details need to be defined later >

5.3.  Error reporting

   This functionality should be used by the (L)RA to report any error
   conditions downstream to the EE.  Potential error reporting by the EE
   upstream to the (L)RA/CA is described in Section 4.3.

   In case the error condition is related to specific details of an ir,
   cr, p10cr, or kur request message it MUST be reported in the specific
   response message, i.e., an ip, cp, or kup with negative contents.

   General error conditions, e.g., problems with the message header,
   protection, or extraCerts, and negative feedback on rr, pollReq,
   certConf, or error messages MUST be reported in the form of an error
   message.

   In both situations the (L)RA reports the errors in the PKIStatusInfo
   structure of the respective message as described in Section 4.3.

   An EE receiving any such negative feedback SHOULD log the error
   appropriately and MUST terminate the current transaction.

6.  CMP message transport variants

   The CMP messages are designed to be self-contained, such that in
   principle any transport can be used.  HTTP SHOULD be used for online
   transport while file-based transport MAY be used in case offline
   transport is required.  In case HTTP transport is not desired or
   possible, CMP messages MAY also be piggybacked on any other reliable
   transport protocol, e.g., CoAP [RFC7252].

   Independently of the means of transport it could happen that messages
   are lost, or a communication partner does not respond.  In order 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
   message is to be expected from the client side.  In this way a
   hanging transaction can be closed cleanly with an error and related
   resources (for instance, any cached extraCerts) can be freed.




Brockhaus, et al.      Expires September 12, 2019              [Page 35]


Internet-Draft               Lightweight CMP                  March 2019


6.1.  HTTP transport

   This transport mechanism can be used by an EE and (L)RA/CA to
   transfer CMP messages over HTTP.  If HTTP transport is used the
   specifications as described in [RFC6712] MUST be followed.

6.2.  HTTPS transport using certificates

   This transport mechanism can be used by an EE and (L)RA/CA to further
   protect the HTTP transport as described in Section 6.1 using TLS 1.2
   [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with
   certificate-based authentication.  Using this transport mechanism,
   the CMP transport via HTTPS MUST use TLS server authentication and
   SHOULD use TLS client authentication.

   EE:

   o  The EE SHOULD use a TLS client certificate as far as available.
      If no dedicated TLS certificate is available the EE SHOULD use an
      already existing certificate identifying the EE (e.g., a
      manufacturer certificate).

   o  If no TLS certificate is available at the EE, server-only
      authenticated TLS SHOULD be used.

   o  The EE MUST validate the TLS server certificate of its
      communication partner.

   (L)RA:

   o  Each (L)RA SHOULD use a TLS client certificate on its upstream
      (client) interface.

   o  Each (L)RA SHOULD use a TLS server certificate on its downstream
      (server) interface.

   o  Each (L)RA MUST validate the TLS certificate of its communication
      partner.

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








Brockhaus, et al.      Expires September 12, 2019              [Page 36]


Internet-Draft               Lightweight CMP                  March 2019


6.3.  HTTPS transport using shared secrets

   This transport mechanism can be used by an EE and (L)RA/CA to further
   protect the HTTP transport as described in Section 6.1 using TLS 1.2
   [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual
   authentication based on shared secrets as described in [RFC5054].

   EE:

   o  The EE MUST use the shared symmetric key for authentication.

   (L)RA:

   o  The (L)RA MUST use the shared symmetric key for authentication.

6.4.  File-based transport

   For offline transfer file-based transport MAY be used.  Offline
   transport is typically used between LRA and RA nodes.

   Connection and error handling mechanisms like those specified for
   HTTP in [RFC6712] need to be implemented.

   < Details need to be defined later >

6.5.  CoAP transport

   In constrained environments where no HTTP transport is desired or
   possible, CoAP [RFC7252] MAY be used instead.

   Connection and error handling mechanisms like those specified for
   HTTP in [RFC6712] need to be implemented.

   < Details need to be defined later >

6.6.  Piggybacking on other reliable transport

   For online transfer where no HTTP transport is desired or possible
   CMP messages MAY also be transported on some other reliable protocol.

   Connection and error handling mechanisms like those specified for
   HTTP in [RFC6712] need to be implemented.

   < Details need to be defined later >







Brockhaus, et al.      Expires September 12, 2019              [Page 37]


Internet-Draft               Lightweight CMP                  March 2019


7.  IANA Considerations

   <Add any IANA considerations>

8.  Security Considerations

   <Add any security considerations>

9.  Acknowledgements

   We would like to thank the various reviewers of this CMP profile.

10.  References

10.1.  Normative References

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

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

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

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

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






Brockhaus, et al.      Expires September 12, 2019              [Page 38]


Internet-Draft               Lightweight CMP                  March 2019


   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
              "Using the Secure Remote Password (SRP) Protocol for TLS
              Authentication", RFC 5054, DOI 10.17487/RFC5054, November
              2007, <https://www.rfc-editor.org/info/rfc5054>.

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

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

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

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

10.2.  Informative References

   [ETSI-3GPP]
              3GPP, "3GPP TS33.310; Network Domain Security (NDS);
              Authentication Framework (AF); Release 16; V16.1.0",
              December 2018,
              <http://www.3gpp.org/ftp/Specs/archive/33_series/33.310/>.

   [IEC62443-3-3]
              International Electrotechnical Commission, "IEC 62443 Part
              3-3 - System security requirements and security levels",
              IEC 62443-3-3, August 2013, <Informative References>.

   [IEEE802.1AR]
              IEEE, "IEEE 802.1AR Secure Device Identifier", 06 2018,
              <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.








Brockhaus, et al.      Expires September 12, 2019              [Page 39]


Internet-Draft               Lightweight CMP                  March 2019


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

   [RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)
              Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
              <https://www.rfc-editor.org/info/rfc6402>.

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

   [UNISIG]   UNISIG, "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.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   Hendrik Brockhaus
   Siemens AG
   Otto-Hahn-Rin 6
   Munich  81739
   Germany

   Email: hendrik.brockhaus@siemens.com
   URI:   http://www.siemens.com/


   Steffen Fries
   Siemens AG
   Otto-Hahn-Ring 6
   Munich  81739
   Germany

   Email: steffen.fries@siemens.com
   URI:   http://www.siemens.com/



Brockhaus, et al.      Expires September 12, 2019              [Page 40]


Internet-Draft               Lightweight CMP                  March 2019


   David von Oheimb
   Siemens AG
   Otto-Hahn-Ring 6
   Munich  81739
   Germany

   Email: david.von.oheimb@siemens.com
   URI:   http://www.siemens.com/











































Brockhaus, et al.      Expires September 12, 2019              [Page 41]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/