Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-05
LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft S. Fries
Intended status: Standards Track D. von Oheimb
Expires: 26 August 2021 Siemens
22 February 2021
Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-05
Abstract
The goal of this document is to facilitate interoperability and
automation by profiling the Certificate Management Protocol (CMP)
version 2, the related Certificate Request Message Format (CRMF)
version 2, and the HTTP Transfer for the Certificate Management
Protocol. It specifies a subset of CMP and CRMF focusing on typical
use cases relevant for managing certificates of devices in many
industrial and IoT scenarios. To limit the overhead of certificate
management for more constrained devices only the most crucial types
of operations are specified as mandatory. To foster interoperability
in more complex scenarios, other types of operations 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 26 August 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Brockhaus, et al. Expires 26 August 2021 [Page 1]
Internet-Draft Lightweight CMP Profile February 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4
1.2. Motivation for a lightweight profile for CMP . . . . . . 5
1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6
1.4. Compatibility with existing CMP profiles . . . . . . . . 8
1.5. Scope of this document . . . . . . . . . . . . . . . . . 9
1.6. Structure of this document . . . . . . . . . . . . . . . 10
1.7. Convention and Terminology . . . . . . . . . . . . . . . 11
2. Architecture and use cases . . . . . . . . . . . . . . . . . 11
2.1. Solution architecture . . . . . . . . . . . . . . . . . . 12
2.2. Basic generic CMP message content . . . . . . . . . . . . 13
2.3. Supported PKI management operations . . . . . . . . . . . 13
2.3.1. Mandatory PKI management operations . . . . . . . . . 14
2.3.2. Recommended PKI management operations . . . . . . . . 14
2.3.3. Optional PKI management operations . . . . . . . . . 15
2.4. CMP message transport . . . . . . . . . . . . . . . . . . 16
3. Generic parts 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 . . . . . . 21
4. End Entity PKI management operations . . . . . . . . . . . . 21
4.1. Requesting a new certificate from a PKI . . . . . . . . . 22
4.1.1. Requesting a certificate from a new PKI with signature
protection . . . . . . . . . . . . . . . . . . . . . 24
4.1.2. Requesting a certificate from a trusted PKI with
signature protection . . . . . . . . . . . . . . . . 30
4.1.3. Updating an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 31
4.1.4. Requesting a certificate from a PKI with MAC
protection . . . . . . . . . . . . . . . . . . . . . 32
4.1.5. Requesting a certificate from a legacy PKI using
PKCS#10 request . . . . . . . . . . . . . . . . . . . 33
4.1.6. Generateing the key pair centrally at the PKI
management entity . . . . . . . . . . . . . . . . . . 36
4.1.6.1. Using key agreement key management technique . . 41
4.1.6.2. Using key transport key management technique . . 43
4.1.6.3. Using password-based key management technique . . 43
Brockhaus, et al. Expires 26 August 2021 [Page 2]
Internet-Draft Lightweight CMP Profile February 2021
4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 44
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48
4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50
4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52
4.4.1. Get CA certificates . . . . . . . . . . . . . . . . . 54
4.4.2. Get root CA certificate update . . . . . . . . . . . 55
4.4.3. Get certificate request template . . . . . . . . . . 56
5. LRA and RA PKI management operations . . . . . . . . . . . . 59
5.1. Forwarding messages . . . . . . . . . . . . . . . . . . . 59
5.1.1. Not changing protection . . . . . . . . . . . . . . . 61
5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61
5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62
5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 63
5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63
5.1.3.1. Handling a single PKI management message . . . . 64
5.1.3.2. Handling a batch of PKI management messages . . . 65
5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 66
5.2. Revoking certificates on behalf of another's PKI
entities . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 67
6. CMP message transport mechanisms . . . . . . . . . . . . . . 67
6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 68
6.2. HTTPS transport using certificates . . . . . . . . . . . 69
6.3. HTTPS transport using shared secrets . . . . . . . . . . 70
6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 70
6.4.1. File-based transport . . . . . . . . . . . . . . . . 71
6.4.2. Other asynchronous transport protocols . . . . . . . 71
6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71
6.6. Piggybacking on other reliable transport . . . . . . . . 71
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
8. Security Considerations . . . . . . . . . . . . . . . . . . . 71
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
10.1. Normative References . . . . . . . . . . . . . . . . . . 72
10.2. Informative References . . . . . . . . . . . . . . . . . 73
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 75
Appendix B. History of changes . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
1. Introduction
[RFC Editor: please delete]:!!! The change history was moved to
Appendix B !!!
Brockhaus, et al. Expires 26 August 2021 [Page 3]
Internet-Draft Lightweight CMP Profile February 2021
[RFC Editor: please delete]: The labels 'RFC-CMP-Updates', 'RFC-CMP-
Alg', and 'RFC-CRMF-Alg' in ASN.1 Syntax needs to be replaced with
the RFC numbers of CMP Updates [I-D.ietf-lamps-cmp-updates], CMP
Algorithms [I-D.ietf-lamps-cmp-algorithms] and CRMF Algorithm
Requirements Update [I-D.ietf-lamps-crmf-update-algs], when
available.
This document specifies PKI management operations supporting machine-
to-machine and IoT use cases. The focus lies on maximum automation
and interoperable implementation of all involved PKI entities 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], HTTP transfer
for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates].
Especially CMP and CRMF are very feature-rich standards, while in
most environments 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 and specifying
in more detail how to use these concepts to implement lightweight
automated certificate management.
1.1. Motivation for profiling 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.
Though CMP is a very solid and 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 of 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
Brockhaus, et al. Expires 26 August 2021 [Page 4]
Internet-Draft Lightweight CMP Profile February 2021
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
scenario need to be dealt with specifically.
Defining such a profile for a new target environment take 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 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.
1.2. Motivation for a lightweight profile for CMP
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 procedures.
Due to increasing security needs 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. The NIST
Framework for Improving Critical Infrastructure Cybersecurity
[NIST.CSWP.04162018] also refers to proper processes for issuance,
management, verification, revocation, and audit for authorized
devices, users and processes involving identity and credential
management. Such PKI operation according to commonly accepted best
practices is 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 operation
typically is 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
Brockhaus, et al. Expires 26 August 2021 [Page 5]
Internet-Draft Lightweight CMP Profile February 2021
required flexibility and functionality, namely self-contained
messages, efficient polling, and support for asynchronous message
transfer while retaining end-to-end security.
1.3. 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 do
only partly address the specific needs for certificate management
automation for unattended machines or application-oriented end
entities.
RFC 4210 [RFC4210] specifies in Appendix D the following mandatory
PKI management operations. All requirements regarding algorithm
support have been updated by CMP Algorithms Section 7.2
[I-D.ietf-lamps-cmp-algorithms], all operations may enroll up to two
certificates, one for a locally generated and optionally another one
for a centrally generated key pair, and all require use of certConf/
pkiConf messages for confirmation.
* Initial registration/certification; an (uninitialized) end entity
requests a (first) certificate from a CA using shared secret based
message authentication. The content is similar to the PKI
management operation specified in Section 4.1.4 of this document.
* Certificate request; an (initialized) end entity requests another
certificate from a CA using signature-based or shared secret-based
message authentication. The content is similar to the PKI
management operation specified in Section 4.1.2 of this document.
* Key update; an (initialized) end entity requests a certificate
from a CA (to update the key pair and/or corresponding certificate
that it already possesses) using signature-based or shared secret-
based message authentication. The content is similar to the PKI
management operation specified in Section 4.1.3 of this document.
Two certificates may be enrolled and authentication is based on
shared secrets because these PKI management operations focus on the
enrollment of certificates of humans.
RFC 4210 [RFC4210] specifies in Appendix E the following optional PKI
management operations. All requirements regarding algorithm support
have been updated by CMP Algorithms Section 7.2
[I-D.ietf-lamps-cmp-algorithms].
Brockhaus, et al. Expires 26 August 2021 [Page 6]
Internet-Draft Lightweight CMP Profile February 2021
* Root CA key update; a root CA updates its key pair and produces a
CA key update announcement message, which can be made available
(via some transport mechanism) to the relevant end entities. This
operation only supports a push model. The content is similar to
the PKI management operation supporting the pull model specified
in Section 4.4.2 of this document.
* Information request/response; an end entity sends a general
message to the PKI requesting details that will be required for
later PKI management operations. The content is similar to the
PKI management operation specified in Section 4.4.3 of this
document.
* Cross-certification request/response (1-way); creation of a single
cross-certificate (i.e., not two at once). The requesting CA MAY
choose who is responsible for publication of the cross-certificate
created by the responding CA through use of the PKIPublicationInfo
control.
* In-band initialization using an external identity certificate
(this PKI management operation may also enroll up to two
certificates and requires use of certConf/pkiConf messages for
confirmation as specified in Appendix D of RFC 4210 [RFC4210]).
An (uninitialized) end entity wishes to initialize into the PKI
with a CA, CA-1. It uses, for authentication purposes, a pre-
existing identity certificate issued by another (external) CA, CA-
X. A trust relationship must already have been established
already between CA-1 and CA-X so that CA-1 can validate the EE's
identity certificate signed by CA-X. Furthermore, some mechanism
must already have been established within the Personal Security
Environment (PSE) of the EE enabling it to authenticate and verify
PKIMessages signed by CA-1. The content is similar to the PKI
management operation specified in Section 4.1.1 of this document.
Both these Appendixes D and E focus on EE-to-CA/RA PKI management
operations and do not address further profiling of RA to CA
communication as typically needed for full backend automation.
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 certificate enrollment in the
subset 137 specifying the ETRAM/ECTS on-line key management for train
control systems [UNISIG.Subset-137] in 2015.
Brockhaus, et al. Expires 26 August 2021 [Page 7]
Internet-Draft Lightweight CMP Profile February 2021
Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and
HTTP transfer for CMP [RFC6712] to add tailored means for automated
PKI management operations for unattended devices and services.
1.4. 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 4210 Section 4.1 [RFC4210] clause 3 is the
recommended default POPO method (deviations are possible for EEs
when requesting central key generation, for (L)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 the push model) are omitted.
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). As UNISIG Subset-137 Table 6
[UNISIG.Subset-137] allows to transport more than one certificate
request message, this conflicts with this document.
Brockhaus, et al. Expires 26 August 2021 [Page 8]
Internet-Draft Lightweight CMP Profile February 2021
* As of RFC 4210 [RFC4210] the messageTime is required to be
Greenwich Mean Time coded as generalizedTime 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. Therefore, UNISIG
Subset-137 [UNISIG.Subset-137] may conflict with RFC 4210
[RFC4210]. Both time formats are described in RFC 5280
Section 4.1.2.5 [RFC5280].
* This profile requires usage of the same type of protection for all
messages of one PKI management operation. This means, in case the
request message is MAC protected, also the response, certConf, and
pkiConf messages have a MAC-based protection. As UNISIG
Subset-137 Table 5 [UNISIG.Subset-137] specifies for the first
certificate request MAC protection for all messages send by the
client and signature protection for all messages send by the
server, this conflicts with this document.
* 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 that in case the protection of the response is
changed to signature-based protection using a certificate issued
under the root CA that is to be transported in the caPubs field,
this is not a secure delivery of the root CA certificate.
* This profile requires that the certConf message has one CertStatus
element where the statusInfo field is recommended. 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.5. Scope of this document
This document specifies requirements on generating PKI management
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
implementation. This means that the number of PKI management
operations that implementations must support are reduced to a
reasonable minimum to support most typical certificate management use
Brockhaus, et al. Expires 26 August 2021 [Page 9]
Internet-Draft Lightweight CMP Profile February 2021
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 resources needed.
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
accept from others" (often reworded as: "Be conservative in what you
send, be liberal in what you accept").
When in Section 3, Section 4, and Section 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 MUST
gracefully handle its presence.
1.6. Structure of this document
Section 2 introduces the general PKI architecture and approach to
certificate management using CMP that is assumed in this document.
Then it enlists the PKI management operations specified in this
document and describes them in general words. The list of supported
PKI management operations is divided into mandatory, recommended, and
optional ones.
Section 3 profiles the CMP message header, protection, and extraCerts
fields as they are general elements of CMP messages.
Section 4 profiles the exchange of CMP messages between an EE and the
first PKI management entity. There are various flavors of
certificate enrollment requests, optionally with polling, revocation,
error handling, and general support PKI management operations.
Section 5 profiles the message exchange between PKI management
entities. In the first place this consists of forwarding messages
coming from or going to an EE. This may include delayed delivery of
messages, which involves polling for certificate responses.
Additionally, it specifies operations where a PKI management entity
manages certificates on behalf of an EE or for itself.
Section 6 outlines several mechanisms for CMP message transfer,
namely HTTP-based transfer as already specified in RFC 6712
[RFC6712], using an additional TLS layer, or offline file-based
transport. CoAP [RFC7252] and piggybacking CMP messages
Brockhaus, et al. Expires 26 August 2021 [Page 10]
Internet-Draft Lightweight CMP Profile February 2021
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 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
authorization checks.
LRA: Local registration authority, an optional RA system component
with proximity to the end entities.
KGA: Key generation authority, an optional system component,
typically co-located with an LRA, RA, or CA, that offers key
generation services to end entities.
EE: End entity, a user, device, or service that holds 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] and used
as follows:
PKI management operation: All CMP messages belonging to one
transaction context. The transaction is
identified in the transactionID field of
the message header.
PKI management entity: All non-EE PKI entities such as LRA, RA,
and CA.
PKI entity: EEs and PKI management entities
2. Architecture and use cases
Brockhaus, et al. Expires 26 August 2021 [Page 11]
Internet-Draft Lightweight CMP Profile February 2021
2.1. Solution architecture
In order to facilitate secure automatic certificate enrollment if the
device hosting an EE is equipped with a manufacturer issued
certificate during production. Such a manufacturer issued
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 on site in its operational environment. An
operational certificate is issued by the owner or operator of the
device to identify the device during operation for use, e.g., in a
security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR
[IEEE.802.1AR_2018] a manufacturer 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 triplet of the certificate and the corresponding private key as
well as certificate chain up to the root certificate.
All certificate management transactions specified in this document
are initiated by the EE. The EE creates a CMP request message,
protects it using some asymmetric credential or shared secret
information, as far as 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, 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----+
on site at operators service partner
+----------plant---------+-----backend services-----+-trust center-+
Brockhaus, et al. Expires 26 August 2021 [Page 12]
Internet-Draft Lightweight CMP Profile February 2021
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
typically has a shared secret information (one per EE) for password-
based protection or a CMP protection key and certificate containing
an extended key usage as specified in CMP Updates
[I-D.ietf-lamps-cmp-updates] allowing it to protect CMP messages it
processes. 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 message
transfer between PKI management entities may be based on synchronous
online connections, delayed asynchronous connections, or even offline
(e.g., file-based) transfer.
This profile focusses on specifying the pull model, where the EE
always requests a specific PKI management operation.
Note: CMP response messages, especially in case of central key
generation, as described in Section 4.1.6, could also be used
proactively to implement the push model towards the EE.
Third-party CAs typically implement other variants of CMP, different
standardized protocols, or even proprietary interfaces for
certificate management. Therefore, the LRA or the RA may need to
adapt the exchanged CMP messages to the flavor of certificate
management interaction 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.
* Header of a CMP message; see Section 3.1.
* Protection of a CMP message; see Section 3.2.
* ExtraCerts field of a CMP message; see Section 3.3.
2.3. Supported PKI management operations
Following the scope outlined in Section 1.5, this section gives a
brief overview of the PKI management operations specified in
Section 4 and Section 5 and states whether implementation by
compliant EE or PKI management entities is mandatory, recommended, or
optional.
Brockhaus, et al. Expires 26 August 2021 [Page 13]
Internet-Draft Lightweight CMP Profile February 2021
2.3.1. Mandatory PKI management operations
The mandatory PKI management operations in this document limit the
overhead of certificate management. This minimal set of operations
may be helpful for keeping development effort low and for use in
memory-constrained devices.
+=======================================+=========+
| PKI management operations | Section |
+=======================================+=========+
| Request a certificate from a new PKI | Section |
| with signature protection | 4.1.1 |
+---------------------------------------+---------+
| Request to update an existing | Section |
| certificate with signature protection | 4.1.3 |
+---------------------------------------+---------+
| Error reporting | Section |
| | 4.3 |
+---------------------------------------+---------+
Table 1: Mandatory End Entity PKI management
operations
+===============================================+===============+
| PKI management operations | Section |
+===============================================+===============+
| Forward messages without changes | Section 5.1.1 |
+-----------------------------------------------+---------------+
| Forward messages with replaced protection and | Section |
| keeping the original proof-of-possession | 5.1.2.1 |
+-----------------------------------------------+---------------+
| Forward messages with replaced protection and | Section |
| setting raVerified as proof-of-possession | 5.1.2.2 |
+-----------------------------------------------+---------------+
| Error reporting | Section 5.3 |
+-----------------------------------------------+---------------+
Table 2: Mandatory LRA and RA PKI management operations
2.3.2. Recommended PKI management operations
Additional recommended PKI management operations shall support some
more complex scenarios, that are considered beneficial for
environments with more specific boundary conditions.
Brockhaus, et al. Expires 26 August 2021 [Page 14]
Internet-Draft Lightweight CMP Profile February 2021
+======================================================+=========+
| PKI management operations | Section |
+======================================================+=========+
| Request a certificate from a PKI with MAC protection | Section |
| | 4.1.4 |
+------------------------------------------------------+---------+
| Revoke a certificate of its own | Section |
| | 4.2 |
+------------------------------------------------------+---------+
Table 3: Recommended End Entity PKI management operations
+========================================+=============+
| PKI management operations | Section |
+========================================+=============+
| Revoke a certificate of another entity | Section 5.2 |
+----------------------------------------+-------------+
Table 4: Recommended LRA and RA PKI management
operations
2.3.3. Optional PKI management operations
The optional PKI management operations support specific requirements
seen only in some environments with special requirements.
Brockhaus, et al. Expires 26 August 2021 [Page 15]
Internet-Draft Lightweight CMP Profile February 2021
+========================================================+=========+
| PKI management operations | Section |
+========================================================+=========+
| Request a certificate from a trusted PKI with | Section |
| signature protection | 4.1.2 |
+--------------------------------------------------------+---------+
| Request a certificate from a legacy PKI using a | Section |
| PKCS#10 [RFC2986] request | 4.1.5 |
+--------------------------------------------------------+---------+
| Add central generation of a key pair 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.) | |
+--------------------------------------------------------+---------+
| Handle delayed enrollment due to asynchronous or | Section |
| offline message delivery | 4.1.7 |
+--------------------------------------------------------+---------+
| Additional support messages - distribution of CA | Section |
| certificates, update of a root CA certificate and | 4.4 |
| provisioning of certificate request template | |
+--------------------------------------------------------+---------+
Table 5: Optional End Entity PKI management operations
+=============================================+===============+
| PKI management operations | Section |
+=============================================+===============+
| Forward messages with additional protection | Section 5.1.3 |
+---------------------------------------------+---------------+
| Initiate delayed enrollment due to | Section 5.1.4 |
| asynchronous or offline message delivery | |
+---------------------------------------------+---------------+
Table 6: Optional LRA and RA PKI management operations
2.4. CMP message transport
On different links between PKI entities, e.g., EE-RA and RA-CA,
different transport MAY be used. As CMP does not have specific needs
regarding message transport, virtually any reliable transport
mechanism may be used, e.g., HTTP, CoAP, and offline file-based
transport. Therefore, this document does not require any specific
transport protocol to be supported by conforming implementations.
Brockhaus, et al. Expires 26 August 2021 [Page 16]
Internet-Draft Lightweight CMP Profile February 2021
HTTP transfer is RECOMMENDED to use for all PKI entities, yet full
flexibility is retained to choose whatever transport is suitable, for
instance for devices with special constraints.
+==================================+=============+
| Transport | Section |
+==================================+=============+
| Transfer CMP messages using HTTP | Section 6.1 |
+----------------------------------+-------------+
Table 7: Recommended transport mechanisms
+========================================+=========+
| Transport | Section |
+========================================+=========+
| Transfer CMP messages using HTTPS with | Section |
| certificate-based authentication | 6.2 |
+----------------------------------------+---------+
| Transfer CMP messages using HTTPS with | Section |
| shared secret-based authentication | 6.3 |
+----------------------------------------+---------+
| Offline CMP message transport | Section |
| | 6.4 |
+----------------------------------------+---------+
| Transfer CMP messages using CoAP | Section |
| | 6.5 |
+----------------------------------------+---------+
Table 8: Optional transport mechanisms
3. Generic parts of the PKI message
The generic parts of the CMP message profiles specified in Section 4
and Section 5 are standardized to the maximum extent possible and are
described centrally in this section to reduce redundancy in the
description and to ease implementation.
As described in section 5.1 of [RFC4210], all CMP messages have the
following general structure:
Brockhaus, et al. Expires 26 August 2021 [Page 17]
Internet-Draft Lightweight CMP Profile February 2021
+--------------------------------------------+
| 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 subsections.
In case a specific CMP message profile needs different contents in
the header, protection, or extraCerts fields, the differences are
described in the respective message profile.
The CMP message body contains the message-specific information. It
is described as part Section 4 and Section 5.
The behavior in case an error occurs while handling the generic parts
of 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 recipient, transactionID, and recipNonce fileds of the
first message of a PKI management operation.
In case a message has MAC-based protection the changes are described
in Section 4.1.4. The variations will affect the fields sender,
protectionAlg, and senderKID.
For requirements regarding proper random number generation please
refer to [RFC4086]. Any message-specific fields or variations are
described in Section 4 and Section 5.
Brockhaus, et al. Expires 26 August 2021 [Page 18]
Internet-Draft Lightweight CMP Profile February 2021
header
pvno REQUIRED
-- MUST be set to 3 to indicate CMP V3 in all cases where
-- EnvelopedData is supported and expected to be used in this PKI
-- management operation
-- MUST be set to 2 to indicate CMP V2 in all other cases
-- For details on version negotiation see RFC-CMP-Updates
sender REQUIRED
-- MUST contain a name representing the originator of the message
-- SHOULD be the subject of the CMP protection certificate, i.e.,
-- the certificate for the private key used to sign the message
recipient REQUIRED
-- SHOULD be the name of the intended recipient and
-- MAY be a NULL-DN, i.e., a zero-length SEQUENCE OF
-- RelativeDistinguishedNames, if the sender does not know the
-- DN of the 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 the same transaction
messageTime RECOMMENDED
-- MUST be the time at which the message was produced, if
-- present
protectionAlg REQUIRED
-- MUST be the algorithm OID of the algorithm used for
-- calculating the protection bits
-- The signature algorithm 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
-- The MAC algorithm MUST be a MSG_MAC_ALG as specified in
-- RFC-CMP-Alg Section 6
algorithm REQUIRED
-- MUST be the OID of the signature or MAC algorithm
senderKID RECOMMENDED
-- MUST be the SubjectKeyIdentifier of the CMP protection
-- certificate or a reference of the shared secret information
-- used for the protection
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 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
-- transaction
senderNonce REQUIRED
-- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED
Brockhaus, et al. Expires 26 August 2021 [Page 19]
Internet-Draft Lightweight CMP Profile February 2021
-- If this is the first message of a transaction: SHOULD be
-- absent
-- 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 field 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
-- See [RFC4210] Section 5.1.1.1.
-- Added to response messages to grant omission of the certConf
-- message
ImplicitConfirmValue REQUIRED
-- ImplicitConfirmValue of the request message MUST be NULL if
-- the EE wants to request not to send a confirmation message
-- ImplicitConfirmValue MUST be NULL if the PKI management
-- entity wants to grant not sending a confirmation message
3.2. General description of the CMP message protection
This section describes the generic protection field of all CMP
messages with signature-based protection. The certificate for the
private key used to sign a CMP message 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 as specified in
Section 4.3 and Section 5.3 is not possible and therefore MAY be
omitted.
For MAC-based protection as specified in Section 4.1.4 major
differences apply as described in the respective section.
The CMP message protection provides, if available, message origin
authentication and integrity protection for the CMP message header
and body. The CMP message extraCerts field is not covered by this
protection.
Brockhaus, et al. Expires 26 August 2021 [Page 20]
Internet-Draft Lightweight CMP Profile February 2021
Note: The extended key usages specified in CMP Updates
[I-D.ietf-lamps-cmp-updates] can be used for authorization of a
sending PKI management entity.
Note: The requirements for checking certificates given in [RFC5280]
MUST be the followed for signature-based CMP message protection. In
case the CMP protection certificate is not the CA certificate that
signed the newly issued certificate, certificate status checking
SHOULD be used for the CMP protection 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. If extraCerts are
required, recommended, or optional is specified in the respective PKI
management operation.
extraCerts
-- SHOULD contain the CMP protection certificate together with
-- its chain, if needed and the self-signed root certificate
-- SHOULD be omitted
-- If present, the first certificate in this field MUST be
-- the CMP protection certificate and each 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.
4. End Entity PKI management operations
This chapter focuses on the communication of the EE with the PKI
management entity it immediately talks to. Depending on the network
and PKI solution, this can be an LRA, RA, or directly a CA.
The PKI management operations specified in this section cover the
following:
* Requesting a certificate from a PKI with variations like initial
enrollment and updates, central key generation, and various
protection mechanisms
Brockhaus, et al. Expires 26 August 2021 [Page 21]
Internet-Draft Lightweight CMP Profile February 2021
* Revocation of a certificate
* General messages for further support functions
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 4.
The behavior in case an error occurs is described in Section 4.3.
This section is aligned with RFC 4210 [RFC4210]. The general rules
for interpretation stated in Appendix D.1 of RFC 4210 [RFC4210] shall
be applied here, too.
Guidelines as well as an algorithm use profile for this document are
available in CMP Algorithms [draft-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 and in the way that the key pair to be certified is generated.
The authentication mechanisms may be as follows:
* Using a certificate from a trusted PKI and the corresponding
private key, e.g., a manufacturer issued certificate
* Using the certificate to be updated and the corresponding private
key
* Using shared secret information known to the EE and the PKI
An EE requests a certificate indirectly or directly from a CA. When
the PKI management entity responds with a message containing the
requested certificate, the EE MUST reply with a confirmation message.
The PKI management entity then MUST respond with a confirmation,
closing the transaction.
Brockhaus, et al. Expires 26 August 2021 [Page 22]
Internet-Draft Lightweight CMP Profile February 2021
The message sequences in this section allow the EE to request
certification of a locally generated public-private key pair. For
requirements regarding proper random number and key generation please
refer to [RFC4086]. The EE SHOULD provide 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 commonly used 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 POPO. As will be detailed in
Section 5.1.2, the targeted PKI management entity should verify
whether this EE is authorized to obtain a certificate with the
requested subject and other fields and extensions. Especially when
removing the protection provided by the EE and applying a new
protection, the PKI management entity MUST verify in particular the
included proof-of-possession self-signature of the certTemplate or
the PKCS#10 certificationRequestInfo 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.
When an EE verifies the protection of a response message with
signature-based protection it needs a trust anchor to verify the
protection certificate. 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 general messages, a voucher
[RFC8366], or other formats for enrollment, or in-band of CMP 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. This authorization is
typically indicated by using shared secret information, but it can
also be indicated by using a private key with a certificate issued by
another PKI authorized for this purpose, for the CMP message
protection.
Brockhaus, et al. Expires 26 August 2021 [Page 23]
Internet-Draft Lightweight CMP Profile February 2021
4.1.1. Requesting a certificate from a new PKI with signature
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. The EE
already has established trust in this new PKI it is about to enroll
to, e.g., by voucher exchange or configuration means. The
certificate request message is signature-protected using the existing
certificate from the external PKI.
Preconditions:
1 The EE MUST have a certificate enrolled by an external PKI in
advance to this PKI management operation to authenticate itself to
the PKI management entity using signature-based protection, e.g.,
using a manufacturer issued 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, the issuer field from a CertReqTemplate response message,
or other configuration means. If the EE does not know the name of
the CA, the PKI management entity MUST know where to route these
requests to.
3 The EE MUST authenticate responses from the PKI management entity;
trust MAY be established using an enrollment voucher or other
configuration means.
4 The PKI management entity MUST trust the external PKI the EE uses
to authenticate itself; trust MAY be established using some
configuration means.
The general message flow for this PKI management operation is like
that given in RFC 4210 Appendix E.7 [RFC4210].
Message flow:
Brockhaus, et al. Expires 26 August 2021 [Page 24]
Internet-Draft Lightweight CMP Profile February 2021
Step# EE PKI management entity
1 format ir
2 -> ir ->
3 handle, re-protect or
forward ir
4 format or receive ip
5 possibly grant implicit
confirm
6 <- ip <-
7 handle ip
8 In case of status
"rejection" in the
ip message, no certConf
and pkiConf are sent
9 format certConf (optional)
10 -> certConf ->
11 handle, re-protect or
forward certConf
12 format or receive pkiConf
13 <- pkiconf <-
14 handle pkiConf (optional)
For this PKI management operation, the EE MUST include exactly one
single 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 request was accepted and a new certificate was issued by the
CA, the PKI management entity MUST return the new certificate in the
certifiedKeyPair field of the ip message. If the EE requested
omission of the certConf message, the PKI management entity MAY grant
this by including the implicitConfirm extension, else this is
rejected by not including the implicitConfirm field in the ip
message.
Brockhaus, et al. Expires 26 August 2021 [Page 25]
Internet-Draft Lightweight CMP Profile February 2021
If the EE did not request implicit confirmation or the request was
not granted by the PKI management entity, certificate confirmation
MUST be performed as follows. If the EE successfully received the
certificate and accepts it, the EE MUST send a certConf message,
which the PKI management entity must respond using 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
this case the PKI management entity SHALL terminate the PKI
management operation. The PKI MAY revoke the newly issued
certificates depending on the local policy.
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 5.3 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:
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
-- 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 OID and valueany
-- parameters
-- In case a central key generation is requested, this field
Brockhaus, et al. Expires 26 August 2021 [Page 26]
Internet-Draft Lightweight CMP Profile February 2021
-- contains the algorithm and parameter preferences of the
-- requesting entity regarding the to-be-generated key pair
subjectPublicKey REQUIRED
-- MUST contain the public key to be certified in case of
-- local key generation
-- MUST contain a zero-length BIT STRING in case a central key
-- generation is requested
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 REQUIRED
POPOSigningKey OPTIONAL
-- MUST be used in case subjectPublicKey contains a public key
-- MUST be absent in case subjectPublicKey contains a
-- zero-length BIT STRING
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 field of the certTemplate
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
Brockhaus, et al. Expires 26 August 2021 [Page 27]
Internet-Draft Lightweight CMP Profile February 2021
-- 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"
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"
-- 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
-- MUST be present when certifiedKeyPair is present
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
-- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in section 5.1.5 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 root certificate SHOULD be omitted
-- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf
Field Value
header
-- As described in Section 3.1
Brockhaus, et al. Expires 26 August 2021 [Page 28]
Internet-Draft Lightweight CMP Profile February 2021
body
-- The message of the EE sends confirmation to the PKI
-- management entity 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
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
-- 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 protecting the ir
extraCerts RECOMMENDED
-- As described in Section 3.3
-- Any certificates in extraCerts MAY be omitted if the message
-- size is critical and the PKI management entity caches the
-- extraCerts from the ir
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 certificate as for protecting the ip
Brockhaus, et al. Expires 26 August 2021 [Page 29]
Internet-Draft Lightweight CMP Profile February 2021
extraCerts RECOMMENDED
-- As described in Section 3.3
-- Any certificates in extraCerts MAY be omitted if the message
-- size is critical and the EE has cached the extraCerts from the
-- ip
4.1.2. Requesting a certificate from a trusted PKI with signature
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.
The general message flow for this PKI management operation is the
same as given in Section 4.1.1.
Preconditions:
1 The EE MUST have a certificate enrolled by the PKI it requests
another certificate from in advance to this PKI management
operation to authenticate itself to the PKI management entity
using signature-based protection.
2 The EE SHOULD know the subject name of the CA it requests a
certificate from; this name MAY be established using an enrollment
voucher, the issuer field from a CertReqTemplate response message,
or other configuration means. If the EE does not know the name of
the CA, the PKI management entity MUST know where to route this
request to.
3 The EE MUST authenticate responses from the PKI management entity;
trust MAY be established using an enrollment voucher or other
configuration means.
4 The PKI management entity MUST trust the current PKI; trust MAY be
established using some configuration means.
The message sequence for this PKI management operation is like that
given in [RFC4210] Appendix D.5.
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 cr and cp,
respectively.
Brockhaus, et al. Expires 26 August 2021 [Page 30]
Internet-Draft Lightweight CMP Profile February 2021
2 The caPubs field in the cp 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 to authenticate itself and for
proving ownership of the certificate to be updated by signing its
request messages with the corresponding private key.
The general message flow for this PKI management operation is the
same as given in Section 4.1.1.
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 PKI management operation is like that
given in [RFC4210] Appendix D.6.
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 publicKey of the
EE only.
5 The oldCertId control SHOULD be used to make clear which
certificate is to be updated.
6 The caPubs field in the kup message MUST be absent.
As part of the certReq structure of the kur the oldCertId control is
added right after the certTemplate.
Brockhaus, et al. Expires 26 August 2021 [Page 31]
Internet-Draft Lightweight CMP Profile February 2021
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 PKI with MAC protection
This PKI management operation 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 shared secret information
established between the EE and the PKI. Therefore, the
initialization request is MAC-protected using this shared secret
information. The PKI management entity checking the MAC-based
protection SHOULD replace this protection according to Section 5.1.2
in case the next hop does not know the shared secret information.
For requirements regarding proper random number and key generation
please refer to [RFC4086].
The general message flow for this PKI management operation is the
same as given in Section 4.1.1.
Preconditions:
1 The EE and the PKI management entity MUST share secret
information, 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, the issuer field from a CertReqTemplate response message,
or other configuration means. If the EE does not know the name of
the CA, the PKI management entity MUST know where to route this
request to.
3 The EE MUST authenticate responses from the PKI management entity;
trust is established using the shared secret information.
The message sequence for this PKI management operation is like that
given in [RFC4210] Appendix D.4.
The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes:
Brockhaus, et al. Expires 26 August 2021 [Page 32]
Internet-Draft Lightweight CMP Profile February 2021
1 The protection of all messages MUST be calculated using Message
Authentication Code (MAC).
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 shared secret information used
for the protection, e.g., the username of the EE.
3 The extraCerts of the ir, certConf, and pkiConf messages MUST be
absent.
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 directly trusted in any case.
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 structure,
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.5. Requesting a certificate from a legacy PKI using 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]. 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.4.
This operation should be used only for compatibility reasons if the
other PKI management operations described in Section 4.1 are not
possible, for instance because a legacy component of the EE only
produces PKCS#10 requests or a legacy CA system can handle only
PKCS#10 requests. In such case the PKI management entity MUST
extract the PKCS#10 certificate request from the p10cr and provids it
separately to the CA.
The general message flow for this PKI management operation is the
same as given in Section 4.1.1, but the public key and all further
certificate template date is contained in the subjectPKInfo and other
certificationRequestInfo fields of the PKCS#10 certificate request.
Preconditions:
1 The EE MUST either have a certificate enrolled from this or any
other accepted PKI, or shared secret information known to the PKI
and the EE to authenticate itself to the RA.
Brockhaus, et al. Expires 26 August 2021 [Page 33]
Internet-Draft Lightweight CMP Profile February 2021
2 The EE SHOULD know the subject name of the CA it requests a
certificate from; this name MAY be established using an enrollment
voucher, the issuer field from a CertReqTemplate response message,
or other configuration means. If the EE does not know the name of
the CA, the RA MUST know where to route this request to.
3 The EE MUST authenticate responses from the RA; trust MAY be
established by an available root certificate, using an enrollment
voucher, or other configuration means.
4 The addressed PKI management entity MUST trust the PKI the EE uses
to authenticate itself when using the signature protection; trust
MAY be established by a corresponding available root certificate
or using some configuration means. When using MAC-based
protection the EE and PKI must share secret information.
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 p10cr and cp,
respectively.
2 The certReqId in the cp message MUST be 0.
3 The caPubs field in the cp message SHOULD be absent.
Detailed description of the p10cr message:
Brockhaus, et al. Expires 26 August 2021 [Page 34]
Internet-Draft Lightweight CMP Profile February 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 set to 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 ID
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 containing the self-signature for proof-of-possession
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
Brockhaus, et al. Expires 26 August 2021 [Page 35]
Internet-Draft Lightweight CMP Profile February 2021
4.1.6. Generateing the key pair centrally at the PKI management entity
This functional extension can be applied in combination with
certificate enrollment as described in Section 4.1.1, Section 4.1.2,
and Section 4.1.4. The functional extension can be used in case an
EE is not able to generate its new public-private key pair itself or
central generation 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 have 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. 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
certification request, this helps a lot 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, e.g., in case of RSA key
generation.
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.
Brockhaus, et al. Expires 26 August 2021 [Page 36]
Internet-Draft Lightweight CMP Profile February 2021
If the EE wishes to request central key generation, it MUST fill the
subjectPublicKey field in the certTemplate structure of the request
message with a zero-length BIT STRING. This indicates 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 is being extended from EncryptedValue to EncryptedKey by CMP
Updates [I-D.ietf-lamps-cmp-updates], also the alternative
EnvelopedData can be used. 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 transaction, CMP V3 MUST be indicated in the message
header, see 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
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].
Brockhaus, et al. Expires 26 August 2021 [Page 37]
Internet-Draft Lightweight CMP Profile February 2021
This AsymmetricKeyPackage structure MUST be wrapped in a SignedData
structure, as specified in CMS Section 5 [RFC5652], 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
kp-id-cmKGA as described in CMP Updates [I-D.ietf-lamps-cmp-updates]
in order to show the authorization to generate key pairs on behalf of
an EE.
Note: When of 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.
This 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 choose to protect the request message. See CMP Updates section
3.4 [I-D.ietf-lamps-cmp-updates] for more details on which key
management technique to use.
* Signature-protected 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.
* MAC-protected 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 protection for the request
message.
Brockhaus, et al. Expires 26 August 2021 [Page 38]
Internet-Draft Lightweight CMP Profile February 2021
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 OPTIONAL. This is due
to 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 asymmetric
algorithms. And as mentioned the password-based key management
technique shall only be used in combination with MAC protection,
which is a sideline in this document.
For details on algorithms to be used, please see CMP Algorithms
Section 4 and 5 [I-D.ietf-lamps-cmp-algorithms].
For encrypting the SignedData structure containing the private key a
fresh content-encryption key MUST be generated with sufficient
entropy for the symmetric encryption algorithm used.
Note: Depending on the lifetime of the certificate and the
criticality of the generated private key, it is advisable to use the
strongest available symmetric encryption algorithm.
The detailed description of the privateKey field as follows:
privateKey OPTIONAL
-- MUST be an EnvelopedData structure as specified in
-- CMS [RFC5652] section 6
version REQUIRED
-- MUST be set to 2 for recipientInfo type KeyAgreeRecipientInfo
-- and KeyTransRecipientInfo
-- MUST be set to 0 for recipientInfo type PasswordRecipientInfo
recipientInfos REQUIRED
-- MUST be exactly one RecipientInfo
recipientInfo REQUIRED
-- MUST be either KeyAgreeRecipientInfo (see section 4.1.6.1),
-- KeyTransRecipientInfo (see section 4.1.6.2), or
-- PasswordRecipientInfo (see section 4.1.6.3)
-- If central key generation is supported, support of
-- KeyAgreeRecipientInfo is REQUIRED and support of
-- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL
encryptedContentInfo
REQUIRED
contentType REQUIRED
-- MUST be id-signedData
contentEncryptionAlgorithm
REQUIRED
-- MUST specify the algorithm OID of the algorithm used for
-- content encryption
-- The algorithm MUST be a PROT_SYM_ALG as specified in
Brockhaus, et al. Expires 26 August 2021 [Page 39]
Internet-Draft Lightweight CMP Profile February 2021
-- RFC-CMP-Alg Section 5
encryptedContent REQUIRED
-- MUST be the SignedData structure as specified in
-- CMS Section 5 [RFC5652] in encrypted form
version REQUIRED
-- MUST be set to 3 if X.509 V3 certificates are included
digestAlgorithms
REQUIRED
-- MUST be exactly one digestAlgorithm OID
digestAlgorithmIdentifier
REQUIRED
-- MUST be the OID of the digest algorithm used for generating
-- the signature and match the signature algorithm specified in
-- signatureAlgorithm
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
AsymmetricKeyPackage
REQUIRED
-- MUST contain exactly one OneAsymmetricKey element
OneAsymmetricKey
REQUIRED
version REQUIRED
-- MUST be set to 1
privateKeyAlgorithm
REQUIRED
-- The privateKeyAlgorithm field MUST contain
-- the OID of the asymmetric key pair algorithm
privateKey
REQUIRED
-- MUST contain the new private key
attributes
OPTIONAL
-- The attributes field SHOULD not be used
publicKey
REQUIRED
-- MUST contain the public key corresponding to the private key
-- for simplicity and consistency with V2 of OneAsymmetricKey
certificates REQUIRED
-- SHOULD contain the certificate, for the private key used
-- to sign the content, together with its chain
-- If present, the first certificate in this field MUST
-- be the 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
Brockhaus, et al. Expires 26 August 2021 [Page 40]
Internet-Draft Lightweight CMP Profile February 2021
crls OPTIONAL
-- MAY be present to provide status information on the protection
-- certificate or its CA certificates
signerInfos REQUIRED
-- MUST be exactly one signerInfo
version REQUIRED
-- MUST be set to 3
sid REQUIRED
subjectKeyIdentifier
REQUIRED
-- MUST be the subjectKeyIdentifier of the protection certificate
digestAlgorithm
REQUIRED
-- MUST be the same as in digestAlgorithmIdentifier
signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the same
-- value as eContentType
-- 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]
signatureAlgorithm
REQUIRED
-- MUST be the algorithm OID of the signature algorithm used for
-- calculation of the signature bits
-- The signature algorithm MUST be a MSG_SIG_ALG as specified in
-- RFC-CMP-Alg Section 3 and MUST be consistent with the
-- subjectPublicKeyInfo field of the CMP KGA certificate
signature REQUIRED
-- MUST be the result of the digital signature generation
NOTE: As defined in Section 1.5 any field of the ASN.1 syntax as
defined in RFC 5652 [RFC5652] not explicitly specified here, SHOULD
NOT be used by the sending entity.
4.1.6.1. Using key agreement key management technique
This key management technique can be applied in combination with the
PKI management operations specified in Section 4.1.1 to Section 4.1.3
using signature-based protected CMP messages. The public key of the
EE certificate used for the signature-based protection of the request
message MUST also be used for the key establishment of the content-
encryption key. To use this key management technique the
KeyAgreeRecipientInfo structure MUST be used in the contentInfo
field.
Brockhaus, et al. Expires 26 August 2021 [Page 41]
Internet-Draft Lightweight CMP Profile February 2021
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:
recipientInfo REQUIRED
-- MUST be KeyAgreeRecipientInfo as specified in
version REQUIRED
-- MUST be set to 3
originator REQUIRED
-- MUST contain the originatorKey choice
algorithm REQUIRED
-- MUST be the algorithm OID of the key agreement algorithm
-- The algorithm 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 OID of the key wrap algorithm
-- The algorithm 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 messages
encryptedKey
REQUIRED
-- MUST be the encrypted content-encryption key
Brockhaus, et al. Expires 26 August 2021 [Page 42]
Internet-Draft Lightweight CMP Profile February 2021
4.1.6.2. Using key transport key management technique
This key management technique can be applied in combination with the
PKI management operations specified in Section 4.1.1 to Section 4.1.3
using signature-based protected CMP messages. The public key of the
EE certificate used for the signature-based protection of the request
message MUST also be used for key encipherment of the content-
encryption key. To use 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:
recipientInfo REQUIRED
-- MUST be KeyTransRecipientInfo as specified in
-- CMS section 6.2.1 [RFC5652]
version REQUIRED
-- MUST be set to 2
rid REQUIRED
-- MUST contain the subjectKeyIdentifier choice
subjectKeyIdentifier
REQUIRED
-- MUST contain the same value as the senderKID in the respective
-- request messages
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm OID of the key transport algorithm
-- The algorithm 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 key management technique can be applied in combination with the
PKI management operation specified in Section 4.1.4 using MAC-based
protected 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 as used for the MAC-based protection . To
use this key management technique the PasswordRecipientInfo structure
MUST be used in the contentInfo field.
Brockhaus, et al. Expires 26 August 2021 [Page 43]
Internet-Draft Lightweight CMP Profile February 2021
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:
recipientInfo REQUIRED
-- MUST be PasswordRecipientInfo as specified in
-- CMS section 6.2.4 [RFC5652]
version REQUIRED
-- MUST be set to 0
keyDerivationAlgorithm
REQUIRED
-- MUST be the algorithm OID of the key derivation algorithm
-- The algorithm MUST be a KM_KD_ALG as specified in RFC-CMP-Alg
-- Section 4.4
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm OID of the key wrap algorithm
-- The algorithm 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.1.7. Delayed enrollment
This functional extension can be applied in combination with
certificate enrollment as described in Section 4.1.1 to
Section 4.1.5. The functional extension can be used in case a PKI
management entity cannot respond to the certificate request in a
timely manner, e.g., due to offline upstream communication or
required registration officer interaction. Depending on the PKI
architecture, the entity initiating delayed enrollment is not
necessarily the PKI management entity directly addressed by the EE.
Note: According to CMP Updates [I-D.ietf-lamps-cmp-updates] polling
is also possible for PKI management operations starting with a p10cr
request message.
The PKI management entity initiating the delayed enrollment MUST
respond with an ip/cp/kup message including the status "waiting".
When receiving a response with status "waiting" the EE MUST send a
poll request to the same PKI management entity as before. The PKI
management entity that initiated the delayed enrollment MUST answer
with a poll response containing a checkAfter time. This value
indicates the minimum number of seconds that should elapse before the
EE sends another poll request. This is repeated as long as no final
response is available or any party involved gives up on the current
Brockhaus, et al. Expires 26 August 2021 [Page 44]
Internet-Draft Lightweight CMP Profile February 2021
transaction. When the PKI management entity that initiated delayed
enrollment can provide the final ip/cp/kup message for the initial
request of the EE, it MUST provide this message in response to a poll
request. After receiving this response, the EE can continue the
original PKI management operation as described in the respective
section of this document, e.g., sending a certConf message.
Message flow:
Step# EE PKI management entity
1 format ir/cr/p10cr/kur
As described in the
respective section
in this document
2 ->ir/cr/p10cr/kur->
3 handle request as described
in the respective section
in this document
4 in case no immediate final
response is possible,
receive or format ip, cp
or kup message containing
status "waiting"
5 <- ip/cp/kup <-
6 handle ip/cp/kup with status "waiting"
7 format pollReq
8 -> pollReq ->
9 handle, re-protect or
forward pollReq
10 in case the requested
certificate or a
corresponding response
message is available,
receive or format ip, cp,
or kup containing the
issued certificate, else
format or receive pollRep
with appropriate
checkAfter value
11 <- pollRep <-
12 handle pollRep
13 let checkAfter
time elapse
14 continue with line 7
Detailed description of the first ip/cp/kup:
Brockhaus, et al. Expires 26 August 2021 [Page 45]
Internet-Draft Lightweight CMP Profile February 2021
Response with status 'waiting' -- ip/cp/kup
Field Value
header
-- MUST contain a header as described for the first response
-- message of the respective PKI management operation
body
-- The response of the PKI management entity to the request in
-- case no immediate appropriate response can be sent
ip/cp/kup REQUIRED
response REQUIRED
-- MUST contain exactly one CertResponse
certReqId REQUIRED
-- MUST be 0
status REQUIRED
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- MUST be "waiting"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to
-- display in a GUI
failInfo PROHIBITED
certifiedKeyPair PROHIBITED
protection REQUIRED
-- MUST contain protection as described for the first response
-- message of the respective PKI management operation, except
-- that the PKI management entity that initiated the delayed
-- enrollment and created this response MUST apply its own
-- protection
extraCerts REQUIRED
-- MUST contain certificates as described for the first response
-- message of the respective PKI management operation. Yet since
-- no new certificate is included yet, no respective certificate
-- chain is included
Polling Request -- pollReq
Field Value
header
-- MUST contain a header as described for the certConf message
-- of the respective PKI management operation
Brockhaus, et al. Expires 26 August 2021 [Page 46]
Internet-Draft Lightweight CMP Profile February 2021
body
-- The message of the EE asks for the final response or for a
-- time to check again
pollReq REQUIRED
-- MUST contain exactly one element
certReqId REQUIRED
-- MUST be 0
protection REQUIRED
-- MUST contain protection as described for the certConf message
-- of the respective PKI management operation
extraCerts OPTIONAL
-- MUST be as described for the certConf message of the
-- respective PKI management operation
Polling Response -- pollRep
Field Value
header
-- MUST contain a header as described for the pkiConf message
-- of the respective PKI management operation
body
-- The message indicates the delay after which the EE may send
-- another pollReq message for this transaction
pollRep REQUIRED
-- MUST contain exactly one entry
certReqId REQUIRED
-- MUST be 0
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
-- MUST contain protection as described for the pkiConf message
-- of the respective profile, except that the PKI management
-- entity that initiated the delayed enrollment and created this
-- response MUST apply its own protection
extraCerts OPTIONAL
-- If present, it MUST contain certificates as described for the
-- pkiConf message of the respective PKI management operation.
Brockhaus, et al. Expires 26 August 2021 [Page 47]
Internet-Draft Lightweight CMP Profile February 2021
Final response -- ip/cp/kup
Field Value
header
-- MUST contain a header as described for the first
-- except that the PKI management entity that initiated the
-- delayed enrollment MUST replace the recipNonce by be the
-- senderNonce of the last pollReq message
body
-- The response of the PKI management entity to the initial
-- request as described in the respective PKI management
-- operation
protection REQUIRED
-- MUST contain protection as described for the first response
-- message of the respective PKI management operation, except
-- that the PKI management entity that initiated the delayed
-- enrollment MUST re-protect the response message
extraCerts REQUIRED
-- MUST contain certificates as described for the first
-- response message of the respective PKI management operation
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. A PKI management entity
could also act as 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.
An EE requests the revocation of an own certificate at the CA that
issued this certificate. The PKI management entity responds with a
message that contains the status of the revocation from the CA.
Preconditions:
1 The certificate the EE wishes to revoke is not yet expired or
revoked.
Message flow:
Brockhaus, et al. Expires 26 August 2021 [Page 48]
Internet-Draft Lightweight CMP Profile February 2021
Step# EE PKI management entity
1 format rr
2 -> rr ->
3 handle, re-protect 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 error
occurred the response to the rr MUST be an rp message containing a
status field with a single set of values.
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 requests MUST be
-- packaged in separate PKI Messages
certDetails REQUIRED
-- MUST be present and be of type CertTemplate
serialNumber REQUIRED
-- MUST contain the certificate serialNumber attribute of the
-- X.509 certificate to be revoked
issuer REQUIRED
-- MUST contain the issuer attribute of the X.509 certificate to
-- be revoked
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
Brockhaus, et al. Expires 26 August 2021 [Page 49]
Internet-Draft Lightweight CMP Profile February 2021
-- 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 and only if status is "rejection"
protection REQUIRED
-- As described in section 3.2
extraCerts REQUIRED
-- As described in section 3.3
4.3. Error reporting
This functionality should be used by an EE to report error conditions
upstream to the PKI management entity such that the involved PKI
management entities can immediately free their resources related to
the current transaction. Error reporting by a PKI management entity
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 MUST be reported in the form of an error message.
Brockhaus, et al. Expires 26 August 2021 [Page 50]
Internet-Draft Lightweight CMP Profile February 2021
In both situations the EE reports the status "rejection" in the
PKIStatusInfo structure of the respective message.
Depending on the PKI architecture, the addressed PKI management
entity MUST forward the error message (upstream) to the next PKI
management entity and MUST terminate this PKI management operation on
receiving any response.
The PKIStatusInfo structure is used to report errors. The
PKIStatusInfo structure consists of the following fields:
* status: Here the PKIStatus value "rejection" is the only one
allowed.
* statusString: Here any human-readable valid value for logging or
to display in a GUI SHOULD be added.
* failInfo: Here the PKIFailureInfo values MAY be used in the way
explained in Appendix F of RFC 4210 [RFC4210]. The following
PKIFailureInfo values have specific usage and therefore are
described in detail here:
- 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.
- systemUnavail or systemFailure: This is sent by a PKI
management entity 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.
Detailed error message description:
Brockhaus, et al. Expires 26 August 2021 [Page 51]
Internet-Draft Lightweight CMP Profile February 2021
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 relevant to the EE that may be provided by the 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 LRA, RA, or CA.
The general messages and general response messages transport
InfoTypeAndValue structures. In addition to those infoType values
defined in RFC 4210 [RFC4210] 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 updates
* PGet certificate request templates
Brockhaus, et al. Expires 26 August 2021 [Page 52]
Internet-Draft Lightweight CMP Profile February 2021
The PKI management operation is similar to that given in Appendix E.5
of RFC 4210 [RFC4210]. In this section the aspects common to all
general messages (genm) and to all general responses (genp) are
described.
The behavior in case an error occurs is described in Section 4.3.
Message flow:
Step# EE PKI management entity
1 format genm
2 -> genm ->
3 handle, re-protect or
forward genm
4 format or receive genp
5 <- genp <-
6 handle genp
Detailed message description:
General Message -- genm
Field Value
header
-- As described in Section 3.1
body
-- A request by the EE to receive information
genm 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 described in the specific PKI
-- management operation described below
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
General Response -- genp
Brockhaus, et al. Expires 26 August 2021 [Page 53]
Internet-Draft Lightweight CMP Profile February 2021
Field Value
header
-- As described in Section 3.1
body
-- The response of the PKI management entity to an
-- information request
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 described in the specific PKI
-- management operation described below
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
4.4.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 from the 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 CA
intermediate and issuing CA certificates or with no content in case
no CA certificate is available.
The message sequence for this PKI management operation is as given in
Section 4.4, with the following specific content:
1 the body MUST contain as infoType the OID 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
Brockhaus, et al. Expires 26 August 2021 [Page 54]
Internet-Draft Lightweight CMP Profile February 2021
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.4.2. Get root CA certificate update
This PKI management operation can be used by an EE to retrieve any
updated root CA Certificate as described in Section 4.4 of RFC 4210
[RFC4210].
An EE requests a root CA certificate update from the PKI management
entity by sending a general message with OID id-it-rootCaKeyUpdate 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 the update of the root CA certificate consisting
of up to three certificates, or with no content in case no update is
available.
The newWithNew certificate is the new root CA certificate and is
REQUIRED to be present in the response message. The newWithOld
certificate is RECOMMENDED to be present in the response message,
because it is needed for those cases where the receiving entity
trusts the old root CA certificate and wishes to gain trust in the
new root CA certificate. It MAY be omitted if the PKI management
entity that performed the message protection of the response message
is authorization to update the trust store of the EE. The oldWithNew
certificate is OPTIONAL, because it is only needed in a scenario
where the requesting entity does not have an own certificate under
the new root CA and wishes to authenticate to entities not trusting
the old root CA.
The message sequence for this PKI management operation is as given in
Section 4.4, with the following specific content:
1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate
2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be a
RootCaKeyUpdate structure
The infoValue field of the general response containing the id-it-
rootCaKeyUpdate extension looks like this:
Brockhaus, et al. Expires 26 August 2021 [Page 55]
Internet-Draft Lightweight CMP Profile February 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 RootCaKeyUpdate
newWithNew REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the new root CA certificate
newWithOld RECOMMENDED
-- SHOULD 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
< TBD: In case the PKI management entity serves for more than one
Root CA. There are three different options to handle this: - The EE
specifies by means of a respective label in the HTTP endpoint for
which Root CA certificate the update is requested. - The EE transfers
the oldWithOld certificate or its S/N+issuer in the InfoValue of the
request. - The PKI management entity provides several
InfoTypeAndValue pairs in the response containing a RootCaKeyUpdate
element for each Root CA where an update is available. >
4.4.3. Get certificate request template
This PKI management operation can be used by an EE to request a
template with parameters for a 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 PKI
management entity responds with a general response with the same OID
that either contains a certificate template containing requirements
on certificate fields and extensions and optionally a keySpec field
containing requirements on algorithms acceptable for key pair
generation, or with no content in case no specific requirements are
imposed by the PKI.
The EE SHOULD follow the requirements from the received CertTemplate
and the optional keySpec field, by including in the certTemplate of
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 CertTemplate fields, Name components,
and extensions or their (sub-)components.
Brockhaus, et al. Expires 26 August 2021 [Page 56]
Internet-Draft Lightweight CMP Profile February 2021
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 CertReqTemplate response message. On the other
hand, a PKI management entity is free to ignore or replace any parts
of the 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.
In case a field of type Name, e.g., issuer or 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 certTemplate
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
MUST be omitted. In case the PKI management entity wishes to make
stipulation on supported algorithms the EE may use for key
generation, this MUST be specified using the control fields as
specified in CMP Updates [I-D.ietf-lamps-cmp-updates].
The keySpec field, if present, specifies the public key types and
lengths for which a certificate may be requested.
The value of a keySpec with the OID id-regCtrl-algId, as specified in
CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of type
AlgorithmIdentitier and gives an algorithm other than RSA. For EC
keys the full curve information MUST be specified as described in the
respective standard documents.
The value of a keySpec with the OID id-regCtrl-rsaKeyLen, as
specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of
type Integer and gives an RSA key length.
The PKI management entity responds with a general response with the
same OID that either contains a certificate template containing
requirements on certificate fields and extensions and optionally a
Brockhaus, et al. Expires 26 August 2021 [Page 57]
Internet-Draft Lightweight CMP Profile February 2021
keySpec field containing requirements on algorithms acceptable for
key pair generation, or with no content in case no specific
requirements are imposed by the PKI.
The EE SHOULD follow the requirements from the received CertTemplate
and the optional keySpec field, by including in the certTemplate of
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 CertTemplate fields, name components,
and extensions or their (sub-)components. In case several keySpec
elements are present the EE can choose one of the specified
algorithms for key pair generation. In case the keySpec field is
absent the EE is free to choose any public key type including
parameters.
In the CertTemplate structure the serialNumber, signingAlg,
publicKey, issuerUID, and subjectUID fields MUST be omitted.
The message sequence for this PKI management operation is as given in
Section 4.4, with the following specific content:
1 the body MUST contain as infoType the OID id-it-certReqTemplate
2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be a CertTemplate
structure and an optional SEQUENCE of AttributeTypeAndValue with
attribute type id-regCtrl-algId or id-regCtrl-rsaKeyLen
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 content of the certificates template
certTemplate REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the prefilled CertTemplate structure elements
-- The SubjectPublicKeyInfo MUST contain no algorithm ID i.e.,
-- the null OBJECT IDENTIFIER) in the algorithm field and a
-- zero-length BIT STRING in the subjectPublicKey field
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 key generation
-- MUST contain one AttributeTypeAndValue per supported algorithm
-- with attribute id-regCtrl-algId or id-regCtrl-rsaKeyLen
Brockhaus, et al. Expires 26 August 2021 [Page 58]
Internet-Draft Lightweight CMP Profile February 2021
< TBD: In case the PKI management entity offers for more than one set
of certificate request parameters. There are three different options
to handle this: - The EE specifies by means of a respective label in
the HTTP endpoint for which set of certificate request parameters is
requested the template. - The EE neame of the set of certificate
request parameters in the InfoValue of the request. - The PKI
management entity provides several InfoTypeAndValue pairs in the
response containing a set of certificate request parameter in each
InfoTypeAndValue pairs. >
5. LRA and RA PKI management operations
This section focuses on the communication among PKI management
entities. Depending on the network and PKI solution design, these
can be LRAs, RAs, and CAs.
A PKI management entity typically forwards request messages from
downstream, but it may also reply to them itself. Besides forwarding
received messages, a PKI management entity may need to revoke
certificates of EEs, report errors, or may need to manage its own
certificates.
5.1. Forwarding messages
In case the PKI solution consists of several PKI management entities,
each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or
certConf) or error message coming from an EE or any other downstream
PKI management entity MUST be sent to the next (upstream) PKI
management entity. Any received response message MUST be forwarded
downstream to the next PKI management entity or EE.
The PKI management entity 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 switch to the operation described in
Section 5.3, i.e., respond with a negative response message and then
MUST NOT forward the request message further upstream.
A PKI management entity SHOULD not change the received message unless
necessary. The PKI management entity SHOULD only update the message
protection 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.
Brockhaus, et al. Expires 26 August 2021 [Page 59]
Internet-Draft Lightweight CMP Profile February 2021
Each hop in a chain of PKI management entity has one or more
functionalities, e.g., a PKI management entity may
* 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,
* add fields to 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 enrollment due to offline upstream
communication or registration officer interaction,
* grant the request of an EE to omit sending a confirmation message,
or
* collect messages from ultiple LRAs and forward them jointly.
Therefore, 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]).
This section specifies the options a PKI management entity may
implement and use.
A PKI management entity MAY update the protection of a message if it
Brockhaus, et al. Expires 26 August 2021 [Page 60]
Internet-Draft Lightweight CMP Profile February 2021
* performs changes to the header or the body of the message,
* needs to securely indicate that it has done checks or validations
on the message to one of the next (upstream) PKI components,
* needs to protect the message using a key and certificate from a
different PKI, or
* needs to replace or produce 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 the next hop. 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.1.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 require 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 with
an error message as specified in Section 5.3.
This variant of forwarding a message SHOULD be used for kur messages
because their protection (using the certificate to be updated) MUST
NOT be changed. If the respective PKI management entity really needs
approve such a request it MUST use a nested message as described in
Section 5.1.3.
5.1.2. Replacing protection
The following two alternatives to forwarding a message can be used by
any PKI management entity forwarding a CMP message with or without
changes, while providing its own protection asserting approval of
messages. In this case the PKI management entity acts as an actual
Registration Authority (RA), which implements important security
functionality of the PKI.
Brockhaus, et al. Expires 26 August 2021 [Page 61]
Internet-Draft Lightweight CMP Profile February 2021
Before replacing the existing protection by a new protection, the PKI
management entity MUST verify the protection provided and approve its
content including any own modifications. For certificate requests
the PKI management entity MUST verify (except in case of central key
generation) the presence and contents of the 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
PKI management entity, the current PKI management entity MUST verify
its protection and approve its content including any own
modifications. For request messages the PKI management entity MUST
check that the other PKI management entity, as authenticated by the
protection of the incoming message, was authorized to issue or
forward the request.
These message adaptations MUST NOT be applied to kur request messages
as 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.
These message adaptations MUST NOT be applied to certificate request
messages as described in Section 4.1.6since 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.1.3.
When an intermediate PKI management entity modifies a message, it
SHOULD NOT change the transactionID nor the sender and recipient
nonce except as stated for delayed enrollment in Section 4.1.7.
Section 4.1.7.
5.1.2.1. Keeping 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.
By replacing the existing protection using its own CMP protecting key
the PKI management entity provides a proof of verifying and approving
of the message as described above.
Brockhaus, et al. Expires 26 August 2021 [Page 62]
Internet-Draft Lightweight CMP Profile February 2021
In case the PKI management entity 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 variant of forwarding a message means that a PKI management
entity forwards an ir or cr message with modifications of the
certTemplate, i.e., modification, addition, or removal of fields.
Such changes will break the signature-based proof-of-possession
provided by the EE in the original message.
By replacing the existing protection and using its own CMP protection
key the PKI management entity provides a proof of verifying and
approving the request message as described above.
In addition, the PKI management entity MUST verify the proof-of-
possession contained in the original message as described above. If
these checks were successful, the PKI management entity 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 PKI
-- management entity verified the popo of the original
-- message
5.1.3. Adding Protection
This variant of forwarding a message means that a PKI management
entity adds another protection to PKI management messages before
forwarding them. Applying an additional protection is specifically
relevant when forwarding a message that requests a certificate update
or a central key generation. This is because the original protection
of the EE must be preserved while adding an indication of approval.
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 case
for adding another protection by a PKI management entity. Specific
procedures are described in more detail in the following sections.
The behavior in case an error occurs is described in Section 4.3.
Brockhaus, et al. Expires 26 August 2021 [Page 63]
Internet-Draft Lightweight CMP Profile February 2021
Message flow:
Step# PKI management entity PKI management entity
1 format nested
2 -> nested ->
3 handle, re-protect or
forward nested
4 format or receive nested
5 <- nested <-
6 handle nested
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.1.3.1. Handling a single PKI management message
A PKI management entity may authentically indicate successful
validation and authorization of a PKI management message by adding an
additional signature to the original PKI management message.
A PKI management entity SHALL wrap the original PKI management
messages in a nested message structure. The additional signature as
prove of verification and authorization by the PKI management entity
MUST be applied as signature-based message protection of the nested
message.
Brockhaus, et al. Expires 26 August 2021 [Page 64]
Internet-Draft Lightweight CMP Profile February 2021
5.1.3.2. Handling a batch of PKI management 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 via an offline interface using the nested message structure.
Nested messages can be used on the upstream interface towards the
next PKI management entity and/or on the downstream interface from
the PKI management entity towards the EE.
This PKI management operation is typically used on the interface
between LRA and RA to bundle several PKI management messages for
offline transport. In this case the LRA needs to initiate delayed
enrollment as described in Section 5.1.4. If the RA may need
different routing information per nested PKI management message a
suitable mechanism may need to be implemented. This mechanism
strongly depends on the requirements of the target architecture.
Therefore, it is out of scope of this document.
An initial nested message is generated locally at the PKI management
entity. For the initial 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.
The recipient field MUST identify the PKI management entity that is
expected to unpack the nested message. An initial nested message may
contain request messages, e.g., ir, cr, p10cr, kur, certConf, rr, or
genm. While building the initial nested message the PKI management
entity SHOULD store the transactionIds and the senderNonces of all
bundled messages together with the transactionId of the initial
nested message.
Such an initial nested message is sent to the next PKI management
entity, which MUST unbundle the included request messages and handle
each of them as usual. It SHOULD answer with a responding nested
message. This responding message MUST use the transactionId of the
initial nested message and return the senderNonce of the initial
nested message as recipNonce of the responding nested message. The
responding nested message SHOULD bundle the individual response
messages (e.g., ip, cp, kup, pkiconf, rp, genp, error) for all
original request messages of the initial nested message. While
unbundling the responding nested message, the former PKI management
entity can determine lost and unexpected responses based on the
previously stored transactionIds and senderNonces. When it forwards
the unbundled responses, any extra messages SHOULD be dropped, and
any missing message SHOULD be replaced by an error message to inform
the respective EE about the failed certificate management operation.
Brockhaus, et al. Expires 26 August 2021 [Page 65]
Internet-Draft Lightweight CMP Profile February 2021
The PKI management entity building the nested message applies a
signature-based protection using its CMP protection key as transport
protection. This protection SHALL NOT be regarded as an indication
of verification or approval of the bundled PKI request messages.
5.1.4. Initiating delayed enrollment
This functional extension can be used by a PKI management entity to
initiate delayed enrollment. In this case a PKI management entity
MUST set the status "waiting" in the response message. The PKI
management entity MUST then reply to the pollReq messages as
described in Section 4.1.7.
Typically, as stated in Section 5.1.2, 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
polling initiated by an intermediate PKI management entity, for
example by an LRA with offline transport to an upstream RA, there is
an exception. Between the EE and that entity, pollReq and pollRep
messages are exchanged handling the nonces as usual. Yet when, after
some pollRep, the final response from upstream arrives at that PKI
management entity, this response contains the recipNonce set to the
value copied (as usual) from the senderNonce in the original request
message. The mentioned entity needs to replace the recipNonce in the
response message with the senderNonce of the last received pollReq
because the downstream entities, including the EE, will expect it in
this way.
5.2. Revoking certificates on behalf of another's PKI entities
This PKI management operation can be used by a PKI management entity
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.
Preconditions:
1 the certificate to be revoked MUST be known to the PKI management
entity
2 the PKI management entity MUST have the authorization to revoke
the certificates of other entities issued by the corresponding CA
The message sequence for this PKI management operation is identical
to that given in Section 4.2, with the following changes:
Brockhaus, et al. Expires 26 August 2021 [Page 66]
Internet-Draft Lightweight CMP Profile February 2021
1 it is not required that the certificate to be revoked is not yet
expired or revoked
2 the PKI management entity acts as EE for this message exchange
3 the rr message MUST be signed using the CMP protection key of the
PKI management entity.
5.3. Error reporting
This functionality should be used by the PKI management entity to
report any arising error conditions downstream to the EE. Note that
error reporting by the EE upstream to the PKI management entity 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 PKI management entity 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 mechanisms
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 such as CoAP [RFC7252].
Independently of the means of transport 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
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 26 August 2021 [Page 67]
Internet-Draft Lightweight CMP Profile February 2021
When conveying a CMP messages in HTTP or MIME-based transport
protocols the internet media type "application/pkixcmp" MUST be set
for transport encoding as specified in Section 5.3 of RFC 2510
[RFC2510] and Section 3.4 of RFC 6712 [RFC6712].
Note: When using TCP as reliable transport layer protocol, which is
typical in conjunction with HTTP, there is the option to keep the
connection open over the lifetime of transactions containing multiple
request-response message pairs. This may improve efficiency but is
not required from a security point of view.
6.1. HTTP transport
This transport mechanism can be used by a PKI entity to transfer CMP
messages over HTTP. If HTTP transport 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 the following URI path:
+=================================+=====================+=========+
| PKI management operation | Path | Details |
+=================================+=====================+=========+
| Enroll client to new PKI | /initialization | Section |
| | | 4.1.1 |
+---------------------------------+---------------------+---------+
| Enroll client to existing PKI | /certification | Section |
| | | 4.1.2 |
+---------------------------------+---------------------+---------+
| Update client certificate | /keyupdate | Section |
| | | 4.1.3 |
+---------------------------------+---------------------+---------+
| Enroll client using PKCS#10 | /p10 | Section |
| | | 4.1.5 |
+---------------------------------+---------------------+---------+
| Enroll client using central key | /serverkeygen | Section |
| generation | | 4.1.6 |
| | | |
| Note: This path element MAY | | |
| also be appended to each of the | | |
| path elements listed above. | | |
+---------------------------------+---------------------+---------+
| Revoke client certificate | /revocation | Section |
| | | 4.2 |
+---------------------------------+---------------------+---------+
| Get CA certificates | /getcacert | Section |
| | | 4.4.1 |
+---------------------------------+---------------------+---------+
Brockhaus, et al. Expires 26 August 2021 [Page 68]
Internet-Draft Lightweight CMP Profile February 2021
| Get root CA certificate update | /getrootupdate | Section |
| | | 4.4.2 |
+---------------------------------+---------------------+---------+
| Get certificate request | /getcertreqtemplate | Section |
| template | | 4.4.3 |
+---------------------------------+---------------------+---------+
| Additional protection | /nested | Section |
| | | 5.1.3 |
| Note: This path element is | | |
| applicable only between PKI | | |
| management entities. | | |
+---------------------------------+---------------------+---------+
Table 9: HTTP endpoints
Subsequent certConf, error, and pollReq messages are sent to the URI
of the respective PKI management operation.
The PKI entity will recognize by the HTTP response status code if a
configured URI is supported by the PKI management entity by sending a
request to its preferred enrollment endpoint.
6.2. HTTPS transport using certificates
This transport mechanism can be used by a PKI entity to further
protect the HTTP transport described in Section 6.1 using TLS 1.2
[RFC5246] or TLS 1.3 [RFC8446] with certificate-based authentication
as described in [RFC2818]. Using this transport mechanism, the CMP
transport via HTTPS MUST use TLS server authentication and SHOULD use
TLS client authentication.
TLS client:
* The client SHOULD use a TLS client certificate as far as
available. If no dedicated TLS certificate is available on an EE
side, this EE SHOULD use an already existing certificate
identifying the EE (e.g., a manufacturer issued certificate).
Each PKI management entity SHOULD use a dedicated TLS client
certificate on its upstream (client) interface.
* If no usable client certificate is available at the client,
server-only authenticated TLS MUST be used.
* The client MUST validate the TLS server certificate of its
communication partner.
TLS server:
Brockhaus, et al. Expires 26 August 2021 [Page 69]
Internet-Draft Lightweight CMP Profile February 2021
* The server MUST use a TLS server certificate.
* The server MUST validate the TLS certificate of its clients if
client authentication is available.
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 communication partners.
6.3. HTTPS transport using shared secrets
This transport mechanism can be used by a PKI entity 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 secret information as described in
[RFC5054].
< TBD: Add an appropriate shared secret-based mechanism for TLS 1.3.
>
TLS client:
* The client MUST use its shared secret information for
authentication.
TLS server:
* The server MUST use a suitable shared secret information for
authentication.
< TBD: It needs to be clarified which cipher suite shall be
recommended as there seems to be no support for TLS-SRP un JavaSE. >
6.4. Offline transport
For transporting 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 transport mechanism SHOULD be able to indicate message loss,
excessive delay, and possibly other transmission errors. In such
cases the PKI entities using this mechanism SHOULD report an error as
specified in Section 4.3 as fare as possible.
Brockhaus, et al. Expires 26 August 2021 [Page 70]
Internet-Draft Lightweight CMP Profile February 2021
6.4.1. File-based transport
CMP messages MAY be transferred between PKI entities using file-
system-based mechanisms, for instance when an off-line end entity or
a PKI management entity performs delayed enrollment. Each file MUST
contain the ASN.1 DER encoding of one CMP message only, which may be
nested. There MUST be no extraneous header or trailer information in
the file. The file name extension ".PKI" MUST be used.
6.4.2. Other asynchronous transport protocols
Other asynchronous transport 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 [RFC8551], section 3.1.
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.
6.5. CoAP transport
In constrained environments where no HTTP transport is desired or
possible, CoAP [RFC7252] as specified in
[I-D.ietf-ace-cmpv2-coap-transport] MAY be used.
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.
A more detailed specification is out of scope of this document and
would need to be given in a separate document, for instance in the
scope of the transport protocol used.
7. IANA Considerations
8. Security Considerations
< TBD: Add any security considerations >
Brockhaus, et al. Expires 26 August 2021 [Page 71]
Internet-Draft Lightweight CMP Profile February 2021
9. Acknowledgements
We thank the various reviewers of this document.
10. References
10.1. Normative References
[I-D.ietf-lamps-cmp-algorithms]
Brockhaus, H., Aschauer, H., Ounsworth, M., and S. Mister,
"CMP Algorithms", Work in Progress, Internet-Draft, draft-
ietf-lamps-cmp-algorithms-02, 20 January 2021,
<https://tools.ietf.org/html/draft-ietf-lamps-cmp-
algorithms-02>.
[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-08, 22 February 2021,
<https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates-
08>.
[I-D.ietf-lamps-crmf-update-algs]
Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", Work in Progress,
Internet-Draft, draft-ietf-lamps-crmf-update-algs-04, 19
February 2021, <https://tools.ietf.org/html/draft-ietf-
lamps-crmf-update-algs-04>.
[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>.
[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>.
Brockhaus, et al. Expires 26 August 2021 [Page 72]
Internet-Draft Lightweight CMP Profile February 2021
[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>.
[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>.
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-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transport for CMPV2",
Work in Progress, Internet-Draft, draft-ietf-ace-cmpv2-
coap-transport-00, 21 February 2021,
<https://tools.ietf.org/html/draft-ietf-ace-cmpv2-coap-
transport-00>.
Brockhaus, et al. Expires 26 August 2021 [Page 73]
Internet-Draft Lightweight CMP Profile February 2021
[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>.
[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>.
[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>.
Brockhaus, et al. Expires 26 August 2021 [Page 74]
Internet-Draft Lightweight CMP Profile February 2021
[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>.
[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>.
[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
This section provides a concrete example for the content of an
infoValue used of type id-it-certReqTemplate as described in
Section 4.4.3.
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
with an ECC key on curve secp256r1 or 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 returned to the EE must be encoded as
follows:
Brockhaus, et al. Expires 26 August 2021 [Page 75]
Internet-Draft Lightweight CMP Profile February 2021
SEQUENCE {
SEQUENCE {
[3] {
SEQUENCE {}
}
[5] {
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
UTnF8String ''
}
}
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String 'myDept'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String 'myGroup'
}
}
}
[6] {
SEQUENCE {
null
NULL
}
BIT STRING, encapsulates {
SEQUENCE {}
}
}
[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 {
Brockhaus, et al. Expires 26 August 2021 [Page 76]
Internet-Draft Lightweight CMP Profile February 2021
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 TBD3)
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 TBD4)
INTEGER 2048
}
}
}
Appendix B. History of changes
Note: This appendix will be deleted in the final version of the
document.
From version 04 -> 05:
* Changed to XML V3
* Added algorithm names introducted 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
Brockhaus, et al. Expires 26 August 2021 [Page 77]
Internet-Draft Lightweight CMP Profile February 2021
* 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
* 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.4 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.1.7 from
recommended to optional as decided at IETF 107
* Introduced the new RootCAKeyUpdate structure for root CA
certificate update in Section 4.4.2 as decided at IETF 107 (also
see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
section 5.4.3")
Brockhaus, et al. Expires 26 August 2021 [Page 78]
Internet-Draft Lightweight CMP Profile February 2021
* 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.4.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.1.3.
* 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.1.3 and delete the paths for /getCertMgtConfig and
/getVoucher
* 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.5; 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.3.
* 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:
Brockhaus, et al. Expires 26 August 2021 [Page 79]
Internet-Draft Lightweight CMP Profile February 2021
* 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.4.2.
* Added a section to specify the usage of nested messages for RAs to
add an additional protection for further discussion, see
Section 5.1.3.
* 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:
* 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.5.
* 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.1.7.
* 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.4.
* 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.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.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.
Brockhaus, et al. Expires 26 August 2021 [Page 80]
Internet-Draft Lightweight CMP Profile February 2021
Authors' Addresses
Hendrik Brockhaus (editor)
Siemens AG
Email: hendrik.brockhaus@siemens.com
Steffen Fries
Siemens AG
Email: steffen.fries@siemens.com
David von Oheimb
Siemens AG
Email: david.von.oheimb@siemens.com
Brockhaus, et al. Expires 26 August 2021 [Page 81]