draft-ietf-lamps-lightweight-cmp-profile-06.txt   draft-ietf-lamps-lightweight-cmp-profile-07.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: 10 January 2022 Siemens Expires: 28 April 2022 Siemens
9 July 2021 25 October 2021
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-06 draft-ietf-lamps-lightweight-cmp-profile-07
Abstract Abstract
This document aims at simple, interoperable, and automated PKI This document aims at simple, interoperable, and automated PKI
management operations covering typical use cases of industrial and management operations covering typical use cases of industrial and
IoT scenarios. This is achieved by profiling the Certificate IoT scenarios. This is achieved by profiling the Certificate
Management Protocol (CMP), the related Certificate Request Message Management Protocol (CMP), the related Certificate Request Message
Format (CRMF), and HTTP-based or CoAP-based transport in a succinct Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
but sufficiently detailed and self-contained way. To make secure but sufficiently detailed and self-contained way. To make secure
certificate management for simple scenarios and constrained devices certificate management for simple scenarios and constrained devices
as lightweight as possible, only the most crucial types of operations as lightweight as possible, only the most crucial types of operations
and options are specified as mandatory. More special and complex use and options are specified as mandatory. More special and complex use
cases are supported as well, by features specified as recommended or cases are supported as well, by features specified as 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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 10 January 2022. This Internet-Draft will expire on 28 April 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4
1.2. Motivation for a lightweight profile of CMP . . . . . . . 4 1.2. Motivation for a lightweight profile of CMP . . . . . . . 4
1.3. Special requirements of industrial and IoT scenarios . . 5 1.3. Special requirements of industrial and IoT scenarios . . 5
1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6
1.5. Compatibility with existing CMP profiles . . . . . . . . 7 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7
1.6. Scope of this document . . . . . . . . . . . . . . . . . 8 1.6. Compatibility with existing CMP profiles . . . . . . . . 7
1.7. Structure of this document . . . . . . . . . . . . . . . 9 1.7. Scope of this document . . . . . . . . . . . . . . . . . 9
1.8. Convention and Terminology . . . . . . . . . . . . . . . 10 1.8. Structure of this document . . . . . . . . . . . . . . . 9
1.9. Convention and Terminology . . . . . . . . . . . . . . . 10
2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11
2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11
2.2. Supported PKI management operations . . . . . . . . . . . 13 2.2. Supported PKI management operations . . . . . . . . . . . 13
2.2.1. Mandatory PKI management operations . . . . . . . . . 13 2.2.1. Mandatory PKI management operations . . . . . . . . . 13
2.2.2. Recommended PKI management operations . . . . . . . . 13 2.2.2. Recommended PKI management operations . . . . . . . . 14
2.2.3. Optional PKI management operations . . . . . . . . . 14 2.2.3. Optional PKI management operations . . . . . . . . . 15
2.3. CMP message transport . . . . . . . . . . . . . . . . . . 16 2.3. CMP message transfer . . . . . . . . . . . . . . . . . . 16
3. Generic aspects of the PKI message . . . . . . . . . . . . . 16 3. Generic aspects 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 . . . . . . 20
3.4. Generic PKI management operation prerequisites . . . . . 20 3.4. Generic PKI management operation prerequisites . . . . . 21
3.5. Generic validation of a PKI message . . . . . . . . . . . 22 3.5. Generic validation of a PKI message . . . . . . . . . . . 22
3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 24 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 24
3.6.1. Reporting error conditions upstream . . . . . . . . . 24 3.6.1. Reporting error conditions upstream . . . . . . . . . 24
3.6.2. Reporting error conditions downstream . . . . . . . . 25 3.6.2. Reporting error conditions downstream . . . . . . . . 25
3.6.3. Handling error conditions on nested messages used for 3.6.3. Handling error conditions on nested messages used for
batching . . . . . . . . . . . . . . . . . . . . . . 25 batching . . . . . . . . . . . . . . . . . . . . . . 25
3.6.4. Reporting error conditions . . . . . . . . . . . . . 25 3.6.4. Reporting error conditions . . . . . . . . . . . . . 26
4. End Entity PKI management operations . . . . . . . . . . . . 27 4. End Entity PKI management operations . . . . . . . . . . . . 28
4.1. Requesting a new certificate from a PKI . . . . . . . . . 30 4.1. Requesting a new certificate from a PKI . . . . . . . . . 31
4.1.1. Requesting a certificate from a new PKI with 4.1.1. Requesting a certificate from a new PKI with
signature-based protection . . . . . . . . . . . . . 31 signature-based protection . . . . . . . . . . . . . 32
4.1.2. Requesting an additional certificate with 4.1.2. Requesting an additional certificate with
signature-based protection . . . . . . . . . . . . . 37 signature-based protection . . . . . . . . . . . . . 38
4.1.3. Updating an existing certificate with signature 4.1.3. Updating an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 38
4.1.4. Requesting a certificate from a PKI with MAC-based
protection . . . . . . . . . . . . . . . . . . . . . 39 protection . . . . . . . . . . . . . . . . . . . . . 39
4.1.5. Requesting a certificate from a legacy PKI using a
4.1.4. Requesting a certificate from a legacy PKI using a
PKCS#10 request . . . . . . . . . . . . . . . . . . . 40 PKCS#10 request . . . . . . . . . . . . . . . . . . . 40
4.1.5. Requesting a certificate from a PKI with MAC-based
protection . . . . . . . . . . . . . . . . . . . . . 42
4.1.6. Adding central key pair generation to a certificate 4.1.6. Adding central key pair generation to a certificate
request . . . . . . . . . . . . . . . . . . . . . . . 42 request . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.6.1. Using key agreement key management technique . . 47 4.1.6.1. Using key agreement key management technique . . 48
4.1.6.2. Using key transport key management technique . . 48 4.1.6.2. Using key transport key management technique . . 50
4.1.6.3. Using password-based key management technique . . 49 4.1.6.3. Using password-based key management technique . . 50
4.1.7. Handling delayed enrollment . . . . . . . . . . . . . 50 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 51
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 55 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 54
4.3. Support messages . . . . . . . . . . . . . . . . . . . . 57 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 56
4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 59 4.3.2. Get root CA certificate update . . . . . . . . . . . 56
4.3.2. Get root CA certificate update . . . . . . . . . . . 60 4.3.3. Get certificate request template . . . . . . . . . . 58
4.3.3. Get certificate request template . . . . . . . . . . 61 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 60
5. PKI management entity operations . . . . . . . . . . . . . . 63 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 62
5.1. Responding to requests . . . . . . . . . . . . . . . . . 64 5. PKI management entity operations . . . . . . . . . . . . . . 66
5.1.1. Responding to a certificate request . . . . . . . . . 64 5.1. Responding to requests . . . . . . . . . . . . . . . . . 66
5.1.2. Initiating delayed enrollment . . . . . . . . . . . . 65 5.1.1. Responding to a certificate request . . . . . . . . . 67
5.1.3. Responding to a confirmation message . . . . . . . . 66 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 68
5.1.4. Responding to a revocation request . . . . . . . . . 66 5.1.3. Responding to a confirmation message . . . . . . . . 68
5.1.5. Responding to a support message . . . . . . . . . . . 66 5.1.4. Responding to a revocation request . . . . . . . . . 69
5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 66 5.1.5. Responding to a support message . . . . . . . . . . . 69
5.2.1. Not changing protection . . . . . . . . . . . . . . . 68 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 69
5.2.2. Adding protection and batching of messages . . . . . 69 5.2.1. Not changing protection . . . . . . . . . . . . . . . 71
5.2.2.1. Adding protection to a request message . . . . . 69 5.2.2. Adding protection and batching of messages . . . . . 72
5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 71 5.2.2.1. Adding protection to a request message . . . . . 72
5.2.3. Replacing protection . . . . . . . . . . . . . . . . 72 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 74
5.2.3.1. Not changing any included proof-of-possession . . 73 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75
5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 73 5.2.3.1. Not changing any included proof-of-possession . . 76
5.3. Acting on behalf of other PKI entities . . . . . . . . . 74 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76
5.3.1. Requesting certificates . . . . . . . . . . . . . . . 74 5.3. Acting on behalf of other PKI entities . . . . . . . . . 77
5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 75 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77
6. CMP message transport mechanisms . . . . . . . . . . . . . . 75 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 78
6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 76 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 78
6.2. CoAP transport . . . . . . . . . . . . . . . . . . . . . 78 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 79
6.3. Piggybacking on other reliable transport . . . . . . . . 80 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 81
6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 80 6.3. Piggybacking on other reliable transfer . . . . . . . . . 83
6.4.1. File-based transport . . . . . . . . . . . . . . . . 80 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 83
6.4.2. Other asynchronous transport protocols . . . . . . . 81 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 83
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 6.4.2. Other asynchronous transfer protocols . . . . . . . . 84
8. Security Considerations . . . . . . . . . . . . . . . . . . . 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 84
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84
10.1. Normative References . . . . . . . . . . . . . . . . . . 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.2. Informative References . . . . . . . . . . . . . . . . . 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 84
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 85 10.2. Informative References . . . . . . . . . . . . . . . . . 86
Appendix B. History of changes . . . . . . . . . . . . . . . . . 87 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 Appendix B. History of changes . . . . . . . . . . . . . . . . . 91
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95
1. Introduction 1. Introduction
[RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC-
CMP-Alg" in ASN.1 Syntax needs to be replaced with the RFC numbers of CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of
CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms], when available. [I-D.ietf-lamps-cmp-algorithms], when available.
This document specifies PKI management operations supporting machine- This document specifies PKI management operations supporting machine-
to-machine and IoT use cases. Its focus is to maximize automation to-machine and IoT use cases. Its focus is to maximize automation
and interoperability between all involved PKI entities, ranging from and interoperability between all involved PKI entities, ranging from
end entities (EE) over any number of intermediate PKI management end entities (EE) over any number of intermediate PKI management
entities such as Registration Authorities (RA) to the CMP endpoints entities such as Registration Authorities (RA) to the CMP endpoints
of Certification Authority (CA) systems. This profile makes use of of Certification Authority (CA) systems. This profile makes use of
the concepts and syntax specified in CMP [RFC4210], CRMF [RFC4211], the concepts and syntax specified in CMP [RFC4210],
CMS [RFC5652], HTTP transfer for CMP [RFC6712], CoAP transfer for CMP [I-D.ietf-lamps-cmp-updates], and [I-D.ietf-lamps-cmp-algorithms],
[I-D.ietf-ace-cmpv2-coap-transport], CRMF Algorithm Requirements CRMF [RFC4211] and [RFC9045], CMS [RFC5652] and [RFC8933], HTTP
Update [RFC9045], CMP Updates [I-D.ietf-lamps-cmp-updates], and CMP transfer for CMP [RFC6712], and CoAP transfer for CMP
Algorithms [I-D.ietf-lamps-cmp-algorithms]. Especially CMP, CRMF, [I-D.ietf-ace-cmpv2-coap-transport]. Especially CMP, CRMF, and CMS
and CMS are very feature-rich standards, while in most application are very feature-rich standards, while in most application scenarios
scenarios only a limited subset of the specified functionality is only a limited subset of the specified functionality is needed.
needed. Additionally, the standards are not always precise enough on Additionally, the standards are not always precise enough on how to
how to interpret and implement the described concepts. Therefore, interpret and implement the described concepts. Therefore, this
this document aims at tailoring the available options and specifying document aims at tailoring the available options and specifying at an
at an adequate detail how to use them to make the implementation of adequate detail how to use them to make the implementation of
interoperable automated certificate management as straightforward and interoperable automated certificate management as straightforward and
lightweight as possible. lightweight as possible.
1.1. How to Read This Document 1.1. How to Read This Document
This document has become longer than the authors would have liked it This document has become longer than the authors would have liked it
to be. Yet apart from studying Section 3, which contains general to be. Yet apart from studying Section 3, which contains general
requirements, the reader does not have to work through the whole 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 document but can use the guidance in Section 1.8, Section 2.2, and
Section 2.3 to figure out which parts of Section 4 to Section 6 are 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 relevant, depending on the PKI management operations and options of
interest. interest.
1.2. Motivation for a lightweight profile of CMP 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
skipping to change at page 5, line 15 skipping to change at page 5, line 15
Though CMP is a solid and very 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 supporting all options but on the other hand, a full implementation supporting all options
is not 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
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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 enrollment of TLS certificates UNISIG has included a CMP profile for enrollment of TLS certificates
in the Subset-137 specifying the ETRAM/ETCS on-line key management in the Subset-137 specifying the ETRAM/ETCS on-line key management
for train control systems [UNISIG.Subset-137] in 2015. for train control systems [UNISIG.Subset-137] in 2015.
Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and
HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI
management operations for unattended devices and services. management operations for unattended devices and services.
1.5. Compatibility with existing CMP profiles 1.5. Use of CMP in SZTP and BRSKI environments
In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments,
SZTP-CSR [I-D.ietf-netconf-sztp-csr] includes certificate signing
requests (CSR) in device bootstrapping to obtain a public-key
certificate for a locally generated key pair. One option is using a
CMP p10cr message. Such a CSR is of form ietf-sztp-types:cmp-csr
from module ietf-sztp-csr. To allow PKI management entities to also
comply with this profile, the p10cr message must be formatted by the
EE as described in Section 4.1.4 of this profile, and it may be
forwarded as specified in Section 5.2.
In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous
Enrollment [I-D.ietf-anima-brski-async-enroll] describes a
generalization regarding the employed enrollment protocols to allow
alternatives to EST [RFC7030]. For the use of CMP, it requires
adherence to this profile.
1.6. Compatibility with existing CMP profiles
The profile specified in this document is compatible with RFC 4210 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,
skipping to change at page 7, line 32 skipping to change at page 7, line 51
according to RFC 4211 Section 4.1 [RFC4211] 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 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, a CMP server on the EE) are excluded in (requiring a push model, a CMP server on the EE) are excluded in
favor of a lightweight implementation on the EE. 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
skipping to change at page 8, line 25 skipping to change at page 8, line 42
* The same type of protection is required to be used for all * 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 protection is MAC-based, also the response, request message protection is MAC-based, also the response,
certConf, and pkiConf messages must have a MAC-based protection. certConf, and pkiConf messages must have a MAC-based protection.
* 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. caPubs.
Note: In case of UNISIG Subset-137 the response to a MAC-protected Note: It remains unclear from UNISIG Subset-137 for which
request shall be signature-based. The signature-based protection certificate(s) the caPubs field should be used. For security
uses a certificate issued under the same root CA that is to be reasons, it cannot be used for delivering the root CA certificate
transported in the caPubs field. This is not a secure delivery of needed for validating the signature-based protection of the given
the root CA certificate. response message (as stated indirectly also in its UNISIG
Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]).
* This profile requires that the certConf message has one CertStatus * This profile requires that the certConf message has one CertStatus
element where the statusInfo field is recommended. element where the statusInfo field is recommended.
Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137] Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137]
requires that the certConf message has one CertStatus element requires that the certConf message has one CertStatus element
where the statusInfo field must be absent. This precludes sending where the statusInfo field must be absent. This precludes sending
a negative certConf message in case the EE rejects the newly a negative certConf message in case the EE rejects the newly
enrolled certificate. This results in violating the general rule enrolled certificate. This results in violating the general rule
that a certificate request transaction must include a certConf that a certificate request transaction must include a certConf
message (since moreover, using implicitConfirm is not allowed message (since moreover, using implicitConfirm is not allowed
there, neither). there, neither).
1.6. Scope of this document 1.7. Scope of this document
To minimize ambiguity and complexity through needless variety, this To minimize ambiguity and complexity through needless variety, this
document specifies exhaustive requirements on generating PKI document specifies exhaustive requirements on generating PKI
management messages on the sender side. On the other hand, it gives management messages on the sender side. On the other hand, it gives
only minimal requirements on checks by the receiving side and how to only minimal requirements on checks by the receiving side and how to
handle error cases. 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 implementations are reduced to a reasonable minimum to operations implementations are reduced to a reasonable minimum to
skipping to change at page 9, line 20 skipping to change at page 9, line 37
resources are expected, while on the side of the PKI management resources are expected, while on the side of the PKI management
entities the profile accepts higher requirements. entities the profile accepts higher requirements.
For the sake of interoperability and robustness, implementations For the sake of interoperability and robustness, implementations
should, as far as security is not affected, adhere to Postel's law: should, as far as security is not affected, adhere to Postel's law:
"Be conservative in what you do, be liberal in what you accept from "Be conservative in what you do, be liberal in what you accept from
others" (often reworded as: "Be conservative in what you send, be others" (often reworded as: "Be conservative in what you send, be
liberal in what you receive"). 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 CMP [RFC4210], CRMF [RFC4211], CMS [RFC5652], syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates],
and CMP Updates [I-D.ietf-lamps-cmp-updates] is not explicitly CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly
specified, it SHOULD not be used by the sending entity. The specified, it SHOULD not be used by the sending entity. The
receiving entity MUST NOT require its absence and if present MUST receiving entity MUST NOT require its absence and if present MUST
gracefully handle its presence. gracefully handle its presence.
1.7. Structure of this document 1.8. 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 that is assumed in this document. Then it certificate management that is assumed in this document. Then it
lists the PKI management operations specified in this document, lists the PKI management operations specified in this document,
partitioning them into mandatory, recommended, and optional ones. partitioning them into mandatory, recommended, and optional ones.
Section 3 profiles the generic aspects of the PKI management Section 3 profiles the generic aspects of the PKI management
operations specified in detail in Section 4 and Section 5 to minimize operations specified in detail in Section 4 and Section 5 to minimize
redundancy in the description and to ease implementation. This redundancy in the description and to ease implementation. This
covers the general structure and protection of messages, as well as covers the general structure and protection of messages, as well as
generic prerequisites, validation, and error handling. 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
PKI management entity. There are various flavors of certificate PKI management entity. There are various flavors of certificate
enrollment requests, optionally with polling, central key generation, enrollment requests, optionally with polling, central key generation,
revocation, and general support PKI management operations. revocation, and general support PKI management operations.
Section 5 profiles responding to requests, exchange between PKI Section 5 profiles responding to requests, exchange between PKI
management entities, and operations on behalf of other PKI entities. management entities, and operations on behalf of other PKI entities.
This may include delayed delivery of messages, which involves polling This may include delayed delivery of messages, which involves polling
for certificate responses, and nesting of messages. for responses, and nesting of messages.
Section 6 outlines several mechanisms for CMP message transfer, Section 6 outlines several mechanisms for CMP message transfer,
including HTTP-based transfer as already specified in RFC 6712 including HTTP-based [RFC6712] transfer optionally using TLS, and
[RFC6712] optionally using TLS, and offline file-based transport. [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS,
CoAP-based transport as specified in and offline file-based transport.
[I-D.ietf-ace-cmpv2-coap-transport] and piggybacking CMP messages are
also briefly addressed.
1.8. Convention and Terminology 1.9. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown 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:
skipping to change at page 10, line 44 skipping to change at page 11, line 9
proximity to the end entities. proximity to the end entities.
Note: For ease of reading, this document uses the term "RA" Note: For ease of reading, this document uses the term "RA"
also for LRAs in all cases where the difference is not also for LRAs in all cases where the difference is not
relevant. relevant.
KGA: Key generation authority, an optional system component, KGA: Key generation authority, an optional system component,
typically co-located with an 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, typically a device or service that holds public- EE: End entity, typically a device or service that holds a 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], as The following terminology is reused from RFC 4210 [RFC4210], as
follows: follows:
PKI management operation: All CMP messages belonging to a single PKI management operation: All CMP messages belonging to a single
transaction. The transaction is transaction. The transaction is
identified by the transactionID field of identified by the transactionID field of
skipping to change at page 12, line 30 skipping to change at page 12, line 41
can have multiple LRAs bundling requests from multiple EEs at can have multiple LRAs bundling requests from multiple EEs at
dedicated locations and one (or more than one) central RA aggregating dedicated locations and one (or more than one) central RA aggregating
the requests from the LRAs. Every LRA in this scenario has shared the requests from the LRAs. Every LRA in this scenario has shared
secret information (one per EE) for MAC-based protection or a CMP secret information (one per EE) for MAC-based protection or a CMP
protection key and certificate allowing it to (re-)protect CMP protection key and certificate allowing it to (re-)protect CMP
messages it processes. The figure above shows an architecture messages it processes. The figure above shows an architecture
example with at least one LRA, RA, and CA. It is also possible not 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. 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 Depending on the network infrastructure, the message transfer between
PKI management entities may be based on synchronous online PKI management entities may be based on synchronous online
connections, delayed asynchronous connections, or even offline (e.g., connections, asynchronous connections, or even offline (e.g., file-
file-based) transfer. based) transfer.
Note: CMP response messages could also be used proactively to Note: CMP response messages could also be used proactively to
implement the push model towards the EE. In this case the EE acts as implement the push model towards the EE. In this case the EE acts as
receiver, not initiating the interaction with the PKI. Also, when receiver, not initiating the interaction with the PKI. Also, when
using a commissioning tool or a registrar agent as described in: using a commissioning tool or a registrar agent as described in BRSKI
Support of asynchronous Enrollment in Bootstrapping Remote Secure Key with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm],
Infrastructures (BRSKI) [I-D.ietf-anima-brski-async-enroll],
certificate enrollment in a push model is needed. CMP in general and certificate enrollment in a push model is needed. CMP in general and
the messages specified in this profile offer all required the messages specified in this profile offer all required
capabilities, but the message flow and state machine as described in capabilities, but the message flow and state machine as described in
Section 4 must be adapted to implement a push model. Section 4 must be adapted to implement a push model.
Third-party CAs may 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 RA may need to adapt the certificate management. Therefore, the RA may need to adapt the
exchanged CMP messages to the flavor of certificate management exchanged CMP messages to the flavor of certificate management
interaction required by the CA. interaction required by the CA.
2.2. Supported PKI management operations 2.2. Supported PKI management operations
Following the scope outlined in Section 1.6, this section gives a Following the scope outlined in Section 1.7, this section gives a
brief overview of the PKI management operations specified in brief overview of the base PKI management operations and their
Section 4 and Section 5 and states whether implementation by variants specified in Section 4 and Section 5 and states whether
compliant EEs or PKI management entities is mandatory, recommended, implementation by compliant EEs or PKI management entities is
or optional. mandatory, recommended, or optional. Variants amend or change
behavior of base PKI management operations and are therefore also
listed here.
2.2.1. Mandatory PKI management operations 2.2.1. Mandatory PKI management operations
The set of mandatory PKI management operations in this document is The set of mandatory PKI management operations in this document is
intentionally lean to help for keeping development effort low and to intentionally lean to help for keeping development effort low and to
enable use in memory-constrained devices. enable use in memory-constrained devices.
+=====================================+=========+ +=====================================+=========+
| PKI management operations | Section | | PKI management operations | Section |
+=====================================+=========+ +=====================================+=========+
skipping to change at page 14, line 9 skipping to change at page 14, line 29
2.2.2. Recommended PKI management operations 2.2.2. Recommended PKI management operations
Additional recommended PKI management operations support some more Additional recommended PKI management operations support some more
complex scenarios, that are considered beneficial for environments complex scenarios, that are considered beneficial for environments
with more specific demand or boundary conditions. with more specific demand or boundary conditions.
+=================================+=========+ +=================================+=========+
| PKI management operations | Section | | PKI management operations | Section |
+=================================+=========+ +=================================+=========+
| Requesting a certificate from a | Section | | Requesting a certificate from a | Section |
| PKI with MAC-based protection | 4.1.4 | | PKI with MAC-based protection | 4.1.5 |
+---------------------------------+---------+ +---------------------------------+---------+
| Revoking a certificate | Section | | Revoking a certificate | Section |
| | 4.2 | | | 4.2 |
+---------------------------------+---------+ +---------------------------------+---------+
Table 3: Recommended End Entity PKI Table 3: Recommended End Entity PKI
management operations management operations
+====================================+===============+ +====================================+===============+
| PKI management operations | Section | | PKI management operations | Section |
skipping to change at page 14, line 32 skipping to change at page 15, line 8
+------------------------------------+---------------+ +------------------------------------+---------------+
| Acting on behalf of other PKI | Section 5.3.2 | | Acting on behalf of other PKI | Section 5.3.2 |
| entities - revoking a certificate | | | entities - revoking a certificate | |
+------------------------------------+---------------+ +------------------------------------+---------------+
Table 4: Recommended PKI management entity operations Table 4: Recommended PKI management entity operations
2.2.3. Optional PKI management operations 2.2.3. Optional PKI management operations
The optional PKI management operations support specific scenarios The optional PKI management operations support specific scenarios
seen only in some environments with special requirements. seen only in some environments with specific requirements.
+========================================================+=========+ +========================================================+=========+
| PKI management operations | Section | | PKI management operations and variants | Section |
+========================================================+=========+ +========================================================+=========+
| Requesting an additional certificate with signature- | Section | | Requesting an additional certificate with signature- | Section |
| based protection | 4.1.2 | | based protection | 4.1.2 |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Requesting a certificate from a legacy PKI using a | Section | | Requesting a certificate from a legacy PKI using a | Section |
| PKCS#10 request | 4.1.5 | | PKCS#10 request | 4.1.4 |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Adding central key generation 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.) | |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Handling delayed enrollment | Section | | Support messages | Section |
| | 4.1.7 | | | 4.3 |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Support messages - get CA certificates, get a trust | Section | | Handling delayed delivery | Section |
| anchor updates, e.g., root CA certificate updates, and | 4.3 | | | 4.4 |
| get a certificate request template | |
+--------------------------------------------------------+---------+ +--------------------------------------------------------+---------+
| Acting on behalf of other PKI entities - requesting | Section | | Acting on behalf of other PKI entities - requesting | Section |
| certificates | 5.3.1 | | 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 and variants | Section |
+===============================================+=========+ +===============================================+===============+
| Forwarding messages - replacing protection, | Section | | Initiating delayed delivery | Section 5.1.2 |
| not changing any included proof-of-possession | 5.2.3.1 | +-----------------------------------------------+---------------+
+-----------------------------------------------+---------+ | Forwarding messages - replacing protection, | Section |
| Forwarding messages - replacing protection, | Section | | not changing any included proof-of-possession | 5.2.3.1 |
| breaking proof-of-possession | 5.2.3.2 | +-----------------------------------------------+---------------+
+-----------------------------------------------+---------+ | Forwarding messages - replacing protection, | Section |
| Batching messages | Section | | breaking proof-of-possession | 5.2.3.2 |
| | 5.2.2.2 | +-----------------------------------------------+---------------+
+-----------------------------------------------+---------+ | Batching messages | Section |
| Initiating delayed enrollment | Section | | | 5.2.2.2 |
| | 5.1.2 | +-----------------------------------------------+---------------+
+-----------------------------------------------+---------+
Table 6: Optional PKI management entity operations Table 6: Optional PKI management entity operations
2.3. CMP message transport 2.3. CMP message transfer
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 transfer mechanisms MAY be used. CMP does not have
regarding message transport, virtually any reliable transport specific needs regarding message transfer, except that for each
mechanism can be used, e.g., HTTP, CoAP, and offline file-based request message sent, eventually exactly one response message should
transport. Therefore, this document does not require any specific be received. Thus, virtually any reliable transfer mechanism can be
transport protocol to be supported by conforming implementations. used, e.g., HTTP, CoAP, and offline file-based transfer. Therefore,
this document does not require any specific transfer protocol to be
supported by conforming implementations.
HTTP transfer is RECOMMENDED to use for all PKI entities, yet full 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 transfer mechanism is
instance for devices and system architectures with special suitable, for instance for devices and system architectures with
constraints. specific constraints.
+================+=============+ +===============+=============+
| Transport | Section | | Transfer | Section |
+================+=============+ +===============+=============+
| HTTP transport | Section 6.1 | | HTTP transfer | Section 6.1 |
+----------------+-------------+ +---------------+-------------+
Table 7: Recommended Table 7: Recommended
transport mechanisms transfer mechanisms
+==========================================+=============+ +=========================================+=============+
| Transport | Section | | Transfer | Section |
+==========================================+=============+ +=========================================+=============+
| Offline transport | Section 6.4 | | Offline transfer | Section 6.4 |
+------------------------------------------+-------------+ +-----------------------------------------+-------------+
| CoAP transport | Section 6.2 | | CoAP transfer | Section 6.2 |
+------------------------------------------+-------------+ +-----------------------------------------+-------------+
| Piggybacking on other reliable transport | Section 6.3 | | Piggybacking on other reliable transfer | Section 6.3 |
+------------------------------------------+-------------+ +-----------------------------------------+-------------+
Table 8: Optional transport mechanisms Table 8: Optional transfer mechanisms
3. Generic aspects of the PKI message 3. Generic aspects of the PKI message
This section covers the generic aspects of the PKI management This section covers the generic aspects of the PKI management
operations specified in Section 4 and Section 5 as upfront general operations specified in Section 4 and Section 5 as upfront general
requirements to minimize redundancy in the description and to ease requirements to minimize redundancy in the description and to ease
implementation. implementation.
As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages
have the following general structure: have the following general structure:
skipping to change at page 17, line 49 skipping to change at page 18, line 24
The generic aspects of handling and reporting errors are described in The generic aspects of handling and reporting errors are described in
Section 3.6. 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 fields of all CMP messages This section describes the generic header fields of all CMP messages
with signature-based protection. with signature-based protection.
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.5. The variations will affect the fields sender,
protectionAlg, and senderKID. protectionAlg, and senderKID.
Any PKI management operation-specific fields or variations are Any PKI management operation-specific fields or variations are
described in Section 4 and 5. described in Section 4 and 5.
header header
pvno REQUIRED pvno REQUIRED
-- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
-- is supported and expected to be used in the current -- is supported and expected to be used in the current
-- PKI management operation -- PKI management operation
-- MUST be 3 to indicate CMP v3 in certConf messages when using -- MUST be 3 to indicate CMP v3 in certConf messages when using
-- the hashAlg field -- the hashAlg field
-- MUST be 2 to indicate CMP v2 in all other cases -- 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
-- SHOULD contain a name representing the originator of the -- SHOULD contain a name representing the originator of the
-- message; otherwise, the NULL-DN (a zero-length -- message; otherwise, the NULL-DN (a zero-length
-- SEQUENCE OF RelativeDistinguishedNames) MUST be used -- 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 corresponding to the private key used to sign
-- the message
-- In a multi-hop scenario, the receiving entity SHOULD not rely -- In a multi-hop scenario, the receiving entity SHOULD not rely
-- on the correctness of the sender field. -- on the correctness of the sender field.
recipient REQUIRED recipient REQUIRED
-- SHOULD be the name of the intended recipient; otherwise, the -- SHOULD be the name of the intended recipient; otherwise, the
-- NULL-DN MUST be used -- NULL-DN MUST be used
-- In the first message of a PKI management operation: -- In the first message of a PKI management operation:
-- SHOULD be the subject DN of the CA the PKI management -- SHOULD be the subject DN of the CA the PKI management
-- operation is requested from -- operation is requested from
-- In all other messages: -- In all other messages:
-- SHOULD contain the value of the sender field of the previous -- SHOULD contain the value of the sender field of the previous
skipping to change at page 19, line 15 skipping to change at page 19, line 37
-- MUST be 128 bits of random data, to minimize the probability -- MUST be 128 bits of random data, to minimize the probability
-- of having the 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
-- PKI management operation -- 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
-- If this is a delayed response message: MUST be present and
-- contain the value of the senderNonce of the respective request
-- message in the same transaction
-- In all other messages: MUST be present and contain the value -- 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 extension 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
-- Added to response messages to grant omission of the certConf -- Added to response messages to grant omission of the certConf
-- message -- message
-- See [RFC4210] Section 5.1.1.1. -- See [RFC4210] Section 5.1.1.1.
ImplicitConfirmValue REQUIRED ImplicitConfirmValue REQUIRED
-- ImplicitConfirmValue MUST be NULL -- ImplicitConfirmValue MUST be NULL
rootCaCert OPTIONAL
-- 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 certProfile OPTIONAL
-- MAY be present in ir/cr/kur/p10cr and in genm messages of type -- MAY be present in ir/cr/kur/p10cr and in genm messages of type
-- id-it-certReqTemplate -- id-it-certReqTemplate
-- MUST be omitted in all other messages -- MUST be omitted in all other messages
-- See [RFC-CMP-Updates] -- See [RFC-CMP-Updates]
CertProfileValue REQUIRED CertProfileValue REQUIRED
-- MUST contain exactly one UTF8String element -- MUST contain exactly one UTF8String element
-- MUST contain the name of a certificate profile -- 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
skipping to change at page 20, line 14 skipping to change at page 20, line 33
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 specified in there are cases where protection of error messages specified in
Section 3.6 is not possible and therefore MAY be omitted. Section 3.6 is not possible and therefore MAY be omitted.
For MAC-based protection as specified in Section 4.1.4 major For MAC-based protection as specified in Section 4.1.5 major
differences apply as described there. 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 header and body. The authentication and integrity protection for the header and body. The
CMP message extraCerts field is not covered by this protection. CMP message extraCerts field is not covered by this protection.
Note: The extended key usages described 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.
skipping to change at page 21, line 17 skipping to change at page 21, line 39
* Each EE SHOULD know the intended recipient of its requests to fill * Each EE SHOULD know the intended recipient of its requests to fill
the recipient field, e.g., the name of the addressed CA. the recipient field, e.g., the name of the addressed CA.
Note: This name may be established using an enrollment voucher, Note: This name may be established using an enrollment voucher,
e.g., [RFC8366], the issuer field from a CertReqTemplate response e.g., [RFC8366], the issuer field from a CertReqTemplate response
message content, or by other configuration means. message content, or by other configuration means.
Routing of CMP messages: Routing of CMP messages:
* Each PKI entity sending messages upstream MUST know the address * Each PKI entity sending messages upstream MUST know the address
needed for transporting messages to the next PKI management needed for transferring messages to the next PKI management
entity. entity.
Note: This address may depend on the recipient, the certificate Note: This address may depend on the recipient, the certificate
profile, and on the used transport mechanism. profile, and on the used transfer mechanism.
Authentication of PKI entities: Authentication of PKI entities:
* Each PKI entity MUST have credentials to authenticate itself. For * Each PKI entity MUST have credentials to authenticate itself. For
signature-based protection it MUST have a private key and the signature-based protection it MUST have a private key and the
corresponding certificate along with its chain. corresponding certificate along with its chain.
* Each PKI entity MUST be able to establish trust in PKI it receives * Each PKI entity MUST be able to establish trust in PKI it receives
responses from. When signature-based protection is used, it MUST responses from. When signature-based protection is used, it MUST
have the trust anchor(s) and any certificate status information have the trust anchor(s) and any certificate status information
skipping to change at page 22, line 38 skipping to change at page 23, line 14
All PKI message header fields not mentioned in this section like the All PKI message header fields not mentioned in this section like the
recipient and generalInfo fields SHOULD be handled gracefully on recipient and generalInfo fields SHOULD be handled gracefully on
reception. reception.
The following list describes the basic set of message input The following list describes the basic set of message input
validation steps. Without these checks the protocol becomes validation steps. Without these checks the protocol becomes
dysfunctional. dysfunctional.
* The formal ASN.1 syntax of the whole message MUST be compliant * The formal ASN.1 syntax of the whole message MUST be compliant
with the definitions given in CMP [RFC4210], CRMF [RFC4211], with the definitions given in CMP [RFC4210] and
RFC 5652 [RFC5652], and CMP Updates [I-D.ietf-lamps-cmp-updates]. [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652]
(failInfo: badDataFormat) and [RFC8933]. (failInfo: badDataFormat)
* The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: * The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit:
unsupportedVersion) unsupportedVersion)
* The transactionID MUST be present. (failInfo bit: badDataFormat) * The transactionID MUST be present. (failInfo bit: badDataFormat)
* The PKI message body type MUST be one of the message types * The PKI message body type MUST be one of the message types
supported by the receiving PKI entity and MUST be allowed in the supported by the receiving PKI entity and MUST be allowed in the
current state of the PKI management operation identified by the current state of the PKI management operation identified by the
given transactionID. (failInfo bit: badRequest) given transactionID. (failInfo bit: badRequest)
skipping to change at page 23, line 15 skipping to change at page 23, line 38
The following list describes the set of message input validation The following list describes the set of message input validation
steps required to ensure secure protocol operation: steps required to ensure secure protocol operation:
* The senderNonce MUST be present and MUST contain at least 128 bits * The senderNonce MUST be present and MUST contain at least 128 bits
of data. (failInfo bit: badSenderNonce) of data. (failInfo bit: badSenderNonce)
* Unless the PKI message is the first message of a PKI management * Unless the PKI message is the first message of a PKI management
operation, operation,
- the recipNonce MUST be present and MUST equal the senderNonce - the recipNonce MUST be present and MUST equal the senderNonce
of the previous message. (failInfo bit: badRecipientNonce) of the previous message or equal the senderNonce of the most
recent request message for which the response was delayed, in
case of delayed delivery as specified in Section 4.4. (failInfo
bit: badRecipientNonce)
* The message protection MUST be validated: * The message protection MUST be validated:
- The protection MUST be signature-based except if MAC-based - The protection MUST be signature-based except if MAC-based
protection is used as described in Section 4.1.4and for some protection is used as described in Section 4.1.5 and for some
error messages as described in Section 3.6.4. (failInfo bit: error messages as described in Section 3.6.4. (failInfo bit:
wrongIntegrity) wrongIntegrity)
- The senderKID SHOULD identify the key material used for - The senderKID SHOULD identify the key material used for
verifying the message protection. (failInfo bit: verifying the message protection. (failInfo bit:
badMessageCheck) badMessageCheck)
- The protection, if present, MUST be validated successfully. If - The protection, if present, MUST be validated successfully. If
signature-based protection is used, the CMP protection signature-based protection is used, the CMP protection
certificate MUST be successfully validated including path certificate MUST be successfully validated including path
skipping to change at page 26, line 11 skipping to change at page 26, line 31
structure of the respective message as described below. It then MUST structure of the respective message as described below. It then MUST
regard the current PKI management operation as terminated with regard the current PKI management operation as terminated with
failure. failure.
The PKIStatusInfo structure is used to report errors. It may be part The PKIStatusInfo structure is used to report errors. It may be part
of various message types, in particular: certConf, ip, cp, kup, and of various message types, in particular: certConf, ip, cp, kup, and
error. The PKIStatusInfo structure consists of the following fields: error. The PKIStatusInfo structure consists of the following fields:
* status: Here the PKIStatus value "rejection" MUST be used. * status: Here the PKIStatus value "rejection" MUST be used.
Note: When a PKI management entity indicates delayed delivery of a
CMP response message to the EE with an error message as described
in Section 4.4, the status "waiting" is used there.
* statusString: Here any human-readable valid value for logging or * statusString: Here any human-readable valid value for logging or
to display via a user interface SHOULD be added. to display via a user interface SHOULD be added.
* failInfo: Here the PKIFailureInfo bits MAY be used in the way * failInfo: Here the PKIFailureInfo bits MAY be used in the way
explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo
bits regarding the validation described in Section 3.5 are bits regarding the validation described in Section 3.5 are
referenced there. The PKIFailureInfo bits referenced in referenced there. The PKIFailureInfo bits referenced in
Section 5.1 and Section 6 are described here: Section 5.1 and Section 6 are described here:
- badCertId: A kur, certConf, or rr message references an unknown - badCertId: A kur, certConf, or rr message references an unknown
skipping to change at page 27, line 13 skipping to change at page 28, line 13
Detailed error message description: Detailed error message description:
Error Message -- error Error Message -- error
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The message sent by an PKI management entity error that -- The message indicating the error that occurred
-- occurred
error REQUIRED error REQUIRED
pKIStatusInfo REQUIRED pKIStatusInfo REQUIRED
status REQUIRED status REQUIRED
-- MUST have the value "rejection" -- MUST have the value "rejection"
statusString RECOMMENDED statusString RECOMMENDED
-- SHOULD be any human-readable text for debugging, logging -- SHOULD be any human-readable text for debugging, logging
-- or to display in a GUI -- or to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present and contain the relevant PKIFailureInfo bits -- MAY be present and contain the relevant PKIFailureInfo bits
skipping to change at page 28, line 6 skipping to change at page 29, line 6
* Revoking a certificate * Revoking a certificate
* Support messages * 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 3. extraCerts as specified in Section 3.
The following diagram shows the EE state machine covering all PKI The following diagram shows the EE state machine covering all PKI
management operations described in this section including negative management operations described in this section, including negative
responses, while no generic error messages are shown. responses, error messages described in Section 3.6.4, as well as
ip/cp/kup/error messages with status "waiting", pollReq, and pollRep
messages described in Section 4.4.
On receiving messages from upstream, the EE MUST perform the general On receiving messages from upstream, the EE MUST perform the general
validation checks described in Section 3.5. The behavior in case an validation checks described in Section 3.5. The behavior in case an
error occurs is described in Section 3.6. error occurs is described in Section 3.6.
State machine: State machine:
start
|
| send ir/cr/p10cr/kur/rr/genm
v
waiting for response
|
+--------------------------+--------------------------+
| | |
| receives ip/cp/kup with | received ip/cp/kup/error | received
| status "accepted" or | with status "waiting" | rp/genp or
| "grantedWithMods" | | ip/cp/kup/
| v | error
| +-------> polling | with status
| | | | "rejection"
| | received | send |
| | pollRep | pollReq |
| | v |
| | waiting for response |
| | | |
| +------------+--------+ |
| | | |
| received ip/cp/kup | | received |
| with status "accepted" | | rp/genp or |
| or "grantedWithMods" | | ip/cp/kup/error |
| | | with status |
+-----------+--------------+ | "rejection" |
| | |
+-----------+-----+ | |
| | | |
| implicitConfirm | implicitConfirm | |
| granted | not granted | |
| | | |
| | send certConf | |
| v | |
| waiting for pkiConf*) | |
| | | |
| | received | |
| | pkiConf | |
+-----------------+-----------------+-----------------+
|
v
end
Start *) in case of a delayed delivery of pkiConf responses the same
| polling mechanism is initiated as for rp or genp messages, by sending
+---------+--------------------+ an error message with status "waiting".
| |
| 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 Note: All CMP messages belonging to the same PKI management operation
MUST have the same transactionID because the message receiver MUST have the same transactionID because the message receiver
identifies the elements of the operation in this way. identifies the elements of the operation in this way.
This section is aligned with CMP [RFC4210], CMP Updates This section is aligned with CMP [RFC4210], CMP Updates
[I-D.ietf-lamps-cmp-updates], and CMP Algorithms [I-D.ietf-lamps-cmp-updates], and CMP Algorithms
[I-D.ietf-lamps-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
skipping to change at page 31, line 32 skipping to change at page 32, line 32
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 POP. As detailed in Section 5.1.1 request message containing that POP. As detailed in Section 5.1.1
and Section 5.1.2, an upstream 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. requested subject and other fields and extensions.
The EE MAY indicate the certificate profile to use in the certProfile The EE MAY indicate the certificate profile to use in the certProfile
extension of the generalInfo field in the PKIHeader of the extension of the generalInfo field in the PKIHeader of the
certificate request message as described in Section 3.1. certificate request message as described in Section 3.1.
In case a new trust anchor, e.g., a root CA certificate, is to be In case the EE receives a CA certificate in the caPubs field for
installed that has been received in the caPubs field of an ip or cp installation as a new trust anchor, it MUST properly authenticate the
message, the EE MUST properly authenticate the message and authorize message and authorize the sender as trusted source of the new trust
its sender as trusted source of the new trust anchor certificate. anchor. This authorization is typically indicated using shared
This authorization is typically indicated by using shared secret secret information for protecting an initialization response (ir)
information, but it can also be indicated by using a private key with message. Authorization can also be signature-based using a
a certificate issued by another PKI explicitly authorized for this certificate issued by another PKI that is explicitly authorized for
purpose, for the CMP message protection. this purpose. A certificate received in caPubs MUST NOT be accepted
as trust anchor if the CMP message has been protected using a
certificate issued by this same CA or one of its subordinate CAs.
4.1.1. Requesting a certificate from a new PKI with signature-based 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. [IEEE.802.1AR_2018], to authenticate itself to the new PKI.
Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI)
[RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE)
[I-D.ietf-anima-brski-async-enroll] describes a generalization
regarding enrollment protocols alternative to EST [RFC7030]. As
replacement of EST simpleenroll, BRSKI-AE uses this PKI management
operation for bootstrapping LDevID certificates.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The certificate of the EE MUST have been enrolled by an external * The certificate of the EE MUST have been enrolled by an external
PKI, e.g., a manufacturer-issued device certificate. PKI, e.g., a manufacturer-issued device certificate.
* The PKI management entity MUST have the trust anchor of the * The PKI management entity MUST have the trust anchor of the
external PKI. external PKI.
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
skipping to change at page 32, line 43 skipping to change at page 34, line 14
For this PKI management operation, the EE MUST include exactly one For this PKI management operation, the EE MUST include exactly one
CertReqMsg in the ir. If more certificates are required, further CertReqMsg in the ir. If more certificates are required, further
requests MUST be sent using separate PKI management operation. If requests MUST be sent using separate PKI management operation. If
the EE wants to omit sending a certificate confirmation message after the EE wants to omit sending a certificate confirmation message after
receiving the ip, e.g., to reduce the number of protocol messages receiving the ip, e.g., to reduce the number of protocol messages
exchanged in this PKI management operation, it MUST request this by exchanged in this PKI management operation, it MUST request this by
including the implicitConfirm extension in the header of the ir including the implicitConfirm extension in the header of the ir
message, see Section 3.1. message, see Section 3.1.
If the EE did not request implicit confirmation or the request was If the EE did not request implicit confirmation or timplicit
not granted by the PKI management entity, certificate confirmation confirmation was not granted by the PKI management entity,
MUST be performed as follows. If the EE successfully received the certificate confirmation MUST be performed as follows. If the EE
certificate, it MUST send a certConf message in due time. On successfully received the certificate, it MUST send a certConf
receiving a certConf message, the PKI management entity MUST respond message in due time. On receiving a valid certConf message, the PKI
with a pkiConf message. If the PKI management entity does not management entity MUST respond with a pkiConf message. If the PKI
receive the expected certConf message in time it MUST handle this management entity does not receive the expected certConf message in
like a rejection by the EE. In case of rejection the PKI management time it MUST handle this like a rejection by the EE. In case of
entity SHALL terminate the PKI management operation, and the PKI MAY rejection the PKI management entity SHALL terminate the PKI
revoke the newly issued certificate. management operation, and the PKI MAY revoke the newly issued
certificate.
If the EE did not request implicit confirmation or the request was
not granted by the PKI management entity, certificate confirmation
MUST be performed as follows. If the EE successfully received the
certificate and accepts it, the EE MUST send a certConf message,
which the PKI management entity must respond using a pkiConf message.
If the PKI management entity does not receive the expected certConf
message in time it MUST handle this like a rejection by the EE. In
this case the PKI management entity SHALL terminate the PKI
management operation. The PKI MAY revoke the newly issued
certificates depending on the local policy.
If the certificate request was rejected by the CA, the PKI management 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 3.6 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:
Initialization Request -- ir Initialization Request -- ir
skipping to change at page 35, line 12 skipping to change at page 36, line 22
-- certificate, of the certificate contained in certOrEncCert -- certificate, of the certificate contained in certOrEncCert
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
-- positive values allowed: "accepted", "grantedWithMods" -- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
-- "waiting" only allowed with polling use case as described in
-- Section 4.4
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 status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" or "grantedWithMods" -- MUST be absent if status is "accepted" or "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
skipping to change at page 35, line 50 skipping to change at page 37, line 14
-- 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 as 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 contain 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 hash algorithm -- MUST be the hash of the certificate, using the hash algorithm
-- indicated in hashAlg or the same one as used to create the -- indicated in hashAlg, see below, or the same one as used to
-- certificate signature -- create the certificate signature
certReqId REQUIRED certReqId REQUIRED
-- MUST be 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
-- MAY be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" -- MUST be absent if status is "accepted"
hashAlg OPTIONAL
-- The hash algorithm to use for calculating certHash
-- SHOULD NOT be used in all cases where the AlgorithmIdentifier
-- of the certificate signature specifies a hash algorithm
-- If used, the pvno field in the header MUST be cmp2021 (3)
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first request message -- MUST use the same credentials as in the first request message
-- of this PKI management operation -- of this PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- MAY be omitted if the message size is critical and -- MAY be omitted if the message size is critical and
-- the PKI management entity caches the extraCerts from the -- the PKI management entity caches the extraCerts from the
skipping to change at page 39, line 14 skipping to change at page 40, line 17
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-based protection 4.1.4. Requesting a certificate from a legacy PKI using a PKCS#10
This PKI management operation should be used by an EE to request a
certificate of a new PKI in case it does not have a certificate to
prove its identity to the target PKI, but has some secret information
shared with the PKI management entity. Therefore, the request and
response messages are MAC-protected using this shared secret
information. The PKI management entity checking the MAC-based
protection SHOULD replace this protection according to Section 5.2.3
in case the next hop does not know the shared secret information.
Note: The entropy of the shared secret information is crucial for the
level of protection when using MAC-based protection. Further
guidance is available in Section 8.
Specific prerequisites augmenting the prerequisites in Section 3.4:
* Rather than using private keys, certificates, and trust anchors,
the EE and the PKI management entity MUST share secret
information.
Note: The shared secret information MUST be established out-of-
band, e.g., by a service technician during initial local
configuration.
* When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes:
1 The protection of all messages MUST be MAC-based.
2 The senderKID MUST contain a reference the recipient can use to
identify the shared secret information used for the protection,
e.g., the username of the EE.
3 The extraCerts of all messages does not contain CMP protection
certs and associated chains.
See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for
details on message authentication code algorithms (MSG_MAC_ALG) to
use. Typically, parameters are part of the protectionAlg field,
e.g., used for key derivation, like a salt and an iteration count.
Such fields SHOULD remain constant for message protection throughout
this PKI management operation to reduce the computational overhead.
4.1.5. Requesting a certificate from a legacy PKI using a PKCS#10
request 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]. This offers a variation of the PKI management operations [RFC4211]. This offers a variation of the PKI management operations
specified in Section 4.1.1 to Section 4.1.4. specified in Section 4.1.2.
In this PKI management operation the public key and all further In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments,
SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr
message as a form of certificate signing request (CSR) to optionally
include in device bootstrapping to obtain an identity certificate as
part of the onboarding information. Such a CSR is of form ietf-sztp-
types:cmp-csr from module ietf-sztp-csr. The requirements given
below on p10cr message MUST be adhered to.
In this PKI management operation, the public key and all further
certificate template data MUST be contained in the subjectPKInfo and certificate template data MUST be contained in the subjectPKInfo and
other certificationRequestInfo fields of the PKCS#10 structure. other certificationRequestInfo fields of the PKCS#10 structure.
The prerequisites are the same as given in Section 4.1.1, The prerequisites are the same as given in Section 4.1.2.
Section 4.1.2, Section 4.1.3, or Section 4.1.4.
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 to Section 4.1.4, with the following to that given in Section 4.1.2, with the following changes:
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 -1.
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:
Certification Request -- p10cr Certification Request -- p10cr
Field Value Field Value
header header
skipping to change at page 42, line 5 skipping to change at page 42, line 5
-- subjectPKInfo field. -- subjectPKInfo field.
signature REQUIRED signature REQUIRED
-- MUST contain the self-signature for proof-of-possession -- MUST contain the self-signature for proof-of-possession
protection REQUIRED protection REQUIRED
-- As described for the underlying PKI management operation -- As described for the underlying PKI management operation
extraCerts REQUIRED extraCerts REQUIRED
-- As described for the underlying PKI management operation -- As described for the underlying PKI management operation
4.1.5. Requesting a certificate from a PKI with MAC-based protection
This is a variant of the PKI management operations described in
Section 4.1.1 to Section 4.1.4. It should be used by an EE to
request a certificate of a new PKI in case it does not have a
certificate to prove its identity to the target PKI, but has some
secret information shared with the PKI management entity. Therefore,
the request and response messages are MAC-protected using this shared
secret information. The distribution of this shared secret is out of
scope for this document. The PKI management entity checking the MAC-
based protection SHOULD replace this protection according to
Section 5.2.3 in case the next hop does not know the shared secret
information.
Note: The entropy of the shared secret information is crucial for the
level of protection when using MAC-based protection. Further
guidance is available in the security considerations of CMP updated
by [I-D.ietf-lamps-cmp-updates].
Specific prerequisites augmenting the prerequisites in Section 3.4:
* Rather than using private keys, certificates, and trust anchors,
the EE and the PKI management entity MUST share secret
information.
Note: The shared secret information MUST be established out-of-
band, e.g., by a service technician during initial local
configuration.
* When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes:
1 The protection of all messages MUST be MAC-based.
2 The senderKID MUST contain a reference the recipient can use to
identify the shared secret information used for the protection,
e.g., the username of the EE.
3 The extraCerts of all messages does not contain CMP protection
certs and associated chains.
See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for
details on message authentication code algorithms (MSG_MAC_ALG) to
use. Typically, parameters are part of the protectionAlg field,
e.g., used for key derivation, like a salt and an iteration count.
Such fields SHOULD remain constant for message protection throughout
this PKI management operation to reduce the computational overhead.
4.1.6. Adding central key pair generation to a certificate request 4.1.6. Adding central key pair generation to a certificate request
This functional extension can combined with certificate enrollment as This is a variant of the PKI management operations described in
described in Section 4.1.1 to Section 4.1.4. It needs to be used in Section 4.1.1 to Section 4.1.4 and the variant described in
case an EE is not able to generate its new public-private key pair Section 4.1.5. It needs to be used in case an EE is not able to
itself or central generation of the EE key material is preferred. It generate its new public-private key pair itself or central generation
is a matter of the local implementation which PKI management entity of the EE key material is preferred. It is a matter of the local
will act as Key Generation Authority (KGA) and perform the key implementation which PKI management entity will act as Key Generation
generation. This PKI management entity MUST use a certificate Authority (KGA) and perform the key generation. This PKI management
containing the additional extended key usage extension id-kp-cmKGA in entity MUST use a certificate containing the additional extended key
order to be accepted by the EE as a legitimate key generation usage extension id-kp-cmKGA in order to be accepted by the EE as a
authority. legitimate key generation authority.
As described in Section 5.3.1, the KGA can use one of the PKI As described in Section 5.3.1, the KGA can use one of the PKI
management operations described in the sections above to request the management operations described in the sections above to request the
certificate for this key pair on behalf of the EE. 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
certificate request, this is advisable 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
skipping to change at page 43, line 51 skipping to change at page 45, line 13
Figure 3: Encrypted private key container Figure 3: Encrypted private key container
The PKI management entity delivers the private key in the privateKey The PKI management entity delivers the private key in the privateKey
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] and [RFC8933],
generating the key pair. The signature MUST be performed using a signed by the KGA generating the key pair. The signature MUST be
private key related to a certificate asserting the extended key usage performed using a private key related to a certificate asserting the
id-kp-cmKGA as described in CMP Updates [I-D.ietf-lamps-cmp-updates] extended key usage id-kp-cmKGA as described in CMP Updates
to demonstrate authorization to generate key pairs on behalf of an [I-D.ietf-lamps-cmp-updates] to demonstrate authorization to generate
EE. The EE SHOULD verify the presence of this extended key usage in key pairs on behalf of an EE. The EE SHOULD verify the presence of
the SignedData structure. this extended key usage in the SignedData structure.
Note: When using password-based key management technique as described Note: When using password-based key management technique as described
in Section 4.1.6.3 it may not be possible or meaningful to the EE to in Section 4.1.6.3 it may not be possible or meaningful to the EE to
validate the KGA signature in the SignedData structure since shared validate the KGA signature in the SignedData structure since shared
secret information is used for initial authentication. In this case secret information is used for initial authentication. In this case
the EE MAY omit this signature validation. the EE MAY omit this signature validation.
The 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.
skipping to change at page 46, line 15 skipping to change at page 47, line 22
contentType REQUIRED contentType REQUIRED
-- MUST be id-signedData -- MUST be id-signedData
contentEncryptionAlgorithm contentEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the algorithm used for -- MUST be the algorithm identifier of the algorithm used for
-- content encryption -- content encryption
-- The algorithm type 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 CMS -- MUST be the SignedData structure as specified in CMS
-- Section 5 [RFC5652] in encrypted form -- Section 5 [RFC5652] and [RFC8933] in encrypted form
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
digestAlgorithms digestAlgorithms
REQUIRED REQUIRED
-- MUST contain exactly one AlgorithmIdentifier element -- MUST contain exactly one AlgorithmIdentifier element
-- MUST be the algorithm identifier of the digest algorithm -- MUST be the algorithm identifier of the digest algorithm
-- used for generating the signature and match the signature -- used for generating the signature and match the signature
-- algorithm specified in signatureAlgorithm -- algorithm specified in signatureAlgorithm, see and [RFC8933]
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
-- MUST be of type AsymmetricKeyPackage and -- MUST be of type AsymmetricKeyPackage and
-- MUST contain exactly one OneAsymmetricKey element -- MUST contain exactly one OneAsymmetricKey element
version REQUIRED version REQUIRED
-- MUST be 1 (indicating v2) -- MUST be 1 (indicating v2)
skipping to change at page 46, line 45 skipping to change at page 48, line 4
REQUIRED REQUIRED
-- The privateKeyAlgorithm field MUST contain the algorithm -- The privateKeyAlgorithm field MUST contain the algorithm
-- identifier of the asymmetric key pair algorithm -- identifier of the asymmetric key pair algorithm
privateKey privateKey
REQUIRED REQUIRED
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
-- MUST contain the certificate for the private key used to sign -- MUST contain the certificate for the private key used to sign
-- the signedData content, together with its chain -- the signedData content, together with its chain
-- The first certificate in this field MUST be the KGA -- The first certificate in this field MUST be the KGA
-- certificate used for protecting this content -- certificate used for protecting this content
-- Self-signed certificates SHOULD NOT be included and MUST NOT -- Self-signed certificates SHOULD NOT be included and MUST NOT
-- be trusted based on their inclusion in any case -- be trusted based on their inclusion in any case
signerInfos REQUIRED signerInfos REQUIRED
-- MUST contain exactly one SignerInfo element -- MUST contain exactly one SignerInfo element
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
sid REQUIRED sid REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST be the subjectKeyIdentifier of the KGA 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 digestAlgorithms
signedAttrs REQUIRED signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the value -- MUST contain an id-contentType attribute containing the value
-- id-ct-KP-aKeyPackage -- 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 -- MAY contain an id-signingTime attribute containing the time
-- of signature -- of signature
-- For details on the signed attributes see CMS Section 5.3 and -- For details on the signed attributes see CMS Section 5.3 and
-- Section 11 [RFC5652] -- Section 11 [RFC5652] and [RFC8933]
signatureAlgorithm signatureAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the signature algorithm -- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits -- used for calculation of the signature bits
-- The signature algorithm type MUST be a MSG_SIG_ALG as -- The signature algorithm type MUST be a MSG_SIG_ALG as
-- specified in RFC-CMP-Alg Section 3 and MUST be consistent -- specified in RFC-CMP-Alg Section 3 and MUST be consistent
-- with the subjectPublicKeyInfo field of the KGA certificate -- with the subjectPublicKeyInfo field of the KGA certificate
signature REQUIRED signature REQUIRED
-- MUST be the digital signature of the encapContentInfo -- MUST be the digital signature of the encapContentInfo
skipping to change at page 49, line 4 skipping to change at page 50, line 13
-- 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 variant can be applied in combination with the PKI management This variant can be applied in combination with the PKI management
operations specified in Section 4.1.1 to Section 4.1.3 using operations specified in Section 4.1.1 to Section 4.1.3 using
signature-based protection of CMP messages. The EE certificate used signature-based protection of CMP messages. The EE certificate used
for the signature-based protection of the request message MUST allow for the signature-based protection of the request message MUST allow
for the key usage "keyEncipherment" and not for "keyAgreement". for the key usage "keyEncipherment" and not for "keyAgreement".
Therefore, the related key pair MUST be used for encipherment of the Therefore, the related key pair MUST be used for encipherment of the
content-encryption key. For this key management technique 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:
ktri REQUIRED ktri REQUIRED
skipping to change at page 49, line 37 skipping to change at page 50, line 46
-- MUST be the algorithm identifier of the key transport -- MUST be the algorithm identifier of the key transport
-- algorithm -- algorithm
-- The algorithm type MUST be a KM_KT_ALG as specified in -- The algorithm type MUST be a KM_KT_ALG as specified in
-- RFC-CMP-Alg Section 4.2 -- 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 variant can be applied in combination with the PKI management This variant can be applied in combination with the PKI management
operation specified in Section 4.1.4 using MAC-based protection of operation specified in Section 4.1.5 using MAC-based protection of
CMP messages. The shared secret information used for the MAC-based CMP messages. The shared secret information used for the MAC-based
protection MUST also be used for the encryption of the content- protection MUST also be used for the encryption of the content-
encryption key but with a different salt value applied in the key encryption key but with a different salt value applied in the key
derivation algorithm. For this key management technique the derivation algorithm. For this key management technique, the
PasswordRecipientInfo structure MUST be used in the contentInfo PasswordRecipientInfo structure MUST be used in the contentInfo
field. field.
Note: The entropy of the shared secret information is crucial for the Note: The entropy of the shared secret information is crucial for the
level of protection when using a password-based key management level of protection when using a password-based key management
technique. For centrally generated key pairs, the entropy of the technique. For centrally generated key pairs, the entropy of the
shared secret information SHALL not be less than the security shared secret information SHALL not be less than the security
strength of the centrally generated key pair. Further guidance is strength of the centrally generated key pair. Further guidance is
available in Section 8. available in Section 8.
skipping to change at page 50, line 30 skipping to change at page 51, line 37
-- The algorithm type MUST be a KM_KD_ALG as specified in -- The algorithm type MUST be a KM_KD_ALG as specified in
-- RFC-CMP-Alg Section 4.4 -- RFC-CMP-Alg Section 4.4
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key wrap algorithm -- MUST be the algorithm identifier of the key wrap algorithm
-- The algorithm type 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
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
4.1.7. Handling delayed enrollment
This functional extension can be applied in combination with
certificate enrollment as described in Section 4.1.1 to
Section 4.1.5, optionally including central key generation. The
functional extension can be used in case a PKI management entity
cannot respond to the certificate request in a timely manner, e.g.,
due to offline upstream communication or required human interaction.
Depending on the PKI architecture, the entity initiating delayed
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] delayed
enrollment is also possible for PKI management operations starting
with a p10cr request message.
The PKI management entity initiating the delayed enrollment MUST
respond with an ip/cp/kup message including the status "waiting".
When receiving a response with status "waiting" the EE MUST send a
poll request. The PKI management entity that initiated the delayed
enrollment MUST answer with a poll response containing a checkAfter
time. This value indicates the minimum number of seconds that SHOULD
elapse before the EE sends another poll request. This is repeated as
long as no final response is available or any party involved gives up
on the current PKI management operation. When the PKI management
entity that initiated delayed enrollment can provide the final ip/cp/
kup message for the initial request of the EE, it MUST provide this
message in response to a poll request. After receiving this
response, the EE can continue the original PKI management operation
as described in the respective section of this document, i.e.,
sending a certConf message if required.
No specific prerequisites apply in addition to those of the
respective certificate enrollment.
Message flow:
Step# EE PKI management entity
1 format ir/cr/p10cr/kur
2 ->ir/cr/p10cr/kur->
3 handle or forward request
4 in case no immediate final
response is possible,
format or receive ip/cp/
kup with status "waiting"
5 <- ip/cp/kup <-
6 handle ip/cp/kup with status "waiting"
-------------------------- start polling -------------------------
7 format pollReq
8 -> pollReq ->
9 handle or forward pollReq
10 in case the requested
certificate or a
corresponding response
message is available,
continue with step 14
otherwise, format or
receive pollRep with
checkAfter value
11 <- pollRep <-
12 handle pollRep
13 let checkAfter
time elapse and
continue with step 7
----------------- end polling, continue as usual -----------------
14 format or receive
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:
Response with status "waiting" -- ip/cp/kup
Field Value
header
-- MUST be as described for the first response message of the
-- respective PKI management operation
body
-- The response of the PKI management entity to the request in
-- case no immediate final response can be sent
ip/cp/kup REQUIRED
response REQUIRED
-- MUST contain exactly one CertResponse
certReqId REQUIRED
-- MUST be 0
status REQUIRED
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- MUST be "waiting"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to
-- display in a GUI
failInfo PROHIBITED
certifiedKeyPair PROHIBITED
protection REQUIRED
-- MUST be as described for the first response message of the
-- respective PKI management operation, except that the PKI
-- management entity that initiated the delayed enrollment and
-- created this response MUST apply its own protection
extraCerts REQUIRED
-- MUST be as described for the first response message of the
-- respective PKI management operation. Yet since no newly
-- enrolled certificate is available yet, no respective
-- certificate chain is included
Polling Request -- pollReq
Field Value
header
-- MUST contain a header as described for the certConf message
-- of the respective PKI management operation
body
-- The message of the EE asks for the final response or for a
-- time to check again
pollReq REQUIRED
-- MUST contain exactly one PollReqContent element
certReqId REQUIRED
-- MUST be 0
protection REQUIRED
-- MUST be as described for the certConf message of the
-- respective PKI management operation
extraCerts OPTIONAL
-- MUST be as described for the certConf message of the
-- respective PKI management operation
Polling Response -- pollRep
Field Value
header
-- MUST contain a header as described for the pkiConf message
-- of the respective PKI management operation
body
-- The message indicates the delay after which the EE SHOULD
-- send another pollReq message for this transaction
pollRep REQUIRED
-- MUST contain exactly one PollRepContent entry
certReqId REQUIRED
-- MUST be 0
checkAfter REQUIRED
-- time in seconds to elapse before a new pollReq SHOULD be sent
reason OPTIONAL
-- MAY be any human-readable text for debugging, logging or to
-- display in a GUI
protection REQUIRED
-- MUST be as described for the pkiConf message of the
-- respectiveprofile, except that the PKI management entity that
-- initiated the delayed enrollment and created this response
-- MUST apply its own protection
extraCerts OPTIONAL
-- If present, it MUST be as described for the pkiConf message
-- of the respective PKI management operation.
Final response -- ip/cp/kup
Field Value
header
-- MUST be as described for the first response except that the
-- PKI management entity that initiated the delayed enrollment
-- MUST use as recipNonce the senderNonce of the last pollReq
-- message
body
-- The response of the PKI management entity to the initial
-- request as described in the respective PKI management
-- operation
protection REQUIRED
-- MUST be as described for the first response message of this
-- PKI management operation, except that the PKI management
-- entity that initiated the delayed enrollment MUST re-protect
-- the response message
extraCerts REQUIRED
-- MUST be as described for the first response message of the
-- 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. 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. This requires, that the EE still possesses the private
key. If this is not the case the revocation has to be initiated by
other means, e.g., revocation by the RA as specified in
Section 5.3.2.
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 handles the issued this certificate. The PKI management entity handles the
request as described in Section 5.1.4 and responds with a message request as described in Section 5.1.4 and responds with a message
that contains the status of the revocation from the CA. that contains the status of the revocation from the CA.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* 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.
skipping to change at page 57, line 36 skipping to change at page 54, line 7
-- MUST be absent if the status is "accepted" -- 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. Support messages 4.3. Support messages
The following support messages offer on demand in-band transport of The following support messages offer on demand in-band delivery of
content relevant to the EE that may be provided by the PKI management content relevant to the EE provided by a PKI management entity. CMP
entity. CMP general messages and general response are used for this general messages and general response are used for this purpose.
purpose. Depending on the environment, these requests may be Depending on the environment, these requests may be answered by an RA
answered by an RA or CA (see also Section 5.1.5). or CA (see also Section 5.1.5).
The general messages and general response messages transport The general messages and general response messages contain
InfoTypeAndValue structures. In addition to those infoType values InfoTypeAndValue structures. In addition to those infoType values
defined in RFC 4210 [RFC4210] and CMP Updates defined in RFC 4210 [RFC4210] and CMP Updates
[I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new [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 update
* Get certificate request template * Get certificate request template
* Get new CRLs
In the following the aspects common to all general messages (genm) In the following the aspects common to all general messages (genm)
and general response (genp) messages are described. 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 or forward genm 3 handle or forward genm
4 format or receive genp 4 format or receive genp
skipping to change at page 58, line 31 skipping to change at page 55, line 13
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 for information
genm REQUIRED genm REQUIRED
-- MUST contain exactly one element of type InfoTypeAndValue -- MUST contain exactly one element of type InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying one of the specific PKI -- MUST be the OID identifying one of the specific PKI
-- management operations described below -- management operations described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific PKI management -- MUST be as specified for the specific PKI management operation
-- 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
skipping to change at page 59, line 4 skipping to change at page 55, line 31
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 on an information -- The response of the PKI management entity providing
-- request -- information
genp REQUIRED genp REQUIRED
-- MUST contain exactly one element of type InfoTypeAndValue -- MUST contain exactly one element of type InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying the specific PKI management -- MUST be the OID identifying the specific PKI management
-- operation described below -- operation described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific PKI management operation -- MUST be as specified for the specific PKI management 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
4.3.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
skipping to change at page 60, line 19 skipping to change at page 57, line 5
-- 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.3.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 request an 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 an update of a root CA certificate from the PKI
entity by sending a general message with OID id-it-rootCaKeyUpdate, management entity by sending a general message with OID id-it-
optionally including the certificate to be updated in the rootCaCert oldTrustAnchor, which SHOULD include this root CA certificate in the
generalInfo field, as specified in CMP Updates message body, as specified in CMP Updates
[I-D.ietf-lamps-cmp-updates]. The PKI management entity responds [I-D.ietf-lamps-cmp-updates]. Optionally, the trust anchor MAY be
with a general response with the same OID that either contains the provided as public key only. The PKI management entity responds with
update of the root CA certificate consisting of up to three a general response with the same OID that either contains the update
certificates, or with no content in case no update is available. of the root CA certificate consisting of up to three certificates, or
with no content in case no update is available.
Note: This mechanism can also be used in case the trust anchor to be
updated is not provided as a self-signed certificate, but, e.g., as a
certificate issued by a different CA.
The newWithNew certificate is the new root CA certificate and is The newWithNew certificate is the new root CA certificate and is
REQUIRED to be present if available. The newWithOld certificate is REQUIRED to be present if available. The newWithOld certificate is
REQUIRED to be present in the response message because it is needed REQUIRED to be present in the response message because it is needed
for the receiving entity trusting the old root CA certificate to gain for the receiving entity trusting the old root CA certificate to gain
trust in the new root CA certificate. The oldWithNew certificate is trust in the new root CA certificate. The oldWithNew certificate is
OPTIONAL because it is only needed in rare scenarios where entities OPTIONAL because it is only needed in rare scenarios where entities
do not already trust the old root CA. do not already trust the old root CA.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 3.4. Section 3.4.
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-rootCaKeyUpdate 1 the infoType OID to use is id-it-oldTrustAnchor in the request and
id-it-trustAnchorUpdate in the response
2 the rootCaCert general info field in the header of the request MAY 2 the infoValue of the request MUST be an OldTrustAnchor structure
contain the root CA certificate the update is requested for referencing the trust anchor the update is requested for
3 the infoValue of the request MUST be absent 3 if present, the infoValue of the response MUST be a
TrustAnchorUpdate structure
4 if present, the infoValue of the response MUST be a The infoValue field of the general request containing the id-it-
RootCaKeyUpdateContent structure oldTrustAnchor OID looks like this:
infoValue RECOMMENDED
-- MUST contain an OldTrustAnchor structure referencing the
-- trust anchor to be updated
-- SHOULD be the root CA certificate, if available
-- MAY be the publicKey of the trust anchor otherwise
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
rootCaKeyUpdate extension looks like this: trustAnchorUpdate OID 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 TrustAnchorUpdate
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 REQUIRED newWithOld REQUIRED
-- MUST 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
4.3.3. Get certificate request template 4.3.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 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 EE MAY specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The EE MAY
indicate the certificate profile to use in the certProfile extension indicate the certificate profile to use in the id-it-certProfile
of the generalInfo field in the PKIHeader of the general message as extension of the generalInfo field in the PKIHeader of the general
described in Section 3.1. The PKI management entity responds with a message as described in Section 3.1. The PKI management entity
general response with the same OID that either contains requirements responds with a general response with the same OID that either
on the certificate request template, or with no content in case no contains requirements on the certificate request template, or with no
specific requirements are imposed by the PKI. The content in case no specific requirements are imposed by the PKI. The
CertReqTemplateValue contains requirements on certificate fields and CertReqTemplateValue contains requirements on certificate fields and
extensions in a certTemplate. Optionally it contains a keySpec field 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. generation.
The EE SHOULD follow the requirements from the received CertTemplate, The EE SHOULD follow the requirements from the received CertTemplate,
by including in the certificate requests all the fields requested, by including in the certificate requests all the fields requested,
taking over all the field values provided and filling in any taking over all the field values provided and filling in any
remaining fields values. The EE SHOULD NOT add further fields, name remaining fields values. The EE SHOULD NOT add further fields, name
components, and extensions or their (sub-)components. components, and extensions or their (sub-)components.
skipping to change at page 62, line 45 skipping to change at page 59, line 42
optionally with parameters, and/or RSA key lengths for which a optionally with parameters, and/or RSA key lengths for which a
certificate may be requested. certificate may be requested.
The value of a keySpec element with the OID id-regCtrl-algId, as The value of a keySpec element with the OID id-regCtrl-algId, as
specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of
type AlgorithmIdentifier and give an algorithm other than RSA. For type AlgorithmIdentifier and give an algorithm other than RSA. For
EC keys the 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 element 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 a
type Integer and give an RSA key length. positive integer value and give an RSA key length.
In the CertTemplate of the CertReqTemplateValue the serialNumber, In the CertTemplate of the CertReqTemplateValue the serialNumber,
signingAlg, issuerUID, and subjectUID fields MUST be omitted. signingAlg, issuerUID, and subjectUID fields MUST be omitted.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-certReqTemplate 1 the infoType OID to use is id-it-certReqTemplate
2 the certProfile generalInfo field in the header of the request MAY 2 the id-it-certProfile generalInfo field in the header of the
contain the name of the requested certificate request template request MAY contain the name of the requested certificate request
template
3 the infoValue of the request MUST be absent 3 the infoValue of the request MUST be absent
4 if present, the infoValue of the response MUST be a 4 if present, the infoValue of the response MUST be a
CertReqTemplateValue containing a CertTemplate structure and an CertReqTemplateValue containing a CertTemplate structure and an
optional keySpec field 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:
skipping to change at page 63, line 42 skipping to change at page 60, line 40
-- The SubjectPublicKeyInfo field MUST be absent -- The SubjectPublicKeyInfo field MUST be absent
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 -- available
-- MUST be present if the PKI management entity has any -- MUST be present if the PKI management entity has any
-- requirements on the keys generated -- requirements on the keys generated
-- MUST contain one AttributeTypeAndValue per supported -- MUST contain one AttributeTypeAndValue per supported
-- algorithm with attribute id-regCtrl-algId or -- algorithm with attribute id-regCtrl-algId or
-- id-regCtrl-rsaKeyLen -- id-regCtrl-rsaKeyLen
4.3.4. CRL update retrieval
This PKI management operation can be used by an EE to request a new
CRL. If a CA offers methods to access a CRL they are often provided
by the CA through the CRLDP or AuthorityInfoAccess as specified in
[RFC5280] components in the issued certificates. In addition, CMP
offers this functionality as part of the PKI management operation.
An EE requests a CRL update from the PKI management entity by sending
a general message with OID id-it-crlStatusList. This MUST include
the CRL source and, if available, the thisUpdate time of the most
current CRL instance it already has, as specified in CMP Updates
[I-D.ietf-lamps-cmp-updates]. The PKI management entity MUST respond
with a general response with OID id-it-crls. If no thisUpdate value
was given by the EE, it MUST return the latest CRL available. If a
thisUpdate value was given, it MUST return the latest available CRL
in case this CRL is more recent, otherwise the infoValue in the
response message MUST be absent.
In addition to the prerequisites specified in Section 3.4, the EE
MUST know for the requested CRL either its CRL distribution point
name or the name of the CRL issuer.
Note: If the EE does not want to request a specific CRL it MAY use
instead a general message with OID id-it-currentCrl as specified in
RFC 4210 Section 5.3.19.6 [I-D.ietf-lamps-cmp-updates].
The message sequence for this PKI management operation is as given
above, with the following specific content:
1 the infoType OID to use is id-it-crlStatusList in the request and
id-it-crls in the response
2 the infoValue of the request MUST be present and contain a
CRLStatus structure
3 if present, the infoValue of the response MUST contain a CRL
The infoValue field of the general request containing the id-it-
crlStatusList OID looks like this:
CRLSourceListValue REQUIRED
-- MUST contain a CRLSource structure
-- MUST contain the dpn choice if the CRL distribution point name
-- is available
-- MUST contain the issuer choice otherwise, naming the CA that
-- issues the CRL.
thisUpdate OPTIONAL
-- SHOULD contain the thisUpdate field of the latest CRL form
-- the given dpn or issuer, in case such a CRL is already known
-- by the EE
The infoValue field of the general response containing the id-it-crls
OID looks like this:
infoValue REQUIRED
-- MUST contain a CRL update from the referenced source, if a
-- thisUpdate value was not given or a more recent CRL is
-- available
4.4. Handling delayed delivery
This is a variant of all PKI management operations described in
described in this document. It is initiated in case a PKI management
entity cannot respond to a request message in a timely manner,
typically due to offline or asynchronous upstream communication, or
due to delays in handling the request. The polling mechanism has
been specified in RFC 4210 Section 5.3.22 [RFC4210] and updated by
[I-D.ietf-lamps-cmp-updates].
Depending on the PKI architecture, the entity initiating delayed
delivery is not necessarily the PKI management entity directly
addressed by the EE.
When initiating delayed delivery of a message received from an EE,
the PKI management entity MUST respond with an ip/cp/kup/error
message including the status "waiting". On receiving this response,
the EE MUST store in its transaction context the senderNonce of the
preceding request message because this value will be needed for
checking the recipNonce of the final response to be received after
polling. It sends a poll request with certReqId 0 if referring to
the CertResponse element contained in the ip/cp/kup message, else -1
to refer to the whole message. In case the final response is not yet
available, the PKI management entity that initiated the delayed
delivery MUST answer with a poll response, with the same certReqId.
The included checkAfter time value indicates the minimum number of
seconds that SHOULD elapse before the EE sends a new pollReq message
to the PKI management entity. This is repeated until a final
response is available or any party involved gives up on the current
PKI management operation, i.e., a timeout occurs.
When the PKI management entity that initiated delayed delivery can
provide the final response for the original request message of the
EE, it MUST send this response to the EE. Using this response, the
EE can continue the current PKI management operation as usual.
No specific prerequisites apply in addition to those of the
respective PKI management operation.
Message flow:
Step# EE PKI management entity
1 format request
message
2 -> request ->
3 handle or forward
request
4 format ip/cp/kup/error
with status "waiting"
response in case no
immediate final response
is available,
5 <- ip/cp/kup/error <-
6 handle
ip/cp/kup/error
with status
"waiting"
-------------------------- start polling --------------------------
7 format pollReq
8 -> pollReq ->
9 handle or forward pollReq
10 in case the final response
for the original request
is available, continue
with step 14
otherwise, format or
receive pollRep with
checkAfter value
11 <- pollRep <-
12 handle pollRep
13 let checkAfter
time elapse and
continue with
step 7
----------------- end polling, continue as usual ------------------
14 format or receive
final response on
original request
15 <- response <-
16 handle final
response
Detailed description of the ip/cp/kup/error response, pollReq, and
pollRep:
Response with status "waiting" -- ip/cp/kup/error
Field Value
header
-- As described in Section 3.1
body
-- as described for the respective PKI management operation, with
-- the following adaptations:
status REQUIRED -- in case of ip/cp/kup
pKIStatusInfo REQUIRED -- in case of error response
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- MUST be status "waiting"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to
-- display in a GUI
failInfo PROHIBITED
protection REQUIRED
-- As described in Section 3.2
extraCerts OPTIONAL
-- As described in Section 3.3
Polling Request -- pollReq
Field Value
header
-- As described in Section 3.1
body
-- The message of the EE asking for the final response or for a
-- time to check again
pollReq REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first request message
-- of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and
-- the PKI management entity caches the extraCerts from the
-- first request message of the PKI management operation
Polling Response -- pollRep
Field Value
header
-- As described in Section 3.1
body
-- The message indicates the delay after which the EE SHOULD
-- send another pollReq message for this transaction
pollRep REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
checkAfter REQUIRED
-- time in seconds to elapse before a new pollReq SHOULD be sent
reason OPTIONAL
-- MAY be any human-readable text for debugging, logging or to
-- display in a GUI
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first response
-- message of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has
-- cached the extraCerts from the first response message of
-- the PKI management operation
Final response – any type of response message
Field Value
header
-- MUST be the header as described for the response message
-- of the respective PKI management operation
body
-- The response of the PKI management entity to the initial
-- request as described in the respective PKI management
-- operation
protection REQUIRED
-- MUST be as described for the response message of the
-- respective PKI management operation
extraCerts REQUIRED
-- MUST be as described for the response message of the
-- respective PKI management operation
5. PKI management entity operations 5. PKI management entity operations
This section focuses on request processing by a PKI management This section focuses on request processing by a PKI management
entity. Depending on the network and PKI solution design, this can entity. Depending on the network and PKI solution design, this can
be an RA or CA, any of which may include protocol conversion or be an RA or CA, any of which may include protocol conversion or
central key generation (i.e., acting as a KGA). central key generation (i.e., acting as a KGA).
A PKI management entity may directly respond to request messages from A PKI management entity may directly respond to request messages from
downstream and report errors. In case the PKI management entity is downstream and report errors. In case the PKI management entity is
an RA it typically forwards the received request messages upstream an RA it typically forwards the received request messages upstream
skipping to change at page 64, line 24 skipping to change at page 66, line 45
related CMP response message or an error. Any intermediate PKI related CMP response message or an error. Any intermediate PKI
management entity MAY respond depending on the PKI configuration and management entity MAY respond depending on the PKI configuration and
policy. policy.
In addition to the checks described in Section 3.5, the responding In addition to the checks described in Section 3.5, the responding
PKI management entity SHOULD check that a request that initiates a PKI management entity SHOULD check that a request that initiates a
new PKI management operation does not use a transactionID that is new PKI management operation does not use a transactionID that is
currently in useThe failInfo bit value to use on reporting failure as currently in useThe failInfo bit value to use on reporting failure as
described in Section 3.6.4 is transactionIdInUse. If any of these described in Section 3.6.4 is transactionIdInUse. If any of these
verification steps or any of the essential checks described in the verification steps or any of the essential checks described in the
below subsections fails, the PKI management entity MUST proceed as following subsections fails, the PKI management entity MUST proceed
described in Section 3.6. as described in Section 3.6.
The responding PKI management entity SHOULD copy the sender field of The responding PKI management entity SHOULD copy the sender field of
the request to the recipient field of the response, MUST copy the the request to the recipient field of the response, MUST copy the
senderNonce of the request to the recipNonce of the response, and senderNonce of the request to the recipNonce of the response, and
MUST use the same transactionID for the response. MUST use the same transactionID for the response.
5.1.1. Responding to a certificate request 5.1.1. Responding to a certificate request
An ir/cr/p10cr/kur message is used to request a certificate as An ir/cr/p10cr/kur message is used to request a certificate as
described in Section 4.1. The responding PKI management entity MUST described in Section 4.1. The responding PKI management entity MUST
proceed as follows unless it initiates delayed enrollment as proceed as follows unless it initiates delayed delivery as described
described in Section 5.1.2. in Section 5.1.2.
The PKI management entity SHOULD check the message body according to The PKI management entity SHOULD check the message body according to
the applicable requirements from Section 4.1. Possible failInfo bit the applicable requirements from Section 4.1. Possible failInfo bit
values used for error reporting in case a check failed include values used for error reporting in case a check failed include
badCertId and badCertTemplate. It MUST verify the presence and value badCertId and badCertTemplate. It MUST verify the presence and value
of the proof-of-possession (failInfo bit: badPOP), unless central key of the proof-of-possession (failInfo bit: badPOP), unless central key
generation is requested. In case the special POP value "raVerified" generation is requested. In case the special POP value "raVerified"
is given, it SHOULD check that the request message was signed using a is given, it SHOULD check that the request message was signed using a
certificate containing the cmcRA extended key usage (failInfo bit: certificate containing the cmcRA extended key usage (failInfo bit:
notAuthorized). The PKI management entity SHOULD perform also any notAuthorized). The PKI management entity SHOULD perform also any
skipping to change at page 65, line 22 skipping to change at page 67, line 42
It may have issued the certificate for the newly generated key pair 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 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 the EE as described in Section 5.3.1, or have received it by other
means from a CA. means from a CA.
The prerequisites of the respective PKI management operation as The prerequisites of the respective PKI management operation as
specified in Section 4.1 apply. specified in Section 4.1 apply.
Note: If the EE requested omission of the certConf message, the PKI 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 management entity SHOULD handle it as described in Section 4.1.1 and
therfore MAY grant this by including the implicitConfirm extension in therefore MAY grant this by including the implicitConfirm extension
the response header. in the response header.
5.1.2. Initiating delayed enrollment 5.1.2. Initiating delayed delivery
This functional extension can be used by a PKI management entity to This functional extension can be used by a PKI management entity in
initiate delayed enrollment. In this case a PKI management entity case the response to a request takes longer than usual. In this case
MUST use the status "waiting" in the response message as described in the PKI management entity MUST completely validate the request as
Section 4.1.7 and then MUST reply to pollReq messages as described usual and then start preparing the response or forward the request
there. further upstream as soon as possible. In the meantime, it MUST
respond with an ip/cp/kup/error message including the status
"waiting" and handle subsequent polling as described in Section 4.4.
Typically, as stated in Section 5.2.3, an intermediate PKI management Note: Typically, as stated in Section 5.2.3, an intermediate PKI
entity SHOULD NOT change the sender and recipient nonces even in case management entity should not change the sender and recipient nonces
it modifies a request or a response message. In the special case of even in case it modifies a request or a response message. In the
delayed enrollment initiated by an intermediate PKI management special case of delayed delivery initiated by an intermediate PKI
entity, for example by an LRA with offline transport to an upstream management entity, there is an exception. Between the EE and this
RA, there is an exception. Between the EE and this PKI management PKI management entity, pollReq and pollRep messages are exchanged
entity, pollReq and pollRep messages are exchanged handling the handling the nonces as usual. Yet when the final response from
nonces as usual. Yet when, after some pollRep, the final response upstream has arrived at the PKI management entity, this response
from upstream arrives at the PKI management entity, this response
contains the recipNonce copied (as usual) from the senderNonce in the contains the recipNonce copied (as usual) from the senderNonce in the
original request message. The PKI management entity that initiated original request message. The PKI management entity that initiated
the delayed enrollment MUST replace the recipNonce in the response the delayed delivery may replace the recipNonce in the response
message with the senderNonce of the last received pollReq because the message with the senderNonce of the last received pollReq because the
downstream entities, including the EE, will expect it in this way. downstream entities, including the EE, might expect it in this way.
Yet the check specified in Section 3.5 allows to alternatively use
the senderNonce of the original request.
The prerequisites of the respective PKI management operation as No specific prerequisites apply in addition to those of the
specified in Section 4.1.7 apply. respective PKI management operation.
5.1.3. Responding to a confirmation message 5.1.3. Responding to a confirmation message
A PKI management entity MUST handle a certConf message if it has A PKI management entity MUST handle a certConf message if it has
responded before with a positive ip/cp/kup message not granting responded before with a positive ip/cp/kup message not granting
implicit confirmation. It SHOULD check the message body according to implicit confirmation. It SHOULD check the message body according to
the requirements given in Section 4.1.1 (failInfo bit: badCertId) and the requirements given in Section 4.1.1 (failInfo bit: badCertId) and
react as described there. react as described there.
The prerequisites of the respective PKI management operation as The prerequisites of the respective PKI management operation as
skipping to change at page 66, line 37 skipping to change at page 69, line 26
Section 3.4. Section 3.4.
5.1.5. Responding to a support message 5.1.5. Responding to a support message
A genm message is used to retrieve extra content. The responding PKI A genm message is used to retrieve extra content. The responding PKI
management entity SHOULD check the message body according to the management entity SHOULD check the message body according to the
applicable requirements in Section 4.3 and perform any further checks applicable requirements in Section 4.3 and perform any further checks
depending on the PKI policy. On success it MUST respond with a genp depending on the PKI policy. On success it MUST respond with a genp
message as described there. message as described there.
Note: The responding PKI management entity may generate the response
from scratch or reuse the contents of previous responses. Therefore,
it may be worth caching the body of the response message as long as
the contained information is still valid, such that further requests
for the same contents can be answered immediately.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 3.4. Section 3.4.
5.2. Forwarding messages 5.2. Forwarding messages
In case the PKI solution consists of intermediate PKI management In case the PKI solution consists of intermediate PKI management
entities (i.e., LRA or RA), each CMP request message coming from an entities (i.e., LRA or RA), each CMP request message coming from an
EE or any other downstream PKI management entity SHOULD be forwarded EE or any other downstream PKI management entity SHOULD be forwarded
to the next (upstream) PKI management entity as described in this to the next (upstream) PKI management entity as described in this
section and otherwise MUST be answered as described in Section 5.1. section and otherwise MUST be answered as described in Section 5.1.
skipping to change at page 67, line 43 skipping to change at page 70, line 38
* 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 delivery due to delays transferring messages or
communication or human interaction, or handling requests, or
* collect messages from multiple RAs and forward them jointly. * collect messages from multiple RAs and forward them jointly.
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]).
A PKI management entity MUST replace or add a protection of a message A PKI management entity MUST replace or add a protection of a message
if it if it
* 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 management entity on the message to one of the next (upstream) PKI management entity
skipping to change at page 71, line 16 skipping to change at page 74, line 16
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 using the nested message structure. In this use case, messages using the nested message structure. In this use case,
nested messages are used both on the upstream interface towards the nested messages are used both on the upstream interface towards the
next PKI management entity and on the downstream interface from the next PKI management entity and on the downstream interface from 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 an LRA and an RA to bundle several messages for offline between an LRA and an RA to bundle several messages for offline
transport. In this case the LRA needs to initiate delayed enrollment delivery. In this case the LRA needs to initiate delayed delivery as
as described in Section 5.1.2. If the RA needs different routing described in Section 5.1.2. If the RA needs different routing
information per nested PKI management message a suitable mechanism information per nested PKI management message a suitable mechanism
may need to be implemented. Since this mechanism strongly depends on may need to be implemented. Since this mechanism strongly depends on
the requirements of the target architecture, it is out of scope of the requirements of the target architecture, it is out of scope of
this document. this document.
A nested message containing requests is generated locally at the PKI A nested message containing requests is generated locally at the PKI
management entity. For the upstream nested message, the PKI management entity. For the upstream nested message, the PKI
management entity acts as a protocol end point and therefore a fresh management entity acts as a protocol end point and therefore a fresh
transactionID and a fresh senderNonce MUST be used in the header of transactionID and a fresh senderNonce MUST be used in the header of
the nested message. An upstream nested message may contain request the nested message. An upstream nested message may contain request
skipping to change at page 73, line 18 skipping to change at page 76, line 18
Generation Authority, which needs to use it for encrypting the new Generation Authority, which needs to use it for encrypting the new
private key for the EE. private key for the EE.
In both the kur and central key generation cases, if a PKI management 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 entity needs to state its approval of the original request message it
MUST provide this using a nested message as specified in MUST provide this using a nested message as specified in
Section 5.2.2.1. Section 5.2.2.1.
When an intermediate PKI management entity modifies a message, it When an intermediate PKI management entity modifies a message, it
SHOULD NOT change the transactionID nor the sender and recipient SHOULD NOT change the transactionID nor the sender and recipient
nonces except as stated for delayed enrollment in Section 4.1.7 and nonces.
Section 5.1.2.
5.2.3.1. Not changing any included proof-of-possession 5.2.3.1. Not changing any included proof-of-possession
This variant of forwarding a message means that a PKI management This variant of forwarding a message means that a PKI management
entity forwards a CMP message with or without modifying the message entity forwards a CMP message with or without modifying the message
header or body while preserving any included proof-of-possession. header or body while preserving any included proof-of-possession.
In case the PKI management entity breaks an existing proof-of- In case the PKI management entity breaks an existing proof-of-
possession, the message adaptation described in Section 5.2.3.2 needs possession, the message adaptation described in Section 5.2.3.2 needs
to be applied instead. to be applied instead.
skipping to change at page 75, line 31 skipping to change at page 78, line 27
Note: An upstream PKI management entity will not be able to Note: An upstream PKI management entity will not be able to
differentiate this PKI management operation from the ones described differentiate this PKI management operation from the ones described
in Section 5.2.3. in Section 5.2.3.
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.2, with the following changes: 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 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. PKI management entity taking the role of the EE in this operation.
6. CMP message transport mechanisms 6. CMP message transfer mechanisms
The CMP messages are designed to be self-contained, such that in 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 reliable transfer mechanism can be used. HTTP SHOULD
transport while file-based transport MAY be used in case offline and CoAP MAY be used for online transfer. CMP messages MAY also be
transport is required. In case HTTP transport is not desired or piggybacked on any other reliable transfer protocol. File-based
possible, CMP messages MAY also be piggybacked on any other reliable transfer MAY be used in case offline transfer is required.
transport protocol such as CoAP [RFC7252].
Independently of the means of transport, it can happen that messages Independently of the means of transfer, 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
Request message is to be expected from the client side within the Request message is to be expected from the client side within the
same transaction. In this way a hanging transaction can be closed same transaction. In this way a hanging transaction can be closed
cleanly with an error as described in Section 3.6 (failInfo bit: cleanly with an error as described in Section 3.6 (failInfo bit:
systemUnavail) and related resources (for instance, any cached systemUnavail) and related resources (for instance, any cached
extraCerts) can be freed. extraCerts) can be freed.
When conveying a CMP messages in HTTP, CoAP, or MIME-based transport Moreover, there are various situations where the delivery of messages
gets delayed. For instance, a serving PKI management entity might
take longer than expected to form a response due to administrative
processes, resource constraints, or upstream message delivery delays.
The transport layer itself may cause delays, for instance due to
offline transport, network segmentation, or intermittent network
connectivity. Part of these issues can be detected and handled at
CMP level using pollReq and pollRep messages as described in
Section 4.4, while others are better handled at transfer level.
Depending on the transfer protocol and system architecture, solutions
for handling delays at transfer level may be present and can be used
for CMP connections, for instance connection re-establishment and
message retransmission.
Note: Long timeout periods are helpful to minimize the need for
polling and maximize chances to handle transfer issues at lower
levels.
Note: When using TCP and similar reliable connection-oriented
transport protocols, which is typical in conjunction with HTTP, there
is the option to keep the connection alive over multiple request-
response message pairs. This may improve efficiency, though is not
required from a security point of view.
When conveying CMP messages in HTTP, CoAP, or MIME-based transfer
protocols, the internet media type "application/pkixcmp" MUST be set protocols, the internet media type "application/pkixcmp" MUST be set
for transport encoding as specified in Section 5.3 of RFC 2510 for transfer encoding as specified in Section 5.3 of RFC 2510
[RFC2510], Section 2.4 of CMP over CoAP [RFC2510], Section 2.4 of CMP over CoAP
[I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP
[RFC6712]. [RFC6712].
Note: When using TCP as reliable transport layer protocol, which is 6.1. HTTP transfer
typical in conjunction with HTTP, there is the option to keep the
connection open over the lifetime of the PKI management operation
containing multiple request-response message pairs. This may improve
efficiency but is not required from a security point of view.
6.1. HTTP transport
This transport mechanism can be used by a PKI entity to transfer CMP This transfer 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 transfer 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 paths. When a PKI management operations SHOULD use URI paths consisting of '/.well-
single request message is nested as described in Section 5.2.2.1, the known/cmp/' followed by an operation label depending on the type of
endpoint to use is the same as for the underlying request message. PKI management operation.
For MAC-based protection the endpoint of the respective message body +=======================================+=================+=========+
SHALL be used, e.g, use /initialization for ir messages. | PKI management operation | operationLabel | Details |
+=======================================+=================+=========+
| Enroll client to new PKI | /initialization | Section |
| | | 4.1.1 |
+---------------------------------------+-----------------+---------+
| Enroll client to existing | /certification | Section |
| PKI | | 4.1.2 |
+---------------------------------------+-----------------+---------+
| Update client certificate | /keyupdate | Section |
| | | 4.1.3 |
+---------------------------------------+-----------------+---------+
| Enroll client using | /p10 | Section |
| PKCS#10 | | 4.1.4 |
+---------------------------------------+-----------------+---------+
| Revoke client certificate | /revocation | Section |
| | | 4.2 |
+---------------------------------------+-----------------+---------+
| Get CA certificates | /getcacerts | Section |
| | | 4.3.1 |
+---------------------------------------+-----------------+---------+
| Get root CA certificate | /getrootupdate | Section |
| update | | 4.3.2 |
+---------------------------------------+-----------------+---------+
| Get certificate request | /getcacerts | Section |
| template | | 4.3.1 |
+---------------------------------------+-----------------+---------+
| Get CRL updates | /getcrls | Section |
| | | 4.3.4 |
+---------------------------------------+-----------------+---------+
| Batching messages | /nested | Section |
| | | 5.2.2.2 |
| Note: This path element is | | |
| applicable only between | | |
| PKI management entities. | | |
+---------------------------------------+-----------------+---------+
+=================================+=====================+=========+ Table 9: HTTP endpoints
| PKI management operation | Path | Details |
+=================================+=====================+=========+
| Enroll client to new PKI | /initialization | Section |
| | | 4.1.1 |
+---------------------------------+---------------------+---------+
| Enroll client to existing PKI | /certification | Section |
| | | 4.1.2 |
+---------------------------------+---------------------+---------+
| Update client certificate | /keyupdate | Section |
| | | 4.1.3 |
+---------------------------------+---------------------+---------+
| Enroll client using PKCS#10 | /p10 | Section |
| | | 4.1.5 |
+---------------------------------+---------------------+---------+
| Enroll client using central key | /serverkeygen | Section |
| generation | | 4.1.6 |
| | | |
| Note: This path element MAY | | |
| also be appended to each of the | | |
| path elements listed above. | | |
+---------------------------------+---------------------+---------+
| Revoke client certificate | /revocation | Section |
| | | 4.2 |
+---------------------------------+---------------------+---------+
| Get CA certificates | /getcacert | Section |
| | | 4.3.1 |
+---------------------------------+---------------------+---------+
| Get root CA certificate update | /getrootupdate | Section |
| | | 4.3.2 |
+---------------------------------+---------------------+---------+
| Get certificate request | /getcertreqtemplate | Section |
| template | | 4.3.3 |
+---------------------------------+---------------------+---------+
| Batching messages | /nested | Section |
| | | 5.2.2.2 |
| Note: This path element is | | |
| applicable only between PKI | | |
| management entities. | | |
+---------------------------------+---------------------+---------+
Table 9: HTTP endpoints Independently of any variants used (see Section 4.1.5, Section 4.1.6,
and Section 4.4) the operation label corresponding to the PKI
management operation SHALL be used.
Subsequent certConf and pollReq messages are sent to the URI of the Any certConf or pollReq messages are sent to the same endpoint as
first request message of the respective PKI management operation. determined by the PKI management operation.
By sending a request to its preferred enrollment endpoint, the PKI When a single request message is nested as described in
entity will recognize via the HTTP response status code whether a Section 5.2.2.1, the label to use is the same as for the underlying
configured URI is supported by the PKI management entity. PKI management operation.
By sending a request to its preferred endpoint, the PKI entity will
recognize via the HTTP response status code whether a configured URI
is supported by the PKI management entity.
In case a PKI management entity receives an unexpected HTTP status In case a PKI management entity receives an unexpected HTTP status
code from upstream, it MUST respond downstream with an error message code from upstream, it MUST respond downstream with an error message
as described in Section 3.6 using a failInfo bit corresponding to the as described in Section 3.6 using a failInfo bit corresponding to the
status code, e.g., systemFailure. status code, e.g., systemFailure.
For certificate management the major security goal is integrity and For certificate management the major security goal is integrity and
data origin authentication. For delivery of centrally generated data origin authentication. For delivery of centrally generated
keys, also confidentiality is a must. These goals are sufficiently keys, also confidentiality is a must. These goals are sufficiently
achieved by CMP itself, also in an end-to-end fashion. If a second 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 line of defense is required or general privacy concerns exist, TLS
can be used to provide confidentiality on a hop-by-hop basis. can be used to provide confidentiality on a hop-by-hop basis.
TLS SHOULD be used with certificate-based authentication to further TLS SHOULD be used with certificate-based authentication to further
protect the HTTP transport as described in [RFC2818]. The CMP protect the HTTP transfer as described in [RFC2818]. The CMP
transport via HTTPS MUST use TLS server authentication and SHOULD use transfer via HTTPS MUST use TLS server authentication and SHOULD use
TLS client authentication. TLS client authentication.
Note: The requirements for checking certificates given in [RFC5280], Note: The requirements for checking certificates given in [RFC5280],
[RFC5246], and [RFC8446] MUST be followed for the TLS layer. [RFC5246], and [RFC8446] MUST be followed for the TLS layer.
Certificate status checking SHOULD be used for the TLS certificates Certificate status checking SHOULD be used for the TLS certificates
of all communication partners. of all communication partners.
TLS with mutual authentication based on shared secret information MAY TLS with mutual authentication based on shared secret information MAY
be used in case no suitable certificates for certificate-based be used in case no suitable certificates for certificate-based
authentication are available, e.g., a PKI management operation with authentication are available, e.g., a PKI management operation with
MAC-based protection is used. MAC-based protection is used.
Note: The entropy of the shared secret information is crucial for the Note: The entropy of the shared secret information is crucial for the
level of protection available using shard secret information-based level of protection available using shard secret information-based
TLS authentication. A pre-shared key (PSK) mechanism is acceptable TLS authentication. A pre-shared key (PSK) mechanism is acceptable
using shared secret information with an entropy of at least 128 bits. using shared secret information with an entropy of at least 128 bits.
Otherwise a password-authenticated key exchange (PAKE) protocol is Otherwise, a password-authenticated key exchange (PAKE) protocol is
RECOMMENDED. RECOMMENDED.
6.2. CoAP transport 6.2. CoAP transfer
This transport mechanism can be used by a PKI entity to transfer CMP This transfer mechanism can be used by a PKI entity to transfer CMP
messages over CoAP [RFC7252], e.g., in constrained environments. If messages over CoAP [RFC7252], e.g., in constrained environments. If
CoAP transport is used the specifications as described in CMP over CoAP transfer is used the specifications as described in CMP over
CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed.
PKI management operations SHOULD use the following URI paths. When a PKI management operations SHOULD use URI paths consisting of '/.well-
single request message is nested as described in Section 5.2.2.1, the known/cmp/' followed by an operation label depending on the type of
path to use is the same as for the underlying request message. For PKI management operation.
MAC-based protection the path of the respective message body SHALL be
used, e.g., use /ir for ir messages.
+==============================================+=======+=========+ +=======================================+================+=========+
| PKI management operation | Path | Details | | PKI management operation | operationLabel | Details |
+==============================================+=======+=========+ +=======================================+================+=========+
| Enroll client to new PKI | /ir | Section | | Enroll client to new PKI | /ir | Section |
| | | 4.1.1 | | | | 4.1.1 |
+----------------------------------------------+-------+---------+ +---------------------------------------+----------------+---------+
| Enroll client to existing PKI | /cr | Section | | Enroll client to existing PKI | /cr | Section |
| | | 4.1.2 | | | | 4.1.2 |
+----------------------------------------------+-------+---------+ +---------------------------------------+----------------+---------+
| Update client certificate | /kur | Section | | Update client certificate | /kur | Section |
| | | 4.1.3 | | | | 4.1.3 |
+----------------------------------------------+-------+---------+ +---------------------------------------+----------------+---------+
| Enroll client using PKCS#10 | /p10 | Section | | Enroll client using PKCS#10 | /p10 | Section |
| | | 4.1.5 | | | | 4.1.4 |
+----------------------------------------------+-------+---------+ +---------------------------------------+----------------+---------+
| Enroll client using central key generation | /ckg | Section | | Revoke client certificate | /rr | Section |
| | | 4.1.6 | | | | 4.2 |
| Note: This path element MAY also be appended | | | +---------------------------------------+----------------+---------+
| to each of the path elements listed above. | | | | Get CA certificates | /crts | Section |
+----------------------------------------------+-------+---------+ | | | 4.3.1 |
| Revoke client certificate | /rr | Section | +---------------------------------------+----------------+---------+
| | | 4.2 | | Get root CA certificate update | /rcu | Section |
+----------------------------------------------+-------+---------+ | | | 4.3.2 |
| Get CA certificates | /crts | Section | +---------------------------------------+----------------+---------+
| | | 4.3.1 | | Get certificate request template | /att | Section |
+----------------------------------------------+-------+---------+ | | | 4.3.3 |
| Get root CA certificate update | /rcu | Section | +---------------------------------------+----------------+---------+
| | | 4.3.2 | | Get CRL updates | /crls | Section |
+----------------------------------------------+-------+---------+ | | | 4.3.4 |
| Get certificate request template | /att | Section | +---------------------------------------+----------------+---------+
| | | 4.3.3 | | Batching messages | /nest | Section |
+----------------------------------------------+-------+---------+ | | | 5.2.2.2 |
| Batching messages | /nest | Section | | Note: This path element is applicable | | |
| | | 5.2.2.2 | | only between PKI management entities. | | |
| Note: This path element is applicable only | | | +---------------------------------------+----------------+---------+
| between PKI management entities. | | |
+----------------------------------------------+-------+---------+
Table 10: CoAP endpoints Table 10: CoAP endpoints
Subsequent certConf and pollReq messages are sent to the URI of the Independently of any variants used (see Section 4.1.5, Section 4.1.6,
first request message of the respective PKI management operation. and Section 4.4) the operation label corresponding to the PKI
management operation SHALL be used.
By sending a request to its preferred enrollment endpoint, the PKI Any certConf or pollReq messages are sent to the same endpoint as
entity will recognize via the CoAP response status code whether a determined by the PKI management operation.
configured URI is supported by the PKI management entity. The CoAP-
inherent discovery mechanisms MAY also be used. When a single request message is nested as described in
Section 5.2.2.1, the label to use is the same as for the underlying
PKI management operation.
By sending a request to its preferred endpoint, the PKI entity will
recognize via the CoAP response status code whether a configured URI
is supported by the PKI management entity. The CoAP-inherent
discovery mechanisms MAY also be used.
In case a PKI management entity receives an unexpected CoAP status In case a PKI management entity receives an unexpected CoAP status
code from upstream, it MUST respond downstream with an error message code from upstream, it MUST respond downstream with an error message
as described in Section 3.6 using a failInfo bit corresponding to the as described in Section 3.6 using a failInfo bit corresponding to the
status code, e.g., systemFailure. status code, e.g., systemFailure.
Like for HTTP transport, to offer a second line of defense or to Like for HTTP transfer , to offer a second line of defense or to
provide hop-by-hop privacy protection, DTLS MAY be utilized as provide hop-by-hop privacy protection, DTLS MAY be utilized as
described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport].
6.3. Piggybacking on other reliable transport 6.3. Piggybacking on other reliable transfer
CMP messages MAY also be transported on some other reliable protocol. CMP messages MAY also be transfer on some other reliable protocol.
Connection and error handling mechanisms similar to those specified Connection, delay, and error handling mechanisms similar to those
for HTTP in Section 6.1 need to be implemented. specified for HTTP in Section 6.1 need to be implemented.
A more detailed specification is out of scope of this document and A more detailed specification is out of scope of this document and
would need to be given for instance in the scope of the transport would need to be given for instance in the scope of the transfer
protocol used. protocol used.
6.4. Offline transport 6.4. Offline transfer
For transporting CMP messages between PKI entities, any mechanism can For transferring 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 transfer 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 SHOULD report an error as specified in cases the PKI entities SHOULD report an error as specified in
Section 3.6 as far as possible. Section 3.6 as far as possible.
6.4.1. File-based transport 6.4.1. File-based transfer
CMP messages MAY be transferred between PKI entities using file-based CMP messages MAY be transferred between PKI entities using file-based
mechanisms, for instance when an offline EE or a PKI management mechanisms, for instance when an offline EE or a PKI management
entity performs delayed enrollment. Each file MUST contain the ASN.1 entity performs delayed delivery. Each file MUST contain the ASN.1
DER encoding of one CMP message only, where the message 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 transfer protocols
Other asynchronous transport protocols, e.g., email or website Other asynchronous transfer 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 RFC 8551 Section 3.1
[RFC8551].
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- MUST be included either in a "content-type" or a "content-
disposition" statement. The file name extension ".PKI" MUST be used. disposition" statement. The file name extension ".pki" MUST be used.
7. IANA Considerations 7. IANA Considerations
8. Security Considerations 8. Security Considerations
For requirements regarding proper random number and key generation The security considerations as laid out in CMP [RFC4210] updated by
please refer to [RFC4086]. CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm
For the case of centrally generated key pairs, the entropy of the Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over
shared secret information SHALL not be less than the security CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply.
strength of the centrally generated key pair; if the shared secret
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.
For the case of a PKI management operation that delivers a new trust
anchor, e.g., a root CA certificate, using caPubs, (a) that is not
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.
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.
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 > For TLS using shared secret information-based authentication, both
PSK and PAKE provide the same amount of protection against a real-
time authentication attack which is directly the amount of entropy in
the shared secret. The difference between a pre-shared key (PSK) and
a password-authenticated key exchange (PAKE) protocols is in the
level of long-term confidentiality of the TLS messages against brute-
force decryption, where a PSK-based cipher suite only provides
security according to the entropy of the shared secret, while a PAKE-
based cipher suite provides full security independent of the entropy
of the shared secret.
9. Acknowledgements 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] [I-D.ietf-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transport for Certificate Sahni, M. and S. Tripathi, "CoAP Transfer for the
Management Protocol", Work in Progress, Internet-Draft, Certificate Management Protocol", Work in Progress,
draft-ietf-ace-cmpv2-coap-transport-02, 25 May 2021, Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-03, 1
<https://datatracker.ietf.org/doc/html/draft-ietf-ace- October 2021, <https://datatracker.ietf.org/doc/html/
cmpv2-coap-transport-02>. draft-ietf-ace-cmpv2-coap-transport-03>.
[I-D.ietf-lamps-cmp-algorithms] [I-D.ietf-lamps-cmp-algorithms]
Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms", Work "Certificate Management Protocol (CMP) Algorithms", Work
in Progress, Internet-Draft, draft-ietf-lamps-cmp- in Progress, Internet-Draft, draft-ietf-lamps-cmp-
algorithms-05, 7 May 2021, algorithms-07, 22 August 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-05>. cmp-algorithms-07>.
[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-10, 4 May 2021, draft-ietf-lamps-cmp-updates-12, 9 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-updates-10>. cmp-updates-12>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005, DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>. <https://www.rfc-editor.org/info/rfc4210>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005, DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>. <https://www.rfc-editor.org/info/rfc4211>.
skipping to change at page 83, line 45 skipping to change at page 86, line 23
[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>.
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax
(CMS) for Algorithm Identifier Protection", RFC 8933,
DOI 10.17487/RFC8933, October 2020,
<https://www.rfc-editor.org/info/rfc8933>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the [RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045, Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021, DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>. <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-anima-brski-async-enroll] [I-D.ietf-anima-brski-async-enroll]
Fries, S., Brockhaus, H., Lear, E., and T. Werner, Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear,
"Support of asynchronous Enrollment in BRSKI (BRSKI-AE)", "Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)",
Work in Progress, Internet-Draft, draft-ietf-anima-brski- Work in Progress, Internet-Draft, draft-ietf-anima-brski-
async-enroll-03, 24 June 2021, async-enroll-04, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima- <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
brski-async-enroll-03>. brski-async-enroll-04>.
[I-D.ietf-anima-brski-prm]
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-00,
25 October 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-00>.
[I-D.ietf-netconf-sztp-csr]
Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-09,
22 October 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-09>.
[IEC.62443-3-3] [IEC.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,
DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,
<https://ieeexplore.ieee.org/document/8423794>. <https://ieeexplore.ieee.org/document/8423794>.
[NIST.CSWP.04162018] [NIST.CSWP.04162018]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Framework for Improving Critical Infrastructure "Framework for Improving Critical Infrastructure
Cybersecurity, Version 1.1", NIST NIST CSWP 04162018, Cybersecurity, Version 1.1", NIST NIST.CSWP.04162018,
DOI 10.6028/NIST.CSWP.04162018, April 2018, DOI 10.6028/NIST.CSWP.04162018, April 2018,
<http://nvlpubs.nist.gov/nistpubs/CSWP/ <http://nvlpubs.nist.gov/nistpubs/CSWP/
NIST.CSWP.04162018.pdf>. NIST.CSWP.04162018.pdf>.
[NIST.SP.800-57p1r5] [NIST.SP.800-57p1r5]
Barker, E B., "Recommendation for key management, part 1 Barker, E B., "Recommendation for key management, part 1
:general", NIST NIST.SP.800-57pt1r5, :general", NIST NIST.SP.800-57pt1r5,
DOI 10.6028/NIST.SP.800-57pt1r5, 2020, DOI 10.6028/NIST.SP.800-57pt1r5, 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>. <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
skipping to change at page 85, line 16 skipping to change at page 88, line 20
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>.
[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>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [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>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
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>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[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
Suppose the server requires that the certTemplate contains Suppose the server requires that the certTemplate contains
* the issuer field with a value to be filled in by the EE, * the issuer field with a value to be filled in by the EE,
skipping to change at page 87, line 24 skipping to change at page 90, line 42
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates { OCTET STRING, encapsulates {
SEQUENCE {} SEQUENCE {}
} }
} }
} }
} }
SEQUENCE { SEQUENCE {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 TBD3) OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 11)
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
} }
} }
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 TBD4) OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)
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 06 -> 07:
* Added references to [draft-ietf-netconf-sztp-csr] in new
Section 1.5 and Section 4.1.4
* Added reference to [I-D.ietf-anima-brski-async-enroll] in new
Section 1.5 and Section 4.1.1
* Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as
the PUSH use case is continued to be discussed in this draft after
the split of BRSKI-AE
* Improved note regarding UNISIG Subset-137 in Section 1.6
* Removed "rootCaCert" in Section 3.1 and updated the structure of
the genm request for root CA certificate updates in Section 4.3.2.
* Simplified handling of sender and recipient nonces in case of
delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2
* Changed the order of Sections 4.1.4 and 4.1.5
* Added reference on RFC 8933 regarding CMS signedAttrs to
Section 4.1.6
* Added Section 4.3.4 on CRL update retrieval
* Generalized delayed enrollment to delayed delivery in Section 4.4
and 5.1.2, updated the state machine in the introduction of
Section 4
* Updated Section 6 regarding delayed message transfer
* Changed file name extension from ".PKI" to ".pki", deleted
operational path for central key generation, and added an
operational path for CRL update retrieval in Sections 6.1 and 6.2
* Shifted many security considerations to CMP Updates
* Replaced the term "transport" by "transfer" where appropriate to
prevent confusion regarding TCP vs. HTTP and CoAP
* Various editorial changes and language corrections
From version 05 -> 06: From version 05 -> 06:
* Changed in Section 2.3 the normative requirement in of adding * Changed in Section 2.3 the normative requirement in of adding
protection to a single message to mandatory and replacing protection to a single message to mandatory and replacing
protection to optional protection to optional
* Added Section 3.4 specifying generic prerequisites to PKI * Added Section 3.4 specifying generic prerequisites to PKI
management operations management operations
* Added Section 3.5 specifying generic message validation * Added Section 3.5 specifying generic message validation
* Added Section 3.6 on generic error reporting. This section * Added Section 3.6 on generic error reporting. This section
replaces the former error handling section from Section 4 and 5. replaces the former error handling section from Section 4 and 5.
skipping to change at page 89, line 23 skipping to change at page 93, 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.5 with regard to conflicts with UNISIG Subset- * Extend Section 1.6 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.4 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.3.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.3.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")
skipping to change at page 91, line 8 skipping to change at page 95, line 8
* Added a table containing endpoints for HTTP transport in * Added a table containing endpoints for HTTP transport in
Section 6.1 to simplify addressing PKI management entities. Section 6.1 to simplify addressing PKI management entities.
* Added some ToDos resulting from discussion with Tomas Gustavsson. * Added some ToDos resulting from discussion with Tomas Gustavsson.
* Minor clarifications and changes in wording. * Minor clarifications and changes in wording.
From version 00 -> 01: From version 00 -> 01:
* Added a section to specify the enrollment with an already trusted * Added a section to specify the enrollment with an already trusted
PKI for further discussion, see Section 4.1.2. PKI for further discussion, see Section 4.1.2.
* Complete specification of requesting a certificate from a legacy * Complete specification of requesting a certificate from a legacy
PKI using a PKCS#10 [RFC2986] request in Section 4.1.5. PKI using a PKCS#10 [RFC2986] request in Section 4.1.4.
* Complete specification of adding central generation of a key pair * Complete specification of adding central generation of a key pair
on behalf of an end entity in Section 4.1.6. on behalf of an end entity in Section 4.1.6.
* Complete specification of handling delayed enrollment due to * Complete specification of handling delayed enrollment due to
asynchronous message delivery in Section 4.1.7. asynchronous message delivery in Section 4.4.
* Complete specification of additional support messages, e.g., to * Complete specification of additional support messages, e.g., to
update a Root CA certificate or to request an RFC 8366 [RFC8366] update a Root CA certificate or to request an RFC 8366 [RFC8366]
voucher, in Section 4.3. voucher, in Section 4.3.
* Minor changes in wording. * Minor changes in wording.
From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft-
brockhaus-lamps-lightweight-cmp-profile-00: brockhaus-lamps-lightweight-cmp-profile-00:
* Change focus from industrial to more multi-purpose use cases and * Change focus from industrial to more multi-purpose use cases and
lightweight CMP profile. lightweight CMP profile.
 End of changes. 184 change blocks. 
826 lines changed or deleted 1000 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/