draft-ietf-lamps-lightweight-cmp-profile-05.txt   draft-ietf-lamps-lightweight-cmp-profile-06.txt 
LAMPS Working Group H. Brockhaus, Ed. LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft S. Fries Internet-Draft S. Fries
Intended status: Standards Track D. von Oheimb Intended status: Standards Track D. von Oheimb
Expires: 26 August 2021 Siemens Expires: 10 January 2022 Siemens
22 February 2021 9 July 2021
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-05 draft-ietf-lamps-lightweight-cmp-profile-06
Abstract Abstract
The goal of this document is to facilitate interoperability and This document aims at simple, interoperable, and automated PKI
automation by profiling the Certificate Management Protocol (CMP) management operations covering typical use cases of industrial and
version 2, the related Certificate Request Message Format (CRMF) IoT scenarios. This is achieved by profiling the Certificate
version 2, and the HTTP Transfer for the Certificate Management Management Protocol (CMP), the related Certificate Request Message
Protocol. It specifies a subset of CMP and CRMF focusing on typical Format (CRMF), and HTTP-based or CoAP-based transport in a succinct
use cases relevant for managing certificates of devices in many but sufficiently detailed and self-contained way. To make secure
industrial and IoT scenarios. To limit the overhead of certificate certificate management for simple scenarios and constrained devices
management for more constrained devices only the most crucial types as lightweight as possible, only the most crucial types of operations
of operations are specified as mandatory. To foster interoperability and options are specified as mandatory. More special and complex use
in more complex scenarios, other types of operations are specified as cases are supported as well, by features specified as recommended or
recommended or optional. optional.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 August 2021. This Internet-Draft will expire on 10 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4
1.2. Motivation for a lightweight profile for CMP . . . . . . 5 1.2. Motivation for a lightweight profile of CMP . . . . . . . 4
1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 1.3. Special requirements of industrial and IoT scenarios . . 5
1.4. Compatibility with existing CMP profiles . . . . . . . . 8 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6
1.5. Scope of this document . . . . . . . . . . . . . . . . . 9 1.5. Compatibility with existing CMP profiles . . . . . . . . 7
1.6. Structure of this document . . . . . . . . . . . . . . . 10 1.6. Scope of this document . . . . . . . . . . . . . . . . . 8
1.7. Convention and Terminology . . . . . . . . . . . . . . . 11 1.7. Structure of this document . . . . . . . . . . . . . . . 9
1.8. Convention and Terminology . . . . . . . . . . . . . . . 10
2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11
2.1. Solution architecture . . . . . . . . . . . . . . . . . . 12 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11
2.2. Basic generic CMP message content . . . . . . . . . . . . 13 2.2. Supported PKI management operations . . . . . . . . . . . 13
2.3. Supported PKI management operations . . . . . . . . . . . 13 2.2.1. Mandatory PKI management operations . . . . . . . . . 13
2.3.1. Mandatory PKI management operations . . . . . . . . . 14 2.2.2. Recommended PKI management operations . . . . . . . . 13
2.3.2. Recommended PKI management operations . . . . . . . . 14 2.2.3. Optional PKI management operations . . . . . . . . . 14
2.3.3. Optional PKI management operations . . . . . . . . . 15 2.3. CMP message transport . . . . . . . . . . . . . . . . . . 16
2.4. CMP message transport . . . . . . . . . . . . . . . . . . 16 3. Generic aspects of the PKI message . . . . . . . . . . . . . 16
3. Generic parts of the PKI message . . . . . . . . . . . . . . 17 3.1. General description of the CMP message header . . . . . . 17
3.1. General description of the CMP message header . . . . . . 18 3.2. General description of the CMP message protection . . . . 19
3.2. General description of the CMP message protection . . . . 20 3.3. General description of CMP message extraCerts . . . . . . 20
3.3. General description of CMP message extraCerts . . . . . . 21 3.4. Generic PKI management operation prerequisites . . . . . 20
4. End Entity PKI management operations . . . . . . . . . . . . 21 3.5. Generic validation of a PKI message . . . . . . . . . . . 22
4.1. Requesting a new certificate from a PKI . . . . . . . . . 22 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 24
4.1.1. Requesting a certificate from a new PKI with signature 3.6.1. Reporting error conditions upstream . . . . . . . . . 24
protection . . . . . . . . . . . . . . . . . . . . . 24 3.6.2. Reporting error conditions downstream . . . . . . . . 25
4.1.2. Requesting a certificate from a trusted PKI with 3.6.3. Handling error conditions on nested messages used for
signature protection . . . . . . . . . . . . . . . . 30 batching . . . . . . . . . . . . . . . . . . . . . . 25
3.6.4. Reporting error conditions . . . . . . . . . . . . . 25
4. End Entity PKI management operations . . . . . . . . . . . . 27
4.1. Requesting a new certificate from a PKI . . . . . . . . . 30
4.1.1. Requesting a certificate from a new PKI with
signature-based protection . . . . . . . . . . . . . 31
4.1.2. Requesting an additional certificate with
signature-based protection . . . . . . . . . . . . . 37
4.1.3. Updating an existing certificate with signature 4.1.3. Updating an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 31 protection . . . . . . . . . . . . . . . . . . . . . 38
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
4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 44 4.1.4. Requesting a certificate from a PKI with MAC-based
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 protection . . . . . . . . . . . . . . . . . . . . . 39
4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50 4.1.5. Requesting a certificate from a legacy PKI using a
4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52 PKCS#10 request . . . . . . . . . . . . . . . . . . . 40
4.4.1. Get CA certificates . . . . . . . . . . . . . . . . . 54 4.1.6. Adding central key pair generation to a certificate
4.4.2. Get root CA certificate update . . . . . . . . . . . 55 request . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.3. Get certificate request template . . . . . . . . . . 56 4.1.6.1. Using key agreement key management technique . . 47
5. LRA and RA PKI management operations . . . . . . . . . . . . 59 4.1.6.2. Using key transport key management technique . . 48
5.1. Forwarding messages . . . . . . . . . . . . . . . . . . . 59 4.1.6.3. Using password-based key management technique . . 49
5.1.1. Not changing protection . . . . . . . . . . . . . . . 61 4.1.7. Handling delayed enrollment . . . . . . . . . . . . . 50
5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 55
5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 57
5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 63 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 59
5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 4.3.2. Get root CA certificate update . . . . . . . . . . . 60
5.1.3.1. Handling a single PKI management message . . . . 64 4.3.3. Get certificate request template . . . . . . . . . . 61
5.1.3.2. Handling a batch of PKI management messages . . . 65 5. PKI management entity operations . . . . . . . . . . . . . . 63
5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 66 5.1. Responding to requests . . . . . . . . . . . . . . . . . 64
5.2. Revoking certificates on behalf of another's PKI 5.1.1. Responding to a certificate request . . . . . . . . . 64
entities . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1.2. Initiating delayed enrollment . . . . . . . . . . . . 65
5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 67 5.1.3. Responding to a confirmation message . . . . . . . . 66
6. CMP message transport mechanisms . . . . . . . . . . . . . . 67 5.1.4. Responding to a revocation request . . . . . . . . . 66
6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 68 5.1.5. Responding to a support message . . . . . . . . . . . 66
6.2. HTTPS transport using certificates . . . . . . . . . . . 69 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 66
6.3. HTTPS transport using shared secrets . . . . . . . . . . 70 5.2.1. Not changing protection . . . . . . . . . . . . . . . 68
6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 70 5.2.2. Adding protection and batching of messages . . . . . 69
6.4.1. File-based transport . . . . . . . . . . . . . . . . 71 5.2.2.1. Adding protection to a request message . . . . . 69
6.4.2. Other asynchronous transport protocols . . . . . . . 71 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 71
6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 72
6.6. Piggybacking on other reliable transport . . . . . . . . 71 5.2.3.1. Not changing any included proof-of-possession . . 73
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 73
8. Security Considerations . . . . . . . . . . . . . . . . . . . 71 5.3. Acting on behalf of other PKI entities . . . . . . . . . 74
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 74
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 75
10.1. Normative References . . . . . . . . . . . . . . . . . . 72 6. CMP message transport mechanisms . . . . . . . . . . . . . . 75
10.2. Informative References . . . . . . . . . . . . . . . . . 73 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 76
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 75 6.2. CoAP transport . . . . . . . . . . . . . . . . . . . . . 78
Appendix B. History of changes . . . . . . . . . . . . . . . . . 77 6.3. Piggybacking on other reliable transport . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 80
6.4.1. File-based transport . . . . . . . . . . . . . . . . 80
6.4.2. Other asynchronous transport protocols . . . . . . . 81
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
8. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 82
10.1. Normative References . . . . . . . . . . . . . . . . . . 82
10.2. Informative References . . . . . . . . . . . . . . . . . 83
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 85
Appendix B. History of changes . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
[RFC Editor: please delete]:!!! The change history was moved to [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC-
Appendix B !!! CMP-Alg" in ASN.1 Syntax needs to be replaced with the RFC numbers of
CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
[RFC Editor: please delete]: The labels 'RFC-CMP-Updates', 'RFC-CMP- [I-D.ietf-lamps-cmp-algorithms], when available.
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- This document specifies PKI management operations supporting machine-
to-machine and IoT use cases. The focus lies on maximum automation to-machine and IoT use cases. Its focus is to maximize automation
and interoperable implementation of all involved PKI entities from and interoperability between all involved PKI entities, ranging from
end entities (EE) through an optional Local Registration Authority end entities (EE) over any number of intermediate PKI management
(LRA) and the RA up to the CA. The profile makes use of the concepts entities such as Registration Authorities (RA) to the CMP endpoints
and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer of Certification Authority (CA) systems. This profile makes use of
for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. the concepts and syntax specified in CMP [RFC4210], CRMF [RFC4211],
Especially CMP and CRMF are very feature-rich standards, while in CMS [RFC5652], HTTP transfer for CMP [RFC6712], CoAP transfer for CMP
most environments only a limited subset of the specified [I-D.ietf-ace-cmpv2-coap-transport], CRMF Algorithm Requirements
functionality is needed. Additionally, the standards are not always Update [RFC9045], CMP Updates [I-D.ietf-lamps-cmp-updates], and CMP
precise enough on how to interpret and implement the described Algorithms [I-D.ietf-lamps-cmp-algorithms]. Especially CMP, CRMF,
concepts. Therefore, this document aims at tailoring and specifying and CMS are very feature-rich standards, while in most application
in more detail how to use these concepts to implement lightweight scenarios only a limited subset of the specified functionality is
automated certificate management. needed. Additionally, the standards are not always precise enough on
how to interpret and implement the described concepts. Therefore,
this document aims at tailoring the available options and specifying
at an adequate detail how to use them to make the implementation of
interoperable automated certificate management as straightforward and
lightweight as possible.
1.1. Motivation for profiling CMP 1.1. How to Read This Document
This document has become longer than the authors would have liked it
to be. Yet apart from studying Section 3, which contains general
requirements, the reader does not have to work through the whole
document but can use the guidance in Section 1.7, Section 2.2, and
Section 2.3 to figure out which parts of Section 4 to Section 6 are
relevant, depending on the PKI management operations and options of
interest.
1.2. Motivation for a lightweight profile of CMP
CMP was standardized in 1999 and is implemented in several PKI CMP was standardized in 1999 and is implemented in several PKI
products. In 2005 a completely reworked and enhanced version 2 of products. In 2005, a completely reworked and enhanced version 2 of
CMP [RFC4210] and CRMF [RFC4211] has been published followed by a CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a
document specifying a transfer mechanism for CMP messages using HTTP document specifying a transfer mechanism for CMP messages using HTTP
[RFC6712] in 2012. [RFC6712] in 2012.
Though CMP is a very solid and capable protocol it is so far not used Though CMP is a solid and very capable protocol it is so far not used
very widely. The most important reason appears to be that the very widely. The most important reason appears to be that the
protocol offers a too large set of features and options. On the one 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, 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 but on the other hand, a full implementation supporting all options
realistic because this would take undue effort. is not realistic because this would take undue effort.
Moreover, many details of the CMP protocol have been left open or Moreover, many details of the CMP protocol have been left open or
have not been specified in full preciseness. The profiles specified have not been specified in full preciseness. The profiles specified
in Appendix D and E of [RFC4210] define some more detailed PKI in Appendix D and E of [RFC4210] define some more detailed PKI
management operations. Yet the specific needs of highly automated management operations. Yet the specific needs of highly automated
scenarios for a machine-to-machine communication are not covered scenarios for a machine-to-machine communication are not covered
sufficiently. sufficiently.
As also 3GPP and UNISIG already put across, profiling is a way of As also 3GPP and UNISIG already put across, profiling is a way of
coping with the challenges mentioned above. To profile means to take coping with the challenges mentioned above. To profile means to take
advantage of the strengths of the given protocol, while explicitly advantage of the strengths of the given protocol, while explicitly
narrowing down the options it provides to those needed for the narrowing down the options it provides to those needed for the
purpose(s) at hand and eliminating all identified ambiguities. In purpose(s) at hand and eliminating all identified ambiguities. In
this way all the general and applicable aspects of the general this way all the general and applicable aspects of the general
protocol are taken over and only the peculiarities of the target protocol are taken over and only the peculiarities of the target
scenario need to be dealt with specifically. scenarios need to be dealt with specifically.
Defining such a profile for a new target environment take a high Defining a profile for a new target environment takes high effort
effort because the range of available options needs to be well because the range of available options needs to be well understood
understood and the selected options need to be consistent with each and the selected options need to be consistent with each other and
other and with the intended usage scenario. Since most industrial suitably cover the intended application scenario. Since most
PKI management use cases typically have much in common it is worth industrial PKI management use cases typically have much in common it
sharing this effort, which is the aim of this document. Other is worth sharing this effort, which is the aim of this document.
standardization bodies can reference this document and do not need to Other standardization bodies can reference this document and do not
come up with individual profiles. need to come up with individual profiles from scratch.
1.2. Motivation for a lightweight profile for CMP 1.3. Special requirements of industrial and IoT scenarios
The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have
been developed particularly for managing certificates of human end been developed particularly for managing certificates of human end
entities. With the evolution of distributed systems and client- entities. With the evolution of distributed systems and client-
server architectures, certificates for machines and applications on server architectures, certificates for machines and applications on
them have become widely used. This trend has strengthened even more them have become widely used. This trend has strengthened even more
in emerging industrial and IoT scenarios. CMP is sufficiently in emerging industrial and IoT scenarios. CMP is sufficiently
flexible to support them well. flexible to support them well.
Today's IT security architectures for industrial solutions typically Today's IT security architectures for industrial solutions typically
use certificates for endpoint authentication within protocols like use certificates for endpoint authentication within protocols like
IPSec, TLS, or SSH. Therefore, the security of these architectures IPSec, TLS, or SSH. Therefore, the security of these architectures
highly relies upon the security and availability of the implemented highly relies upon the security and availability of the implemented
certificate management procedures. certificate management operations.
Due to increasing security needs in operational networks as well as Due to increasing security needs in operational networks as well as
availability requirements, especially on critical infrastructures and availability requirements, especially on critical infrastructures and
systems with a high volume of certificates, a state-of-the-art systems with a high number of certificates, a state-of-the-art
certificate management must be constantly available and cost- certificate management system must be constantly available and cost-
efficient, which calls for high automation and reliability. The NIST efficient, which calls for high automation and reliability.
Framework for Improving Critical Infrastructure Cybersecurity Consequently, the NIST Framework for Improving Critical
[NIST.CSWP.04162018] also refers to proper processes for issuance, Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper
management, verification, revocation, and audit for authorized processes for issuance, management, verification, revocation, and
devices, users and processes involving identity and credential audit for authorized devices, users, and processes involving identity
management. Such PKI operation according to commonly accepted best and credential management. Such PKI management operations according
practices is also required in IEC 62443-3-3 [IEC.62443-3-3] for to commonly accepted best practices are also required in
security level 2 and higher. IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher.
Further challenges in many industrial systems are network Further challenges in many industrial systems are network
segmentation and asynchronous communication, while PKI operation segmentation and asynchronous communication, while PKI management
typically is not deployed on-site but in a more protected environment entities like Certification Authorities (CA) typically are not
of a data center or trust center. Certificate management must be deployed on-site but in a more protected environment of a data center
able to cope with such network architectures. CMP offers the or trust center. Certificate management must be able to cope with
required flexibility and functionality, namely self-contained such network architectures. CMP offers the required flexibility and
messages, efficient polling, and support for asynchronous message functionality, namely self-contained messages, efficient polling, and
transfer while retaining end-to-end security. support for asynchronous message transfer while retaining end-to-end
security.
1.3. Existing CMP profiles 1.4. Existing CMP profiles
As already stated, RFC 4210 [RFC4210] contains profiles with As already stated, RFC 4210 [RFC4210] contains profiles with
mandatory and optional PKI management operations in Appendix D and E. mandatory and optional PKI management operations in Appendix D and E.
Those profiles focus on management of human user certificates and do Those profiles focus on management of human user certificates and
only partly address the specific needs for certificate management only partly address the specific needs of certificate management
automation for unattended machines or application-oriented end automation for unattended devices or machine-to-machine application
entities. scenarios.
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 Both Appendixes D and E focus on EE-to-RA/CA PKI management
management operations. All requirements regarding algorithm support operations and do not address further profiling of RA-to-CA
have been updated by CMP Algorithms Section 7.2 communication as typically needed for full backend automation. All
requirements regarding algorithm support for RFC 4210 Appendix D and
E [RFC4210] have been updated by CMP Algorithms Section 7.1
[I-D.ietf-lamps-cmp-algorithms]. [I-D.ietf-lamps-cmp-algorithms].
* 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 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310
[ETSI-3GPP.33.310] for automatic management of IPSec certificates in [ETSI-3GPP.33.310] for automatic management of IPSec certificates in
3G, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP
profile for initial certificate enrollment and certificate update profile for initial certificate enrollment and certificate update
operations between EE and RA/CA is specified in that document. operations between EE and RA/CA is specified in that document.
UNISIG has included a CMP profile for certificate enrollment in the UNISIG has included a CMP profile for enrollment of TLS certificates
subset 137 specifying the ETRAM/ECTS on-line key management for train in the Subset-137 specifying the ETRAM/ETCS on-line key management
control systems [UNISIG.Subset-137] in 2015. for train control systems [UNISIG.Subset-137] in 2015.
Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and
HTTP transfer for CMP [RFC6712] to add tailored means for automated HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI
PKI management operations for unattended devices and services. management operations for unattended devices and services.
1.4. Compatibility with existing CMP profiles 1.5. Compatibility with existing CMP profiles
The profile specified in this document is compatible with RFC 4210 The profile specified in this document is compatible with RFC 4210
Appendixes D and E (PKI Management Message Profiles) [RFC4210], with Appendixes D and E (PKI Management Message Profiles) [RFC4210], with
the following exceptions: the following exceptions:
* signature-based protection is the default protection; an initial * signature-based protection is the default protection; an initial
PKI management operation may also use MAC-based protection, PKI management operation may also use MAC-based protection,
* certification of a second key pair within the same PKI management * certification of a second key pair within the same PKI management
operation is not supported, operation is not supported,
* proof-of-possession (POPO) with self-signature of the certTemplate * proof-of-possession (POPO) with self-signature of the certTemplate
according to RFC 4210 Section 4.1 [RFC4210] clause 3 is the according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the
recommended default POPO method (deviations are possible for EEs recommended default POPO method (deviations are possible for EEs
when requesting central key generation, for (L)RAs when using when requesting central key generation, for RAs when using
raVerified, and if the newly generated keypair is technically not raVerified, and if the newly generated keypair is technically not
capable to generate digital signatures), capable to generate digital signatures),
* confirmation of newly enrolled certificates may be omitted, and * confirmation of newly enrolled certificates may be omitted, and
* all PKI management operations consist of request-response message * all PKI management operations consist of request-response message
pairs originating at the EE, i.e., announcement messages pairs originating at the EE, i.e., announcement messages
(requiring the push model) are omitted. (requiring the push model, a CMP server on the EE) are excluded in
favor of a lightweight implementation on the EE.
The profile specified in this document is compatible with the CMP The profile specified in this document is compatible with the CMP
profile for 3G, LTE, and 5G network domain security and profile for 3G, LTE, and 5G network domain security and
authentication framework [ETSI-3GPP.33.310], except that: authentication framework [ETSI-3GPP.33.310], except that:
* protection of initial PKI management operations may be MAC-based, * protection of initial PKI management operations may be MAC-based,
* the subject field is mandatory in certificate templates, and * the subject field is mandatory in certificate templates, and
* confirmation of newly enrolled certificates may be omitted. * confirmation of newly enrolled certificates may be omitted.
The profile specified in this document is compatible with the CMP The profile specified in this document is compatible with the CMP
profile for on-line key management in rail networks as specified in profile for on-line key management in rail networks as specified in
UNISIG Subset-137 [UNISIG.Subset-137], except that: UNISIG Subset-137 [UNISIG.Subset-137], except that:
* A certificate enrollment request message consists of only one * A certificate enrollment request message consists of only one
certificate request (CertReqMsg). As UNISIG Subset-137 Table 6 certificate request (CertReqMsg).
[UNISIG.Subset-137] allows to transport more than one certificate
request message, this conflicts with this document.
* As of RFC 4210 [RFC4210] the messageTime is required to be * RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean
Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137 Time coded as generalizedTime.
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 Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly
states that the messageTime in required to be "UTC time", it is
not clear if this means a coding as UTCTime or generalizedTime and
if other time zones than Greenwich Mean Time shall be allowed.
Both time formats are described in RFC 5280 Section 4.1.2.5
[RFC5280].
* The same type of protection is required to be used for all
messages of one PKI management operation. This means, in case the messages of one PKI management operation. This means, in case the
request message is MAC protected, also the response, certConf, and request message protection is MAC-based, also the response,
pkiConf messages have a MAC-based protection. As UNISIG certConf, and pkiConf messages must have a MAC-based protection.
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 * Use of caPubs is not required but typically allowed in combination
with MAC-based protected PKI management operations. On the other with MAC-based protected PKI management operations. On the other
hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using
caPubs. Note that in case the protection of the response is caPubs.
changed to signature-based protection using a certificate issued
under the root CA that is to be transported in the caPubs field, Note: In case of UNISIG Subset-137 the response to a MAC-protected
this is not a secure delivery of the root CA certificate. request shall be signature-based. The signature-based protection
uses a certificate issued under the same 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 * This profile requires that the certConf message has one CertStatus
element where the statusInfo field is recommended. In contrast, element where the statusInfo field is recommended.
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 Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137]
requires that the certConf message has one CertStatus element
where the statusInfo field must be absent. This precludes sending
a negative certConf message in case the EE rejects the newly
enrolled certificate. This results in violating the general rule
that a certificate request transaction must include a certConf
message (since moreover, using implicitConfirm is not allowed
there, neither).
This document specifies requirements on generating PKI management 1.6. Scope of this document
messages on the sender side. It does not specify strictness of
verification on the receiving side and how in detail to handle error To minimize ambiguity and complexity through needless variety, this
cases. document specifies exhaustive requirements on generating PKI
management messages on the sender side. On the other hand, it gives
only minimal requirements on checks by the receiving side and how to
handle error cases.
Especially on the EE side this profile aims at a lightweight Especially on the EE side this profile aims at a lightweight
implementation. This means that the number of PKI management implementation. This means that the number of PKI management
operations that implementations must support are reduced to a operations implementations are reduced to a reasonable minimum to
reasonable minimum to support most typical certificate management use support typical certificate management use cases in industrial
cases in industrial machine-to-machine environments. On the EE side machine-to-machine environments. On the EE side only limited
only limited resources are expected, while on the side of the PKI resources are expected, while on the side of the PKI management
management entities the profile accepts higher resources needed. entities the profile accepts higher requirements.
For the sake of robustness and preservation of security properties For the sake of interoperability and robustness, implementations
implementations should, as far as security is not affected, adhere to should, as far as security is not affected, adhere to Postel's law:
Postel's law: "Be conservative in what you do, be liberal in what you "Be conservative in what you do, be liberal in what you accept from
accept from others" (often reworded as: "Be conservative in what you others" (often reworded as: "Be conservative in what you send, be
send, be liberal in what you accept"). liberal in what you receive").
When in Section 3, Section 4, and Section 5 a field of the ASN.1 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 syntax as defined in CMP [RFC4210], CRMF [RFC4211], CMS [RFC5652],
explicitly specified, it SHOULD not be used by the sending entity. and CMP Updates [I-D.ietf-lamps-cmp-updates] is not explicitly
The receiving entity MUST NOT require its absence and if present MUST 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. gracefully handle its presence.
1.6. Structure of this document 1.7. Structure of this document
Section 2 introduces the general PKI architecture and approach to Section 2 introduces the general PKI architecture and approach to
certificate management using CMP that is assumed in this document. certificate management that is assumed in this document. Then it
Then it enlists the PKI management operations specified in this lists the PKI management operations specified in this document,
document and describes them in general words. The list of supported partitioning them into mandatory, recommended, and optional ones.
PKI management operations is divided into mandatory, recommended, and
optional ones.
Section 3 profiles the CMP message header, protection, and extraCerts Section 3 profiles the generic aspects of the PKI management
fields as they are general elements of CMP messages. operations specified in detail in Section 4 and Section 5 to minimize
redundancy in the description and to ease implementation. This
covers the general structure and protection of messages, as well as
generic prerequisites, validation, and error handling.
Section 4 profiles the exchange of CMP messages between an EE and the Section 4 profiles the exchange of CMP messages between an EE and the
first PKI management entity. There are various flavors of PKI management entity. There are various flavors of certificate
certificate enrollment requests, optionally with polling, revocation, enrollment requests, optionally with polling, central key generation,
error handling, and general support PKI management operations. revocation, and general support PKI management operations.
Section 5 profiles the message exchange between PKI management Section 5 profiles responding to requests, exchange between PKI
entities. In the first place this consists of forwarding messages management entities, and operations on behalf of other PKI entities.
coming from or going to an EE. This may include delayed delivery of This may include delayed delivery of messages, which involves polling
messages, which involves polling for certificate responses. for certificate responses, and nesting of messages.
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, Section 6 outlines several mechanisms for CMP message transfer,
namely HTTP-based transfer as already specified in RFC 6712 including HTTP-based transfer as already specified in RFC 6712
[RFC6712], using an additional TLS layer, or offline file-based [RFC6712] optionally using TLS, and offline file-based transport.
transport. CoAP [RFC7252] and piggybacking CMP messages CoAP-based transport as specified in
[I-D.ietf-ace-cmpv2-coap-transport] and piggybacking CMP messages are
also briefly addressed.
1.7. Convention and Terminology 1.8. Convention and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC8174] when, and only when, they appear in all capitals, as shown 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. capitals, as shown here.
Technical terminology is used in conformance with RFC 4210 [RFC4210], Technical terminology is used in conformance with RFC 4210 [RFC4210],
RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR
[IEEE.802.1AR_2018]. The following key words are used: [IEEE.802.1AR_2018]. The following key words are used:
CA: Certification authority, which issues certificates. CA: Certification authority, which issues certificates.
RA: Registration authority, an optional PKI component to which a CA RA: Registration authority, an optional PKI component to which a CA
delegates certificate management functions such as delegates certificate management functions such as end entity
authorization checks. authentication and authorization checks for incoming requests.
An RA can also provide conversion between various certificate
management protocols and other protocols providing some
operations related to certificate management.
LRA: Local registration authority, an optional RA system component LRA: Local registration authority, a specific form of RA with
with proximity to the end entities. proximity to the end entities.
Note: For ease of reading, this document uses the term "RA"
also for LRAs in all cases where the difference is not
relevant.
KGA: Key generation authority, an optional system component, KGA: Key generation authority, an optional system component,
typically co-located with an LRA, RA, or CA, that offers key typically co-located with an RA or CA, that offers key
generation services to end entities. generation services to end entities.
EE: End entity, a user, device, or service that holds public- EE: End entity, typically a device or service that holds public-
private key pair for which it manages a public-key certificate. private key pair for which it manages a public-key certificate.
An identifier for the EE is given as the subject of its An identifier for the EE is given as the subject of its
certificate. certificate.
The following terminology is reused from RFC 4210 [RFC4210] and used The following terminology is reused from RFC 4210 [RFC4210], as
as follows: follows:
PKI management operation: All CMP messages belonging to one PKI management operation: All CMP messages belonging to a single
transaction context. The transaction is transaction. The transaction is
identified in the transactionID field of identified by the transactionID field of
the message header. the message headers.
PKI management entity: All non-EE PKI entities such as LRA, RA, PKI management entity: A non-EE PKI entity, i.e., RA or CA.
and CA.
PKI entity: EEs and PKI management entities PKI entity: An EE or PKI management entity.
2. Architecture and use cases 2. Architecture and use cases
2.1. Solution architecture 2.1. Solution architecture
In order to facilitate secure automatic certificate enrollment if the To facilitate secure automatic certificate enrollment, the device
device hosting an EE is equipped with a manufacturer issued hosting an EE is typically equipped with a manufacturer-issued device
certificate during production. Such a manufacturer issued certificate. Such a certificate is typically installed during
certificate is installed during production to identify the device production and is meant to identify the device throughout its
throughout its lifetime. This manufacturer certificate can be used lifetime. This certificate can be used to protect the initial
to protect the initial enrollment of operational certificates after enrollment of operational certificates after installation of the EE
installation of the EE on site in its operational environment. An in its operational environment. In contrast to the manufacturer-
operational certificate is issued by the owner or operator of the issued device certificate, operational certificates are issued by the
device to identify the device during operation for use, e.g., in a owner or operator of the device to identify the device or one of its
security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR components for operational use, e.g., in a security protocol like
[IEEE.802.1AR_2018] a manufacturer certificate is called IDevID IPSec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a
certificate and an operational certificate is called LDevID manufacturer-issued device certificate is called IDevID certificate
certificate. and an operational certificate is called LDevID certificate.
Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises
the triplet of the certificate and the corresponding private key as the triple of the certificate, the corresponding private key, and the
well as certificate chain up to the root certificate. certificate chain.
All certificate management transactions specified in this document All certificate management operations specified in this document
are initiated by the EE. The EE creates a CMP request message, follow the pull model, i.e., are initiated by an EE (or by an RA
protects it using some asymmetric credential or shared secret acting as an EE). The EE creates a CMP request message, protects it
information, as far as available, and sends it to its locally using some asymmetric credential or shared secret information and
reachable PKI component. This PKI component may be an LRA, RA, or sends it to its locally reachable PKI management entity. This PKI
the CA, which checks the request, responds to it itself, or forwards management entity may be a CA or more typically an RA, which checks
the request upstream to the next PKI component. In case an (L)RA the request, responds to it itself, or forwards the request upstream
changes the CMP request message header or body or wants to prove a to the next PKI management entity. In case an RA changes the CMP
successful verification or authorization, it can apply a protection request message header or body or wants to demonstrate successful
of its own. Especially the communication between an LRA and RA can verification or authorization, it can apply a protection of its own.
be performed synchronously or asynchronously. Synchronous Especially the communication between an LRA and RA can be performed
communication describes a timely uninterrupted communication between synchronously or asynchronously. Synchronous communication describes
two communication partners, while asynchronous communication is not a timely uninterrupted communication between two communication
performed in a timely consistent manner, e.g., because of a delayed partners, while asynchronous communication is not performed in a
message delivery. timely consistent manner, e.g., because of a delayed message
delivery.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| EE |<---------->| LRA |<-------------->| RA |<---------->| CA | | EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
| | | | | | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
synchronous (a)synchronous (a)synchronous synchronous (a)synchronous (a)synchronous
+----connection----+------connection------+----connection----+ +----connection----+------connection------+----connection----+
on site at operators service partner operators service partner
+----------plant---------+-----backend services-----+-trust center-+ +---------on site--------+----back-end services-----+-trust center-+
Figure 1: Certificate management on site
In operation environments a layered LRA-RA-CA architecture can be Figure 1: Certificate management architecture example
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 In operational environments the certificate management architecture
always requests a specific PKI management operation. can have multiple LRAs bundling requests from multiple EEs at
dedicated locations and one (or more than one) central RA aggregating
the requests from the LRAs. Every LRA in this scenario has shared
secret information (one per EE) for MAC-based protection or a CMP
protection key and certificate allowing it to (re-)protect CMP
messages it processes. The figure above shows an architecture
example with at least one LRA, RA, and CA. It is also possible not
to have an RA or LRA or that there is no CA with a CMP interface.
Depending on the network infrastructure, the message transfer between
PKI management entities may be based on synchronous online
connections, delayed asynchronous connections, or even offline (e.g.,
file-based) transfer.
Note: CMP response messages, especially in case of central key Note: CMP response messages could also be used proactively to
generation, as described in Section 4.1.6, could also be used implement the push model towards the EE. In this case the EE acts as
proactively to implement the push model towards the EE. receiver, not initiating the interaction with the PKI. Also, when
using a commissioning tool or a registrar agent as described in:
Support of asynchronous Enrollment in Bootstrapping Remote Secure Key
Infrastructures (BRSKI) [I-D.ietf-anima-brski-async-enroll],
certificate enrollment in a push model is needed. CMP in general and
the messages specified in this profile offer all required
capabilities, but the message flow and state machine as described in
Section 4 must be adapted to implement a push model.
Third-party CAs typically implement other variants of CMP, different Third-party CAs may implement other variants of CMP, different
standardized protocols, or even proprietary interfaces for standardized protocols, or even proprietary interfaces for
certificate management. Therefore, the LRA or the RA may need to certificate management. Therefore, the RA may need to adapt the
adapt the exchanged CMP messages to the flavor of certificate exchanged CMP messages to the flavor of certificate management
management interaction required by the CA. 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 2.2. Supported PKI management operations
Following the scope outlined in Section 1.5, this section gives a Following the scope outlined in Section 1.6, this section gives a
brief overview of the PKI management operations specified in brief overview of the PKI management operations specified in
Section 4 and Section 5 and states whether implementation by Section 4 and Section 5 and states whether implementation by
compliant EE or PKI management entities is mandatory, recommended, or compliant EEs or PKI management entities is mandatory, recommended,
optional. or optional.
2.3.1. Mandatory PKI management operations 2.2.1. Mandatory PKI management operations
The mandatory PKI management operations in this document limit the The set of mandatory PKI management operations in this document is
overhead of certificate management. This minimal set of operations intentionally lean to help for keeping development effort low and to
may be helpful for keeping development effort low and for use in enable use in memory-constrained devices.
memory-constrained devices.
+=======================================+=========+ +=====================================+=========+
| PKI management operations | Section | | PKI management operations | Section |
+=======================================+=========+ +=====================================+=========+
| Request a certificate from a new PKI | Section | | Requesting a certificate from a new | Section |
| with signature protection | 4.1.1 | | PKI with signature-based protection | 4.1.1 |
+---------------------------------------+---------+ +-------------------------------------+---------+
| Request to update an existing | Section | | Updating an existing certificate | Section |
| certificate with signature protection | 4.1.3 | | with signature-based protection | 4.1.3 |
+---------------------------------------+---------+ +-------------------------------------+---------+
| Error reporting | Section |
| | 4.3 |
+---------------------------------------+---------+
Table 1: Mandatory End Entity PKI management Table 1: Mandatory End Entity PKI management
operations operations
+===============================================+===============+ +===============================================+=================+
| PKI management operations | Section | | PKI management operations | Section |
+===============================================+===============+ +===============================================+=================+
| Forward messages without changes | Section 5.1.1 | | Responding to a certificate request | Section 5.1 |
+-----------------------------------------------+---------------+ +-----------------------------------------------+-----------------+
| Forward messages with replaced protection and | Section | | Responding to a confirmation message | Section 5.1.3 |
| keeping the original proof-of-possession | 5.1.2.1 | +-----------------------------------------------+-----------------+
+-----------------------------------------------+---------------+ | Forwarding messages - not changing protection | Section 5.2.1 |
| Forward messages with replaced protection and | Section | +-----------------------------------------------+-----------------+
| setting raVerified as proof-of-possession | 5.1.2.2 | | Adding protection to a request message | Section 5.2.2.1 |
+-----------------------------------------------+---------------+ +-----------------------------------------------+-----------------+
| Error reporting | Section 5.3 |
+-----------------------------------------------+---------------+
Table 2: Mandatory LRA and RA PKI management operations Table 2: Mandatory PKI management entity operations
2.3.2. Recommended PKI management operations 2.2.2. Recommended PKI management operations
Additional recommended PKI management operations shall support some Additional recommended PKI management operations support some more
more complex scenarios, that are considered beneficial for complex scenarios, that are considered beneficial for environments
environments with more specific boundary conditions. with more specific demand or boundary conditions.
+======================================================+=========+ +=================================+=========+
| PKI management operations | Section | | PKI management operations | Section |
+======================================================+=========+ +=================================+=========+
| Request a certificate from a PKI with MAC protection | Section | | Requesting a certificate from a | Section |
| | 4.1.4 | | PKI with MAC-based protection | 4.1.4 |
+------------------------------------------------------+---------+ +---------------------------------+---------+
| Revoke a certificate of its own | Section | | Revoking a certificate | Section |
| | 4.2 | | | 4.2 |
+------------------------------------------------------+---------+ +---------------------------------+---------+
Table 3: Recommended End Entity PKI management operations Table 3: Recommended End Entity PKI
management operations
+========================================+=============+ +====================================+===============+
| PKI management operations | Section | | PKI management operations | Section |
+========================================+=============+ +====================================+===============+
| Revoke a certificate of another entity | Section 5.2 | | Responding to a revocation request | Section 5.1.4 |
+----------------------------------------+-------------+ +------------------------------------+---------------+
| Acting on behalf of other PKI | Section 5.3.2 |
| entities - revoking a certificate | |
+------------------------------------+---------------+
Table 4: Recommended LRA and RA PKI management Table 4: Recommended PKI management entity operations
operations
2.3.3. Optional PKI management operations 2.2.3. Optional PKI management operations
The optional PKI management operations support specific requirements The optional PKI management operations support specific scenarios
seen only in some environments with special requirements. seen only in some environments with special requirements.
+========================================================+=========+ +========================================================+=========+
| PKI management operations | Section | | PKI management operations | Section |
+========================================================+=========+ +========================================================+=========+
| Request a certificate from a trusted PKI with | Section | | Requesting an additional certificate with signature- | Section |
| signature protection | 4.1.2 | | based protection | 4.1.2 |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Request a certificate from a legacy PKI using a | Section | | Requesting a certificate from a legacy PKI using a | Section |
| PKCS#10 [RFC2986] request | 4.1.5 | | PKCS#10 request | 4.1.5 |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Add central generation of a key pair to a certificate | Section | | Adding central key generation to a certificate | Section |
| request. (If central key generation is supported, the | 4.1.6 | | request. (If central key generation is supported, the | 4.1.6 |
| key agreement key management technique is REQUIRED to | | | key agreement key management technique is REQUIRED to | |
| be supported, and the key transport and password-based | | | be supported, and the key transport and password-based | |
| key management techniques are OPTIONAL.) | | | key management techniques are OPTIONAL.) | |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Handle delayed enrollment due to asynchronous or | Section | | Handling delayed enrollment | Section |
| offline message delivery | 4.1.7 | | | 4.1.7 |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Additional support messages - distribution of CA | Section | | Support messages - get CA certificates, get a trust | Section |
| certificates, update of a root CA certificate and | 4.4 | | anchor updates, e.g., root CA certificate updates, and | 4.3 |
| provisioning of certificate request template | | | get a certificate request template | |
+--------------------------------------------------------+---------+
| Acting on behalf of other PKI entities - requesting | Section |
| certificates | 5.3.1 |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
Table 5: Optional End Entity PKI management operations Table 5: Optional End Entity PKI management operations
+=============================================+===============+ +===============================================+=========+
| PKI management operations | Section | | PKI management operations | Section |
+=============================================+===============+ +===============================================+=========+
| Forward messages with additional protection | Section 5.1.3 | | Forwarding messages - replacing protection, | Section |
+---------------------------------------------+---------------+ | not changing any included proof-of-possession | 5.2.3.1 |
| Initiate delayed enrollment due to | Section 5.1.4 | +-----------------------------------------------+---------+
| asynchronous or offline message delivery | | | Forwarding messages - replacing protection, | Section |
+---------------------------------------------+---------------+ | breaking proof-of-possession | 5.2.3.2 |
+-----------------------------------------------+---------+
| Batching messages | Section |
| | 5.2.2.2 |
+-----------------------------------------------+---------+
| Initiating delayed enrollment | Section |
| | 5.1.2 |
+-----------------------------------------------+---------+
Table 6: Optional LRA and RA PKI management operations Table 6: Optional PKI management entity operations
2.4. CMP message transport 2.3. CMP message transport
On different links between PKI entities, e.g., EE-RA and RA-CA, 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 different transport MAY be used. As CMP does not have specific needs
regarding message transport, virtually any reliable transport regarding message transport, virtually any reliable transport
mechanism may be used, e.g., HTTP, CoAP, and offline file-based mechanism can be used, e.g., HTTP, CoAP, and offline file-based
transport. Therefore, this document does not require any specific transport. Therefore, this document does not require any specific
transport protocol to be supported by conforming implementations. transport protocol to be supported by conforming implementations.
HTTP transfer is RECOMMENDED to use for all PKI entities, yet full HTTP transfer is RECOMMENDED to use for all PKI entities, yet full
flexibility is retained to choose whatever transport is suitable, for flexibility is retained to choose whatever transport is suitable, for
instance for devices with special constraints. instance for devices and system architectures with special
constraints.
+==================================+=============+ +================+=============+
| Transport | Section | | Transport | Section |
+==================================+=============+ +================+=============+
| Transfer CMP messages using HTTP | Section 6.1 | | HTTP transport | Section 6.1 |
+----------------------------------+-------------+ +----------------+-------------+
Table 7: Recommended transport mechanisms Table 7: Recommended
transport mechanisms
+========================================+=========+ +==========================================+=============+
| Transport | Section | | Transport | Section |
+========================================+=========+ +==========================================+=============+
| Transfer CMP messages using HTTPS with | Section | | Offline transport | Section 6.4 |
| certificate-based authentication | 6.2 | +------------------------------------------+-------------+
+----------------------------------------+---------+ | CoAP transport | Section 6.2 |
| Transfer CMP messages using HTTPS with | Section | +------------------------------------------+-------------+
| shared secret-based authentication | 6.3 | | Piggybacking on other reliable transport | Section 6.3 |
+----------------------------------------+---------+ +------------------------------------------+-------------+
| Offline CMP message transport | Section |
| | 6.4 |
+----------------------------------------+---------+
| Transfer CMP messages using CoAP | Section |
| | 6.5 |
+----------------------------------------+---------+
Table 8: Optional transport mechanisms Table 8: Optional transport mechanisms
3. Generic parts of the PKI message 3. Generic aspects of the PKI message
The generic parts of the CMP message profiles specified in Section 4 This section covers the generic aspects of the PKI management
and Section 5 are standardized to the maximum extent possible and are operations specified in Section 4 and Section 5 as upfront general
described centrally in this section to reduce redundancy in the requirements to minimize redundancy in the description and to ease
description and to ease implementation. implementation.
As described in section 5.1 of [RFC4210], all CMP messages have the As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages
following general structure: have the following general structure:
+--------------------------------------------+ +--------------------------------------------+
| PKIMessage | | PKIMessage |
| +----------------------------------------+ | | +----------------------------------------+ |
| | header | | | | header | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | body | | | | body | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | protection (OPTIONAL) | | | | protection (OPTIONAL) | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | extraCerts (OPTIONAL) | | | | extraCerts (OPTIONAL) | |
| +----------------------------------------+ | | +----------------------------------------+ |
+--------------------------------------------+ +--------------------------------------------+
Figure 2: CMP message structure Figure 2: CMP message structure
The general contents of the message header, protection, and The general contents of the message header, protection, and
extraCerts fields are specified in the following subsections. extraCerts fields are specified in the following three subsections.
In case a specific CMP message profile needs different contents in In case a specific PKI management operation needs different contents
the header, protection, or extraCerts fields, the differences are in the header, protection, or extraCerts fields, the differences are
described in the respective message profile. described in the respective subsections.
The CMP message body contains the message-specific information. It The CMP message body contains the PKI management operation-specific
is described as part Section 4 and Section 5. information. It is described in Section 4 and Section 5.
The behavior in case an error occurs while handling the generic parts The generic prerequisites needed by the PKI entities in order to be
of a CMP message is described in Section 5.3. able to perform PKI management operations are described in
Section 3.4.
The generic validation steps to be performed by PKI entities on
receiving a CMP message are described in Section 3.5.
The generic aspects of handling and reporting errors are described in
Section 3.6.
3.1. General description of the CMP message header 3.1. General description of the CMP message header
This section describes the generic header field of all CMP messages This section describes the generic header fields of all CMP messages
with signature-based protection. The only variations described here with signature-based protection.
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 case a message has MAC-based protection the changes are described
in Section 4.1.4. The variations will affect the fields sender, in Section 4.1.4. The variations will affect the fields sender,
protectionAlg, and senderKID. protectionAlg, and senderKID.
For requirements regarding proper random number generation please Any PKI management operation-specific fields or variations are
refer to [RFC4086]. Any message-specific fields or variations are described in Section 4 and 5.
described in Section 4 and Section 5.
header header
pvno REQUIRED pvno REQUIRED
-- MUST be set to 3 to indicate CMP V3 in all cases where -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
-- EnvelopedData is supported and expected to be used in this PKI -- is supported and expected to be used in the current
-- management operation -- PKI management operation
-- MUST be set to 2 to indicate CMP V2 in all other cases -- MUST be 3 to indicate CMP v3 in certConf messages when using
-- the hashAlg field
-- MUST be 2 to indicate CMP v2 in all other cases
-- For details on version negotiation see RFC-CMP-Updates -- For details on version negotiation see RFC-CMP-Updates
sender REQUIRED sender REQUIRED
-- MUST contain a name representing the originator of the message -- SHOULD contain a name representing the originator of the
-- message; otherwise, the NULL-DN (a zero-length
-- SEQUENCE OF RelativeDistinguishedNames) MUST be used
-- SHOULD be the subject of the CMP protection certificate, i.e., -- SHOULD be the subject of the CMP protection certificate, i.e.,
-- the certificate for the private key used to sign the message -- the certificate for the private key used to sign the message
-- In a multi-hop scenario, the receiving entity SHOULD not rely
-- on the correctness of the sender field.
recipient REQUIRED recipient REQUIRED
-- SHOULD be the name of the intended recipient and -- SHOULD be the name of the intended recipient; otherwise, the
-- MAY be a NULL-DN, i.e., a zero-length SEQUENCE OF -- NULL-DN MUST be used
-- RelativeDistinguishedNames, if the sender does not know the -- In the first message of a PKI management operation:
-- DN of the recipient -- SHOULD be the subject DN of the CA the PKI management
-- If this is the first message of a transaction: SHOULD be the -- operation is requested from
-- subject of the issuing CA certificate -- In all other messages:
-- In all other messages: SHOULD be the same name as in the -- SHOULD contain the value of the sender field of the previous
-- sender field of the previous message in the same transaction -- message in the same PKI management operation
-- The recipient field SHALL be handled gracefully by the
-- receiving entity, because in a multi-hop scenario its
-- correctness cannot be guaranteed.
messageTime RECOMMENDED messageTime RECOMMENDED
-- MUST be the time at which the message was produced, if -- MUST be the time at which the message was produced, if present
-- present
protectionAlg REQUIRED protectionAlg REQUIRED
-- MUST be the algorithm OID of the algorithm used for -- MUST be an algorithm identifier indicating the algorithm
-- calculating the protection bits -- used for calculating the protection bits
-- The signature algorithm MUST be a MSG_SIG_ALG as specified in -- If it is a signature algorithm its type MUST be a
-- RFC-CMP-Alg Section 3 and MUST be consistent with the -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and
-- subjectPublicKeyInfo field of the protection certificate -- MUST be consistent with the subjectPublicKeyInfo field of
-- The MAC algorithm MUST be a MSG_MAC_ALG as specified in -- the protection certificate
-- RFC-CMP-Alg Section 6 -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as
algorithm REQUIRED -- specified in [RFC-CMP-Alg] Section 6.1
-- MUST be the OID of the signature or MAC algorithm
senderKID RECOMMENDED senderKID RECOMMENDED
-- MUST be the SubjectKeyIdentifier of the CMP protection -- MUST be the SubjectKeyIdentifier of the CMP protection
-- certificate or a reference of the shared secret information -- certificate
-- used for the protection
transactionID REQUIRED transactionID REQUIRED
-- If this is the first message of a transaction: -- In the first message of a PKI management operation:
-- MUST be 128 bits of random data for the start of a
-- transaction, to minimize the probability of having the -- MUST be 128 bits of random data, to minimize the probability
-- transactionID already in use at the server -- of having the transactionID already in use at the server
-- In all other messages: -- In all other messages:
-- MUST be the value from the previous message in the same -- MUST be the value from the previous message in the same
-- transaction -- PKI management operation
senderNonce REQUIRED senderNonce REQUIRED
-- MUST be cryptographically secure and fresh 128 random bits -- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED recipNonce RECOMMENDED
-- If this is the first message of a transaction: SHOULD be -- If this is the first message of a transaction: SHOULD be
-- absent -- absent
-- In all other messages: MUST be present and contain the value -- In all other messages: MUST be present and contain the value
-- of the senderNonce of the previous message in the same -- of the senderNonce of the previous message in the same
-- transaction -- transaction
generalInfo OPTIONAL generalInfo OPTIONAL
implicitConfirm OPTIONAL implicitConfirm OPTIONAL
-- The field is optional in ir/cr/kur/p10cr requests and -- The extension is optional in ir/cr/kur/p10cr requests and
-- ip/cp/kup response messages and PROHIBTED in other types of -- ip/cp/kup response messages and PROHIBTED in other types of
-- messages -- messages
-- Added to request messages to request omission of the certConf -- Added to request messages to request omission of the certConf
-- message -- message
-- See [RFC4210] Section 5.1.1.1.
-- Added to response messages to grant omission of the certConf -- Added to response messages to grant omission of the certConf
-- message -- message
ImplicitConfirmValue REQUIRED -- See [RFC4210] Section 5.1.1.1.
-- ImplicitConfirmValue of the request message MUST be NULL if ImplicitConfirmValue REQUIRED
-- the EE wants to request not to send a confirmation message -- ImplicitConfirmValue MUST be NULL
-- ImplicitConfirmValue MUST be NULL if the PKI management rootCaCert OPTIONAL
-- entity wants to grant not sending a confirmation message -- MAY be present in genm messages of type id-it-rootCaKeyUpdate
-- MUST be omitted in all other messages
-- See [RFC-CMP-Updates]
RootCaCertValue REQUIRED
-- contains the root CA certificate for which an update is
-- requested
certProfile OPTIONAL
-- MAY be present in ir/cr/kur/p10cr and in genm messages of type
-- id-it-certReqTemplate
-- MUST be omitted in all other messages
-- See [RFC-CMP-Updates]
CertProfileValue REQUIRED
-- MUST contain exactly one UTF8String element
-- MUST contain the name of a certificate profile
3.2. General description of the CMP message protection 3.2. General description of the CMP message protection
This section describes the generic protection field of all CMP This section describes the generic protection field contents of all
messages with signature-based protection. The certificate for the CMP messages with signature-based protection. The private key used
private key used to sign a CMP message is called 'protection to sign a CMP message is called "protection key" and the related
certificate'. Any included keyUsage extension SHOULD allow certificate is called "protection certificate". Any included
digitalSignature. keyUsage extension SHOULD allow digitalSignature.
protection RECOMMENDED protection RECOMMENDED
-- MUST contain the signature calculated using the private key -- MUST contain the signature calculated using the private key
-- of the entity protecting the message. The signature -- of the entity protecting the message. The signature
-- algorithm used MUST be given in the protectionAlg field. -- algorithm used MUST be given in the protectionAlg field.
Generally, CMP message protection is required for CMP messages, but Generally, CMP message protection is required for CMP messages, but
there are cases where protection of error messages as specified in there are cases where protection of error messages specified in
Section 4.3 and Section 5.3 is not possible and therefore MAY be Section 3.6 is not possible and therefore MAY be omitted.
omitted.
For MAC-based protection as specified in Section 4.1.4 major For MAC-based protection as specified in Section 4.1.4 major
differences apply as described in the respective section. differences apply as described there.
The CMP message protection provides, if available, message origin The CMP message protection provides, if available, message origin
authentication and integrity protection for the CMP message header authentication and integrity protection for the header and body. The
and body. The CMP message extraCerts field is not covered by this CMP message extraCerts field is not covered by this protection.
protection.
Note: The extended key usages specified in CMP Updates Note: The extended key usages described in CMP Updates
[I-D.ietf-lamps-cmp-updates] can be used for authorization of a [I-D.ietf-lamps-cmp-updates] can be used for authorization of a
sending PKI management entity. 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 3.3. General description of CMP message extraCerts
This section describes the generic extraCerts field of all CMP This section describes the generic extraCerts field of all CMP
messages with signature-based protection. If extraCerts are messages with signature-based protection. Any specific requirements
required, recommended, or optional is specified in the respective PKI on the extraCerts are specified in the respective PKI management
management operation. operation.
extraCerts extraCerts
-- SHOULD contain the CMP protection certificate together with -- SHOULD contain the CMP protection certificate together with
-- its chain, if needed and the self-signed root certificate -- its chain, if needed
-- SHOULD be omitted
-- If present, the first certificate in this field MUST be -- If present, the first certificate in this field MUST be
-- the CMP protection certificate and each followed by its chain -- the CMP protection certificate followed by its chain
-- where each element SHOULD directly certify the one -- where each element SHOULD directly certify the one
-- immediately preceding it. -- immediately preceding it.
-- Self-signed certificates SHOULD be omitted from extraCerts, -- Self-signed certificates SHOULD be omitted from extraCerts,
-- unless they are the same as the protection certificate and -- unless they are the same as the protection certificate and
-- MUST NOT be trusted based on their inclusion in any case -- MUST NOT be trusted based on their inclusion in any case
Note: For maximum compatibility, all implementations SHOULD be Note: For maximum compatibility, all implementations SHOULD be
prepared to handle potentially additional certificates and arbitrary prepared to handle potentially additional certificates and arbitrary
orderings of the certificates. orderings of the certificates.
3.4. Generic PKI management operation prerequisites
This subsection describes what is generally needed by the PKI
entities to be able to perform PKI management operations.
Identification of PKI entities:
* Each EE SHOULD know its own identity to fill the sender field.
* Each EE SHOULD know the intended recipient of its requests to fill
the recipient field, e.g., the name of the addressed CA.
Note: This name may be established using an enrollment voucher,
e.g., [RFC8366], the issuer field from a CertReqTemplate response
message content, or by other configuration means.
Routing of CMP messages:
* Each PKI entity sending messages upstream MUST know the address
needed for transporting messages to the next PKI management
entity.
Note: This address may depend on the recipient, the certificate
profile, and on the used transport mechanism.
Authentication of PKI entities:
* Each PKI entity MUST have credentials to authenticate itself. For
signature-based protection it MUST have a private key and the
corresponding certificate along with its chain.
* Each PKI entity MUST be able to establish trust in PKI it receives
responses from. When signature-based protection is used, it MUST
have the trust anchor(s) and any certificate status information
needed to perform path validation of CMP protection certificates
used for signature-based protection.
Note: A trust anchor usually is a root certificate of the PKI
addressed by the requesting EE. It may be established by
configuration or in an out-of-band manner. For an EE it may be
established using an enrollment voucher [RFC8366] or in-band of
CMP by the caPubs field in a certificate response message.
Authorization of PKI management operations:
* Each EE or RA MUST have sufficient information to be able to
authorize the PKI management entity for performing the upstream
PKI management operation.
Note: This may be achieved for example by using the cmcRA extended
key usage in server certificates, by local configuration such as
specific name patterns for subject DN or SAN portions that may
identify an RA, and/or by having a dedicated PKI Infrastructure
root CA usable only for authenticating PKI management entities.
* Each PKI management entity MUST have sufficient information to be
able to authorize the downstream PKI entity requesting the PKI
management operation.
Note: For authorizing an RA the same examples apply as above. The
authorization of EEs can be very specific to the application
domain and may involve information from configuration or inventory
database. It may involve, e.g., the issuer information of the EE
certificate, specific contents of the CMP protection certificate
used by the EE such as name patterns of subject DN or SAN
portions, shared secret information, and other types of
credentials and evidence potentially communicated out-of-band.
3.5. Generic validation of a PKI message
This section describes generic validation steps of each PKI entity
receiving a PKI request or response message before any further
processing or forwarding. If a PKI management entity decides to
terminate a PKI management operation because a check failed, it MUST
send a negative response or an error message as described in
Section 3.6. The PKIFailureInfo bits given below in parentheses MAY
be used in the failInfo field of the PKIStatusInfo as described in
Section 3.6.4, see also RFC 4210 Appendix F [RFC4210].
All PKI message header fields not mentioned in this section like the
recipient and generalInfo fields SHOULD be handled gracefully on
reception.
The following list describes the basic set of message input
validation steps. Without these checks the protocol becomes
dysfunctional.
* The formal ASN.1 syntax of the whole message MUST be compliant
with the definitions given in CMP [RFC4210], CRMF [RFC4211],
RFC 5652 [RFC5652], and CMP Updates [I-D.ietf-lamps-cmp-updates].
(failInfo: badDataFormat)
* The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit:
unsupportedVersion)
* The transactionID MUST be present. (failInfo bit: badDataFormat)
* The PKI message body type MUST be one of the message types
supported by the receiving PKI entity and MUST be allowed in the
current state of the PKI management operation identified by the
given transactionID. (failInfo bit: badRequest)
The following list describes the set of message input validation
steps required to ensure secure protocol operation:
* The senderNonce MUST be present and MUST contain at least 128 bits
of data. (failInfo bit: badSenderNonce)
* Unless the PKI message is the first message of a PKI management
operation,
- the recipNonce MUST be present and MUST equal the senderNonce
of the previous message. (failInfo bit: badRecipientNonce)
* The message protection MUST be validated:
- The protection MUST be signature-based except if MAC-based
protection is used as described in Section 4.1.4and for some
error messages as described in Section 3.6.4. (failInfo bit:
wrongIntegrity)
- The senderKID SHOULD identify the key material used for
verifying the message protection. (failInfo bit:
badMessageCheck)
- The protection, if present, MUST be validated successfully. If
signature-based protection is used, the CMP protection
certificate MUST be successfully validated including path
validation using a trust anchor and MUST be authorized
according to local policies. If the keyUsage extension is
present in the CMP protection certificate the digitalSignature
bit SHOULD be set. (failInfo bit: badAlg, badMessageCheck, or
signerNotTrusted)
- The sender of a request message MUST be authorized for
requesting the operation according to PKI policies. (failInfo
bit: notAuthorized)
Note: The requirements for checking certificates given in RFC 5280
[RFC5280] MUST be followed for signature-based CMP message
protection. Unless the message is a positive ip/cp/kup where the
issuing CA certificate of the newly enrolled certificate is the same
as the CMP protection certificate of that message, certificate status
checking SHOULD be performed on the CMP protection certificates.
Depending on local policies, one or more of the input validation
checks described below need to be implemented:
* If signature-based protection is used, the sender field SHOULD
match the subject of the CMP protection certificate. (failInfo
bit: badMessageCheck)
* If the messageTime is present, it SHOULD be close to the current
time. (failInfo bit: badTime)
3.6. Error handling
This section describes how a PKI entity handles error conditions on
messages it receives. Each error condition SHOULD be logged
appropriately.
3.6.1. Reporting error conditions upstream
An EE SHALL NOT send error messages. PKI management entities SHALL
NOT send error messages in upstream direction, either.
In case an EE rejects a newly issued certificate contained in an ip,
cp, or kup message and implicit confirmation has not been granted,
the EE MUST report this using a certConf message with "rejection"
status and await the pkiConf response as described in Section 4.1.1.
On all other error conditions regarding response messages, the EE or
PKI management entity MUST regard the current PKI management
operation as terminated with failure. The error conditions include
* invalid response message header, body type, protection, or
extraCerts according to the checks described in Section 3.5,
* any issue detected with response message contents,
* receipt of an error message from upstream,
* timeout occurred while waiting for a response,
* rejection of a newly issued certificate while implicit
confirmation has been granted.
Upstream PKI management entities will not receive any CMP message to
learn that the PKI management operation has been terminated. In case
they expect a further message from the EE, a connection interruption
or timeout will occur. Then they also MUST regard the current PKI
management operation as terminated with failure and MUST not attempt
to send an error message downstream.
3.6.2. Reporting error conditions downstream
In case the PKI management entity detects an error condition, e.g.,
rejecting the request due to policy decision, in the body of an ir,
cr, p10cr, kur, or rr message received from downstream, it SHOULD
report the error in the specific response message, i.e., an ip, cp,
kup, or rp with "rejection" status, as described in Section 4.1.1 and
Section 4.2. This can also happen in case of polling.
In case the PKI management entity detects any other error condition
on requests, including pollReq, certConf, genm, and nested messages,
received from downstream and on responses received from upstream,
such as invalid message header, body type, protection, or extraCerts
according to the checks described in Section 3.5 it MUST report them
downstream in the form of an error message as described in
Section 3.6.4.
3.6.3. Handling error conditions on nested messages used for batching
Batching of messages using nested messages as described in
Section 5.2.2.2 requires special error handling.
If the error condition is on an upstream nested message containing
batched requests, it MUST not attempt to respond to the individual
requests included in it.
In case a PKI management entity receives an error message in response
to a nested message, it must propagate the error by responding with
an error message to each of the request messages contained in the
nested message.
In case a PKI management entity detects an error condition on the
downstream nested message received in response to a nested message
sent before, it MAY ignore this error condition and handle the
response as described in Section 5.2.2.2. Otherwise, it MUST
propagate the error by responding with an error message to each of
the requests contained in the nested message it sent originally.
3.6.4. Reporting error conditions
When sending any kind of negative response, including error messages,
a PKI entity MUST indicate the error condition in the PKIStatusInfo
structure of the respective message as described below. It then MUST
regard the current PKI management operation as terminated with
failure.
The PKIStatusInfo structure is used to report errors. It may be part
of various message types, in particular: certConf, ip, cp, kup, and
error. The PKIStatusInfo structure consists of the following fields:
* status: Here the PKIStatus value "rejection" MUST be used.
* statusString: Here any human-readable valid value for logging or
to display via a user interface SHOULD be added.
* failInfo: Here the PKIFailureInfo bits MAY be used in the way
explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo
bits regarding the validation described in Section 3.5 are
referenced there. The PKIFailureInfo bits referenced in
Section 5.1 and Section 6 are described here:
- badCertId: A kur, certConf, or rr message references an unknown
certificate
- badPOP: An ir/cr/p10cr/kur contains an invalid proof-of-
possession
- certRevoked: Revocation requested for a certificate already
revoked
- badCertTemplate: The contents of a certificate request are not
accepted, e.g., a field is missing or has a non-acceptable
value or the given public key is already in use in some other
certificate (depending on policy).
- transactionIdInUse: This is sent by a PKI management entity in
case the received request contains a transaction ID that has
already been used for another transaction. An EE receiving
such error message SHOULD resend the request in a new
transaction using a different transaction ID.
- notAuthorized: The sender of a request message is not
authorized for requesting the operation.
- systemUnavail: This is sent by a PKI management entity in case
a back-end system is not available.
- systemFailure: This is sent by a PKI management entity in case
a back-end system is currently not functioning correctly.
An EE receiving a systemUnavail or systemFailure failInfo SHOULD
resend the request in a new transaction after some time.
Detailed error message description:
Error Message -- error
Field Value
header
-- As described in Section 3.1
body
-- The message sent by an PKI management entity error that
-- occurred
error REQUIRED
pKIStatusInfo REQUIRED
status REQUIRED
-- MUST have the value "rejection"
statusString RECOMMENDED
-- SHOULD be any human-readable text for debugging, logging
-- or to display in a GUI
failInfo OPTIONAL
-- MAY be present and contain the relevant PKIFailureInfo bits
protection REQUIRED
-- As described in Section 3.2
extraCerts OPTIONAL
-- As described in Section 3.3
4. End Entity PKI management operations 4. End Entity PKI management operations
This chapter focuses on the communication of the EE with the PKI This chapter focuses on the communication of an EE with the PKI
management entity it immediately talks to. Depending on the network management entity it directly talks to. Depending on the network and
and PKI solution, this can be an LRA, RA, or directly a CA. PKI solution, this can be an RA or directly a CA. Handling of a
message by a PKI management entity is described in Section 5.
The PKI management operations specified in this section cover the The PKI management operations specified in this section cover the
following: following:
* Requesting a certificate from a PKI with variations like initial * Requesting a certificate with variations like initial enrollment,
enrollment and updates, central key generation, and various certificate updates, central key generation, and MAC-based
protection mechanisms protection
* Revocation of a certificate * Revoking a certificate
* General messages for further support functions * Support messages
These operations mainly specify the message body of the CMP messages These operations mainly specify the message body of the CMP messages
and utilize the specification of the message header, protection and and utilize the specification of the message header, protection and
extraCerts as specified in Section 4. extraCerts as specified in Section 3.
The behavior in case an error occurs is described in Section 4.3. The following diagram shows the EE state machine covering all PKI
management operations described in this section including negative
responses, while no generic error messages are shown.
This section is aligned with RFC 4210 [RFC4210]. The general rules On receiving messages from upstream, the EE MUST perform the general
for interpretation stated in Appendix D.1 of RFC 4210 [RFC4210] shall validation checks described in Section 3.5. The behavior in case an
be applied here, too. error occurs is described in Section 3.6.
State machine:
Start
|
+---------+--------------------+
| |
| send ir/cr/p10cr/kur | send
| | rr/genm
v v
Waiting for ip/cp/kup Waiting for rp/genp
| |
| ip/cp/kup received | rp/genp
+-------------------+------------------+ | received
| | \ \
| with status | with status \ \
| "accepted" or | "waiting" \ \
| "grantedWithMods" | \ \
| and certificate | \ \
| v | \
| +---------> Polling | \
| | | | |
| | pollRep | send | with status |
| | received | pollReq | "rejection" |
| | v | |
| | Waiting for pollRep/ip/cp/kup | |
| | | | | | |
| +---+ | ip/cp/kup | ip/cp/kup | |
| | with certificate | with status | |
| | received | "rejection" | |
v v | received | |
certificate received | | |
| | | |
+-----------+-----+ | | |
| | | | |
| implicitConfirm | implicitConfirm | | |
| granted | not granted | | |
| | | | |
| | send certConf | | |
| v | | |
| Waiting for pkiConf | | |
| | | | |
| | pkiConf | | |
| | received | | |
+-----------------+--------------------+-------------+-------------+
|
v
End
Note: All CMP messages belonging to the same PKI management operation
MUST have the same transactionID because the message receiver
identifies the elements of the operation in this way.
This section is aligned with CMP [RFC4210], CMP Updates
[I-D.ietf-lamps-cmp-updates], and CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms].
Guidelines as well as an algorithm use profile for this document are Guidelines as well as an algorithm use profile for this document are
available in CMP Algorithms [draft-ietf-lamps-cmp-algorithms]. available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms].
4.1. Requesting a new certificate from a PKI 4.1. Requesting a new certificate from a PKI
There are various approaches for requesting a 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 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. PKI, in the form of the request being used, and how the key pair to
The authentication mechanisms may be as follows: be certified is generated. The authentication mechanisms may be as
follows:
* Using a certificate from a trusted PKI and the corresponding * Using a certificate from an external PKI, e.g., a manufacturer-
private key, e.g., a manufacturer issued certificate issued device certificate, and the corresponding private key
* Using a private key and certificate issued from the same PKI that
is addressed for requesting a certificate
* Using the certificate to be updated and the corresponding private * Using the certificate to be updated and the corresponding private
key key
* Using shared secret information known to the EE and the PKI * Using shared secret information known to the EE and the PKI
management entity
An EE requests a certificate indirectly or directly from a CA. When An EE requests a certificate indirectly or directly from a CA. When
the PKI management entity responds with a message containing the the PKI management entity handles the request as described in
requested certificate, the EE MUST reply with a confirmation message. Section 5.1.1 and responds with a message containing the requested
The PKI management entity then MUST respond with a confirmation, certificate, the EE MUST reply with a confirmation message unless
closing the transaction. implicitConfirm was granted. The PKI management entity then MUST
handle it as described in Section 5.1.3 and respond with a
confirmation, closing the PKI management operation.
The message sequences in this section allow the EE to request The message sequences described in this section allow the EE to
certification of a locally generated public-private key pair. For request certification of a locally or centrally generated public-
requirements regarding proper random number and key generation please private key pair. Typically, the EE provides a signature-based
refer to [RFC4086]. The EE SHOULD provide a signature-based proof- proof-of-possession of the private key associated with the public key
of-possession of the private key associated with the public key
contained in the certificate request as defined by RFC 4211 contained in the certificate request as defined by RFC 4211
Section 4.1 [RFC4211] case 3. To this end it is assumed that the 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 private key can technically be used for signing. This is the case
for the most commonly used algorithms RSA and ECDSA, regardless of for the most common algorithms RSA and ECDSA, regardless of
potentially intended restrictions of the key usage. potentially intended restrictions of the key usage.
Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 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 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for
self-signature, if technically possible, even if the keyUsage self-signature, if technically possible, even if the keyUsage
extension requested in the certificate request prohibits generation extension requested in the certificate request prohibits generation
of digital signatures. of digital signatures.
The requesting EE provides the binding of the proof-of-possession to The requesting EE provides the binding of the proof-of-possession to
its identity by signature-based or MAC-based protection of the CMP its identity by signature-based or MAC-based protection of the CMP
request message containing that POPO. As will be detailed in request message containing that POP. As detailed in Section 5.1.1
Section 5.1.2, the targeted PKI management entity should verify and Section 5.1.2, an upstream PKI management entity should verify
whether this EE is authorized to obtain a certificate with the whether this EE is authorized to obtain a certificate with the
requested subject and other fields and extensions. Especially when requested subject and other fields and extensions.
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 The EE MAY indicate the certificate profile to use in the certProfile
signature-based protection it needs a trust anchor to verify the extension of the generalInfo field in the PKIHeader of the
protection certificate. There are several ways to install the Root certificate request message as described in Section 3.1.
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.
4.1.1. Requesting a certificate from a new PKI with signature In case a new trust anchor, e.g., a root CA certificate, is to be
installed that has been received in the caPubs field of an ip or cp
message, the EE MUST properly authenticate the message and authorize
its sender as trusted source of the new trust anchor certificate.
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 explicitly authorized for this
purpose, for the CMP message protection.
4.1.1. Requesting a certificate from a new PKI with signature-based
protection protection
This PKI management operation should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate from a new PKI using an existing certificate from an certificate from a new PKI using an existing certificate from an
external PKI, e.g., a manufacturer-issued IDevID certificate external PKI, e.g., a manufacturer-issued IDevID certificate
[IEEE.802.1AR_2018], to authenticate itself to the new PKI. The EE [IEEE.802.1AR_2018], to authenticate itself to the new PKI.
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 Specific prerequisites augmenting the prerequisites in Section 3.4:
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; * The certificate of the EE MUST have been enrolled by an external
trust MAY be established using an enrollment voucher or other PKI, e.g., a manufacturer-issued device certificate.
configuration means.
4 The PKI management entity MUST trust the external PKI the EE uses * The PKI management entity MUST have the trust anchor of the
to authenticate itself; trust MAY be established using some external PKI.
configuration means.
The general message flow for this PKI management operation is like * When using the generalInfo field certProfile, the EE MUST know the
that given in RFC 4210 Appendix E.7 [RFC4210]. identifier needed to indicate the requested certificate profile.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format ir 1 format ir
2 -> ir -> 2 -> ir ->
3 handle, re-protect or 3 handle or
forward ir forward ir
4 format or receive ip 4 format or receive ip
5 possibly grant implicit 5 possibly grant
confirm implicitConfirm
6 <- ip <- 6 <- ip <-
7 handle ip 7 handle ip
8 In case of status
"rejection" in the ----------------- if implicitConfirm not granted -----------------
ip message, no certConf
and pkiConf are sent 8 format certConf
9 format certConf (optional) 9 -> certConf ->
10 -> certConf -> 10 handle or
11 handle, re-protect or
forward certConf forward certConf
12 format or receive pkiConf 11 format or receive pkiConf
13 <- pkiconf <- 12 <- pkiConf <-
14 handle pkiConf (optional) 13 handle pkiConf
For this PKI management operation, the EE MUST include exactly one For this PKI management operation, the EE MUST include exactly one
single CertReqMsg in the ir. If more certificates are required, CertReqMsg in the ir. If more certificates are required, further
further requests MUST be sent using separate PKI management requests MUST be sent using separate PKI management operation. If
operation. If the EE wants to omit sending a certificate the EE wants to omit sending a certificate confirmation message after
confirmation message after receiving the ip, e.g., to reduce the receiving the ip, e.g., to reduce the number of protocol messages
number of protocol messages exchanged in this PKI management exchanged in this PKI management operation, it MUST request this by
operation, it MUST request this by including the implicitConfirm including the implicitConfirm extension in the header of the ir
extension in the header of the ir message, see Section 3.1. message, see Section 3.1.
If the request was accepted and a new certificate was issued by the If the EE did not request implicit confirmation or the request was
CA, the PKI management entity MUST return the new certificate in the not granted by the PKI management entity, certificate confirmation
certifiedKeyPair field of the ip message. If the EE requested MUST be performed as follows. If the EE successfully received the
omission of the certConf message, the PKI management entity MAY grant certificate, it MUST send a certConf message in due time. On
this by including the implicitConfirm extension, else this is receiving a certConf message, the PKI management entity MUST respond
rejected by not including the implicitConfirm field in the ip with a pkiConf message. If the PKI management entity does not
message. receive the expected certConf message in time it MUST handle this
like a rejection by the EE. In case of rejection the PKI management
entity SHALL terminate the PKI management operation, and the PKI MAY
revoke the newly issued certificate.
If the EE did not request implicit confirmation or the request was If the EE did not request implicit confirmation or the request was
not granted by the PKI management entity, certificate confirmation not granted by the PKI management entity, certificate confirmation
MUST be performed as follows. If the EE successfully received the MUST be performed as follows. If the EE successfully received the
certificate and accepts it, the EE MUST send a certConf message, certificate and accepts it, the EE MUST send a certConf message,
which the PKI management entity must respond using a pkiConf message. which the PKI management entity must respond using a pkiConf message.
If the PKI management entity does not receive the expected certConf 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 message in time it MUST handle this like a rejection by the EE. In
this case the PKI management entity SHALL terminate the PKI this case the PKI management entity SHALL terminate the PKI
management operation. The PKI MAY revoke the newly issued management operation. The PKI MAY revoke the newly issued
certificates depending on the local policy. certificates depending on the local policy.
If the certificate request was rejected by the CA, the PKI management If the certificate request was rejected by the CA, the PKI management
entity must return an ip message containing the status code entity must return an ip message containing the status code
"rejection" as described in Section 5.3 and no certifiedKeyPair "rejection" as described in Section 3.6 and no certifiedKeyPair
field. The EE MUST NOT react to such an ip message with a certConf field. The EE MUST NOT react to such an ip message with a certConf
message and the PKI management operation MUST be terminated. message and the PKI management operation MUST be terminated.
Detailed message description: Detailed message description:
Certification Request -- ir Initialization Request -- ir
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE for a new certificate -- The request of the EE for a new certificate
ir REQUIRED ir REQUIRED
-- MUST be exactly one CertReqMsg -- MUST contain exactly one CertReqMsg
-- If more certificates are required, further requests MUST be -- If more certificates are required, further PKI management
-- packaged in separate PKI Messages -- operations MUST be initiated
certReq REQUIRED certReq REQUIRED
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be 0
certTemplate REQUIRED certTemplate REQUIRED
version OPTIONAL version OPTIONAL
-- MUST be 2 if supplied. -- MUST be 2 if supplied
subject REQUIRED subject REQUIRED
-- The EE subject name MUST be carried in the subject field -- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension. -- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName -- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN -- extension, then the subject field MUST be a NULL-DN
publicKey REQUIRED publicKey REQUIRED
algorithm REQUIRED algorithm REQUIRED
-- MUST include the subject public key algorithm OID and valueany -- MUST include the subject public key algorithm identifier
-- parameters
-- In case a central key generation is requested, this field
-- contains the algorithm and parameter preferences of the
-- requesting entity regarding the to-be-generated key pair
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST contain the public key to be certified in case of -- MUST contain the public key to be certified in case of local
-- local key generation -- key generation
-- MUST contain a zero-length BIT STRING in case a central key
-- generation is requested
extensions OPTIONAL extensions OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the -- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name, -- requested certificate like subject alternative name, key
-- key usage, and extended key usage -- usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE -- The subjectAltName extension MUST be present if the EE subject
-- subject name includes a subject alternative name. -- name includes a subject alternative name.
Popo REQUIRED popo OPTIONAL
POPOSigningKey OPTIONAL -- MUST be present if local key generation is used
-- MUST be used in case subjectPublicKey contains a public key -- MUST be absent if central key generation is requested
-- MUST be absent in case subjectPublicKey contains a signature RECOMMENDED
-- zero-length BIT STRING -- MUST be used by an EE if the key can be used for signing and
-- has the type POPOSigningKey
poposkInput PROHIBITED poposkInput PROHIBITED
-- MUST NOT be used; it is not needed because subject and -- MUST NOT be used; it is not needed because subject and
-- publicKey are both present in the certTemplate -- publicKey are both present in the certTemplate
algorithmIdentifier REQUIRED algorithmIdentifier REQUIRED
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the publicKey
-- publicKey field of the certTemplate -- algorithm field of the certTemplate
signature REQUIRED signature REQUIRED
-- MUST be the signature computed over the DER-encoded -- MUST contain the signature value computed over the DER-encoded
-- certTemplate -- certTemplate
raVerified OPTIONAL
-- MAY be used by an RA after verifying the proof-of-possession
-- provided by the EE
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
Certification Response -- ip Initialization Response -- ip
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The response of the CA to the request as appropriate -- The response of the CA to the request as appropriate
ip REQUIRED ip REQUIRED
caPubs OPTIONAL caPubs OPTIONAL
-- MAY be used -- MAY be used if the certifiedKeyPair field is present
-- If used it MUST contain only the root certificate of the -- If used it MUST contain only a trust anchor, e.g. root
-- certificate contained in certOrEncCert -- certificate, of the certificate contained in certOrEncCert
response REQUIRED response REQUIRED
-- MUST be exactly one CertResponse -- MUST contain exactly one CertResponse
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be 0
status REQUIRED status REQUIRED
-- PKIStatusInfo structure MUST be present -- PKIStatusInfo structure MUST be present
status REQUIRED status REQUIRED
-- positive values allowed: "accepted", "grantedWithMods" -- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, logging or to
-- display in a GUI -- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MUST be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if the status is "accepted" or -- MUST be absent if status is "accepted" or "grantedWithMods"
-- "grantedWithMods"
certifiedKeyPair OPTIONAL certifiedKeyPair OPTIONAL
-- MUST be present if status is "accepted" or "grantedWithMods" -- MUST be present if status is "accepted" or "grantedWithMods"
-- MUST be absent if status is "rejection" -- MUST be absent if status is "rejection"
certOrEncCert REQUIRED certOrEncCert REQUIRED
-- MUST be present when certifiedKeyPair is present -- MUST be present if status is "accepted" or "grantedWithMods"
certificate REQUIRED certificate REQUIRED
-- MUST be present when certifiedKeyPair is present -- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate -- MUST contain the newly enrolled X.509 certificate
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be absent in case of local key-generation -- MUST be absent in case of local key generation or "rejection"
-- MUST contain the encrypted private key in an EnvelopedData -- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in section 5.1.5 in case the private -- structure as specified in Section 4.1.6 in case the private
-- key was generated centrally -- key was generated centrally
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
-- MUST contain the chain of the certificate present in -- MUST contain the chain of the certificate present in
-- certOrEncCert -- certOrEncCert
-- Self-signed root certificate SHOULD be omitted -- Self-signed certificates SHOULD be omitted
-- Duplicate certificates MAY be omitted -- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf Certificate Confirmation -- certConf
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The message of the EE sends confirmation to the PKI -- The message of the EE sends confirmation to the PKI
-- management entity to accept or reject the issued certificates -- management entity to accept or reject the issued certificates
certConf REQUIRED certConf REQUIRED
-- MUST be exactly one CertStatus -- MUST contain exactly one CertStatus
CertStatus REQUIRED CertStatus REQUIRED
hashAlg OPTIONAL
-- The hash algorithm to use for calculating certHash
-- SHOULD NOT be used in all cases where the AlgorithmIdentifier
-- of the certificate signature specifies a hash algorithm
-- If used, the pvno field in the header MUST be cmp2021 (3)
certHash REQUIRED certHash REQUIRED
-- MUST be the hash of the certificate, using the same hash -- MUST be the hash of the certificate, using the hash algorithm
-- algorithm as used to create the certificate signature -- indicated in hashAlg or the same one as used to create the
-- certificate signature
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be 0
statusInfo RECOMMENDED statusInfo RECOMMENDED
-- PKIStatusInfo structure SHOULD be present -- PKIStatusInfo structure SHOULD be present
-- Omission indicates acceptance of the indicated certificate -- Omission indicates acceptance of the indicated certificate
status REQUIRED status REQUIRED
-- positive values allowed: "accepted" -- positive values allowed: "accepted"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging, or to -- MAY be any human-readable text for debugging, logging, or to
-- display in a GUI -- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MUST be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if the status is "accepted" -- MUST be absent if status is "accepted"
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same certificate as for protecting the ir -- MUST use the same credentials as in the first request message
-- of this PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- Any certificates in extraCerts MAY be omitted if the message -- MAY be omitted if the message size is critical and
-- size is critical and the PKI management entity caches the -- the PKI management entity caches the extraCerts from the
-- extraCerts from the ir -- first request message of this PKI management operation
PKI Confirmation -- pkiconf PKI Confirmation -- pkiConf
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
pkiconf REQUIRED pkiconf REQUIRED
-- The content of this field MUST be NULL -- The content of this field MUST be NULL
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same certificate as for protecting the ip -- MUST use the same credentials as in the first response
-- message of this PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- Any certificates in extraCerts MAY be omitted if the message -- MAY be omitted if the message size is critical and the EE has
-- size is critical and the EE has cached the extraCerts from the -- cached the extraCerts from the first response message of
-- ip -- this PKI management operation
4.1.2. Requesting a certificate from a trusted PKI with signature 4.1.2. Requesting an additional certificate with signature-based
protection protection
This PKI management operation should be used by an EE to request an This PKI management operation should be used by an EE to request an
additional certificate of the same PKI it already has certificates additional certificate of the same PKI it already has certificates
from. The EE uses one of these existing certificates to authenticate from. The EE uses one of these existing certificates to authenticate
itself by signing its request messages using the respective private itself by signing its request messages using the respective private
key. key.
The general message flow for this PKI management operation is the Specific prerequisites augmenting the prerequisites in Section 3.4:
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 * The certificate used by the EE MUST have been enrolled by the PKI
established using some configuration means. it requests another certificate from.
The message sequence for this PKI management operation is like that * When using the generalInfo field certProfile, the EE MUST know the
given in [RFC4210] Appendix D.5. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes: 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, 1 The body of the first request and response SHOULD be cr and cp,
respectively. respectively.
2 The caPubs field in the cp message SHOULD be absent. Note: Since the difference between ir/ip and cr/cp is
syntactically not essential, an ir/ip MAY be used in this PKI
management operation.
2 The caPubs field in the certificate response message SHOULD be
absent.
4.1.3. Updating an existing certificate with signature protection 4.1.3. Updating an existing certificate with signature protection
This PKI management operation should be used by an EE to request an 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 update for one of its certificates that is still valid. The EE uses
the certificate it wishes to update to authenticate itself and for the certificate it wishes to update as the protection certificate.
proving ownership of the certificate to be updated by signing its Both for authenticating itself and for proving ownership of the
request messages with the corresponding private key. certificate to be updated, it signs the 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: Specific prerequisites augmenting the prerequisites in Section 3.4:
1 The certificate the EE wishes to update MUST NOT be expired or * The certificate the EE wishes to update MUST NOT be expired or
revoked. revoked and MUST have been issued by the addressed CA.
2 A new public-private key pair SHOULD be used. * A new public-private key pair SHOULD be used.
The message sequence for this PKI management operation is like that * When using the generalInfo field certProfile, the EE MUST know the
given in [RFC4210] Appendix D.6. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes: 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, 1 The body of the first request and response MUST be kur and kup,
respectively. respectively.
2 Protection of the kur MUST be performed using the certificate to 2 Protection of the kur MUST be performed using the certificate to
be updated. be updated.
3 The subject field and/or the subjectAltName extension of the 3 The subject field and/or the subjectAltName extension of the
CertTemplate MUST contain the EE subject name of the existing certTemplate MUST contain the EE subject name of the existing
certificate to be updated, without modifications. certificate to be updated, without modifications.
4 The CertTemplate SHOULD contain the subject and publicKey of the 4 The certTemplate SHOULD contain the subject and/or subjectAltName
EE only. extension and publicKey of the EE only.
5 The oldCertId control SHOULD be used to make clear which 5 The oldCertId control MAY be used to make clear which certificate
certificate is to be updated. is to be updated.
6 The caPubs field in the kup message MUST be absent. 6 The caPubs field in the kup message MUST be absent.
As part of the certReq structure of the kur the oldCertId control is As part of the certReq structure of the kur the oldCertId control is
added right after the certTemplate. added after the certTemplate field.
controls controls
type RECOMMENDED type RECOMMENDED
-- MUST be the value id-regCtrl-oldCertID, if present -- MUST be the value id-regCtrl-oldCertID, if present
value value
issuer REQUIRED issuer REQUIRED
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the issuer and serialNumber of the certificate -- MUST contain the issuer and serialNumber of the certificate
-- to be updated -- to be updated
4.1.4. Requesting a certificate from a PKI with MAC protection 4.1.4. Requesting a certificate from a PKI with MAC-based protection
This PKI management operation should be used by an EE to request a 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 certificate of a new PKI in case it does not have a certificate to
identity to the target PKI, but there is shared secret information prove its identity to the target PKI, but has some secret information
established between the EE and the PKI. Therefore, the shared with the PKI management entity. Therefore, the request and
initialization request is MAC-protected using this shared secret response messages are MAC-protected using this shared secret
information. The PKI management entity checking the MAC-based information. The PKI management entity checking the MAC-based
protection SHOULD replace this protection according to Section 5.1.2 protection SHOULD replace this protection according to Section 5.2.3
in case the next hop does not know the shared secret information. in case the next hop does not know the shared secret information.
For requirements regarding proper random number and key generation Note: The entropy of the shared secret information is crucial for the
please refer to [RFC4086]. level of protection when using MAC-based protection. Further
guidance is available in Section 8.
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 Specific prerequisites augmenting the prerequisites in Section 3.4:
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 * Rather than using private keys, certificates, and trust anchors,
certificate from; this name MAY be established using an enrollment the EE and the PKI management entity MUST share secret
voucher, the issuer field from a CertReqTemplate response message, information.
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; Note: The shared secret information MUST be established out-of-
trust is established using the shared secret information. band, e.g., by a service technician during initial local
configuration.
The message sequence for this PKI management operation is like that * When using the generalInfo field certProfile, the EE MUST know the
given in [RFC4210] Appendix D.4. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
1 The protection of all messages MUST be calculated using Message 1 The protection of all messages MUST be MAC-based.
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 2 The senderKID MUST contain a reference the recipient can use to
absent. identify the shared secret information used for the protection,
e.g., the username of the EE.
4 The extraCerts of the ip message MUST contain the chain of the 3 The extraCerts of all messages does not contain CMP protection
issued certificate and root certificates SHOULD not be included certs and associated chains.
and MUST NOT be directly trusted in any case.
See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for
details on message authentication code algorithms (MSG_MAC_ALG) to details on message authentication code algorithms (MSG_MAC_ALG) to
use. Typically, parameters are part of the protectionAlg structure, use. Typically, parameters are part of the protectionAlg field,
e.g., used for key derivation, like a salt and an iteration count. e.g., used for key derivation, like a salt and an iteration count.
Such fields SHOULD remain constant for message protection throughout Such fields SHOULD remain constant for message protection throughout
this PKI management operation to reduce the computational overhead. this PKI management operation to reduce the computational overhead.
4.1.5. Requesting a certificate from a legacy PKI using PKCS#10 request 4.1.5. Requesting a certificate from a legacy PKI using a PKCS#10
request
This PKI management operation can be used by an EE to request a This PKI management operation can be used by an EE to request a
certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF
[RFC4211]. The EE can prove its identity to the target PKI by using [RFC4211]. This offers a variation of the PKI management operations
various protection means as described in Section 4.1.1 or specified in Section 4.1.1 to Section 4.1.4.
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.
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 In this PKI management operation the public key and all further
established by an available root certificate, using an enrollment certificate template data MUST be contained in the subjectPKInfo and
voucher, or other configuration means. other certificationRequestInfo fields of the PKCS#10 structure.
4 The addressed PKI management entity MUST trust the PKI the EE uses The prerequisites are the same as given in Section 4.1.1,
to authenticate itself when using the signature protection; trust Section 4.1.2, Section 4.1.3, or Section 4.1.4.
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 The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes: to that given in Section 4.1.1 to Section 4.1.4, with the following
changes:
1 The body of the first request and response MUST be p10cr and cp, 1 The body of the first request and response MUST be p10cr and cp,
respectively. respectively.
2 The certReqId in the cp message MUST be 0. 2 The certReqId in the cp message MUST be 0.
3 The caPubs field in the cp message SHOULD be absent. 3 The caPubs field in the cp message SHOULD be absent.
Detailed description of the p10cr message: Detailed description of the p10cr message:
skipping to change at page 35, line 18 skipping to change at page 41, line 18
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE for a new certificate using a PKCS#10 -- The request of the EE for a new certificate using a PKCS#10
-- certificate request -- certificate request
p10cr REQUIRED p10cr REQUIRED
certificationRequestInfo REQUIRED certificationRequestInfo REQUIRED
version REQUIRED version REQUIRED
-- MUST be set to 0 to indicate PKCS#10 V1.7 -- MUST be 0 to indicate PKCS#10 V1.7
subject REQUIRED subject REQUIRED
-- The EE subject name MUST be carried in the subject field -- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension. -- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName -- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN -- extension, then the subject field MUST be a NULL-DN
subjectPKInfo REQUIRED subjectPKInfo REQUIRED
algorithm REQUIRED algorithm REQUIRED
-- MUST include the subject public key algorithm ID -- MUST include the subject public key algorithm identifier
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST include the public key to be certified -- MUST include the public key to be certified
attributes OPTIONAL attributes OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the -- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name, -- requested certificate like subject alternative name,
-- key usage, and extended key usage. -- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE -- The subjectAltName extension MUST be present if the EE
-- subject name includes a subject alternative name. -- subject name includes a subject alternative name.
signatureAlgorithm REQUIRED signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPKInfo field. -- subjectPKInfo field.
signature REQUIRED signature REQUIRED
-- MUST containing the self-signature for proof-of-possession -- MUST contain the self-signature for proof-of-possession
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described for the underlying PKI management operation
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described for the underlying PKI management operation
4.1.6. Generateing the key pair centrally at the PKI management entity 4.1.6. Adding central key pair generation to a certificate request
This functional extension can be applied in combination with This functional extension can combined with certificate enrollment as
certificate enrollment as described in Section 4.1.1, Section 4.1.2, described in Section 4.1.1 to Section 4.1.4. It needs to be used in
and Section 4.1.4. The functional extension can be used in case an case an EE is not able to generate its new public-private key pair
EE is not able to generate its new public-private key pair itself or itself or central generation of the EE key material is preferred. It
central generation the EE key material is preferred. It is a matter is a matter of the local implementation which PKI management entity
of the local implementation which PKI management entity will act as will act as Key Generation Authority (KGA) and perform the key
Key Generation Authority (KGA) and perform the key generation. This generation. This PKI management entity MUST use a certificate
PKI management entity MUST have a certificate containing the containing the additional extended key usage extension id-kp-cmKGA in
additional extended key usage extension id-kp-cmKGA in order to be order to be accepted by the EE as a legitimate key generation
accepted by the EE as a legitimate key generation authority. The KGA authority.
can use one of the PKI management operations described in the
sections above to request the certificate for this key pair on behalf As described in Section 5.3.1, the KGA can use one of the PKI
of the EE. 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 Generally speaking, in machine-to-machine scenarios it is strongly
preferable to generate public-private key pairs locally at the EE. preferable to generate public-private key pairs locally at the EE.
Together with proof-of-possession of the private key in the Together with proof-of-possession of the private key in the
certification request, this helps a lot to make sure that the entity certificate request, this is advisable to make sure that the entity
identified in the newly issued certificate is the only entity that identified in the newly issued certificate is the only entity that
knows the private key. knows the private key.
Reasons for central key generation may include the following: Reasons for central key generation may include the following:
* Lack of sufficient initial entropy. * Lack of sufficient initial entropy.
Note: Good random numbers are needed not only for key generation but Note: Good random numbers are needed not only for key generation
also for session keys and nonces in any security protocol. but also for session keys and nonces in any security protocol.
Therefore, a decent security architecture should anyways support good Therefore, a decent security architecture should anyways support
random number generation on the EE side or provide enough initial good random number generation on the EE side or provide enough
entropy for the RNG seed to guarantee good pseudo-random number initial entropy for the RNG seed to guarantee good pseudo-random
generation. Yet maybe this is not the case at the time of requesting number generation. Yet maybe this is not the case at the time of
an initial certificate during manufacturing. requesting an initial certificate during manufacturing.
* Lack of computational resources, e.g., in case of RSA key * Lack of computational resources, in particular for RSA key
generation. generation.
Note: Since key generation could be performed in advance to the Note: Since key generation could be performed in advance to the
certificate enrollment communication, it is often not time critical. certificate enrollment communication, it is often not time
critical.
Note: As mentioned in Section 2.1 central key generation may be Note: As mentioned in Section 2.1, central key generation may be
required in a push model, where the certificate response message is required in a push model, where the certificate response message is
transferred by the PKI management entity to the EE without a previous transferred by the PKI management entity to the EE without a previous
request message. request message.
If the EE wishes to request central key generation, it MUST fill the The EE requesting central key generation MUST omit the publicKey
subjectPublicKey field in the certTemplate structure of the request field from the certTemplate or, in case it has a preference on the
message with a zero-length BIT STRING. This indicates to the PKI key type to be generated, provide it in the algorithm sub-field and
management entity that a new key pair shall be generated centrally on fill the subjectPublicKey sub-field with a zero-length BIT STRING.
behalf of the EE. Both variants indicate to the PKI management entity that a new key
pair shall be generated centrally on behalf of the EE.
Note: As the protection of centrally generated keys in the response Note: As the protection of centrally generated keys in the response
message is being extended from EncryptedValue to EncryptedKey by CMP message has been extended to EncryptedKey by CMP Updates
Updates [I-D.ietf-lamps-cmp-updates], also the alternative [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred
EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the
of EncryptedValue has been deprecated in favor of the EnvelopedData use of EncryptedValue has been deprecated in favor of the
structure. Therefore, this profile requires using EnvelopedData as EnvelopedData structure. Therefore, this profile requires using
specified in CMS Section 6 [RFC5652]. When EnvelopedData is to be EnvelopedData as specified in CMS Section 6 [RFC5652]. When
used in a transaction, CMP V3 MUST be indicated in the message EnvelopedData is to be used in a PKI management operation, CMP v3
header, see CMP Updates [I-D.ietf-lamps-cmp-updates]. MUST be indicated in the message header already for the initial
request message, see Section 7 of CMP Updates
[I-D.ietf-lamps-cmp-updates].
+----------------------------------+ +----------------------------------+
| EnvelopedData | | EnvelopedData |
| [RFC5652] section 6 | | [RFC5652] section 6 |
| +------------------------------+ | | +------------------------------+ |
| | SignedData | | | | SignedData | |
| | [RFC5652] section 5 | | | | [RFC5652] section 5 | |
| | +--------------------------+ | | | | +--------------------------+ | |
| | | AsymmetricKeyPackage | | | | | | AsymmetricKeyPackage | | |
| | | [RFC5958] | | | | | | [RFC5958] | | |
skipping to change at page 38, line 9 skipping to change at page 44, line 5
field in the certifiedKeyPair structure of the response message also field in the certifiedKeyPair structure of the response message also
containing the newly issued certificate. containing the newly issued certificate.
The private key MUST be provided as an AsymmetricKeyPackage structure The private key MUST be provided as an AsymmetricKeyPackage structure
as defined in RFC 5958 [RFC5958]. as defined in RFC 5958 [RFC5958].
This AsymmetricKeyPackage structure MUST be wrapped in a SignedData This AsymmetricKeyPackage structure MUST be wrapped in a SignedData
structure, as specified in CMS Section 5 [RFC5652], signed by the KGA structure, as specified in CMS Section 5 [RFC5652], signed by the KGA
generating the key pair. The signature MUST be performed using a generating the key pair. The signature MUST be performed using a
private key related to a certificate asserting the extended key usage 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] id-kp-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 to demonstrate authorization to generate key pairs on behalf of an
an EE. EE. The EE SHOULD verify the presence of this extended key usage in
the SignedData structure.
Note: When of using password-based key management technique as Note: When using password-based key management technique as described
described in Section 4.1.6.3 it may not be possible or meaningful to in Section 4.1.6.3 it may not be possible or meaningful to the EE to
the EE to validate the KGA signature in the SignedData structure validate the KGA signature in the SignedData structure since shared
since shared secret information is used for initial authentication. secret information is used for initial authentication. In this case
In this case the EE MAY omit this signature validation. the EE MAY omit this signature validation.
This SignedData structure MUST be wrapped in an EnvelopedData The SignedData structure MUST be wrapped in an EnvelopedData
structure, as specified in CMS Section 6 [RFC5652], encrypting it structure, as specified in CMS Section 6 [RFC5652], encrypting it
using a newly generated symmetric content-encryption key. using a newly generated symmetric content-encryption key.
This content-encryption key MUST be securely provided as part of the This content-encryption key MUST be securely provided as part of the
EnvelopedData structure to the EE using one of three key management EnvelopedData structure to the EE using one of three key management
techniques. The choice of the key management technique to be used by techniques. The choice of the key management technique to be used by
the PKI management entity depends on the authentication mechanism the the PKI management entity depends on the authentication mechanism the
EE choose to protect the request message. See CMP Updates section EE chose to protect the request message. See CMP Updates section 2.8
3.4 [I-D.ietf-lamps-cmp-updates] for more details on which key [I-D.ietf-lamps-cmp-updates] for more details on which key management
management technique to use. technique to use.
* Signature-protected request message: * Signature-based protection of the request message:
- The content-encryption key SHALL be protected using the key - The content-encryption key SHALL be protected using the key
agreement key management technique, see Section 4.1.6.1, if the agreement key management technique, see Section 4.1.6.1, if the
certificate used by the EE for protecting the request message certificate used by the EE for protecting the request message
allows the key usage keyAgreement. If the certificate also allows the key usage keyAgreement. If the certificate also
allows the key usage keyEncipherment, the key transport key allows the key usage keyEncipherment, the key transport key
management technique SHALL NOT be used. management technique SHALL NOT be used.
- The content-encryption key SHALL be protected using the key - The content-encryption key SHALL be protected using the key
transport key management technique, see Section 4.1.6.2, if the transport key management technique, see Section 4.1.6.2, if the
certificate used by the EE for protecting the respective certificate used by the EE for protecting the respective
request message allows the key usage keyEncipherment but not request message allows the key usage keyEncipherment but not
keyAgreement. keyAgreement.
* MAC-protected request message: * MAC-based protected of the request message:
- The content-encryption key SHALL be protected using the - The content-encryption key SHALL be protected using the
password-based key management technique, see Section 4.1.6.3, password-based key management technique, see Section 4.1.6.3,
if and only if the EE used MAC protection for the request if and only if the EE used MAC-based protection for the request
message. message.
If central key generation is supported, support of the key agreement If central key generation is supported, support of the key agreement
key management technique is REQUIRED and support of key transport and key management technique is REQUIRED and support of key transport and
password-based key management techniques are OPTIONAL. This is due password-based key management techniques are OPTION, for two reasons:
to two reasons: The key agreement key management technique is The key agreement key management technique is supported by most
supported by most asymmetric algorithms, while the key transport key asymmetric algorithms, while the key transport key management
management technique is supported only by a very few asymmetric technique is supported only by a very few of them. The password-
algorithms. And as mentioned the password-based key management based key management technique shall only be used in combination with
technique shall only be used in combination with MAC protection, MAC-based protection, which is a sideline in this document.
which is a sideline in this document.
For details on algorithms to be used, please see CMP Algorithms Specific prerequisites augmenting those of the respective certificate
Section 4 and 5 [I-D.ietf-lamps-cmp-algorithms]. enrollment PKI management operations:
For encrypting the SignedData structure containing the private key a * If signature-based protection is used, the EE MUST be able to
fresh content-encryption key MUST be generated with sufficient authenticate and authorize the KGA, using suitable information,
entropy for the symmetric encryption algorithm used. which includes a trust anchor.
Note: Depending on the lifetime of the certificate and the * If MAC-based protection is used, the KGA MUST also know the shared
criticality of the generated private key, it is advisable to use the secret information to protect the encrypted transport of the newly
strongest available symmetric encryption algorithm. generated key pair. Consequently, the EE can also authorize the
KGA.
* The PKI management entity MUST have a certificate containing the
additional extended key usage extension id-kp-cmKGA for signing
the SignedData structure containing the private key package.
* For encrypting the SignedData structure a fresh content-encryption
key to be used by the symmetric encryption algorithm MUST be
generated with sufficient entropy.
Note: The security strength of the protection of the generated
private key should be similar or higher than the security strength
of the generated private key.
The detailed description of the privateKey field as follows: The detailed description of the privateKey field as follows:
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be an EnvelopedData structure as specified in -- MUST be an EnvelopedData structure as specified in CMS
-- CMS [RFC5652] section 6 -- Section 6 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be set to 2 for recipientInfo type KeyAgreeRecipientInfo -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
-- and KeyTransRecipientInfo -- KeyTransRecipientInfo
-- MUST be set to 0 for recipientInfo type PasswordRecipientInfo -- MUST be 0 for recipientInfo type PasswordRecipientInfo
recipientInfos REQUIRED recipientInfos REQUIRED
-- MUST be exactly one RecipientInfo -- MUST contain exactly one RecipientInfo, which MUST be
recipientInfo REQUIRED -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1),
-- MUST be either KeyAgreeRecipientInfo (see section 4.1.6.1), -- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or
-- KeyTransRecipientInfo (see section 4.1.6.2), or -- pwri of type PasswordRecipientInfo (see section 4.1.6.3)
-- 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 encryptedContentInfo
REQUIRED REQUIRED
contentType REQUIRED contentType REQUIRED
-- MUST be id-signedData -- MUST be id-signedData
contentEncryptionAlgorithm contentEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST specify the algorithm OID of the algorithm used for -- MUST be the algorithm identifier of the algorithm used for
-- content encryption -- content encryption
-- The algorithm MUST be a PROT_SYM_ALG as specified in -- The algorithm type MUST be a PROT_SYM_ALG as specified in
-- RFC-CMP-Alg Section 5 -- RFC-CMP-Alg Section 5
encryptedContent REQUIRED encryptedContent REQUIRED
-- MUST be the SignedData structure as specified in -- MUST be the SignedData structure as specified in CMS
-- CMS Section 5 [RFC5652] in encrypted form -- Section 5 [RFC5652] in encrypted form
version REQUIRED version REQUIRED
-- MUST be set to 3 if X.509 V3 certificates are included -- MUST be 3
digestAlgorithms digestAlgorithms
REQUIRED REQUIRED
-- MUST be exactly one digestAlgorithm OID -- MUST contain exactly one AlgorithmIdentifier element
digestAlgorithmIdentifier -- MUST be the algorithm identifier of the digest algorithm
REQUIRED -- used for generating the signature and match the signature
-- MUST be the OID of the digest algorithm used for generating -- algorithm specified in signatureAlgorithm
-- the signature and match the signature algorithm specified in
-- signatureAlgorithm
encapContentInfo encapContentInfo
REQUIRED REQUIRED
-- MUST contain the content that is to be signed -- MUST contain the content that is to be signed
eContentType REQUIRED eContentType REQUIRED
-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
eContent REQUIRED eContent REQUIRED
AsymmetricKeyPackage -- MUST be of type AsymmetricKeyPackage and
REQUIRED
-- MUST contain exactly one OneAsymmetricKey element -- MUST contain exactly one OneAsymmetricKey element
OneAsymmetricKey
REQUIRED
version REQUIRED version REQUIRED
-- MUST be set to 1 -- MUST be 1 (indicating v2)
privateKeyAlgorithm privateKeyAlgorithm
REQUIRED REQUIRED
-- The privateKeyAlgorithm field MUST contain -- The privateKeyAlgorithm field MUST contain the algorithm
-- the OID of the asymmetric key pair algorithm -- identifier of the asymmetric key pair algorithm
privateKey privateKey
REQUIRED REQUIRED
-- MUST contain the new private key
attributes
OPTIONAL
-- The attributes field SHOULD not be used
publicKey publicKey
REQUIRED REQUIRED
-- MUST contain the public key corresponding to the private key -- MUST contain the public key corresponding to the private key
-- for simplicity and consistency with V2 of OneAsymmetricKey -- for simplicity and consistency with v2 of OneAsymmetricKey
certificates REQUIRED certificates REQUIRED
-- SHOULD contain the certificate, for the private key used -- MUST contain the certificate for the private key used to sign
-- to sign the content, together with its chain -- the signedData content, together with its chain
-- If present, the first certificate in this field MUST -- The first certificate in this field MUST be the KGA
-- be the certificate used for protecting this content -- certificate used for protecting this content
-- Self-signed certificates SHOULD NOT be included -- Self-signed certificates SHOULD NOT be included and MUST NOT
-- and MUST NOT be trusted based on their inclusion in any case -- be trusted based on their inclusion in any case
crls OPTIONAL signerInfos REQUIRED
-- MAY be present to provide status information on the protection
-- certificate or its CA certificates -- MUST contain exactly one SignerInfo element
signerInfos REQUIRED
-- MUST be exactly one signerInfo
version REQUIRED version REQUIRED
-- MUST be set to 3 -- MUST be 3
sid REQUIRED sid REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST be the subjectKeyIdentifier of the protection certificate -- MUST be the subjectKeyIdentifier of the KGA certificate
digestAlgorithm digestAlgorithm
REQUIRED REQUIRED
-- MUST be the same as in digestAlgorithmIdentifier -- MUST be the same as in digestAlgorithmIdentifier
signedAttrs REQUIRED signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the same -- MUST contain an id-contentType attribute containing the value
-- value as eContentType -- id-ct-KP-aKeyPackage
-- MUST contain an id-messageDigest attribute containing the -- MUST contain an id-messageDigest attribute containing the
-- message digest of eContent -- message digest of eContent
-- MAY contain an id-signingTime attribute containing the time of -- MAY contain an id-signingTime attribute containing the time
-- signature -- of signature
-- For details on the signed attributes see CMS Section 5.3 -- For details on the signed attributes see CMS Section 5.3 and
-- and Section 11 [RFC5652] -- Section 11 [RFC5652]
signatureAlgorithm signatureAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm OID of the signature algorithm used for -- MUST be the algorithm identifier of the signature algorithm
-- calculation of the signature bits -- used for calculation of the signature bits
-- The signature algorithm MUST be a MSG_SIG_ALG as specified in -- The signature algorithm type MUST be a MSG_SIG_ALG as
-- RFC-CMP-Alg Section 3 and MUST be consistent with the -- specified in RFC-CMP-Alg Section 3 and MUST be consistent
-- subjectPublicKeyInfo field of the CMP KGA certificate -- with the subjectPublicKeyInfo field of the KGA certificate
signature REQUIRED signature REQUIRED
-- MUST be the result of the digital signature generation -- MUST be the digital signature of the encapContentInfo
NOTE: As defined in Section 1.5 any field of the ASN.1 syntax as NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that
defined in RFC 5652 [RFC5652] not explicitly specified here, SHOULD are defined in RFC 5652 [RFC5652] but are not explicitly specified
NOT be used by the sending entity. here SHOULD NOT be used.
4.1.6.1. Using key agreement key management technique 4.1.6.1. Using key agreement key management technique
This key management technique can be applied in combination with the This variant can be applied in combination with the PKI management
PKI management operations specified in Section 4.1.1 to Section 4.1.3 operations specified in Section 4.1.1 to Section 4.1.3 using
using signature-based protected CMP messages. The public key of the signature-based protection of CMP messages. The EE certificate used
EE certificate used for the signature-based protection of the request for the signature-based protection of the request message MUST allow
message MUST also be used for the key establishment of the content- for the key usage "keyAgreement" and therefore, the related key pair
encryption key. To use this key management technique the MUST be used for establishment of the content-encryption key. For
KeyAgreeRecipientInfo structure MUST be used in the contentInfo this key management technique the KeyAgreeRecipientInfo structure
field. MUST be used in the contentInfo field.
The KeyAgreeRecipientInfo structure included into the EnvelopedData The KeyAgreeRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.2 [RFC5652]. structure is specified in CMS Section 6.2.2 [RFC5652].
The detailed description of the KeyAgreeRecipientInfo structure looks The detailed description of the KeyAgreeRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED kari REQUIRED
-- MUST be KeyAgreeRecipientInfo as specified in -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section
-- 6.2.2 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be set to 3 -- MUST be 3
originator REQUIRED originator REQUIRED
-- MUST contain the originatorKey choice -- MUST contain the originatorKey choice
algorithm REQUIRED algorithm REQUIRED
-- MUST be the algorithm OID of the key agreement algorithm -- MUST be the algorithm identifier of the key agreement
-- The algorithm MUST be a KM_KA_ALG as specified in -- algorithm
-- The algorithm type MUST be a KM_KA_ALG as specified in
-- RFC-CMP-Alg Section 4.1 -- RFC-CMP-Alg Section 4.1
publicKey REQUIRED publicKey REQUIRED
-- MUST be the ephemeral public key of the sending party -- MUST be the ephemeral public key of the sending party
ukm RECOMMENDED ukm RECOMMENDED
-- MUST be used when 1-pass ECMQV is used -- MUST be used when 1-pass ECMQV is used
-- SHOULD be present to ensure uniqueness of the key -- SHOULD be present to ensure uniqueness of the key
-- encryption key, see [RFC8419] -- encryption key, see [RFC8419]
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm OID of the key wrap algorithm -- MUST be the algorithm identifier of the key wrap algorithm
-- The algorithm MUST be a KM_KW_ALG as specified in -- The algorithm type MUST be a KM_KW_ALG as specified in
-- RFC-CMP-Alg Section 4.3 -- RFC-CMP-Alg Section 4.3
recipientEncryptedKeys recipientEncryptedKeys
REQUIRED REQUIRED
-- MUST contain exactly one RecipientEncryptedKey element -- MUST contain exactly one RecipientEncryptedKey element
rid REQUIRED rid REQUIRED
-- MUST contain the rKeyId choice -- MUST contain the rKeyId choice
rKeyId REQUIRED rKeyId REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST contain the same value as the senderKID in the -- MUST contain the same value as the senderKID in the
-- respective request messages -- respective request message header
encryptedKey encryptedKey
REQUIRED REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
4.1.6.2. Using key transport key management technique 4.1.6.2. Using key transport key management technique
This key management technique can be applied in combination with the This variant can be applied in combination with the PKI management
PKI management operations specified in Section 4.1.1 to Section 4.1.3 operations specified in Section 4.1.1 to Section 4.1.3 using
using signature-based protected CMP messages. The public key of the signature-based protection of CMP messages. The EE certificate used
EE certificate used for the signature-based protection of the request for the signature-based protection of the request message MUST allow
message MUST also be used for key encipherment of the content- for the key usage "keyEncipherment" and not for "keyAgreement".
encryption key. To use this key management technique the Therefore, the related key pair MUST be used for encipherment of the
content-encryption key. For this key management technique the
KeyTransRecipientInfo structure MUST be used in the contentInfo KeyTransRecipientInfo structure MUST be used in the contentInfo
field. field.
The KeyTransRecipientInfo structure included into the EnvelopedData The KeyTransRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.1 [RFC5652]. structure is specified in CMS Section 6.2.1 [RFC5652].
The detailed description of the KeyTransRecipientInfo structure looks The detailed description of the KeyTransRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED ktri REQUIRED
-- MUST be KeyTransRecipientInfo as specified in -- MUST be a KeyTransRecipientInfo as specified in CMS
-- CMS section 6.2.1 [RFC5652] -- Section 6.2.1 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be set to 2 -- MUST be 2
rid REQUIRED rid REQUIRED
-- MUST contain the subjectKeyIdentifier choice -- MUST contain the subjectKeyIdentifier choice
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST contain the same value as the senderKID in the respective -- MUST contain the same value as the senderKID in the
-- request messages -- respective request message header
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm OID of the key transport algorithm -- MUST be the algorithm identifier of the key transport
-- The algorithm MUST be a KM_KT_ALG as specified in RFC-CMP-Alg -- algorithm
-- Section 4.2 -- The algorithm type MUST be a KM_KT_ALG as specified in
-- RFC-CMP-Alg Section 4.2
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
4.1.6.3. Using password-based key management technique 4.1.6.3. Using password-based key management technique
This key management technique can be applied in combination with the This variant can be applied in combination with the PKI management
PKI management operation specified in Section 4.1.4 using MAC-based operation specified in Section 4.1.4 using MAC-based protection of
protected CMP messages. The shared secret information used for the CMP messages. The shared secret information used for the MAC-based
MAC-based protection MUST also be used for the encryption of the protection MUST also be used for the encryption of the content-
content-encryption key but with a different salt value applied in the encryption key but with a different salt value applied in the key
key derivation algorithm as used for the MAC-based protection . To derivation algorithm. For this key management technique the
use this key management technique the PasswordRecipientInfo structure PasswordRecipientInfo structure MUST be used in the contentInfo
MUST be used in the contentInfo field. field.
Note: The entropy of the shared secret information is crucial for the
level of protection when using a password-based key management
technique. For centrally generated key pairs, the entropy of the
shared secret information SHALL not be less than the security
strength of the centrally generated key pair. Further guidance is
available in Section 8.
The PasswordRecipientInfo structure included into the EnvelopedData The PasswordRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.4 [RFC5652]. structure is specified in CMS Section 6.2.4 [RFC5652].
The detailed description of the PasswordRecipientInfo structure looks The detailed description of the PasswordRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED pwri REQUIRED
-- MUST be PasswordRecipientInfo as specified in -- MUST be a PasswordRecipientInfo as specified in CMS
-- CMS section 6.2.4 [RFC5652] -- Section 6.2.4 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be set to 0 -- MUST be 0
keyDerivationAlgorithm keyDerivationAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm OID of the key derivation algorithm -- MUST be the algorithm identifier of the key derivation
-- The algorithm MUST be a KM_KD_ALG as specified in RFC-CMP-Alg -- algorithm
-- Section 4.4 -- The algorithm type MUST be a KM_KD_ALG as specified in
-- RFC-CMP-Alg Section 4.4
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm OID of the key wrap algorithm -- MUST be the algorithm identifier of the key wrap algorithm
-- The algorithm MUST be a KM_KW_ALG as specified in RFC-CMP-Alg -- The algorithm type MUST be a KM_KW_ALG as specified in
-- Section 4.3 -- RFC-CMP-Alg Section 4.3
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
4.1.7. Delayed enrollment 4.1.7. Handling delayed enrollment
This functional extension can be applied in combination with This functional extension can be applied in combination with
certificate enrollment as described in Section 4.1.1 to certificate enrollment as described in Section 4.1.1 to
Section 4.1.5. The functional extension can be used in case a PKI Section 4.1.5, optionally including central key generation. The
management entity cannot respond to the certificate request in a functional extension can be used in case a PKI management entity
timely manner, e.g., due to offline upstream communication or cannot respond to the certificate request in a timely manner, e.g.,
required registration officer interaction. Depending on the PKI due to offline upstream communication or required human interaction.
architecture, the entity initiating delayed enrollment is not Depending on the PKI architecture, the entity initiating delayed
necessarily the PKI management entity directly addressed by the EE. enrollment (see also Section 5.1.2) is not necessarily the PKI
management entity addressed by the EE.
Note: According to CMP Updates [I-D.ietf-lamps-cmp-updates] polling Note: According to CMP Updates [I-D.ietf-lamps-cmp-updates] delayed
is also possible for PKI management operations starting with a p10cr enrollment is also possible for PKI management operations starting
request message. with a p10cr request message.
The PKI management entity initiating the delayed enrollment MUST The PKI management entity initiating the delayed enrollment MUST
respond with an ip/cp/kup message including the status "waiting". respond with an ip/cp/kup message including the status "waiting".
When receiving a response with status "waiting" the EE MUST send a When receiving a response with status "waiting" the EE MUST send a
poll request to the same PKI management entity as before. The PKI poll request. The PKI management entity that initiated the delayed
management entity that initiated the delayed enrollment MUST answer enrollment MUST answer with a poll response containing a checkAfter
with a poll response containing a checkAfter time. This value time. This value indicates the minimum number of seconds that SHOULD
indicates the minimum number of seconds that should elapse before the elapse before the EE sends another poll request. This is repeated as
EE sends another poll request. This is repeated as long as no final long as no final response is available or any party involved gives up
response is available or any party involved gives up on the current on the current PKI management operation. When the PKI management
transaction. When the PKI management entity that initiated delayed entity that initiated delayed enrollment can provide the final ip/cp/
enrollment can provide the final ip/cp/kup message for the initial kup message for the initial request of the EE, it MUST provide this
request of the EE, it MUST provide this message in response to a poll message in response to a poll request. After receiving this
request. After receiving this response, the EE can continue the response, the EE can continue the original PKI management operation
original PKI management operation as described in the respective as described in the respective section of this document, i.e.,
section of this document, e.g., sending a certConf message. sending a certConf message if required.
No specific prerequisites apply in addition to those of the
respective certificate enrollment.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format ir/cr/p10cr/kur 1 format ir/cr/p10cr/kur
As described in the
respective section
in this document
2 ->ir/cr/p10cr/kur-> 2 ->ir/cr/p10cr/kur->
3 handle request as described 3 handle or forward request
in the respective section
in this document
4 in case no immediate final 4 in case no immediate final
response is possible, response is possible,
receive or format ip, cp format or receive ip/cp/
or kup message containing kup with status "waiting"
status "waiting"
5 <- ip/cp/kup <- 5 <- ip/cp/kup <-
6 handle ip/cp/kup with status "waiting" 6 handle ip/cp/kup with status "waiting"
-------------------------- start polling -------------------------
7 format pollReq 7 format pollReq
8 -> pollReq -> 8 -> pollReq ->
9 handle, re-protect or 9 handle or forward pollReq
forward pollReq
10 in case the requested 10 in case the requested
certificate or a certificate or a
corresponding response corresponding response
message is available, message is available,
receive or format ip, cp, continue with step 14
or kup containing the otherwise, format or
issued certificate, else receive pollRep with
format or receive pollRep
with appropriate
checkAfter value checkAfter value
11 <- pollRep <- 11 <- pollRep <-
12 handle pollRep 12 handle pollRep
13 let checkAfter 13 let checkAfter
time elapse time elapse and
14 continue with line 7 continue with step 7
----------------- end polling, continue as usual -----------------
14 format or receive
ip/cp/kup
15 possibly grant implicit
confirm
16 <- ip/cp/kup <-
17 handle ip/cp/kup
----------------- if implicitConfirm not granted -----------------
18 format certConf
19 -> certConf ->
20 handle or forward certConf
21 format or receive pkiConf
22 <- pkiConf <-
23 handle pkiConf
Detailed description of the first ip/cp/kup: Detailed description of the first ip/cp/kup:
Response with status 'waiting' -- ip/cp/kup Response with status "waiting" -- ip/cp/kup
Field Value Field Value
header header
-- MUST contain a header as described for the first response -- MUST be as described for the first response message of the
-- message of the respective PKI management operation -- respective PKI management operation
body body
-- The response of the PKI management entity to the request in -- The response of the PKI management entity to the request in
-- case no immediate appropriate response can be sent -- case no immediate final response can be sent
ip/cp/kup REQUIRED ip/cp/kup REQUIRED
response REQUIRED response REQUIRED
-- MUST contain exactly one CertResponse -- MUST contain exactly one CertResponse
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
status REQUIRED status REQUIRED
-- PKIStatusInfo structure MUST be present -- PKIStatusInfo structure MUST be present
status REQUIRED status REQUIRED
-- MUST be "waiting" -- MUST be "waiting"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, logging or to
-- display in a GUI -- display in a GUI
failInfo PROHIBITED failInfo PROHIBITED
certifiedKeyPair PROHIBITED certifiedKeyPair PROHIBITED
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the first response -- MUST be as described for the first response message of the
-- message of the respective PKI management operation, except -- respective PKI management operation, except that the PKI
-- that the PKI management entity that initiated the delayed -- management entity that initiated the delayed enrollment and
-- enrollment and created this response MUST apply its own -- created this response MUST apply its own protection
-- protection
extraCerts REQUIRED extraCerts REQUIRED
-- MUST contain certificates as described for the first response -- MUST be as described for the first response message of the
-- message of the respective PKI management operation. Yet since -- respective PKI management operation. Yet since no newly
-- no new certificate is included yet, no respective certificate -- enrolled certificate is available yet, no respective
-- chain is included -- certificate chain is included
Polling Request -- pollReq Polling Request -- pollReq
Field Value Field Value
header header
-- MUST contain a header as described for the certConf message -- MUST contain a header as described for the certConf message
-- of the respective PKI management operation -- of the respective PKI management operation
body body
-- The message of the EE asks for the final response or for a -- The message of the EE asks for the final response or for a
-- time to check again -- time to check again
pollReq REQUIRED pollReq REQUIRED
-- MUST contain exactly one element -- MUST contain exactly one PollReqContent element
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the certConf message -- MUST be as described for the certConf message of the
-- of the respective PKI management operation -- respective PKI management operation
extraCerts OPTIONAL extraCerts OPTIONAL
-- MUST be as described for the certConf message of the -- MUST be as described for the certConf message of the
-- respective PKI management operation -- respective PKI management operation
Polling Response -- pollRep Polling Response -- pollRep
Field Value Field Value
header header
-- MUST contain a header as described for the pkiConf message -- MUST contain a header as described for the pkiConf message
-- of the respective PKI management operation -- of the respective PKI management operation
body body
-- The message indicates the delay after which the EE may send -- The message indicates the delay after which the EE SHOULD
-- another pollReq message for this transaction -- send another pollReq message for this transaction
pollRep REQUIRED pollRep REQUIRED
-- MUST contain exactly one entry -- MUST contain exactly one PollRepContent entry
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
checkAfter REQUIRED checkAfter REQUIRED
-- time in seconds to elapse before a new pollReq should be sent -- time in seconds to elapse before a new pollReq SHOULD be sent
reason OPTIONAL reason OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, logging or to
-- display in a GUI -- display in a GUI
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the pkiConf message -- MUST be as described for the pkiConf message of the
-- of the respective profile, except that the PKI management -- respectiveprofile, except that the PKI management entity that
-- entity that initiated the delayed enrollment and created this -- initiated the delayed enrollment and created this response
-- response MUST apply its own protection -- MUST apply its own protection
extraCerts OPTIONAL extraCerts OPTIONAL
-- If present, it MUST contain certificates as described for the -- If present, it MUST be as described for the pkiConf message
-- pkiConf message of the respective PKI management operation. -- of the respective PKI management operation.
Final response -- ip/cp/kup Final response -- ip/cp/kup
Field Value Field Value
header header
-- MUST contain a header as described for the first -- MUST be as described for the first response except that the
-- except that the PKI management entity that initiated the -- PKI management entity that initiated the delayed enrollment
-- delayed enrollment MUST replace the recipNonce by be the -- MUST use as recipNonce the senderNonce of the last pollReq
-- senderNonce of the last pollReq message -- message
body body
-- The response of the PKI management entity to the initial -- The response of the PKI management entity to the initial
-- request as described in the respective PKI management -- request as described in the respective PKI management
-- operation -- operation
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the first response -- MUST be as described for the first response message of this
-- message of the respective PKI management operation, except -- PKI management operation, except that the PKI management
-- that the PKI management entity that initiated the delayed -- entity that initiated the delayed enrollment MUST re-protect
-- enrollment MUST re-protect the response message -- the response message
extraCerts REQUIRED extraCerts REQUIRED
-- MUST contain certificates as described for the first -- MUST be as described for the first response message of the
-- response message of the respective PKI management operation -- respective PKI management operation
4.2. Revoking a certificate 4.2. Revoking a certificate
This PKI management operation should be used by an entity to request This PKI management operation should be used by an entity to request
revocation of a certificate. Here the revocation request is used by revocation of a certificate. Here the revocation request is used by
an EE to revoke one of its own certificates. A PKI management entity an EE to revoke one of its own certificates.
could also act as an EE to revoke one of its own certificates.
The revocation request message MUST be signed using the certificate The revocation request message MUST be signed using the certificate
that is to be revoked to prove the authorization to revoke. The that is to be revoked to prove the authorization to revoke. The
revocation request message is signature-protected using this revocation request message is signature-protected using this
certificate. certificate.
An EE requests the revocation of an own certificate at the CA that An EE requests the revocation of an own certificate at the CA that
issued this certificate. The PKI management entity responds with a issued this certificate. The PKI management entity handles the
message that contains the status of the revocation from the CA. request as described in Section 5.1.4 and responds with a message
that contains the status of the revocation from the CA.
Preconditions: Specific prerequisites augmenting the prerequisites in Section 3.4:
1 The certificate the EE wishes to revoke is not yet expired or * The certificate the EE wishes to revoke is not yet expired or
revoked. revoked.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format rr 1 format rr
2 -> rr -> 2 -> rr ->
3 handle, re-protect or 3 handle or forward rr
forward rr 4 format or receive rp
4 format or receive rp 5 <- rp <-
5 <- rp <- 6 handle rp
6 handle rp
For this PKI management operation, the EE MUST include exactly one For this PKI management operation, the EE MUST include exactly one
RevDetails structure in the rr message body. In case no error RevDetails structure in the rr message body. In case no generic
occurred the response to the rr MUST be an rp message containing a error occurred the response to the rr MUST be an rp message
status field with a single set of values. containing a single status field.
Detailed message description: Detailed message description:
Revocation Request -- rr Revocation Request -- rr
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE to revoke its certificate -- The request of the EE to revoke its certificate
rr REQUIRED rr REQUIRED
-- MUST contain exactly one element of type RevDetails -- MUST contain exactly one element of type RevDetails
-- If more revocations are desired, further requests MUST be -- If more revocations are desired, further PKI management
-- packaged in separate PKI Messages -- operations MUST be initiated
certDetails REQUIRED certDetails REQUIRED
-- MUST be present and be of type CertTemplate -- MUST be present and is of type CertTemplate
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the certificate serialNumber attribute of the -- MUST contain the certificate serialNumber attribute of the
-- X.509 certificate to be revoked -- certificate to be revoked
issuer REQUIRED issuer REQUIRED
-- MUST contain the issuer attribute of the X.509 certificate to -- MUST contain the issuer attribute of the certificate to be
-- be revoked -- revoked
crlEntryDetails REQUIRED crlEntryDetails REQUIRED
-- MUST contain exactly one reasonCode of type CRLReason (see -- MUST contain exactly one reasonCode of type CRLReason (see
-- [RFC5280] section 5.3.1) -- [RFC5280] section 5.3.1)
-- If the reason for this revocation is not known or shall not be -- If the reason for this revocation is not known or shall not
-- published the reasonCode MUST be 0 = unspecified -- be published the reasonCode MUST be 0 = unspecified
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 and using the private key related -- As described in Section 3.2 and using the private key related
-- to the certificate to be revoked -- to the certificate to be revoked
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
Revocation Response -- rp Revocation Response -- rp
skipping to change at page 50, line 26 skipping to change at page 57, line 25
rp REQUIRED rp REQUIRED
status REQUIRED status REQUIRED
-- MUST contain exactly one element of type PKIStatusInfo -- MUST contain exactly one element of type PKIStatusInfo
status REQUIRED status REQUIRED
-- positive value allowed: "accepted" -- positive value allowed: "accepted"
-- negative value allowed: "rejection" -- negative value allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, logging or to
-- display in a GUI -- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if and only if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if the status is "accepted"
protection REQUIRED protection REQUIRED
-- As described in section 3.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 3.3 -- As described in section 3.3
4.3. Error reporting 4.3. Support messages
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.
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:
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 The following support messages offer on demand in-band transport of
content relevant to the EE that may be provided by the PKI management content relevant to the EE that may be provided by the PKI management
entity. CMP general messages and general response are used for this entity. CMP general messages and general response are used for this
purpose. Depending on the environment, these requests may be purpose. Depending on the environment, these requests may be
answered by an LRA, RA, or CA. answered by an RA or CA (see also Section 5.1.5).
The general messages and general response messages transport The general messages and general response messages transport
InfoTypeAndValue structures. In addition to those infoType values InfoTypeAndValue structures. In addition to those infoType values
defined in RFC 4210 [RFC4210] further OIDs MAY be used to define new defined in RFC 4210 [RFC4210] and CMP Updates
[I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new
PKI management operations or new general-purpose support messages as PKI management operations or new general-purpose support messages as
needed in specific environments. needed in specific environments.
The following contents are specified in this document: The following contents are specified in this document:
* Get CA certificates * Get CA certificates
* Get root CA certificate update
* Get root CA certificate updates * Get certificate request template
* PGet certificate request templates
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. In the following the aspects common to all general messages (genm)
and general response (genp) messages are described.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format genm 1 format genm
2 -> genm -> 2 -> genm ->
3 handle, re-protect or 3 handle or forward genm
forward genm
4 format or receive genp 4 format or receive genp
5 <- genp <- 5 <- genp <-
6 handle genp 6 handle genp
Detailed message description: Detailed message description:
General Message -- genm General Message -- genm
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- A request by the EE to receive information -- A request by the EE to receive information
genm REQUIRED genm REQUIRED
-- MUST contain exactly one element of type -- MUST contain exactly one element of type InfoTypeAndValue
-- InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying the specific PKI -- MUST be the OID identifying one of the specific PKI
-- management operation described below -- management operations described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific PKI -- MUST be as described in the specific PKI management
-- management operation described below -- operation described below
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
General Response -- genp General Response -- genp
Field Value
Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The response of the PKI management entity to an -- The response of the PKI management entity on an information
-- information request -- request
genp REQUIRED genp REQUIRED
-- MUST contain exactly one element of type -- MUST contain exactly one element of type InfoTypeAndValue
-- InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying the specific PKI -- MUST be the OID identifying the specific PKI management
-- management operation described below -- operation described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific PKI -- MUST be as described in the specific PKI management operation
-- management operation described below -- described below
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
4.4.1. Get CA certificates 4.3.1. Get CA certificates
This PKI management operation can be used by an EE to request CA This PKI management operation can be used by an EE to request CA
certificates from the PKI management entity. certificates from the PKI management entity.
An EE requests CA certificates from the PKI management entity by An EE requests CA certificates, e.g., for chain construction, from an
sending a general message with OID id-it-caCerts as specified in CMP PKI management entity by sending a general message with OID id-it-
Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity caCerts as specified in CMP Updates [I-D.ietf-lamps-cmp-updates].
responds with a general response with the same OID that either The PKI management entity responds with a general response with the
contains a SEQUENCE of certificates populated with the available CA same OID that either contains a SEQUENCE of certificates populated
intermediate and issuing CA certificates or with no content in case with the available intermediate and issuing CA certificates or with
no CA certificate is available. no content in case no CA certificate is available.
The message sequence for this PKI management operation is as given in No specific prerequisites apply in addition to those specified in
Section 4.4, with the following specific content: Section 3.4.
1 the body MUST contain as infoType the OID id-it-caCerts The message sequence for this PKI management operation is as given
above, with the following specific content:
1 the infoType OID to use is id-it-caCerts
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST contain a sequence 3 if present, the infoValue of the response MUST contain a sequence
of certificates of certificates
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
caCerts OID looks like this: caCerts OID looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CA certificate is available -- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available -- MUST be present if CA certificates are available
-- MUST be a sequence of CMPCertificate -- MUST be a sequence of CMPCertificate
4.4.2. Get root CA certificate update 4.3.2. Get root CA certificate update
This PKI management operation can be used by an EE to retrieve any This PKI management operation can be used by an EE to request an
updated root CA Certificate as described in Section 4.4 of RFC 4210 updated root CA Certificate as described in Section 4.4 of RFC 4210
[RFC4210]. [RFC4210].
An EE requests a root CA certificate update from the PKI management An EE requests a root CA certificate update from the PKI management
entity by sending a general message with OID id-it-rootCaKeyUpdate as entity by sending a general message with OID id-it-rootCaKeyUpdate,
specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI optionally including the certificate to be updated in the rootCaCert
management entity responds with a general response with the same OID generalInfo field, as specified in CMP Updates
that either contains the update of the root CA certificate consisting [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds
of up to three certificates, or with no content in case no update is with a general response with the same OID that either contains the
available. 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 The newWithNew certificate is the new root CA certificate and is
REQUIRED to be present in the response message. The newWithOld REQUIRED to be present if available. The newWithOld certificate is
certificate is RECOMMENDED to be present in the response message, REQUIRED to be present in the response message because it is needed
because it is needed for those cases where the receiving entity for the receiving entity trusting the old root CA certificate to gain
trusts the old root CA certificate and wishes to gain trust in the trust in the new root CA certificate. The oldWithNew certificate is
new root CA certificate. It MAY be omitted if the PKI management OPTIONAL because it is only needed in rare scenarios where entities
entity that performed the message protection of the response message do not already trust the old root CA.
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 No specific prerequisites apply in addition to those specified in
Section 4.4, with the following specific content: Section 3.4.
1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate The message sequence for this PKI management operation is as given
above, with the following specific content:
2 the infoValue of the request MUST be absent 1 the infoType OID to use is id-it-rootCaKeyUpdate
3 if present, the infoValue of the response MUST be a 2 the rootCaCert general info field in the header of the request MAY
RootCaKeyUpdate structure contain the root CA certificate the update is requested for
3 the infoValue of the request MUST be absent
4 if present, the infoValue of the response MUST be a
RootCaKeyUpdateContent structure
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
rootCaKeyUpdate extension looks like this: rootCaKeyUpdate extension looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no update of the root CA certificate is -- MUST be absent if no update of the root CA certificate is
-- available -- available
-- MUST be present if an update of the root CA certificate -- MUST be present if an update of the root CA certificate
-- is available and MUST be of type RootCaKeyUpdate -- is available and MUST be of type RootCaKeyUpdate
newWithNew REQUIRED newWithNew REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the new root CA certificate -- MUST contain the new root CA certificate
newWithOld RECOMMENDED newWithOld REQUIRED
-- SHOULD be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain a certificate containing the new public -- MUST contain a certificate containing the new public
-- root CA key signed with the old private root CA key -- root CA key signed with the old private root CA key
oldWithNew OPTIONAL oldWithNew OPTIONAL
-- MAY be present if infoValue is present -- MAY be present if infoValue is present
-- MUST contain a certificate containing the old public -- MUST contain a certificate containing the old public
-- root CA key signed with the new private root CA key -- root CA key signed with the new private root CA key
< TBD: In case the PKI management entity serves for more than one 4.3.3. Get certificate request template
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 This PKI management operation can be used by an EE to request a
template with parameters for a future certificate requests. template with parameters for a future certificate requests.
An EE requests certificate request parameters from the PKI management An EE requests certificate request parameters from the PKI management
entity by sending a general message with OID id-it-certReqTemplate as entity by sending a general message with OID id-it-certReqTemplate as
specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The EE MAY
management entity responds with a general response with the same OID indicate the certificate profile to use in the certProfile extension
that either contains a certificate template containing requirements of the generalInfo field in the PKIHeader of the general message as
on certificate fields and extensions and optionally a keySpec field described in Section 3.1. The PKI management entity responds with a
general response with the same OID that either contains requirements
on the certificate request template, or with no content in case no
specific requirements are imposed by the PKI. The
CertReqTemplateValue contains requirements on certificate fields and
extensions in a certTemplate. Optionally it contains a keySpec field
containing requirements on algorithms acceptable for key pair containing requirements on algorithms acceptable for key pair
generation, or with no content in case no specific requirements are generation.
imposed by the PKI.
The EE SHOULD follow the requirements from the received CertTemplate The EE SHOULD follow the requirements from the received CertTemplate,
and the optional keySpec field, by including in the certTemplate of by including in the certificate requests all the fields requested,
certificate requests all the fields requested, taking over all the taking over all the field values provided and filling in any
field values provided and filling in any remaining fields values. remaining fields values. The EE SHOULD NOT add further fields, name
The EE SHOULD NOT add further CertTemplate fields, Name components, components, and extensions or their (sub-)components.
and extensions or their (sub-)components.
Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order 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 to allow more flexibility in case the rules given here are not
sufficient for specific scenarios. The EE can populate the sufficient for specific scenarios. The EE can populate the
certificate request as wanted and ignore any of the requirements certificate request as wanted and ignore any of the requirements
contained in the CertReqTemplate response message. On the other contained in the CertReqTemplateValue. On the other hand, a PKI
hand, a PKI management entity is free to ignore or replace any parts management entity is free to ignore or replace any parts of the
of the content of the certificate request provided by the EE. The content of the certificate request provided by the EE. The
CertReqTemplate PKI management operation offers means to ease a joint CertReqTemplate PKI management operation offers means to ease a joint
understanding which fields and/or which field values should be used. understanding which fields and/or which field values should be used.
An example is provided in Appendix A.
In case a field of type Name, e.g., issuer or subject, is present in In case a field of type Name, e.g., subject, is present in the
the CertTemplate but has the value NULL-DN (i.e., has an empty list CertTemplate but has the value NULL-DN (i.e., has an empty list of
of RDN components) the field SHOULD be included in the certTemplate RDN components), the field SHOULD be included in the certificate
and filled with content provided by the EE. Similarly, in case an request and filled with content provided by the EE. Similarly, in
X.509v3 extension is present but its extnValue is empty this means case an X.509v3 extension is present but its extnValue is empty, this
that the extension SHOULD be included and filled with content means that the extension SHOULD be included and filled with content
provided by the EE. In case a Name component, for instance a common 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 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- SHOULD fill in a value. Similarly, in case an extension has sub-
components (e.g., an IP address in a SubjectAltName field) with empty components (e.g., an IP address in a SubjectAltName field) with empty
value, the EE SHOULD fill in a value. value, the EE SHOULD fill in a value.
The EE MUST ignore (i.e., not include and fill in) empty fields, The EE MUST ignore (i.e., not include and fill in) empty fields,
extensions, and sub-components that it does not understand or does extensions, and sub-components that it does not understand or does
not know suitable values to be filled in. not know suitable values to be filled in.
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate The publicKey field of type SubjectPublicKeyInfo in the CertTemplate
MUST be omitted. In case the PKI management entity wishes to make of the CertReqTemplateValue MUST be omitted. In case the PKI
stipulation on supported algorithms the EE may use for key management entity wishes to make stipulation on algorithms the EE may
generation, this MUST be specified using the control fields as use for key generation, this MUST be specified using the keySpec
specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates].
The keySpec field, if present, specifies the public key types and The keySpec field, if present, specifies the public key types
lengths for which a certificate may be requested. optionally with parameters, and/or RSA key lengths for which a
certificate may be requested.
The value of a keySpec with the OID id-regCtrl-algId, as specified in The value of a keySpec element with the OID id-regCtrl-algId, as
CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of type specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of
AlgorithmIdentitier and gives an algorithm other than RSA. For EC type AlgorithmIdentifier and give an algorithm other than RSA. For
keys the full curve information MUST be specified as described in the EC keys the curve information MUST be specified as described in the
respective standard documents. respective standard documents.
The value of a keySpec with the OID id-regCtrl-rsaKeyLen, as The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as
specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of
type Integer and gives an RSA key length. type Integer and give an RSA key length.
The PKI management entity responds with a general response with the In the CertTemplate of the CertReqTemplateValue the serialNumber,
same OID that either contains a certificate template containing signingAlg, issuerUID, and subjectUID fields MUST be omitted.
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 Specific prerequisites augmenting the prerequisites in Section 3.4:
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, * When using the generalInfo field certProfile, the EE MUST know the
publicKey, issuerUID, and subjectUID fields MUST be omitted. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is as given in The message sequence for this PKI management operation is as given
Section 4.4, with the following specific content: above, with the following specific content:
1 the body MUST contain as infoType the OID id-it-certReqTemplate 1 the infoType OID to use is id-it-certReqTemplate
2 the infoValue of the request MUST be absent 2 the certProfile generalInfo field in the header of the request MAY
contain the name of the requested certificate request template
3 if present, the infoValue of the response MUST be a CertTemplate 3 the infoValue of the request MUST be absent
structure and an optional SEQUENCE of AttributeTypeAndValue with
attribute type id-regCtrl-algId or id-regCtrl-rsaKeyLen 4 if present, the infoValue of the response MUST be a
CertReqTemplateValue containing a CertTemplate structure and an
optional keySpec field
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
certReqTemplate OID looks like this: certReqTemplate OID looks like this:
InfoValue OPTIONAL InfoValue OPTIONAL
-- MUST be absent if no requirements are available -- MUST be absent if no requirements are available
-- MUST be present if the PKI management entity has any -- MUST be present if the PKI management entity has any
-- requirements on the content of the certificates template -- requirements on the contents of the certificate template
certTemplate REQUIRED certTemplate REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the prefilled CertTemplate structure elements -- MUST contain the required CertTemplate structure elements
-- The SubjectPublicKeyInfo MUST contain no algorithm ID i.e., -- The SubjectPublicKeyInfo field MUST be absent
-- the null OBJECT IDENTIFIER) in the algorithm field and a
-- zero-length BIT STRING in the subjectPublicKey field
keySpec OPTIONAL keySpec OPTIONAL
-- MUST be absent if no requirements on the public key are -- MUST be absent if no requirements on the public key are
-- available MUST be present if the PKI management entity has any -- available
-- requirements on the key generation -- MUST be present if the PKI management entity has any
-- MUST contain one AttributeTypeAndValue per supported algorithm -- requirements on the keys generated
-- with attribute id-regCtrl-algId or id-regCtrl-rsaKeyLen -- MUST contain one AttributeTypeAndValue per supported
-- algorithm with attribute id-regCtrl-algId or
-- id-regCtrl-rsaKeyLen
< TBD: In case the PKI management entity offers for more than one set 5. PKI management entity operations
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 request processing by a PKI management
entity. Depending on the network and PKI solution design, this can
be an RA or CA, any of which may include protocol conversion or
central key generation (i.e., acting as a KGA).
This section focuses on the communication among PKI management A PKI management entity may directly respond to request messages from
entities. Depending on the network and PKI solution design, these downstream and report errors. In case the PKI management entity is
can be LRAs, RAs, and CAs. an RA it typically forwards the received request messages upstream
after checking them and forwards respective response messages
downstream. Besides responding to messages or forwarding them, a PKI
management entity may request or revoke certificates on behalf of
EEs. A PKI management entity may also need to manage its own
certificates and thus act as an EE using the PKI management
operations specified in Section 4.
A PKI management entity typically forwards request messages from 5.1. Responding to requests
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 The PKI management entity terminating the PKI management operation at
CMP level MUST respond to all received requests by returning a
related CMP response message or an error. Any intermediate PKI
management entity MAY respond depending on the PKI configuration and
policy.
In case the PKI solution consists of several PKI management entities, In addition to the checks described in Section 3.5, the responding
each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or PKI management entity SHOULD check that a request that initiates a
certConf) or error message coming from an EE or any other downstream new PKI management operation does not use a transactionID that is
PKI management entity MUST be sent to the next (upstream) PKI currently in useThe failInfo bit value to use on reporting failure as
management entity. Any received response message MUST be forwarded described in Section 3.6.4 is transactionIdInUse. If any of these
downstream to the next PKI management entity or EE. verification steps or any of the essential checks described in the
below subsections fails, the PKI management entity MUST proceed as
described in Section 3.6.
The PKI management entity SHOULD verify the protection, the syntax, The responding PKI management entity SHOULD copy the sender field of
the required message fields, the message type, and if applicable the the request to the recipient field of the response, MUST copy the
authorization and the proof-of-possession of the message. Additional senderNonce of the request to the recipNonce of the response, and
checks or actions MAY be applied depending on the PKI solution MUST use the same transactionID for the response.
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 5.1.1. Responding to a certificate request
An ir/cr/p10cr/kur message is used to request a certificate as
described in Section 4.1. The responding PKI management entity MUST
proceed as follows unless it initiates delayed enrollment as
described in Section 5.1.2.
The PKI management entity SHOULD check the message body according to
the applicable requirements from Section 4.1. Possible failInfo bit
values used for error reporting in case a check failed include
badCertId and badCertTemplate. It MUST verify the presence and value
of the proof-of-possession (failInfo bit: badPOP), unless central key
generation is requested. In case the special POP value "raVerified"
is given, it SHOULD check that the request message was signed using a
certificate containing the cmcRA extended key usage (failInfo bit:
notAuthorized). The PKI management entity SHOULD perform also any
further checks on the certTemplate contents (failInfo:
badCertTemplate) according to any applicable PKI policy and
certificate profile.
If the requested certificate is available, the PKI management entity
MUST respond with a positive ip/cp/kup message as described in
Section 4.1.
Note: If central key generation is performed by the responding PKI
management entity, the responding PKI management entity MUST include
in the response the privateKey field as specified in Section 4.1.6.
It may have issued the certificate for the newly generated key pair
itself if it is a CA, or have requested the certificate on behalf of
the EE as described in Section 5.3.1, or have received it by other
means from a CA.
The prerequisites of the respective PKI management operation as
specified in Section 4.1 apply.
Note: If the EE requested omission of the certConf message, the PKI
management entity SHOULD handle it as described in Section 4.1.1 and
therfore MAY grant this by including the implicitConfirm extension in
the response header.
5.1.2. 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 use the status "waiting" in the response message as described in
Section 4.1.7 and then MUST reply to pollReq messages as described
there.
Typically, as stated in Section 5.2.3, an intermediate PKI management
entity SHOULD NOT change the sender and recipient nonces even in case
it modifies a request or a response message. In the special case of
delayed enrollment 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 this PKI management
entity, pollReq and pollRep messages are exchanged handling the
nonces as usual. Yet when, after some pollRep, the final response
from upstream arrives at the PKI management entity, this response
contains the recipNonce copied (as usual) from the senderNonce in the
original request message. The PKI management entity that initiated
the delayed enrollment MUST 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.
The prerequisites of the respective PKI management operation as
specified in Section 4.1.7 apply.
5.1.3. Responding to a confirmation message
A PKI management entity MUST handle a certConf message if it has
responded before with a positive ip/cp/kup message not granting
implicit confirmation. It SHOULD check the message body according to
the requirements given in Section 4.1.1 (failInfo bit: badCertId) and
react as described there.
The prerequisites of the respective PKI management operation as
specified in Section 4.1 apply.
5.1.4. Responding to a revocation request
An rr message is used to request revocation of a certificate. The
responding PKI management entity SHOULD check the message body
according to the requirements in Section 4.2. It MUST make sure that
the referenced certificate exists (failInfo bit: badCertId), has been
issued by the addressed CA, and is not already expired or revoked
(failInfo bit: certRevoked). On success it MUST respond with a
positive rp message as described in Section 4.2.
No specific prerequisites apply in addition to those specified in
Section 3.4.
5.1.5. Responding to a support message
A genm message is used to retrieve extra content. The responding PKI
management entity SHOULD check the message body according to the
applicable requirements in Section 4.3 and perform any further checks
depending on the PKI policy. On success it MUST respond with a genp
message as described there.
No specific prerequisites apply in addition to those specified in
Section 3.4.
5.2. Forwarding messages
In case the PKI solution consists of intermediate PKI management
entities (i.e., LRA or RA), each CMP request message coming from an
EE or any other downstream PKI management entity SHOULD be forwarded
to the next (upstream) PKI management entity as described in this
section and otherwise MUST be answered as described in Section 5.1.
Any received response message or error message MUST be forwarded to
the next (downstream) PKI entity.
In addition to the checks described in Section 3.5, the forwarding
PKI management entity MAY verify the proof-of-possession for
ir/cr/p10cr/kur messages. If one of these verification procedures
fails, the RA proceeds as described in Section 3.6.
A PKI management entity SHOULD NOT change the received message unless
necessary. The PKI management entity SHOULD only update the message necessary. The PKI management entity SHOULD only update the message
protection if this is technically necessary. Concrete PKI system protection and the certificate template in a certificate request
message if this is technically necessary. Concrete PKI system
specifications may define in more detail when to do so. specifications may define in more detail when to do so.
This is particularly relevant in the upstream communication of a This is particularly relevant in the upstream communication of a
request message. request message.
Each hop in a chain of PKI management entity has one or more Each forwarding PKI management entity has one or more
functionalities, e.g., a PKI management entity may functionalities. It may
* verify the identities of EEs or base authorization decisions for * verify the identities of EEs and make authorization decisions for
certification request processing on specific knowledge of the certification request processing based on specific knowledge of
local setup, e.g., by consulting an inventory or asset management the local setup, e.g., by consulting an inventory or asset
system, management system,
* add fields to certificate request messages, * add or modify fields of certificate request messages,
* store data from a message in a database for later usage or audit * store data from a message in a database for later usage or audit
purposes, purposes,
* provide traversal of a network boundary, * provide traversal of a network boundary,
* replace a MAC-based protection by a signature-based protection * replace a MAC-based protection by a signature-based protection
that can be verified also further upstream, that can be verified also further upstream,
* double-check if the messages transferred back and forth are * double-check if the messages transferred back and forth are
properly protected and well-formed, properly protected and well-formed,
* provide an authentic indication that it has performed all required * provide an authentic indication that it has performed all required
checks, checks,
* initiate a delayed enrollment due to offline upstream * initiate a delayed enrollment due to offline upstream
communication or registration officer interaction, communication or human interaction, or
* grant the request of an EE to omit sending a confirmation message,
or
* collect messages from ultiple LRAs and forward them jointly. * collect messages from multiple RAs and forward them jointly.
Therefore, the decision if a message should be forwarded The decision if a message should be forwarded
* unchanged with the original protection, * unchanged with the original protection,
* unchanged with a new protection, or * unchanged with a new protection, or
* changed with a new protection * changed with a new protection
depends on the PKI solution design and the associated security policy depends on the PKI solution design and the associated security policy
(CP/CPS [RFC3647]). (CP/CPS [RFC3647]).
This section specifies the options a PKI management entity may A PKI management entity MUST replace or add a protection of a message
implement and use. if it
A PKI management entity MAY update the protection of a message if it
* performs changes to the header or the body of the message,
* needs to securely indicate that it has done checks or validations * needs to securely indicate that it has done checks or validations
on the message to one of the next (upstream) PKI components, on the message to one of the next (upstream) PKI management entity
or
* needs to protect the message using a key and certificate from a * needs to protect the message using a key and certificate from a
different PKI, or different PKI.
* needs to replace or produce a MAC-based protection. A PKI management entity MUST replace a protection of a message if it
* performs changes to the header or the body of the message or
* needs to convert from or to a MAC-based protection.
This is particularly relevant in the upstream communication of This is particularly relevant in the upstream communication of
certificate request messages. certificate request messages.
Note that the message protection covers only the header and the body Note that the message protection covers only the header and the body
and not the extraCerts. The PKI management entity MAY change the and not the extraCerts. The PKI management entity MAY change the
extraCerts in any of the following message adaptations, e.g., to extraCerts in any of the following message adaptations, e.g., to
sort, add, or delete certificates to support the next hop. This may sort, add, or delete certificates to support subsequent PKI entities.
be particularly helpful to augment upstream messages with additional This may be particularly helpful to augment upstream messages with
certificates or to reduce the number of certificates in downstream additional certificates or to reduce the number of certificates in
messages when forwarding to constrained devices. downstream messages when forwarding to constrained devices.
5.1.1. Not changing protection 5.2.1. Not changing protection
This variant means that a PKI management entity forwards a CMP This variant means that a PKI management entity forwards a CMP
message without changing the header, body, or protection. In this message without changing the header, body, or protection. In this
case the PKI management entity acts more like a proxy, e.g., on a case the PKI management entity acts more like a proxy, e.g., on a
network boundary, implementing no specific RA-like security network boundary, implementing no specific RA-like security
functionality that require an authentic indication to the PKI. Still functionality that requires an authentic indication to the PKI.
the PKI management entity might implement checks that result in Still the PKI management entity might implement checks that result in
refusing to forward the request message and instead responding with refusing to forward the request message and instead responding as
an error message as specified in Section 5.3. specified in Section 3.6.
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.
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.
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 This variant of forwarding a message or the one described in
structure of the modified message as follows: Section 5.2.2.1 SHOULD be used for kur messages and for central key
generation.
popo No specific prerequisites apply in addition to those specified in
raVerified REQUIRED Section 3.4.
-- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original
-- message
5.1.3. Adding Protection 5.2.2. Adding protection and batching of messages
This variant of forwarding a message means that a PKI management This variant of forwarding a message means that a PKI management
entity adds another protection to PKI management messages before entity adds another protection to PKI management messages before
forwarding them. Applying an additional protection is specifically forwarding them.
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 The nested message is a PKI management message containing a
PKIMessages sequence as its body containing one or more CMP messages. 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 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 CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases
for adding another protection by a PKI management entity. Specific for adding another protection by a PKI management entity. Specific
procedures are described in more detail in the following sections. procedures are described in more detail in the following sections.
The behavior in case an error occurs is described in Section 4.3.
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: Detailed message description:
Nested Message - nested Nested Message - nested
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
skipping to change at page 64, line 39 skipping to change at page 69, line 45
PKIMessages REQUIRED PKIMessages REQUIRED
-- MUST be a sequence of one or more CMP messages -- MUST be a sequence of one or more CMP messages
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 using the CMP protection key of -- As described in Section 3.2 using the CMP protection key of
-- the PKI management entity -- the PKI management entity
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
5.1.3.1. Handling a single PKI management message 5.2.2.1. Adding protection to a request message
A PKI management entity may authentically indicate successful A PKI management entity may authentically indicate successful
validation and authorization of a PKI management message by adding an validation and approval of a request message by adding an extra
additional signature to the original PKI management message. signature to the original message.
A PKI management entity SHALL wrap the original PKI management By adding a protection using its own CMP protecting key the PKI
messages in a nested message structure. The additional signature as management entity provides a proof of verifying and approving the
prove of verification and authorization by the PKI management entity message as described above. Thus, the PKI management entity acts as
MUST be applied as signature-based message protection of the nested an actual Registration Authority (RA), which implements important
message. security functionality of the PKI. Applying an additional protection
is specifically relevant when forwarding a message that requests a
certificate update or central key generation. This is because the
original protection of the EE must be preserved while adding an
indication of approval by the PKI management entity.
5.1.3.2. Handling a batch of PKI management messages The PKI management entity wrapping the original request message in a
nested message structure MUST take over the recipient, recipNonce,
and transactionID of the original message to the nested message and
apply signature-based protection. The additional signature serves as
proof of verification and authorization by this PKI management
entity.
The PKI management entity receiving such a nested message that
contains a single request message MUST validate the additional
protection signature on the nested message and check the
authorization for the approval it implies.
The PKI management entity responding to the request contained in the
nested message sends the response message as described in
Section 5.1, without wrapping it in a nested message.
Note: This form of nesting messages is characterized by the fact that
the transactionID in the header of the nested message is the same as
the one used in the included message.
Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST have the authorization to perform
the validation and approval of the respective request according to
the PKI policies.
Message flow:
Step# PKI management entity PKI management entity
1 format nested
2 -> nested ->
3 handle or forward nested
4 format or receive response
5 <- response <-
6 forward response
5.2.2.2. Batching messages
A PKI management entity MAY bundle any number of PKI management A PKI management entity MAY bundle any number of PKI management
messages for batch processing or to transfer a bulk 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. messages using the nested message structure. In this use case,
Nested messages can be used on the upstream interface towards the nested messages are used both on the upstream interface towards the
next PKI management entity and/or on the downstream interface from next PKI management entity and on the downstream interface from the
the PKI management entity towards the EE. PKI management entity towards the EE.
This PKI management operation is typically used on the interface This PKI management operation is typically used on the interface
between LRA and RA to bundle several PKI management messages for between an LRA and an RA to bundle several messages for offline
offline transport. In this case the LRA needs to initiate delayed transport. In this case the LRA needs to initiate delayed enrollment
enrollment as described in Section 5.1.4. If the RA may need as described in Section 5.1.2. If the RA needs different routing
different routing information per nested PKI management message a information per nested PKI management message a suitable mechanism
suitable mechanism may need to be implemented. This mechanism may need to be implemented. Since this mechanism strongly depends on
strongly depends on the requirements of the target architecture. the requirements of the target architecture, it is out of scope of
Therefore, it is out of scope of this document. this document.
An initial nested message is generated locally at the PKI management A nested message containing requests is generated locally at the PKI
entity. For the initial nested message, the PKI management entity management entity. For the upstream nested message, the PKI
acts as a protocol end point and therefore a fresh transactionId and management entity acts as a protocol end point and therefore a fresh
a fresh senderNonce MUST be used in the header of the nested message. transactionID and a fresh senderNonce MUST be used in the header of
The recipient field MUST identify the PKI management entity that is the nested message. An upstream nested message may contain request
expected to unpack the nested message. An initial nested message may messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm.
contain request messages, e.g., ir, cr, p10cr, kur, certConf, rr, or While building the upstream nested message the PKI management entity
genm. While building the initial nested message the PKI management SHOULD store the sender, transactionID, and senderNonce fields of all
entity SHOULD store the transactionIds and the senderNonces of all bundled messages together with the transactionID of the upstream
bundled messages together with the transactionId of the initial
nested message. nested message.
Such an initial nested message is sent to the next PKI management Such an upstream nested message is sent to the next PKI management
entity, which MUST unbundle the included request messages and handle entity. The upstream PKI management entity that unbundles it MUST
each of them as usual. It SHOULD answer with a responding nested handle each of the included request messages as usual. It MUST
message. This responding message MUST use the transactionId of the answer with a downstream nested message. This downstream nested
initial nested message and return the senderNonce of the initial message MUST use the transactionID of the upstream nested message and
nested message as recipNonce of the responding nested message. The return the senderNonce of the upstream nested message as the
responding nested message SHOULD bundle the individual response recipNonce of the downstream nested message. The downstream nested
messages (e.g., ip, cp, kup, pkiconf, rp, genp, error) for all message SHOULD bundle the individual response messages (e.g., ip, cp,
original request messages of the initial nested message. While kup, pollRep, pkiConf, rp, genp, error) for all original request
unbundling the responding nested message, the former PKI management messages of the upstream nested message. While unbundling the
entity can determine lost and unexpected responses based on the downstream nested message, the former PKI management entity can
previously stored transactionIds and senderNonces. When it forwards determine lost and unexpected responses based on the previously
the unbundled responses, any extra messages SHOULD be dropped, and stored transactionIDs. When it forwards the unbundled responses, any
any missing message SHOULD be replaced by an error message to inform extra messages SHOULD be dropped, and any missing response message
the respective EE about the failed certificate management operation. (failInfo bit: systemUnavail) MUST be answered with an error message
to inform the respective requester about the failed certificate
management operation.
The PKI management entity building the nested message applies a Note: This form of nesting messages is characterized by the fact that
signature-based protection using its CMP protection key as transport the transactionID in the header of the nested message is different to
protection. This protection SHALL NOT be regarded as an indication those used in the included messages.
of verification or approval of the bundled PKI request messages.
5.1.4. Initiating delayed enrollment The protection of the nested messages SHOULD NOT be regarded as an
indication of verification or approval of the bundled PKI request
messages.
This functional extension can be used by a PKI management entity to No specific prerequisites apply in addition to those specified in
initiate delayed enrollment. In this case a PKI management entity Section 3.4.
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 Message flow:
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 Step# PKI management entity PKI management entity
1 format nested
2 -> nested ->
3 handle or forward nested
4 format or receive nested
5 <- nested <-
6 handle nested
This PKI management operation can be used by a PKI management entity 5.2.3. Replacing protection
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: The following two alternatives can be used by any PKI management
entity forwarding a CMP message with or without changes while
providing its own protection and in this way asserting approval of
the message.
1 the certificate to be revoked MUST be known to the PKI management By replacing the existing protection using its own CMP protecting key
entity the PKI management entity provides a proof of verifying and approving
the message as described above. Thus, the PKI management entity acts
as an actual Registration Authority (RA), which implements important
security functionality of the PKI.
2 the PKI management entity MUST have the authorization to revoke Before replacing the existing protection by a new protection, the PKI
the certificates of other entities issued by the corresponding CA management entity MUST verify the protection provided and approve its
content, including any modifications that it may perform. It MUST
also check that the sender, as authenticated by the message
protection, is authorized for the given operation.
The message sequence for this PKI management operation is identical These message adaptations MUST NOT be applied to kur messages
to that given in Section 4.2, with the following changes: 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.
1 it is not required that the certificate to be revoked is not yet These message adaptations MUST NOT be applied to certificate request
expired or revoked messages described in for central key generation Section 4.1.6 since
their original protection needs to be preserved up to the Key
Generation Authority, which needs to use it for encrypting the new
private key for the EE.
2 the PKI management entity acts as EE for this message exchange In both the kur and central key generation cases, if a PKI management
entity needs to state its approval of the original request message it
MUST provide this using a nested message as specified in
Section 5.2.2.1.
3 the rr message MUST be signed using the CMP protection key of the When an intermediate PKI management entity modifies a message, it
PKI management entity. SHOULD NOT change the transactionID nor the sender and recipient
nonces except as stated for delayed enrollment in Section 4.1.7 and
Section 5.1.2.
5.3. Error reporting 5.2.3.1. Not changing any included proof-of-possession
This functionality should be used by the PKI management entity to This variant of forwarding a message means that a PKI management
report any arising error conditions downstream to the EE. Note that entity forwards a CMP message with or without modifying the message
error reporting by the EE upstream to the PKI management entity is header or body while preserving any included proof-of-possession.
described in Section 4.3.
In case the error condition is related to specific details of an ir, In case the PKI management entity breaks an existing proof-of-
cr, p10cr, or kur request message it MUST be reported in the specific possession, the message adaptation described in Section 5.2.3.2 needs
response message, i.e., an ip, cp, or kup with negative contents. to be applied instead.
General error conditions, e.g., problems with the message header, Specific prerequisites augmenting the prerequisites in Section 3.4:
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 PKI management entity MUST have the authorization to perform
the PKIStatusInfo structure of the respective message as described in the validation and approval of the respective request according to
Section 4.3. the PKI policies.
An EE receiving any such negative feedback SHOULD log the error 5.2.3.2. Breaking proof-of-possession
appropriately and MUST terminate the current transaction.
This variant of forwarding a message needs to be used if a PKI
management entity breaks a signature-based proof-of-possession in a
certificate request message, for instance because it forwards an ir
or cr message with modifications of the certTemplate, i.e.,
modification, addition, or removal of fields.
The PKI management entity MUST verify the proof-of-possession
contained in the original message using the included public key. If
successful, the PKI management entity MUST change the popo field
value to raVerified.
Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST have the authorization to verify
the proof-of-possession.
* The PKI management entity MUST have the authorization to perform
the validation and approval of the respective request according to
the PKI policies.
The new popo field MUST contain the raVerified choice in the certReq
structure of the modified message as follows:
popo
raVerified REQUIRED
-- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original message
5.3. Acting on behalf of other PKI entities
A PKI management entity may need to request a PKI management
operation on behalf of another PKI entity. In this case the PKI
management entity initiates the respective PKI management operation
as described in Section 4 acting in the role of the EE.
5.3.1. Requesting certificates
A PKI management entity may use on of the PKI management operations
described in Section 4.1 to request a certificate on behalf of
another PKI entity. It either generates the key pair itself and
inserts the new public key in the subjectPublicKey field of the
request certTemplate, or it uses a certificate request received from
downstream, e.g., by means of a different protocol. In the latter
case it SHOULD verify the received proof-of-possession.
No specific prerequisites apply in addition to those specified in
Section 4.1.
Note: An upstream PKI management entity will not be able to
differentiate this PKI management operation from the one described in
Section 5.2.3.
The message sequence for this PKI management operation is identical
to the respective PKI management operation given in Section 4.1, with
the following changes:
1 The request messages MUST be signed using the CMP protection key
of the PKI management entity taking the role of the EE in this
operation.
2 If inclusion of a proper proof-of-possession is not possible the
PKI management entity MUST verify the POP provided from downstream
and use "raVerified" in its upstream request.
5.3.2. Revoking a certificate
A PKI management entity may use the PKI management operation
described in Section 4.2 to revoke a certificate of another PKI
entity. This revocation request message MUST be signed by the PKI
management entity using its own CMP protection key to prove to the
PKI authorization to revoke the certificate on behalf of that PKI
entity.
No specific prerequisites apply in addition to those specified in
Section 4.2.
Note: An upstream PKI management entity will not be able to
differentiate this PKI management operation from the ones described
in Section 5.2.3.
The message sequence for this PKI management operation is identical
to that given in Section 4.2, with the following changes:
1 The rr message MUST be signed using the CMP protection key of the
PKI management entity taking the role of the EE in this operation.
6. CMP message transport mechanisms 6. CMP message transport mechanisms
The CMP messages are designed to be self-contained, such that in The CMP messages are designed to be self-contained, such that in
principle any transport can be used. HTTP SHOULD be used for online principle any transport can be used. HTTP SHOULD be used for online
transport while file-based transport MAY be used in case offline transport while file-based transport MAY be used in case offline
transport is required. In case HTTP transport is not desired or transport is required. In case HTTP transport is not desired or
possible, CMP messages MAY also be piggybacked on any other reliable possible, CMP messages MAY also be piggybacked on any other reliable
transport protocol such as CoAP [RFC7252]. transport protocol such as CoAP [RFC7252].
Independently of the means of transport it can happen that messages Independently of the means of transport, it can happen that messages
are lost or that a communication partner does not respond. To are lost or that a communication partner does not respond. To
prevent waiting indefinitely, each CMP client component SHOULD use a prevent waiting indefinitely, each CMP client component SHOULD use a
configurable per-request timeout, and each CMP server component configurable per-request timeout, and each CMP server component
SHOULD use a configurable per-response timeout in case a further SHOULD use a configurable per-response timeout in case a further
message is to be expected from the client side. In this way a Request message is to be expected from the client side within the
hanging transaction can be closed cleanly with an error and related same transaction. In this way a hanging transaction can be closed
resources (for instance, any cached extraCerts) can be freed. cleanly with an error as described in Section 3.6 (failInfo bit:
systemUnavail) and related resources (for instance, any cached
extraCerts) can be freed.
When conveying a CMP messages in HTTP or MIME-based transport When conveying a CMP messages in HTTP, CoAP, or MIME-based transport
protocols the internet media type "application/pkixcmp" MUST be set protocols, the internet media type "application/pkixcmp" MUST be set
for transport encoding as specified in Section 5.3 of RFC 2510 for transport encoding as specified in Section 5.3 of RFC 2510
[RFC2510] and Section 3.4 of RFC 6712 [RFC6712]. [RFC2510], Section 2.4 of CMP over CoAP
[I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP
[RFC6712].
Note: When using TCP as reliable transport layer protocol, which is Note: When using TCP as reliable transport layer protocol, which is
typical in conjunction with HTTP, there is the option to keep the typical in conjunction with HTTP, there is the option to keep the
connection open over the lifetime of transactions containing multiple connection open over the lifetime of the PKI management operation
request-response message pairs. This may improve efficiency but is containing multiple request-response message pairs. This may improve
not required from a security point of view. efficiency but is not required from a security point of view.
6.1. HTTP transport 6.1. HTTP transport
This transport mechanism can be used by a PKI entity to transfer CMP This transport mechanism can be used by a PKI entity to transfer CMP
messages over HTTP. If HTTP transport is used the specifications as messages over HTTP. If HTTP transport is used the specifications as
described in [RFC6712] and updated by CMP Updates described in [RFC6712] and updated by CMP Updates
[I-D.ietf-lamps-cmp-updates] MUST be followed. [I-D.ietf-lamps-cmp-updates] MUST be followed.
PKI management operations SHOULD use the following URI path: PKI management operations SHOULD use the following URI paths. When a
single request message is nested as described in Section 5.2.2.1, the
endpoint to use is the same as for the underlying request message.
For MAC-based protection the endpoint of the respective message body
SHALL be used, e.g, use /initialization for ir messages.
+=================================+=====================+=========+ +=================================+=====================+=========+
| PKI management operation | Path | Details | | PKI management operation | Path | Details |
+=================================+=====================+=========+ +=================================+=====================+=========+
| Enroll client to new PKI | /initialization | Section | | Enroll client to new PKI | /initialization | Section |
| | | 4.1.1 | | | | 4.1.1 |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
| Enroll client to existing PKI | /certification | Section | | Enroll client to existing PKI | /certification | Section |
| | | 4.1.2 | | | | 4.1.2 |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
skipping to change at page 68, line 51 skipping to change at page 77, line 31
| generation | | 4.1.6 | | generation | | 4.1.6 |
| | | | | | | |
| Note: This path element MAY | | | | Note: This path element MAY | | |
| also be appended to each of the | | | | also be appended to each of the | | |
| path elements listed above. | | | | path elements listed above. | | |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
| Revoke client certificate | /revocation | Section | | Revoke client certificate | /revocation | Section |
| | | 4.2 | | | | 4.2 |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
| Get CA certificates | /getcacert | Section | | Get CA certificates | /getcacert | Section |
| | | 4.4.1 | | | | 4.3.1 |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
| Get root CA certificate update | /getrootupdate | Section | | Get root CA certificate update | /getrootupdate | Section |
| | | 4.4.2 | | | | 4.3.2 |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
| Get certificate request | /getcertreqtemplate | Section | | Get certificate request | /getcertreqtemplate | Section |
| template | | 4.4.3 | | template | | 4.3.3 |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
| Additional protection | /nested | Section | | Batching messages | /nested | Section |
| | | 5.1.3 | | | | 5.2.2.2 |
| Note: This path element is | | | | Note: This path element is | | |
| applicable only between PKI | | | | applicable only between PKI | | |
| management entities. | | | | management entities. | | |
+---------------------------------+---------------------+---------+ +---------------------------------+---------------------+---------+
Table 9: HTTP endpoints Table 9: HTTP endpoints
Subsequent certConf, error, and pollReq messages are sent to the URI Subsequent certConf and pollReq messages are sent to the URI of the
of the respective PKI management operation. first request message of the respective PKI management operation.
The PKI entity will recognize by the HTTP response status code if a By sending a request to its preferred enrollment endpoint, the PKI
configured URI is supported by the PKI management entity by sending a entity will recognize via the HTTP response status code whether a
request to its preferred enrollment endpoint. configured URI is supported by the PKI management entity.
6.2. HTTPS transport using certificates In case a PKI management entity receives an unexpected HTTP status
code from upstream, it MUST respond downstream with an error message
as described in Section 3.6 using a failInfo bit corresponding to the
status code, e.g., systemFailure.
This transport mechanism can be used by a PKI entity to further For certificate management the major security goal is integrity and
protect the HTTP transport described in Section 6.1 using TLS 1.2 data origin authentication. For delivery of centrally generated
[RFC5246] or TLS 1.3 [RFC8446] with certificate-based authentication keys, also confidentiality is a must. These goals are sufficiently
as described in [RFC2818]. Using this transport mechanism, the CMP achieved by CMP itself, also in an end-to-end fashion. If a second
line of defense is required or general privacy concerns exist, TLS
can be used to provide confidentiality on a hop-by-hop basis.
TLS SHOULD be used with certificate-based authentication to further
protect the HTTP transport as described in [RFC2818]. The CMP
transport via HTTPS MUST use TLS server authentication and SHOULD use transport via HTTPS MUST use TLS server authentication and SHOULD use
TLS client authentication. TLS client authentication.
TLS client: Note: The requirements for checking certificates given in [RFC5280],
[RFC5246], and [RFC8446] MUST be followed for the TLS layer.
* The client SHOULD use a TLS client certificate as far as Certificate status checking SHOULD be used for the TLS certificates
available. If no dedicated TLS certificate is available on an EE of all communication partners.
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, TLS with mutual authentication based on shared secret information MAY
server-only authenticated TLS MUST be used. be used in case no suitable certificates for certificate-based
authentication are available, e.g., a PKI management operation with
MAC-based protection is used.
* The client MUST validate the TLS server certificate of its Note: The entropy of the shared secret information is crucial for the
communication partner. level of protection available using shard secret information-based
TLS authentication. A pre-shared key (PSK) mechanism is acceptable
using shared secret information with an entropy of at least 128 bits.
Otherwise a password-authenticated key exchange (PAKE) protocol is
RECOMMENDED.
TLS server: 6.2. CoAP transport
* The server MUST use a TLS server certificate. This transport mechanism can be used by a PKI entity to transfer CMP
messages over CoAP [RFC7252], e.g., in constrained environments. If
CoAP transport is used the specifications as described in CMP over
CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed.
* The server MUST validate the TLS certificate of its clients if PKI management operations SHOULD use the following URI paths. When a
client authentication is available. single request message is nested as described in Section 5.2.2.1, the
path to use is the same as for the underlying request message. For
MAC-based protection the path of the respective message body SHALL be
used, e.g., use /ir for ir messages.
Note: The requirements for checking certificates given in [RFC5280], +==============================================+=======+=========+
[RFC5246] and [RFC8446] MUST be followed for the TLS layer. | PKI management operation | Path | Details |
Certificate status checking SHOULD be used for the TLS certificates +==============================================+=======+=========+
of communication partners. | Enroll client to new PKI | /ir | Section |
| | | 4.1.1 |
+----------------------------------------------+-------+---------+
| Enroll client to existing PKI | /cr | Section |
| | | 4.1.2 |
+----------------------------------------------+-------+---------+
| Update client certificate | /kur | Section |
| | | 4.1.3 |
+----------------------------------------------+-------+---------+
| Enroll client using PKCS#10 | /p10 | Section |
| | | 4.1.5 |
+----------------------------------------------+-------+---------+
| Enroll client using central key generation | /ckg | Section |
| | | 4.1.6 |
| Note: This path element MAY also be appended | | |
| to each of the path elements listed above. | | |
+----------------------------------------------+-------+---------+
| Revoke client certificate | /rr | Section |
| | | 4.2 |
+----------------------------------------------+-------+---------+
| Get CA certificates | /crts | Section |
| | | 4.3.1 |
+----------------------------------------------+-------+---------+
| Get root CA certificate update | /rcu | Section |
| | | 4.3.2 |
+----------------------------------------------+-------+---------+
| Get certificate request template | /att | Section |
| | | 4.3.3 |
+----------------------------------------------+-------+---------+
| Batching messages | /nest | Section |
| | | 5.2.2.2 |
| Note: This path element is applicable only | | |
| between PKI management entities. | | |
+----------------------------------------------+-------+---------+
6.3. HTTPS transport using shared secrets Table 10: CoAP endpoints
This transport mechanism can be used by a PKI entity to further Subsequent certConf and pollReq messages are sent to the URI of the
protect the HTTP transport as described in Section 6.1 using TLS 1.2 first request message of the respective PKI management operation.
[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. By sending a request to its preferred enrollment endpoint, the PKI
> entity will recognize via the CoAP response status code whether a
configured URI is supported by the PKI management entity. The CoAP-
inherent discovery mechanisms MAY also be used.
TLS client: In case a PKI management entity receives an unexpected CoAP status
code from upstream, it MUST respond downstream with an error message
as described in Section 3.6 using a failInfo bit corresponding to the
status code, e.g., systemFailure.
* The client MUST use its shared secret information for Like for HTTP transport, to offer a second line of defense or to
authentication. provide hop-by-hop privacy protection, DTLS MAY be utilized as
described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport].
TLS server: 6.3. Piggybacking on other reliable transport
* The server MUST use a suitable shared secret information for CMP messages MAY also be transported on some other reliable protocol.
authentication. Connection and error handling mechanisms similar to those specified
for HTTP in Section 6.1 need to be implemented.
< TBD: It needs to be clarified which cipher suite shall be A more detailed specification is out of scope of this document and
recommended as there seems to be no support for TLS-SRP un JavaSE. > would need to be given for instance in the scope of the transport
protocol used.
6.4. Offline transport 6.4. Offline transport
For transporting CMP messages between PKI entities any mechanism can For transporting CMP messages between PKI entities, any mechanism can
be used that is able to store and forward binary objects of be used that is able to store and forward binary objects of
sufficient length and with sufficient reliability while preserving sufficient length and with sufficient reliability while preserving
the order of messages for each transaction. the order of messages for each transaction.
The transport mechanism SHOULD be able to indicate message loss, The transport mechanism SHOULD be able to indicate message loss,
excessive delay, and possibly other transmission errors. In such excessive delay, and possibly other transmission errors. In such
cases the PKI entities using this mechanism SHOULD report an error as cases the PKI entities SHOULD report an error as specified in
specified in Section 4.3 as fare as possible. Section 3.6 as far as possible.
6.4.1. File-based transport 6.4.1. File-based transport
CMP messages MAY be transferred between PKI entities using file- CMP messages MAY be transferred between PKI entities using file-based
system-based mechanisms, for instance when an off-line end entity or mechanisms, for instance when an offline EE or a PKI management
a PKI management entity performs delayed enrollment. Each file MUST entity performs delayed enrollment. Each file MUST contain the ASN.1
contain the ASN.1 DER encoding of one CMP message only, which may be DER encoding of one CMP message only, where the message may be
nested. There MUST be no extraneous header or trailer information in nested. There MUST be no extraneous header or trailer information in
the file. The file name extension ".PKI" MUST be used. the file. The file name extension ".PKI" MUST be used.
6.4.2. Other asynchronous transport protocols 6.4.2. Other asynchronous transport protocols
Other asynchronous transport protocols, e.g., email or website Other asynchronous transport protocols, e.g., email or website
up-/download, MAY transfer CMP messages between PKI entities. A MIME up-/download, MAY transfer CMP messages between PKI entities. A MIME
wrapping is defined for those environments that are MIME native. The wrapping is defined for those environments that are MIME-native. The
MIME wrapping in this section is specified in [RFC8551], section 3.1. 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 ASN.1 DER encoding of the CMP messages MUST be transferred using
the "application/pkixcmp" content type and base64-encoded content- the "application/pkixcmp" content type and base64-encoded content
transfer-encoding as specified in [RFC2510], section 5.3. A filename transfer encoding as specified in [RFC2510], section 5.3. A filename
MUST be included either in a content-type or a content-disposition MUST be included either in a "content-type" or a "content-
statement. The file name extension ".PKI" MUST be used. disposition" statement. The file name extension ".PKI" MUST be used.
6.5. CoAP transport 7. IANA Considerations
In constrained environments where no HTTP transport is desired or 8. Security Considerations
possible, CoAP [RFC7252] as specified in
[I-D.ietf-ace-cmpv2-coap-transport] MAY be used.
6.6. Piggybacking on other reliable transport For requirements regarding proper random number and key generation
please refer to [RFC4086].
For online transfer where no HTTP transport is desired or possible For the case of centrally generated key pairs, the entropy of the
CMP messages MAY also be transported on some other reliable protocol. shared secret information SHALL not be less than the security
Connection and error handling mechanisms like those specified for strength of the centrally generated key pair; if the shared secret
HTTP in [RFC6712] need to be implemented. information is re-used for different key pairs, the entropy and the
security of the underlying cryptographic mechanisms SHOULD exceed the
security strength of the key pairs.
A more detailed specification is out of scope of this document and For the case of a PKI management operation that delivers a new trust
would need to be given in a separate document, for instance in the anchor, e.g., a root CA certificate, using caPubs, (a) that is not
scope of the transport protocol used. concluded in a timely manner or (b) where the shared secret
information is re-used for several key management operations, the
entropy of the shared secret information SHALL not be less than the
security strength of the key material being managed by the operation.
7. IANA Considerations For other cases, it is recommended to (a) either use a shared secret
information of possibly low entropy (e.g., a password) only for a
single PKI management operation or (b) use a shared secret
information with an entropy that matches the security strength of the
key material being managed by the operation.
8. Security Considerations Further recommendations on algorithms to use with shared secret
information is available in CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms].
For TLS using shared secret information-based authentication both PSK
and PAKE provide the same amount of protection against a real-time
authentication attack which is directly the amount of entropy in the
shared secret. The difference between a pre-shared key (PSK) and a
password-authenticated key exchange (PAKE) protocols is in the level
of long-term confidentiality of the TLS messages against brute-force
decryption, where a PSK-based cipher suite only provides security
according to the entropy of the shared secret, while a PAKE-based
cipher suite provides full security independent of the entropy of the
shared secret.
< TBD: Add any security considerations > < TBD: Add any security considerations >
9. Acknowledgements 9. Acknowledgements
We thank the various reviewers of this document. We thank the various reviewers of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transport for Certificate
Management Protocol", Work in Progress, Internet-Draft,
draft-ietf-ace-cmpv2-coap-transport-02, 25 May 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
cmpv2-coap-transport-02>.
[I-D.ietf-lamps-cmp-algorithms] [I-D.ietf-lamps-cmp-algorithms]
Brockhaus, H., Aschauer, H., Ounsworth, M., and S. Mister, Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"CMP Algorithms", Work in Progress, Internet-Draft, draft- "Certificate Management Protocol (CMP) Algorithms", Work
ietf-lamps-cmp-algorithms-02, 20 January 2021, in Progress, Internet-Draft, draft-ietf-lamps-cmp-
<https://tools.ietf.org/html/draft-ietf-lamps-cmp- algorithms-05, 7 May 2021,
algorithms-02>. <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-05>.
[I-D.ietf-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H. and D. V. Oheimb, "Certificate Management Brockhaus, H. and D. V. Oheimb, "Certificate Management
Protocol (CMP) Updates", Work in Progress, Internet-Draft, Protocol (CMP) Updates", Work in Progress, Internet-Draft,
draft-ietf-lamps-cmp-updates-08, 22 February 2021, draft-ietf-lamps-cmp-updates-10, 4 May 2021,
<https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
08>. cmp-updates-10>.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
skipping to change at page 73, line 40 skipping to change at page 83, line 45
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712, Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012, DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>. <https://www.rfc-editor.org/info/rfc6712>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>.
10.2. Informative References 10.2. Informative References
[ETSI-3GPP.33.310] [ETSI-3GPP.33.310]
3GPP, "Network Domain Security (NDS); Authentication 3GPP, "Network Domain Security (NDS); Authentication
Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020.
[I-D.ietf-ace-cmpv2-coap-transport] [I-D.ietf-anima-brski-async-enroll]
Sahni, M. and S. Tripathi, "CoAP Transport for CMPV2", Fries, S., Brockhaus, H., Lear, E., and T. Werner,
Work in Progress, Internet-Draft, draft-ietf-ace-cmpv2- "Support of asynchronous Enrollment in BRSKI (BRSKI-AE)",
coap-transport-00, 21 February 2021, Work in Progress, Internet-Draft, draft-ietf-anima-brski-
<https://tools.ietf.org/html/draft-ietf-ace-cmpv2-coap- async-enroll-03, 24 June 2021,
transport-00>. <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
brski-async-enroll-03>.
[IEC.62443-3-3] [IEC.62443-3-3]
IEC, "Industrial communication networks - Network and IEC, "Industrial communication networks - Network and
system security - Part 3-3: System security requirements system security - Part 3-3: System security requirements
and security levels", IEC 62443-3-3, August 2013, and security levels", IEC 62443-3-3, August 2013,
<https://webstore.iec.ch/publication/7033>. <https://webstore.iec.ch/publication/7033>.
[IEEE.802.1AR_2018] [IEEE.802.1AR_2018]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", IEEE 802.1AR-2018, networks - Secure Device Identity", IEEE 802.1AR-2018,
skipping to change at page 74, line 46 skipping to change at page 85, line 11
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>. <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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
skipping to change at page 75, line 36 skipping to change at page 85, line 42
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[UNISIG.Subset-137] [UNISIG.Subset-137]
UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management
FFFIS; V1.0.0", December 2015, FFFIS; V1.0.0", December 2015,
<https://www.era.europa.eu/filebrowser/download/542_en>. <https://www.era.europa.eu/filebrowser/download/542_en>.
Appendix A. Example CertReqTemplate Appendix A. Example CertReqTemplate
This section provides a concrete example for the content of an Suppose the server requires that the certTemplate contains
infoValue used of type id-it-certReqTemplate as described in
Section 4.4.3.
Suppose the server requires that the certTemplate contains the issuer * the issuer field with a value to be filled in by the EE,
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 * the subject field with a common name to be filled in by the EE and
fields with given values "myDept" and "myGroup", the publicKey field two organizational unit fields with given values "myDept" and
with an ECC key on curve secp256r1 or RSA public key of length 2048, "myGroup",
the subjectAltName extension with DNS name "www.myServer.com" and an
IP address to be filled in, the keyUsage extension marked critical * the publicKey field contains an ECC key on curve secp256r1 or an
with the value digitalSignature and keyAgreement, and the extKeyUsage RSA public key of length 2048,
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 * the subjectAltName extension with DNS name "www.myServer.com" and
follows: an IP address to be filled in,
* the keyUsage extension marked critical with the value
digitalSignature and keyAgreement, and
* the extKeyUsage extension with values to be filled in by the EE.
Then the infoValue with certTemplate and keySpec fields returned to
the EE will be encoded as follows:
SEQUENCE { SEQUENCE {
SEQUENCE { SEQUENCE {
[3] { [3] {
SEQUENCE {} SEQUENCE {}
} }
[5] { [5] {
SEQUENCE { SEQUENCE {
SET { SET {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3) OBJECT IDENTIFIER commonName (2 5 4 3)
UTnF8String '' UTF8String ""
} }
} }
SET {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String 'myDept' UTF8String "myDept"
} }
} }
SET { SET {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String 'myGroup' UTF8String "myGroup"
} }
} }
} }
[6] {
SEQUENCE {
null
NULL
}
BIT STRING, encapsulates {
SEQUENCE {}
}
} }
[9] { [9] {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17) OBJECT IDENTIFIER subjectAltName (2 5 29 17)
OCTET STRING, encapsulates { OCTET STRING, encapsulates {
SEQUENCE { SEQUENCE {
[2] 'www.myServer.com' [2] "www.myServer.com"
[7] '' [7] ""
} }
} }
} }
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15) OBJECT IDENTIFIER keyUsage (2 5 29 15)
BOOLEAN TRUE BOOLEAN TRUE
OCTET STRING, encapsulates { OCTET STRING, encapsulates {
BIT STRING 3 unused bits BIT STRING 3 unused bits
'10001'B "10001"B
} }
} }
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates { OCTET STRING, encapsulates {
SEQUENCE {} SEQUENCE {}
} }
} }
} }
} }
skipping to change at page 77, line 36 skipping to change at page 87, line 42
INTEGER 2048 INTEGER 2048
} }
} }
} }
Appendix B. History of changes Appendix B. History of changes
Note: This appendix will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
From version 05 -> 06:
* Changed in Section 2.3 the normative requirement in of adding
protection to a single message to mandatory and replacing
protection to optional
* Added Section 3.4 specifying generic prerequisites to PKI
management operations
* Added Section 3.5 specifying generic message validation
* Added Section 3.6 on generic error reporting. This section
replaces the former error handling section from Section 4 and 5.
* Added reference to using hashAlg
* Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates
* Added Section 5.1 specifying the behavior of PKI management
entities when responding to requests
* Reworked Section 5.2.3. on usage of nested messages
* Updates Section 5.3 on performing PKI management operation on
behalf of another entity
* Updates Section 6.2 on HTTPS transport of CMP messages as
discusses at IETF 110 and email thread "I-D Action: draft-ietf-
lamps-lightweight-cmp-profile-05.txt"
* Added CoAP endpoints to Section 6.4
* Added security considerations on usage of shared secret
information
* Updated the example in Appendix A
* Added newly registered OIDs to the example in Appendix A
* Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs
* Multiple language corrections, clarifications, and changes in
wording
From version 04 -> 05: From version 04 -> 05:
* Changed to XML V3 * Changed to XML V3
* Added algorithm names introducted in CMP Algorithms Section 7.3 to * Added algorithm names introduced in CMP Algorithms Section 7.3 to
Section 4 of this document Section 4 of this document
* Updates Syntax in Section 4.4.3 due to changes made in CMP Updates * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates
* Deleted the text on HTTP-based discovery as discussed in * Deleted the text on HTTP-based discovery as discussed in
Section 6.1 Section 6.1
* Updates Appendix A due to change syntax in Section 4.4.3 * Updates Appendix A due to change syntax in Section 4.4.3
* Many clarifications and changes in wording thanks to David's * Many clarifications and changes in wording thanks to David's
extensive review extensive review
From version 03 -> 04: From version 03 -> 04:
skipping to change at page 78, line 37 skipping to change at page 89, line 23
nested messages when a protection by the RA is required. nested messages when a protection by the RA is required.
* Deleted the section on HTTP URI definition and discovery as some * Deleted the section on HTTP URI definition and discovery as some
content was moved to CMP Updates. The rest of the content was content was moved to CMP Updates. The rest of the content was
moved back to the HTTP transport section moved back to the HTTP transport section
* Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts,
id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates
* Minor changes in wording and addition of some open ToDos * Minor changes in wording and addition of some open ToDos
From version 01 -> 02: From version 01 -> 02:
* Extend Section 1.4 with regard to conflicts with UNISIG Subset- * Extend Section 1.5 with regard to conflicts with UNISIG Subset-
137. 137.
* Minor clarifications on extraCerts in Section 3.3 and * Minor clarifications on extraCerts in Section 3.3 and
Section 4.1.1. Section 4.1.1.
* Complete specification of requesting a certificate from a trusted * Complete specification of requesting a certificate from a trusted
PKI with signature protection in Section 4.1.2. PKI with signature protection in Section 4.1.2.
* Changed from symmetric key-encryption to password-based key * Changed from symmetric key-encryption to password-based key
management technique in section Section 4.1.6.3 as discussed on management technique in section Section 4.1.6.3 as discussed on
the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.1.6.1") profile-01, section 5.1.6.1")
* Changed delayed enrollment described in Section 4.1.7 from * Changed delayed enrollment described in Section 4.1.7 from
recommended to optional as decided at IETF 107 recommended to optional as decided at IETF 107
* Introduced the new RootCAKeyUpdate structure for root CA * Introduced the new RootCAKeyUpdate structure for root CA
certificate update in Section 4.4.2 as decided at IETF 107 (also certificate update in Section 4.3.2 as decided at IETF 107 (also
see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
section 5.4.3") section 5.4.3")
* Extend the description of the CertReqTemplate PKI management * Extend the description of the CertReqTemplate PKI management
operation, including an example added in the Appendix. Keep operation, including an example added in the Appendix. Keep
rsaKeyLen as a single integer value in Section 4.4.3 as discussed rsaKeyLen as a single integer value in Section 4.3.3 as discussed
on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.4.4") profile-01, section 5.4.4")
* Deleted Sections "Get certificate management configuration" and * Deleted Sections "Get certificate management configuration" and
"Get enrollment voucher" as decided at IETF 107 "Get enrollment voucher" as decided at IETF 107
* Complete specification of adding an additional protection by an * Complete specification of adding an additional protection by an
PKI management entity in Section 5.1.3. PKI management entity in Section 5.2.2.
* Added a section on HTTP URI definition and discovery and extended * Added a section on HTTP URI definition and discovery and extended
Section 6.1 on definition and discovery of supported HTTP URIs and Section 6.1 on definition and discovery of supported HTTP URIs and
content types, add a path for nested messages as specified in content types, add a path for nested messages as specified in
Section 5.1.3 and delete the paths for /getCertMgtConfig and Section 5.2.2 and delete the paths for /getCertMgtConfig and
/getVoucher /getVoucher
* Changed Section 6.4 to address offline transport and added more * Changed Section 6.4 to address offline transport and added more
detailed specification file-based transport of CMP detailed specification file-based transport of CMP
* Added a reference to the new I-D of Mohit Sahni on "CoAP Transport * 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 for CMPV2" in Section 6.2; thanks to Mohit supporting the effort
to ease utilization of CMP to ease utilization of CMP
* Moved the change history to the Appendix * Moved the change history to the Appendix
* Minor changes in wording * Minor changes in wording
From version 00 -> 01: From version 00 -> 01:
* Harmonize terminology with CMP [RFC4210], e.g., * Harmonize terminology with CMP [RFC4210], e.g.,
- transaction, message sequence, exchange, use case -> PKI - transaction, message sequence, exchange, use case -> PKI
management operation management operation
- PKI component, (L)RA/CA -> PKI management entity - PKI component, (L)RA/CA -> PKI management entity
skipping to change at page 79, line 44 skipping to change at page 90, line 30
From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf-
lamps-lightweight-cmp-profile-00: lamps-lightweight-cmp-profile-00:
* Changes required to reflect WG adoption * Changes required to reflect WG adoption
* Minor changes in wording * Minor changes in wording
From version 02 -> 03: From version 02 -> 03:
* Added a short summary of [RFC4210] Appendix D and E in * Added a short summary of [RFC4210] Appendix D and E in
Section 1.3. Section 1.4.
* Clarified some references to different sections and added some * Clarified some references to different sections and added some
clarification in response to feedback from Michael Richardson and clarification in response to feedback from Michael Richardson and
Tomas Gustavsson. Tomas Gustavsson.
* Added an additional label to the operational path to address * Added an additional label to the operational path to address
multiple CAs or certificate profiles in Section 6.1. multiple CAs or certificate profiles in Section 6.1.
From version 01 -> 02: From version 01 -> 02:
* Added some clarification on the key management techniques for * Added some clarification on the key management techniques for
protection of centrally generated keys in Section 4.1.6. protection of centrally generated keys in Section 4.1.6.
* Added some clarifications on the certificates for root CA * Added some clarifications on the certificates for root CA
certificate update in Section 4.4.2. certificate update in Section 4.3.2.
* Added a section to specify the usage of nested messages for RAs to * Added a section to specify the usage of nested messages for RAs to
add an additional protection for further discussion, see add an additional protection for further discussion, see
Section 5.1.3. Section 5.2.2.
* Added a table containing endpoints for HTTP transport in * Added a table containing endpoints for HTTP transport in