< draft-ietf-lamps-lightweight-cmp-profile-10.txt   draft-ietf-lamps-lightweight-cmp-profile-11.txt >
LAMPS Working Group H. Brockhaus, Ed. LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft D. von Oheimb Internet-Draft D. von Oheimb
Intended status: Standards Track S. Fries Intended status: Standards Track S. Fries
Expires: 5 August 2022 Siemens Expires: 17 October 2022 Siemens
1 February 2022 15 April 2022
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-10 draft-ietf-lamps-lightweight-cmp-profile-11
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 transfer 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
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 5 August 2022. This Internet-Draft will expire on 17 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised 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 . . . . . . . 5 1.2. Motivation for a Lightweight Profile of CMP . . . . . . . 5
1.3. Special requirements of industrial and IoT scenarios . . 6 1.3. Special Requirements of Industrial and IoT Scenarios . . 6
1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 1.4. Existing CMP Profiles . . . . . . . . . . . . . . . . . . 7
1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 1.5. Use of CMP in SZTP and BRSKI Environments . . . . . . . . 7
1.6. Compatibility with existing CMP profiles . . . . . . . . 8 1.6. Compatibility with Existing CMP Profiles . . . . . . . . 8
1.7. Scope of this document . . . . . . . . . . . . . . . . . 10 1.7. Scope of this Document . . . . . . . . . . . . . . . . . 10
1.8. Structure of this document . . . . . . . . . . . . . . . 10 1.8. Structure of this Document . . . . . . . . . . . . . . . 10
1.9. Convention and Terminology . . . . . . . . . . . . . . . 11 1.9. Convention and Terminology . . . . . . . . . . . . . . . 11
2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12 2. Solution Architecture . . . . . . . . . . . . . . . . . . . . 12
3. Generic aspects of the PKI message . . . . . . . . . . . . . 14 3. Generic Aspects of PKI Messages and PKI Management
3.1. General description of the CMP message header . . . . . . 15 Operations . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. General description of the CMP message protection . . . . 17 3.1. General Description of the CMP Message Header . . . . . . 15
3.3. General description of CMP message extraCerts . . . . . . 17 3.2. General Description of the CMP Message Protection . . . . 17
3.4. Generic PKI management operation prerequisites . . . . . 18 3.3. General Description of CMP Message ExtraCerts . . . . . . 17
3.5. Generic validation of a PKI message . . . . . . . . . . . 19 3.4. Generic PKI Management Operation Prerequisites . . . . . 18
3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21 3.5. Generic Validation of a PKI Message . . . . . . . . . . . 19
3.6.1. Reporting error conditions upstream . . . . . . . . . 21 3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 21
3.6.2. Reporting error conditions downstream . . . . . . . . 22 3.6.1. Reporting Error Conditions Upstream . . . . . . . . . 21
3.6.3. Handling error conditions on nested messages used for 3.6.2. Reporting Error Conditions Downstream . . . . . . . . 22
batching . . . . . . . . . . . . . . . . . . . . . . 22 3.6.3. Handling Error Conditions on Nested Messages Used for
3.6.4. Reporting error conditions . . . . . . . . . . . . . 23 Batching . . . . . . . . . . . . . . . . . . . . . . 22
4. End Entity PKI management operations . . . . . . . . . . . . 24 3.6.4. PKIStatusInfo and Error Messages . . . . . . . . . . 23
4.1. Requesting a new certificate from a PKI . . . . . . . . . 27 4. PKI Management Operations . . . . . . . . . . . . . . . . . . 25
4.1.1. Requesting a certificate from a new PKI with 4.1. Enrolling End Entities . . . . . . . . . . . . . . . . . 27
signature-based protection . . . . . . . . . . . . . 28 4.1.1. Enrolling an End Entity to a New PKI . . . . . . . . 28
4.1.2. Requesting an additional certificate with 4.1.2. Enrolling an End Entity to a Known PKI . . . . . . . 34
signature-based protection . . . . . . . . . . . . . 34 4.1.3. Updating a Valid Certificate . . . . . . . . . . . . 35
4.1.3. Updating an existing certificate with signature 4.1.4. Enrolling an End Entity Using a PKCS#10 Request . . . 36
protection . . . . . . . . . . . . . . . . . . . . . 35 4.1.5. Using MAC-Based Protection for Enrollment . . . . . . 38
4.1.4. Requesting a certificate from a legacy PKI using a 4.1.6. Adding Central Key Pair Generation to Enrollment . . 39
PKCS#10 request . . . . . . . . . . . . . . . . . . . 36 4.1.6.1. Using Key Agreement Key Management Technique . . 45
4.1.5. Requesting a certificate from a PKI with MAC-based 4.1.6.2. Using Key Transport Key Managemen Technique . . . 46
protection . . . . . . . . . . . . . . . . . . . . . 38 4.1.6.3. Using Password-Based Key Management Technique . . 47
4.1.6. Adding central key pair generation to a certificate 4.2. Revoking a Certificate . . . . . . . . . . . . . . . . . 48
request . . . . . . . . . . . . . . . . . . . . . . . 39 4.3. Support Messages . . . . . . . . . . . . . . . . . . . . 50
4.3.1. Get CA Certificates . . . . . . . . . . . . . . . . . 53
4.1.6.1. Using key agreement key management technique . . 45 4.3.2. Get Root CA Certificate Update . . . . . . . . . . . 53
4.1.6.2. Using key transport key management technique . . 46 4.3.3. Get Certificate Request Template . . . . . . . . . . 55
4.1.6.3. Using password-based key management technique . . 47 4.3.4. CRL Update Retrieval . . . . . . . . . . . . . . . . 57
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 4.4. Handling Delayed Delivery . . . . . . . . . . . . . . . . 59
4.3. Support messages . . . . . . . . . . . . . . . . . . . . 50 5. PKI Management Entity Operations . . . . . . . . . . . . . . 64
4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 53 5.1. Responding to Requests . . . . . . . . . . . . . . . . . 64
4.3.2. Get root CA certificate update . . . . . . . . . . . 53 5.1.1. Responding to a Certificate Request . . . . . . . . . 65
4.3.3. Get certificate request template . . . . . . . . . . 55 5.1.2. Responding to a Confirmation Message . . . . . . . . 65
4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 57 5.1.3. Responding to a Revocation Request . . . . . . . . . 66
4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 59 5.1.4. Responding to a Support Message . . . . . . . . . . . 66
5. PKI management entity operations . . . . . . . . . . . . . . 64 5.1.5. Initiating Delayed Delivery . . . . . . . . . . . . . 66
5.1. Responding to requests . . . . . . . . . . . . . . . . . 64 5.2. Forwarding Messages . . . . . . . . . . . . . . . . . . . 67
5.1.1. Responding to a certificate request . . . . . . . . . 65 5.2.1. Not Changing Protection . . . . . . . . . . . . . . . 69
5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 65 5.2.2. Adding Protection and Batching of Messages . . . . . 69
5.1.3. Responding to a confirmation message . . . . . . . . 66 5.2.2.1. Adding Protection to a Request Message . . . . . 70
5.1.4. Responding to a revocation request . . . . . . . . . 66 5.2.2.2. Batching Messages . . . . . . . . . . . . . . . . 71
5.1.5. Responding to a support message . . . . . . . . . . . 67 5.2.3. Replacing Protection . . . . . . . . . . . . . . . . 73
5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 67 5.2.3.1. Not Changing Proof-of-Possession . . . . . . . . 73
5.2.1. Not changing protection . . . . . . . . . . . . . . . 69 5.2.3.2. Using raVerified . . . . . . . . . . . . . . . . 74
5.2.2. Adding protection and batching of messages . . . . . 69 5.3. Acting on Behalf of other PKI Entities . . . . . . . . . 74
5.2.2.1. Adding protection to a request message . . . . . 70 5.3.1. Requesting a Certificate . . . . . . . . . . . . . . 75
5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 71 5.3.2. Revoking a Certificate . . . . . . . . . . . . . . . 75
5.2.3. Replacing protection . . . . . . . . . . . . . . . . 73 6. CMP Message Transfer Mechanisms . . . . . . . . . . . . . . . 76
5.2.3.1. Not changing any included proof-of-possession . . 73 6.1. HTTP Transfer . . . . . . . . . . . . . . . . . . . . . . 77
5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 74 6.2. CoAP Transfer . . . . . . . . . . . . . . . . . . . . . . 79
5.3. Acting on behalf of other PKI entities . . . . . . . . . 74 6.3. Piggybacking on other Reliable Transfer . . . . . . . . . 81
5.3.1. Requesting certificates . . . . . . . . . . . . . . . 75 6.4. Offline Transfer . . . . . . . . . . . . . . . . . . . . 81
5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 75 6.4.1. File-Based Transfer . . . . . . . . . . . . . . . . . 82
6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 76 6.4.2. Other Asynchronous Transfer Protocols . . . . . . . . 82
6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 77 7. Conformance Requirements . . . . . . . . . . . . . . . . . . 82
6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 79 7.1. PKI Management Operations . . . . . . . . . . . . . . . . 82
6.3. Piggybacking on other reliable transfer . . . . . . . . . 81 7.2. Message Transfer . . . . . . . . . . . . . . . . . . . . 85
6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 81
6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 82
6.4.2. Other asynchronous transfer protocols . . . . . . . . 82
7. Conformance requirements . . . . . . . . . . . . . . . . . . 82
7.1. PKI management operations . . . . . . . . . . . . . . . . 82
7.2. Message transfer . . . . . . . . . . . . . . . . . . . . 85
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
9. Security Considerations . . . . . . . . . . . . . . . . . . . 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
11.1. Normative References . . . . . . . . . . . . . . . . . . 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 88
11.2. Informative References . . . . . . . . . . . . . . . . . 88 11.2. Informative References . . . . . . . . . . . . . . . . . 90
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 91 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 92
Appendix B. History of changes . . . . . . . . . . . . . . . . . 93 Appendix B. History of Changes . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
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 need 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
the target certificate management solution depending on the PKI the target certificate management solution depending on the PKI
management operations, their variants, and types of message transfer management operations, their variants, and types of message transfer
needed. needed.
Since conformity to this document can be achieved by implementing Since conformity to this document can be achieved by implementing
only the functionality declared mandatory in Section 7, the profile only the functionality declared mandatory in Section 7, the profile
can still be called lightweight because in particular for end can still be called lightweight because in particular for end
entities the mandatory-to-implement set of features is rather entities the mandatory-to-implement set of features is rather
limited. limited.
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
[RFC6712] in 2012. [RFC6712] in 2012.
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
skipping to change at page 6, line 10 skipping to change at page 6, line 10
Defining a profile for a new target environment takes high effort Defining a profile for a new target environment takes high effort
because the range of available options needs to be well understood because the range of available options needs to be well understood
and the selected options need to be consistent with each other and and the selected options need to be consistent with each other and
suitably cover the intended application scenario. Since most suitably cover the intended application scenario. Since most
industrial PKI management use cases typically have much in common it industrial PKI management use cases typically have much in common it
is worth sharing this effort, which is the aim of this document. is worth sharing this effort, which is the aim of this document.
Other standardization bodies can reference this document and do not Other standardization bodies can reference this document and do not
need to come up with individual profiles from scratch. need to come up with individual profiles from scratch.
1.3. Special requirements of industrial and IoT scenarios 1.3. Special Requirements of Industrial and IoT Scenarios
The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have
been developed particularly for managing certificates of human end been developed particularly for managing certificates of human end
entities. With the evolution of distributed systems and client- entities. With the evolution of distributed systems and client-
server architectures, certificates for machines and applications on server architectures, certificates for machines and applications on
them have become widely used. This trend has strengthened even more them have become widely used. This trend has strengthened even more
in emerging industrial and IoT scenarios. CMP is sufficiently in emerging industrial and IoT scenarios. CMP is sufficiently
flexible to support them well. flexible to support them well.
Today's IT security architectures for industrial solutions typically Today's IT security architectures for industrial solutions typically
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Further challenges in many industrial systems are network Further challenges in many industrial systems are network
segmentation and asynchronous communication, while PKI management segmentation and asynchronous communication, while PKI management
entities like Certification Authorities (CA) typically are not entities like Certification Authorities (CA) typically are not
deployed on-site but in a more protected environment of a data center deployed on-site but in a more protected environment of a data center
or trust center. Certificate management must be able to cope with or trust center. Certificate management must be able to cope with
such network architectures. CMP offers the required flexibility and such network architectures. CMP offers the required flexibility and
functionality, namely self-contained messages, efficient polling, and functionality, namely self-contained messages, efficient polling, and
support for asynchronous message transfer while retaining end-to-end support for asynchronous message transfer while retaining end-to-end
security. security.
1.4. Existing CMP profiles 1.4. Existing CMP Profiles
As already stated, RFC 4210 [RFC4210] contains profiles with As already stated, RFC 4210 [RFC4210] contains profiles with
mandatory and optional PKI management operations in Appendix D and E. mandatory and optional PKI management operations in Appendix D and E.
Those profiles focus on management of human user certificates and Those profiles focus on management of human user certificates and
only partly address the specific needs of certificate management only partly address the specific needs of certificate management
automation for unattended devices or machine-to-machine application automation for unattended devices or machine-to-machine application
scenarios. scenarios.
Both Appendixes D and E focus on EE-to-RA/CA PKI management Both Appendixes D and E focus on EE-to-RA/CA PKI management
operations and do not address further profiling of RA-to-CA operations and do not address further profiling of RA-to-CA
skipping to change at page 7, line 35 skipping to change at page 7, line 35
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. Use of CMP in SZTP and BRSKI environments 1.5. Use of CMP in SZTP and BRSKI Environments
In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other
environments using NETCONF/YANG modules, SZTP-CSR environments using NETCONF/YANG modules, SZTP-CSR
[I-D.ietf-netconf-sztp-csr] offers a YANG module that includes [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes
different types of certificate requests to obtain a public-key different types of certificate requests to obtain a public-key
certificate for a locally generated key pair. One option is using a certificate for a locally generated key pair. One option is using a
CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp- CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp-
csr from module ietf-ztp-csr and offers both proof-of-possession and csr from module ietf-ztp-csr and offers both proof-of-possession and
proof-of-identity. To allow PKI management entities to also comply proof-of-identity. To allow PKI management entities to also comply
with this profile, the p10cr message must be formatted by the EE as 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 described in Section 4.1.4 of this profile, and it may be forwarded
as specified in Section 5.2. as specified in Section 5.2.
In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous
Enrollment [I-D.ietf-anima-brski-async-enroll] describes a Enrollment [I-D.ietf-anima-brski-ae] describes a generalization
generalization regarding the employed enrollment protocols to allow regarding the employed enrollment protocols to allow alternatives to
alternatives to EST [RFC7030]. For the use of CMP, it requires EST [RFC7030]. For the use of CMP, it requires adherence to this
adherence to this profile. profile.
1.6. Compatibility with existing CMP profiles 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 10, line 5 skipping to change at page 10, line 5
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.7. 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 10, line 34 skipping to change at page 10, line 34
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] and [I-D.ietf-lamps-cmp-updates], syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates],
CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] 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.8. 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
skipping to change at page 12, line 20 skipping to change at page 12, line 20
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
the message headers. the message headers.
PKI management entity: A non-EE PKI entity, i.e., RA or CA. PKI management entity: A non-EE PKI entity, i.e., RA or CA.
PKI entity: An EE or PKI management entity. PKI entity: An EE or PKI management entity.
2. Solution architecture 2. Solution Architecture
To facilitate secure automatic certificate enrollment, the device To facilitate secure automatic certificate enrollment, the device
hosting an EE is typically equipped with a manufacturer-issued device hosting an EE is typically equipped with a manufacturer-issued device
certificate. Such a certificate is typically installed during certificate. Such a certificate is typically installed during
production and is meant to identify the device throughout its production and is meant to identify the device throughout its
lifetime. This certificate can be used to protect the initial lifetime. This certificate can be used to protect the initial
enrollment of operational certificates after installation of the EE enrollment of operational certificates after installation of the EE
in its operational environment. In contrast to the manufacturer- in its operational environment. In contrast to the manufacturer-
issued device certificate, operational certificates are issued by the issued device certificate, operational certificates are issued by the
owner or operator of the device to identify the device or one of its owner or operator of the device to identify the device or one of its
skipping to change at page 13, line 21 skipping to change at page 13, line 21
| EE |<---------->| LRA |<-------------->| RA |<---------->| CA | | EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
| | | | | | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
synchronous (a)synchronous (a)synchronous synchronous (a)synchronous (a)synchronous
+----connection----+------connection------+----connection----+ +----connection----+------connection------+----connection----+
operators service partner operators service partner
+---------on site--------+----back-end services-----+-trust center-+ +---------on site--------+----back-end services-----+-trust center-+
Figure 1: Certificate management architecture example Figure 1: Certificate Management Architecture Example
In operational environments the certificate management architecture In operational environments the certificate management architecture
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.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
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.
3. Generic aspects of the PKI message 3. Generic Aspects of PKI Messages and PKI Management Operations
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 14, line 31 skipping to change at page 14, line 31
| | body | | | | body | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | protection (OPTIONAL) | | | | protection (OPTIONAL) | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | extraCerts (OPTIONAL) | | | | extraCerts (OPTIONAL) | |
| +----------------------------------------+ | | +----------------------------------------+ |
+--------------------------------------------+ +--------------------------------------------+
Figure 2: CMP message structure Figure 2: CMP Message Structure
The general contents of the message header, protection, and The general contents of the message header, protection, and
extraCerts fields are specified in the following three subsections. extraCerts fields are specified in the following three subsections.
In case a specific PKI management operation needs different contents In case a specific PKI management operation needs different contents
in the header, protection, or extraCerts fields, the differences are in the header, protection, or extraCerts fields, the differences are
described in the respective subsections. described in the respective subsections.
The CMP message body contains the PKI management operation-specific The CMP message body contains the PKI management operation-specific
information. It is described in Section 4 and Section 5. information. It is described in Section 4 and Section 5.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
The generic prerequisites needed by the PKI entities in order to be The generic prerequisites needed by the PKI entities in order to be
able to perform PKI management operations are described in able to perform PKI management operations are described in
Section 3.4. Section 3.4.
The generic validation steps to be performed by PKI entities on The generic validation steps to be performed by PKI entities on
receiving a CMP message are described in Section 3.5. receiving a CMP message are described in Section 3.5.
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.5. 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.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
-- ImplicitConfirmValue MUST be NULL -- ImplicitConfirmValue MUST be NULL
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
This section describes the generic protection field contents of all This section describes the generic protection field contents of all
CMP messages with signature-based protection. The private key used CMP messages with signature-based protection, which is the default
to sign a CMP message is called "protection key" and the related protection mechanism for all CMP messages described in this profile.
certificate is called "protection certificate". Any included The private key used to sign a CMP message is called "protection key"
keyUsage extension SHOULD allow digitalSignature. and the related certificate is called "protection certificate". Any
included keyUsage extension SHOULD allow digitalSignature.
protection RECOMMENDED protection
-- RECOMMENDED for error messages
-- REQUIRED for all other messages
-- 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 messages MUST be protected, but there are cases where
there are cases where protection of error messages specified in protection of error messages specified in Section 3.6.4 is not
Section 3.6 is not possible and therefore MAY be omitted. possible and therefore MAY be omitted.
For MAC-based protection as specified in Section 4.1.5 major For MAC-based protection as specified in Section 4.1.5 and
differences apply as described there. Section 4.1.6.3 major 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 Section 2.2 Note: The extended key usages described in CMP Updates Section 2.2
[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.
3.3. General description of CMP message extraCerts 3.3. General Description of CMP Message ExtraCerts
This section describes the generic extraCerts field of all CMP This section describes the generic extraCerts field of all CMP
messages with signature-based protection. Any specific requirements messages with signature-based protection. Any specific requirements
on the extraCerts are specified in the respective PKI management on the extraCerts are specified in the respective PKI management
operation. operation.
extraCerts extraCerts
-- SHOULD contain the CMP protection certificate together with -- SHOULD contain the CMP protection certificate together with
-- its chain, if needed -- its chain, if needed
-- If present, the first certificate in this field MUST be -- If present, the first certificate in this field MUST be
skipping to change at page 18, line 9 skipping to change at page 18, line 9
-- where each element SHOULD directly certify the one -- where each element SHOULD directly certify the one
-- immediately preceding it. -- immediately preceding it.
-- Self-signed certificates SHOULD be omitted from extraCerts, -- Self-signed certificates SHOULD be omitted from extraCerts,
-- unless they are the same as the protection certificate and -- unless they are the same as the protection certificate and
-- MUST NOT be trusted based on their inclusion in any case -- MUST NOT be trusted based on their inclusion in any case
Note: For maximum compatibility, all implementations SHOULD be Note: For maximum compatibility, all implementations SHOULD be
prepared to handle potentially additional certificates and arbitrary prepared to handle potentially additional certificates and arbitrary
orderings of the certificates. orderings of the certificates.
3.4. Generic PKI management operation prerequisites 3.4. Generic PKI Management Operation Prerequisites
This subsection describes what is generally needed by the PKI This subsection describes what is generally needed by the PKI
entities to be able to perform PKI management operations. entities to be able to perform PKI management operations.
Identification of PKI entities: Identification of PKI entities:
* Each EE SHOULD know its own identity to fill the sender field. * Each EE SHOULD know its own identity to fill the sender field.
* 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.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
for authenticating PKI management entities. for authenticating PKI management entities.
* Each PKI management entity MUST have sufficient information to be * Each PKI management entity MUST have sufficient information to be
able to authorize the downstream PKI entity requesting the PKI able to authorize the downstream PKI entity requesting the PKI
management operation. management operation.
Note: For authorizing an RA the same examples apply as above. The Note: For authorizing an RA the same examples apply as above. The
authorization of EEs can be very specific to the application authorization of EEs can be very specific to the application
domain based on local PKI policy. domain based on local PKI policy.
3.5. Generic validation of a PKI message 3.5. Generic Validation of a PKI Message
This section describes generic validation steps of each PKI entity This section describes generic validation steps of each PKI entity
receiving a PKI request or response message before any further receiving a PKI request or response message before any further
processing or forwarding. If a PKI management entity decides to processing or forwarding. If a PKI management entity decides to
terminate a PKI management operation because a check failed, it MUST terminate a PKI management operation because a check failed, it MUST
send a negative response or an error message as described in send a negative response or an error message as described in
Section 3.6. The PKIFailureInfo bits given below in parentheses MAY Section 3.6. The PKIFailureInfo bits given below in parentheses MAY
be used in the failInfo field of the PKIStatusInfo as described in be used in the failInfo field of the PKIStatusInfo as described in
Section 3.6.4, see also RFC 4210 Appendix F [RFC4210]. Section 3.6.4, see also RFC 4210 Appendix F [RFC4210].
skipping to change at page 20, line 26 skipping to change at page 20, line 26
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 or equal the senderNonce of the most of the previous message or equal the senderNonce of the most
recent request message for which the response was delayed, in recent request message for which the response was delayed, in
case of delayed delivery as specified in Section 4.4. (failInfo case of delayed delivery as specified in Section 4.4. (failInfo
bit: badRecipientNonce) 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
protection is used as described in Section 4.1.5 and for some
error messages as described in Section 3.6.4. (failInfo bit: o MAC-based protection is used as described in Section 4.1.5
wrongIntegrity) and Section 4.1.6.3 or
o protection is omitted in certain error messages as described
in Section 3.6.4.
(failInfo bit: 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
validation using a trust anchor and MUST be authorized validation using a trust anchor and MUST be authorized
according to local policies. If the keyUsage extension is according to local policies. If the keyUsage extension is
skipping to change at page 21, line 18 skipping to change at page 21, line 22
Depending on local policies, one or more of the input validation Depending on local policies, one or more of the input validation
checks described below need to be implemented: checks described below need to be implemented:
* If signature-based protection is used, the sender field SHOULD * If signature-based protection is used, the sender field SHOULD
match the subject of the CMP protection certificate. (failInfo match the subject of the CMP protection certificate. (failInfo
bit: badMessageCheck) bit: badMessageCheck)
* If the messageTime is present, it SHOULD be close to the current * If the messageTime is present, it SHOULD be close to the current
time. (failInfo bit: badTime) time. (failInfo bit: badTime)
3.6. Error handling 3.6. Error Handling
This section describes how a PKI entity handles error conditions on This section describes how a PKI entity handles error conditions on
messages it receives. Each error condition SHOULD be logged messages it receives. Each error condition SHOULD be logged
appropriately. appropriately.
3.6.1. Reporting error conditions upstream 3.6.1. Reporting Error Conditions Upstream
An EE SHALL NOT send error messages. PKI management entities SHALL An EE SHALL NOT send error messages. PKI management entities SHALL
NOT send error messages in upstream direction, either. NOT send error messages in upstream direction, either.
In case an EE rejects a newly issued certificate contained in an ip, In case an EE rejects a newly issued certificate contained in an ip,
cp, or kup message and implicit confirmation has not been granted, cp, or kup message and implicit confirmation has not been granted,
the EE MUST report this using a certConf message with "rejection" the EE MUST report this using a certConf message with "rejection"
status and await the pkiConf response as described in Section 4.1.1. status and await the pkiConf response as described in Section 4.1.1.
On all other error conditions regarding response messages, the EE or On all other error conditions regarding response messages, the EE or
skipping to change at page 22, line 12 skipping to change at page 22, line 12
* rejection of a newly issued certificate while implicit * rejection of a newly issued certificate while implicit
confirmation has been granted. confirmation has been granted.
Upstream PKI management entities will not receive any CMP message to Upstream PKI management entities will not receive any CMP message to
learn that the PKI management operation has been terminated. In case learn that the PKI management operation has been terminated. In case
they expect a further message from the EE, a connection interruption they expect a further message from the EE, a connection interruption
or timeout will occur. Then they also MUST regard the current PKI or timeout will occur. Then they also MUST regard the current PKI
management operation as terminated with failure and MUST NOT attempt management operation as terminated with failure and MUST NOT attempt
to send an error message downstream. to send an error message downstream.
3.6.2. Reporting error conditions downstream 3.6.2. Reporting Error Conditions Downstream
In case the PKI management entity detects an error condition, e.g., In case the PKI management entity detects an error condition, e.g.,
rejecting the request due to policy decision, in the body of an ir, rejecting the request due to policy decision, in the body of an ir,
cr, p10cr, kur, or rr message received from downstream, it SHOULD cr, p10cr, kur, or rr message received from downstream, it SHOULD
report the error in the specific response message, i.e., an ip, cp, report the error in the specific response message, i.e., an ip, cp,
kup, or rp with "rejection" status, as described in Section 4.1.1 and kup, or rp with "rejection" status, as described in Section 4.1.1 and
Section 4.2. This can also happen in case of polling. Section 4.2. This can also happen in case of polling.
In case the PKI management entity detects any other error condition In case the PKI management entity detects any other error condition
on requests, including pollReq, certConf, genm, and nested messages, on requests, including pollReq, certConf, genm, and nested messages,
received from downstream and on responses received from upstream, received from downstream and on responses received from upstream,
such as invalid message header, body type, protection, or extraCerts such as invalid message header, body type, protection, or extraCerts
according to the checks described in Section 3.5 it MUST report them according to the checks described in Section 3.5 it MUST report them
downstream in the form of an error message as described in downstream in the form of an error message as described in
Section 3.6.4. Section 3.6.4.
3.6.3. Handling error conditions on nested messages used for batching 3.6.3. Handling Error Conditions on Nested Messages Used for Batching
Batching of messages using nested messages as described in Batching of messages using nested messages as described in
Section 5.2.2.2 requires special error handling. Section 5.2.2.2 requires special error handling.
If the error condition is on an upstream nested message containing If the error condition is on an upstream nested message containing
batched requests, it MUST NOT attempt to respond to the individual batched requests, it MUST NOT attempt to respond to the individual
requests included in it. requests included in it.
In case a PKI management entity receives an error message in response In case a PKI management entity receives an error message in response
to a nested message, it must propagate the error by responding with to a nested message, it must propagate the error by responding with
an error message to each of the request messages contained in the an error message to each of the request messages contained in the
nested message. nested message.
In case a PKI management entity detects an error condition on the In case a PKI management entity detects an error condition on the
downstream nested message received in response to a nested message downstream nested message received in response to a nested message
sent before, it MAY ignore this error condition and handle the sent before, it MAY ignore this error condition and handle the
response as described in Section 5.2.2.2. Otherwise, it MUST response as described in Section 5.2.2.2. Otherwise, it MUST
propagate the error by responding with an error message to each of propagate the error by responding with an error message to each of
the requests contained in the nested message it sent originally. the requests contained in the nested message it sent originally.
3.6.4. Reporting error conditions 3.6.4. PKIStatusInfo and Error Messages
When sending any kind of negative response, including error messages, When sending any kind of negative response, including error messages,
a PKI entity MUST indicate the error condition in the PKIStatusInfo a PKI entity MUST indicate the error condition in the PKIStatusInfo
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:
skipping to change at page 24, line 17 skipping to change at page 24, line 17
- systemUnavail: This is sent by a PKI management entity in case - systemUnavail: This is sent by a PKI management entity in case
a back-end system is not available. a back-end system is not available.
- systemFailure: This is sent by a PKI management entity in case - systemFailure: This is sent by a PKI management entity in case
a back-end system is currently not functioning correctly. a back-end system is currently not functioning correctly.
An EE receiving a systemUnavail or systemFailure failInfo SHOULD An EE receiving a systemUnavail or systemFailure failInfo SHOULD
resend the request in a new transaction after some time. resend the request in a new transaction after some time.
Detailed error message description: Detailed 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 indicating the error that occurred -- The message indicating the error that 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
protection REQUIRED protection RECOMMENDED
-- As described in Section 3.2 -- As described in Section 3.2
-- MAY be omitted if protection is technically not feasible
extraCerts OPTIONAL extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
4. End Entity PKI management operations Note: Protecting the error message may not be technically feasible if
it is not clear which credential the recipient will be able to use
when validating this protection, e.g., in case the request message
was fundamentally broken.
4. PKI Management Operations
This chapter focuses on the communication of an EE with the PKI This chapter focuses on the communication of an EE with the PKI
management entity it directly talks to. Depending on the network and management entity it directly talks to. Depending on the network and
PKI solution, this can be an RA or directly a CA. Handling of a PKI solution, this can be an RA or directly a CA. Handling of a
message by a PKI management entity is described in Section 5. message by a PKI management entity is described in Section 5.
The PKI management operations specified in this section cover the The PKI management operations specified in this section cover the
following: following:
* Requesting a certificate with variations like initial enrollment, * Requesting a certificate with variations like initial enrollment,
skipping to change at page 26, line 5 skipping to change at page 26, line 5
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, error messages described in Section 3.6.4, as well as responses, error messages described in Section 3.6.4, as well as
ip/cp/kup/error messages with status "waiting", pollReq, and pollRep ip/cp/kup/error messages with status "waiting", pollReq, and pollRep
messages described in Section 4.4. 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: End Entity State Machine:
start start
| |
| send ir/cr/p10cr/kur/rr/genm | send ir/cr/p10cr/kur/rr/genm
v v
waiting for response waiting for response
| |
+--------------------------+--------------------------+ +--------------------------+--------------------------+
| | | | | |
| receives ip/cp/kup with | received ip/cp/kup/error | received | receives ip/cp/kup with | received ip/cp/kup/error | received
| status "accepted" or | with status "waiting" | rp/genp or | status "accepted" or | with status "waiting" | rp/genp or
skipping to change at page 27, line 16 skipping to change at page 27, line 16
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
available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms].
4.1. Requesting a new certificate from a PKI 4.1. Enrolling End Entities
There are various approaches for requesting a certificate from a PKI. There are various approaches for requesting a certificate from a PKI.
These approaches differ in the way the EE authenticates itself to the These approaches differ in the way the EE authenticates itself to the
PKI, in the form of the request being used, and how the key pair to PKI, in the form of the request being used, and how the key pair to
be certified is generated. The authentication mechanisms may be as be certified is generated. The authentication mechanisms may be as
follows: follows:
* Using a certificate from an external PKI, e.g., a manufacturer- * Using a certificate from an external PKI, e.g., a manufacturer-
issued device certificate, and the corresponding private key issued device certificate, and the corresponding private key
skipping to change at page 27, line 42 skipping to change at page 27, line 42
key key
* Using shared secret information known to the EE and the PKI * Using shared secret information known to the EE and the PKI
management entity management entity
An EE requests a certificate indirectly or directly from a CA. When An EE requests a certificate indirectly or directly from a CA. When
the PKI management entity handles the request as described in the PKI management entity handles the request as described in
Section 5.1.1 and responds with a message containing the requested Section 5.1.1 and responds with a message containing the requested
certificate, the EE MUST reply with a confirmation message unless certificate, the EE MUST reply with a confirmation message unless
implicitConfirm was granted. The PKI management entity then MUST implicitConfirm was granted. The PKI management entity then MUST
handle it as described in Section 5.1.3 and respond with a handle it as described in Section 5.1.2 and respond with a
confirmation, closing the PKI management operation. confirmation, closing the PKI management operation.
The message sequences described in this section allow the EE to The message sequences described in this section allow the EE to
request certification of a locally or centrally generated public- request certification of a locally or centrally generated public-
private key pair. Typically, the EE provides a signature-based private key pair. Typically, the EE provides a signature-based
proof-of-possession of the private key associated with the public key proof-of-possession of the private key associated with the public key
contained in the certificate request as defined by RFC 4211 contained in the certificate request as defined by RFC 4211
Section 4.1 [RFC4211] case 3. To this end it is assumed that the Section 4.1 [RFC4211] case 3. To this end it is assumed that the
private key can technically be used for signing. This is the case private key can technically be used for signing. This is the case
for the most common algorithms RSA and ECDSA, regardless of for the most common algorithms RSA and ECDSA, regardless of
skipping to change at page 28, line 43 skipping to change at page 28, line 43
installation as a new trust anchor, it MUST properly authenticate the installation as a new trust anchor, it MUST properly authenticate the
message and authorize the sender as trusted source of the new trust message and authorize the sender as trusted source of the new trust
anchor. This authorization is typically indicated using shared anchor. This authorization is typically indicated using shared
secret information for protecting an initialization response (ir) secret information for protecting an initialization response (ir)
message. Authorization can also be signature-based using a message. Authorization can also be signature-based using a
certificate issued by another PKI that is explicitly authorized for certificate issued by another PKI that is explicitly authorized for
this purpose. A certificate received in caPubs MUST NOT be accepted this purpose. A certificate received in caPubs MUST NOT be accepted
as a trust anchor if it is the root CA certificate of the certificate as a trust anchor if it is the root CA certificate of the certificate
used for protecting the message. used for protecting the message.
4.1.1. Requesting a certificate from a new PKI with signature-based 4.1.1. Enrolling an End Entity to a New PKI
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) Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI)
[RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE) [RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE)
[I-D.ietf-anima-brski-async-enroll] describes a generalization [I-D.ietf-anima-brski-ae] describes a generalization regarding
regarding enrollment protocols alternative to EST [RFC7030]. As enrollment protocols alternative to EST [RFC7030]. As replacement of
replacement of EST simpleenroll, BRSKI-AE uses this PKI management EST simpleenroll, BRSKI-AE uses this PKI management operation for
operation for bootstrapping LDevID certificates. 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.
Message flow: Message Flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format ir 1 format ir
2 -> ir -> 2 -> ir ->
3 handle or 3 handle or
forward ir forward ir
4 format or receive ip 4 format or receive ip
5 possibly grant 5 possibly grant
implicitConfirm implicitConfirm
6 <- ip <- 6 <- ip <-
skipping to change at page 30, line 39 skipping to change at page 30, line 36
In this case it is advisable not to do the publication until a In this case it is advisable not to do the publication until a
positive certificate confirmation has been received. This way the positive certificate confirmation has been received. This way the
need to revoke the certificate on negative confirmation is avoided. need to revoke the certificate on negative confirmation is avoided.
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
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE for a new certificate -- The request of the EE for a new certificate
skipping to change at page 34, line 38 skipping to change at page 34, line 34
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first response -- MUST use the same credentials as in the first response
-- message of this PKI management operation -- message 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 the EE has -- MAY be omitted if the message size is critical and the EE has
-- cached the extraCerts from the first response message of -- cached the extraCerts from the first response message of
-- this PKI management operation -- this PKI management operation
4.1.2. Requesting an additional certificate with signature-based 4.1.2. Enrolling an End Entity to a Known PKI
protection
This PKI management operation should be used by an EE to request an This PKI management operation should be used by an EE to request an
additional certificate of the same PKI it already has certificates additional certificate of the same PKI it already has certificates
from. The EE uses one of these existing certificates to authenticate from. The EE uses one of these existing certificates to authenticate
itself by signing its request messages using the respective private itself by signing its request messages using the respective private
key. key.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The certificate used by the EE MUST have been enrolled by the PKI * The certificate used by the EE MUST have been enrolled by the PKI
skipping to change at page 35, line 21 skipping to change at page 35, line 18
1 The body of the first request and response SHOULD be cr and cp, 1 The body of the first request and response SHOULD be cr and cp,
respectively. respectively.
Note: Since the difference between ir/ip and cr/cp is Note: Since the difference between ir/ip and cr/cp is
syntactically not essential, an ir/ip MAY be used in this PKI syntactically not essential, an ir/ip MAY be used in this PKI
management operation. management operation.
2 The caPubs field in the certificate response message SHOULD be 2 The caPubs field in the certificate response message SHOULD be
absent. absent.
4.1.3. Updating an existing certificate with signature protection 4.1.3. Updating a Valid Certificate
This PKI management operation should be used by an EE to request an This PKI management operation should be used by an EE to request an
update for one of its certificates that is still valid. The EE uses update for one of its certificates that is still valid. The EE uses
the certificate it wishes to update as the protection certificate. the certificate it wishes to update as the protection certificate.
Both for authenticating itself and for proving ownership of the Both for authenticating itself and for proving ownership of the
certificate to be updated, it signs the request messages with the certificate to be updated, it signs the request messages with the
corresponding private key. corresponding private key.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
skipping to change at page 36, line 25 skipping to change at page 36, line 22
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 legacy PKI using a PKCS#10 4.1.4. Enrolling an End Entity 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.2. specified in Section 4.1.2.
In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments,
SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr 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 message as a form of certificate signing request (CSR) to optionally
include in device bootstrapping to obtain an identity certificate as include in device bootstrapping to obtain an identity certificate as
skipping to change at page 37, line 9 skipping to change at page 37, line 5
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.2, with the following changes: to that given in Section 4.1.2, with the following changes:
1 The body of the first request and response MUST be p10cr and cp, 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 -1. 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 Message Description:
Certification Request -- p10cr Certification Request -- p10cr
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE for a new certificate using a PKCS#10 -- The request of the EE for a new certificate using a PKCS#10
skipping to change at page 37, line 48 skipping to change at page 37, line 44
-- key usage, and extended key usage -- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE -- The subjectAltName extension MUST be present if the EE
-- subject name includes a subject alternative name. -- subject name includes a subject alternative name.
signatureAlgorithm REQUIRED signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPKInfo field. -- subjectPKInfo field.
signature REQUIRED signature REQUIRED
-- MUST 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 in Section 3.2
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 4.1.5. Using MAC-Based Protection for Enrollment
This is a variant of the PKI management operations described in 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 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 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 certificate to prove its identity to the target PKI, but has some
secret information shared with the PKI management entity. Therefore, secret information shared with the PKI management entity. Therefore,
the request and response messages are MAC-protected using this shared the request and response messages are MAC-protected using this shared
secret information. The distribution of this shared secret is out of secret information. The distribution of this shared secret is out of
scope for this document. The PKI management entity checking the MAC- scope for this document. The PKI management entity checking the MAC-
based protection SHOULD replace this protection according to based protection SHOULD replace this protection according to
skipping to change at page 39, line 12 skipping to change at page 39, line 12
3 The extraCerts of all messages does not contain CMP protection 3 The extraCerts of all messages does not contain CMP protection
certs and associated chains. certs and associated chains.
See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for
details on message authentication code algorithms (MSG_MAC_ALG) to details on message authentication code algorithms (MSG_MAC_ALG) to
use. Typically, parameters are part of the protectionAlg field, use. Typically, parameters are part of the protectionAlg field,
e.g., used for key derivation, like a salt and an iteration count. e.g., used for key derivation, like a salt and an iteration count.
Such fields SHOULD remain constant for message protection throughout Such fields SHOULD remain constant for message protection throughout
this PKI management operation to reduce the computational overhead. this PKI management operation to reduce the computational overhead.
4.1.6. Adding central key pair generation to a certificate request 4.1.6. Adding Central Key Pair Generation to Enrollment
This is a variant of the PKI management operations described in This is a variant of the PKI management operations described in
Section 4.1.1 to Section 4.1.4 and the variant described in Section 4.1.1 to Section 4.1.4 and the variant described in
Section 4.1.5. It needs to be used in case an EE is not able to Section 4.1.5. It needs to be used in case an EE is not able to
generate its new public-private key pair itself or central generation generate its new public-private key pair itself or central generation
of the EE key material is preferred. It is a matter of the local of the EE key material is preferred. It is a matter of the local
implementation which PKI management entity will act as Key Generation implementation which PKI management entity will act as Key Generation
Authority (KGA) and perform the key generation. This PKI management Authority (KGA) and perform the key generation. This PKI management
entity MUST use a certificate containing the additional extended key entity MUST use a certificate containing the additional extended key
usage extension id-kp-cmKGA in order to be accepted by the EE as a usage extension id-kp-cmKGA in order to be accepted by the EE as a
skipping to change at page 40, line 50 skipping to change at page 40, line 50
| | | AsymmetricKeyPackage | | | | | | AsymmetricKeyPackage | | |
| | | [RFC5958] | | | | | | [RFC5958] | | |
| | | +----------------------+ | | | | | | +----------------------+ | | |
| | | | privateKey | | | | | | | | privateKey | | | |
| | | | OCTET STRING | | | | | | | | OCTET STRING | | | |
| | | +----------------------+ | | | | | | +----------------------+ | | |
| | +--------------------------+ | | | | +--------------------------+ | |
| +------------------------------+ | | +------------------------------+ |
+----------------------------------+ +----------------------------------+
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] and [RFC8933], structure, as specified in CMS Section 5 [RFC5652] and [RFC8933],
skipping to change at page 42, line 51 skipping to change at page 42, line 51
the SignedData structure containing the private key package. the SignedData structure containing the private key package.
* For encrypting the SignedData structure a fresh content-encryption * For encrypting the SignedData structure a fresh content-encryption
key to be used by the symmetric encryption algorithm MUST be key to be used by the symmetric encryption algorithm MUST be
generated with sufficient entropy. generated with sufficient entropy.
Note: The security strength of the protection of the generated Note: The security strength of the protection of the generated
private key should be similar or higher than the security strength private key should be similar or higher than the security strength
of the generated private key. of the generated private key.
The detailed description of the privateKey field as follows: Detailed Description of privateKey Field:
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be an EnvelopedData structure as specified in CMS -- MUST be an EnvelopedData structure as specified in CMS
-- Section 6 [RFC5652] -- Section 6 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
-- KeyTransRecipientInfo -- KeyTransRecipientInfo
-- MUST be 0 for recipientInfo type PasswordRecipientInfo -- MUST be 0 for recipientInfo type PasswordRecipientInfo
recipientInfos REQUIRED recipientInfos REQUIRED
-- MUST contain exactly one RecipientInfo, which MUST be -- MUST contain exactly one RecipientInfo, which MUST be
skipping to change at page 45, line 5 skipping to change at page 45, line 5
-- 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
NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that
are defined in RFC 5652 [RFC5652] but are not explicitly specified are defined in RFC 5652 [RFC5652] but are not explicitly specified
here SHOULD NOT be used. here SHOULD NOT be used.
4.1.6.1. Using key agreement key management technique 4.1.6.1. Using Key Agreement Key Management Technique
This 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 "keyAgreement" and therefore, the related key pair for the key usage "keyAgreement" and therefore, the related key pair
MUST be used for establishment of the content-encryption key. For MUST be used for establishment of the content-encryption key. For
this key management technique the KeyAgreeRecipientInfo structure this key management technique the KeyAgreeRecipientInfo structure
MUST be used in the contentInfo field. MUST be used in the contentInfo field.
The KeyAgreeRecipientInfo structure included into the EnvelopedData The KeyAgreeRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.2 [RFC5652]. structure is specified in CMS Section 6.2.2 [RFC5652].
The detailed description of the KeyAgreeRecipientInfo structure looks Detailed Description of KeyAgreeRecipientInfo Structure:
like this:
kari REQUIRED kari REQUIRED
-- MUST be a KeyAgreeRecipientInfo as specified in CMS Section -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section
-- 6.2.2 [RFC5652] -- 6.2.2 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
originator REQUIRED originator REQUIRED
-- MUST contain the subjectKeyIdentifier of the certificate, -- MUST contain the subjectKeyIdentifier of the certificate,
-- and thereby identifies the sender's public key. -- and thereby identifies the sender's public key.
-- MUST contain the same value as the senderKID in the -- MUST contain the same value as the senderKID in the
skipping to change at page 46, line 43 skipping to change at page 46, line 43
-- MUST contain the rKeyId choice -- MUST contain the rKeyId choice
rKeyId REQUIRED rKeyId REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST contain the same value as the senderKID in the -- MUST contain the same value as the senderKID in the
-- respective request message header -- respective request message header
encryptedKey encryptedKey
REQUIRED REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
4.1.6.2. Using key transport key management technique 4.1.6.2. Using Key Transport Key Managemen 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 Detailed Description of KeyTransRecipientInfo Structure:
like this:
ktri REQUIRED ktri REQUIRED
-- MUST be a KeyTransRecipientInfo as specified in CMS -- MUST be a KeyTransRecipientInfo as specified in CMS
-- Section 6.2.1 [RFC5652] -- Section 6.2.1 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 2 -- MUST be 2
rid REQUIRED rid REQUIRED
-- MUST contain the subjectKeyIdentifier choice -- MUST contain the subjectKeyIdentifier choice
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
skipping to change at page 47, line 32 skipping to change at page 47, line 31
-- respective request message header -- respective request message header
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- 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.5 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 9. available in Section 9.
The PasswordRecipientInfo structure included into the EnvelopedData The PasswordRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.4 [RFC5652]. structure is specified in CMS Section 6.2.4 [RFC5652].
The detailed description of the PasswordRecipientInfo structure looks Detailed Description of PasswordRecipientInfo Structure:
like this:
pwri REQUIRED pwri REQUIRED
-- MUST be a PasswordRecipientInfo as specified in CMS -- MUST be a PasswordRecipientInfo as specified in CMS
-- Section 6.2.4 [RFC5652] -- Section 6.2.4 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 0 -- MUST be 0
keyDerivationAlgorithm keyDerivationAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key derivation -- MUST be the algorithm identifier of the key derivation
-- algorithm -- algorithm
-- 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.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. This requires, that the EE still possesses the private certificate. This requires, that the EE still possesses the private
key. If this is not the case the revocation has to be initiated by 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 other means, e.g., revocation by the RA as specified in
Section 5.3.2. 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.3 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.
Message flow: Message Flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format rr 1 format rr
2 -> rr -> 2 -> rr ->
3 handle or forward rr 3 handle or forward rr
4 format or receive rp 4 format or receive rp
5 <- rp <- 5 <- rp <-
6 handle rp 6 handle rp
For this PKI management operation, the EE MUST include exactly one For this PKI management operation, the EE MUST include exactly one
RevDetails structure in the rr message body. In case no generic RevDetails structure in the rr message body. In case no generic
error occurred the response to the rr MUST be an rp message error occurred the response to the rr MUST be an rp message
containing a single status field. containing a single status field.
Detailed message description: Detailed Message Description:
Revocation Request -- rr Revocation Request -- rr
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The request of the EE to revoke its certificate -- The request of the EE to revoke its certificate
skipping to change at page 50, line 34 skipping to change at page 50, line 34
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if the status is "accepted" -- MUST be absent if 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 delivery of The following support messages offer on demand in-band delivery of
content relevant to the EE provided by a PKI management entity. CMP content relevant to the EE provided by a PKI management entity. CMP
general messages and general response are used for this purpose. general messages and general response are used for this purpose.
Depending on the environment, these requests may be answered by an RA Depending on the environment, these requests may be answered by an RA
or CA (see also Section 5.1.5). or CA (see also Section 5.1.4).
The general messages and general response messages contain 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 * 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
5 <- genp <- 5 <- genp <-
6 handle genp 6 handle genp
Detailed message description: Detailed Message Description:
General Message -- genm General Message -- genm
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- A request by the EE for information -- A request by the EE for information
skipping to change at page 53, line 5 skipping to change at page 53, line 5
-- operation described below -- operation described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation -- MUST be as specified for the specific PKI management operation
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
certificates from the PKI management entity. certificates from the PKI management entity.
An EE requests CA certificates, e.g., for chain construction, from an An EE requests CA certificates, e.g., for chain construction, from an
PKI management entity by sending a general message with OID id-it- PKI management entity by sending a general message with OID id-it-
caCerts as specified in CMP Updates Section 2.13 caCerts as specified in CMP Updates Section 2.13
[I-D.ietf-lamps-cmp-updates]. The PKI management entity responds [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds
with a general response with the same OID that either contains a with a general response with the same OID that either contains a
SEQUENCE of certificates populated with the available intermediate SEQUENCE of certificates populated with the available intermediate
skipping to change at page 53, line 32 skipping to change at page 53, line 32
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-caCerts 1 the infoType OID to use is id-it-caCerts
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST contain a sequence 3 if present, the infoValue of the response MUST contain a sequence
of certificates of certificates
The infoValue field of the general response containing the id-it- Detailed Description of infoValue Field of genp:
caCerts OID looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CA certificate is available -- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available -- MUST be present if CA certificates are available
-- MUST be a sequence of CMPCertificate -- MUST be a sequence of CMPCertificate
4.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 an update of a root CA certificate from the PKI An EE requests an update of a root CA certificate from the PKI
management entity by sending a general message with OID id-it- management entity by sending a general message with OID id-it-
rootCaCert, which SHOULD include the old root CA certificate in the rootCaCert, which SHOULD include the old root CA certificate in the
message body, as specified in CMP Updates Section 2.14 message body, as specified in CMP Updates Section 2.14
[I-D.ietf-lamps-cmp-updates]. The PKI management entity responds [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds
skipping to change at page 54, line 42 skipping to change at page 54, line 42
1 the infoType OID to use is id-it-rootCaCert in the request and id- 1 the infoType OID to use is id-it-rootCaCert in the request and id-
it-rootCaKeyUpdate in the response it-rootCaKeyUpdate in the response
2 the infoValue of the request SHOULD contain the root CA 2 the infoValue of the request SHOULD contain the root CA
certificate the update is requested for certificate the update is requested for
3 if present, the infoValue of the response MUST be a 3 if present, the infoValue of the response MUST be a
RootCaKeyUpdateContent structure RootCaKeyUpdateContent structure
The infoValue field of the general request containing the id-it- Detailed Description of infoValue Field of genm:
rootCaCert OID looks like this:
infoValue RECOMMENDED infoValue RECOMMENDED
-- MUST contain the root CA certificate to be updated, if -- MUST contain the root CA certificate to be updated, if
-- available -- available
The infoValue field of the general response containing the id-it- Detailed Description of infoValue Field of genp:
rootCaKeyUpdate 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 RootCaKeyUpdateContent -- is available and MUST be of type RootCaKeyUpdateContent
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 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 Section 2.15 [I-D.ietf-lamps-cmp-updates]. specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates].
The EE MAY indicate the certificate profile to use in the id-it- The EE MAY indicate the certificate profile to use in the id-it-
certProfile extension of the generalInfo field in the PKIHeader of certProfile extension of the generalInfo field in the PKIHeader of
the general message as described in Section 3.1. The PKI management the general message as described in Section 3.1. The PKI management
skipping to change at page 57, line 23 skipping to change at page 57, line 23
2 the id-it-certProfile generalInfo field in the header of the 2 the id-it-certProfile generalInfo field in the header of the
request MAY contain the name of the requested certificate request request MAY contain the name of the requested certificate request
template 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- Detailed Description of infoValue Field of genp:
certReqTemplate OID looks like this:
InfoValue OPTIONAL InfoValue OPTIONAL
-- MUST be absent if no requirements are available -- MUST be absent if no requirements are available
-- MUST be present if the PKI management entity has any -- MUST be present if the PKI management entity has any
-- requirements on the contents of the certificate template -- requirements on the contents of the certificate template
certTemplate REQUIRED certTemplate REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the required CertTemplate structure elements -- MUST contain the required CertTemplate structure elements
-- 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 4.3.4. CRL Update Retrieval
This PKI management operation can be used by an EE to request a new This PKI management operation can be used by an EE to request a new
CRL. If a CA offers methods to access a CRL, it may include CRL CRL. If a CA offers methods to access a CRL, it may include CRL
distribution points or authority information access extensions as distribution points or authority information access extensions as
specified in RFC 5280 [RFC5280] into the issued certificates. In specified in RFC 5280 [RFC5280] into the issued certificates. In
addition, CMP offers CRL provisioning functionality as part of the addition, CMP offers CRL provisioning functionality as part of the
PKI management operation. PKI management operation.
An EE requests a CRL update from the PKI management entity by sending An EE requests a CRL update from the PKI management entity by sending
a general message with OID id-it-crlStatusList. The EE MUST include a general message with OID id-it-crlStatusList. The EE MUST include
skipping to change at page 58, line 48 skipping to change at page 58, line 48
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-crlStatusList in the request and 1 the infoType OID to use is id-it-crlStatusList in the request and
id-it-crls in the response id-it-crls in the response
2 the infoValue of the request MUST be present and contain a 2 the infoValue of the request MUST be present and contain a
CRLStatus structure CRLStatus structure
3 if present, the infoValue of the response MUST contain a CRL 3 if present, the infoValue of the response MUST contain a CRL
The infoValue field of the general request containing the id-it- Detailed Description of infoValue Field of genm:
crlStatusList OID looks like this:
CRLSource REQUIRED CRLSource REQUIRED
-- MUST contain exactly one CRLSource structure -- MUST contain exactly one CRLSource structure
-- MUST contain the dpn choice of type DistributionPointName if -- MUST contain the dpn choice of type DistributionPointName if
-- the CRL distribution point name is available -- the CRL distribution point name is available
-- Otherwise, MUST contain the issuer choice identifying the CA -- Otherwise, MUST contain the issuer choice identifying the CA
-- that issues the CRL. It MUST contain the issuer DN in the -- that issues the CRL. It MUST contain the issuer DN in the
-- directoryName field of a GeneralName element. -- directoryName field of a GeneralName element.
thisUpdate OPTIONAL thisUpdate OPTIONAL
-- SHOULD contain the thisUpdate field of the latest CRL form -- SHOULD contain the thisUpdate field of the latest CRL form
-- the issuer specified in the given dpn or issuer field, -- the issuer specified in the given dpn or issuer field,
-- in case such a CRL is already known by the EE -- in case such a CRL is already known by the EE
The infoValue field of the general response containing the id-it-crls Detailed Description of infoValue Field of genp:
OID looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CRL to be returned is available -- MUST be absent if no CRL to be returned is available
-- MUST contain one CRL update from the referenced source, if a -- MUST contain one CRL update from the referenced source, if a
-- thisUpdate value was not given or a more recent CRL is -- thisUpdate value was not given or a more recent CRL is
-- available -- available
4.4. Handling delayed delivery 4.4. Handling Delayed Delivery
This is a variant of all PKI management operations described in this This is a variant of all PKI management operations described in this
document. It is initiated in case a PKI management entity cannot document. It is initiated in case a PKI management entity cannot
respond to a request message in a timely manner, typically due to respond to a request message in a timely manner, typically due to
offline or asynchronous upstream communication, or due to delays in offline or asynchronous upstream communication, or due to delays in
handling the request. The polling mechanism has been specified in handling the request. The polling mechanism has been specified in
RFC 4210 Section 5.3.22 [RFC4210] and updated by RFC 4210 Section 5.3.22 [RFC4210] and updated by
[I-D.ietf-lamps-cmp-updates]. [I-D.ietf-lamps-cmp-updates].
Depending on the PKI architecture, the entity initiating delayed Depending on the PKI architecture, the entity initiating delayed
skipping to change at page 60, line 16 skipping to change at page 60, line 30
PKI management operation, i.e., a timeout occurs. PKI management operation, i.e., a timeout occurs.
When the PKI management entity that initiated delayed delivery can When the PKI management entity that initiated delayed delivery can
provide the final response for the original request message of the 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, it MUST send this response to the EE. Using this response, the
EE can continue the current PKI management operation as usual. EE can continue the current PKI management operation as usual.
No specific prerequisites apply in addition to those of the No specific prerequisites apply in addition to those of the
respective PKI management operation. respective PKI management operation.
Message flow: Message Flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format request 1 format request
message message
2 -> request -> 2 -> request ->
3 handle or forward 3 handle or forward
request request
4 format ip/cp/kup/error 4 format ip/cp/kup/error
with status "waiting" with status "waiting"
response in case no response in case no
skipping to change at page 61, line 50 skipping to change at page 61, line 50
----------------- end polling, continue as usual ------------------ ----------------- end polling, continue as usual ------------------
14 format or receive 14 format or receive
final response on final response on
original request original request
15 <- response <- 15 <- response <-
16 handle final 16 handle final
response response
Detailed description of the ip/cp/kup/error response, pollReq, and Detailed Message Description:
pollRep:
Response with status "waiting" -- ip/cp/kup/error Response with Status "waiting" -- ip/cp/kup/error
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- as described for the respective PKI management operation, with -- as described for the respective PKI management operation, with
-- the following adaptations: -- the following adaptations:
status REQUIRED -- in case of ip/cp/kup status REQUIRED -- in case of ip/cp/kup
skipping to change at page 63, line 38 skipping to change at page 63, line 38
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first response -- MUST use the same credentials as in the first response
-- message of the PKI management operation -- message of the 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 the EE has -- MAY be omitted if the message size is critical and the EE has
-- cached the extraCerts from the first response message of -- cached the extraCerts from the first response message of
-- the PKI management operation -- the PKI management operation
Final response - any type of response message Final Response - Any Type of Response Message
Field Value Field Value
header header
-- MUST be the header as described for the response message -- MUST be the header as described for the response message
-- of the respective PKI management operation -- of the respective PKI management operation
body body
-- The response of the PKI management entity to the initial -- The response of the PKI management entity to the initial
skipping to change at page 64, line 14 skipping to change at page 64, line 14
-- operation -- operation
protection REQUIRED protection REQUIRED
-- MUST be as described for the response message of the -- MUST be as described for the response message of the
-- respective PKI management operation -- respective PKI management operation
extraCerts REQUIRED extraCerts REQUIRED
-- MUST be as described for the response message of the -- MUST be as described for the response message of the
-- respective PKI management operation -- 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
after checking them and forwards respective response messages after checking them and forwards respective response messages
downstream. Besides responding to messages or forwarding them, a PKI downstream. Besides responding to messages or forwarding them, a PKI
management entity may request or revoke certificates on behalf of management entity may request or revoke certificates on behalf of
EEs. A PKI management entity may also need to manage its own EEs. A PKI management entity may also need to manage its own
certificates and thus act as an EE using the PKI management certificates and thus act as an EE using the PKI management
operations specified in Section 4. operations specified in Section 4.
5.1. Responding to requests 5.1. Responding to Requests
The PKI management entity terminating the PKI management operation at The PKI management entity terminating the PKI management operation at
CMP level MUST respond to all received requests by returning a CMP level MUST respond to all received requests by returning a
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
skipping to change at page 65, line 5 skipping to change at page 65, line 5
as described in Section 3.6.4 is transactionIdInUse. If any of these as 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
following subsections fails, the PKI management entity MUST proceed following subsections fails, the PKI management entity MUST proceed
as 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 delivery as described proceed as follows unless it initiates delayed delivery as described
in Section 5.1.2. in Section 5.1.5.
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 45 skipping to change at page 65, line 45
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
therefore MAY grant this by including the implicitConfirm extension therefore MAY grant this by including the implicitConfirm extension
in the response header. in the response header.
5.1.2. Initiating delayed delivery 5.1.2. Responding to a Confirmation Message
This functional extension can be used by a PKI management entity in
case the response to a request takes longer than usual. In this case
the PKI management entity MUST completely validate the request as
usual and then start preparing the response or forward the request
further upstream as soon as possible. In the meantime, it MUST
respond with an ip/cp/kup/error message including the status
"waiting" and handle subsequent polling as described in Section 4.4.
Note: Typically, as stated in Section 5.2.3, an intermediate PKI
management entity should not change the sender and recipient nonces
even in case it modifies a request or a response message. In the
special case of delayed delivery initiated by an intermediate PKI
management entity, there is an exception. Between the EE and this
PKI management entity, pollReq and pollRep messages are exchanged
handling the nonces as usual. Yet when the final response from
upstream has arrived at the PKI management entity, this response
contains the recipNonce copied (as usual) from the senderNonce in the
original request message. The PKI management entity that initiated
the delayed delivery may replace the recipNonce in the response
message with the senderNonce of the last received pollReq because the
downstream entities, including the EE, might expect it in this way.
Yet the check specified in Section 3.5 allows to alternatively use
the senderNonce of the original request.
No specific prerequisites apply in addition to those of the
respective PKI management operation.
5.1.3. Responding to a confirmation message
A PKI management entity MUST handle a certConf message if it has 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
specified in Section 4.1 apply. specified in Section 4.1 apply.
5.1.4. Responding to a revocation request 5.1.3. Responding to a Revocation Request
An rr message is used to request revocation of a certificate. The An rr message is used to request revocation of a certificate. The
responding PKI management entity SHOULD check the message body responding PKI management entity SHOULD check the message body
according to the requirements in Section 4.2. It MUST make sure that according to the requirements in Section 4.2. It MUST make sure that
the referenced certificate exists (failInfo bit: badCertId), has been the referenced certificate exists (failInfo bit: badCertId), has been
issued by the addressed CA, and is not already expired or revoked issued by the addressed CA, and is not already expired or revoked
(failInfo bit: certRevoked). On success it MUST respond with a (failInfo bit: certRevoked). On success it MUST respond with a
positive rp message as described in Section 4.2. positive rp message as described in Section 4.2.
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.1.5. Responding to a support message 5.1.4. 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 Note: The responding PKI management entity may generate the response
from scratch or reuse the contents of previous responses. Therefore, from scratch or reuse the contents of previous responses. Therefore,
it may be worth caching the body of the response message as long as it may be worth caching the body of the response message as long as
the contained information is still valid, such that further requests the contained information is still valid, such that further requests
for the same contents can be answered immediately. 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.1.5. Initiating Delayed Delivery
This functional extension can be used by a PKI management entity in
case the response to a request takes longer than usual. In this case
the PKI management entity MUST completely validate the request as
usual and then start preparing the response or forward the request
further upstream as soon as possible. In the meantime, it MUST
respond with an ip/cp/kup/error message including the status
"waiting" and handle subsequent polling as described in Section 4.4.
Note: Typically, as stated in Section 5.2.3, an intermediate PKI
management entity should not change the sender and recipient nonces
even in case it modifies a request or a response message. In the
special case of delayed delivery initiated by an intermediate PKI
management entity, there is an exception. Between the EE and this
PKI management entity, pollReq and pollRep messages are exchanged
handling the nonces as usual. Yet when the final response from
upstream has arrived at the PKI management entity, this response
contains the recipNonce copied (as usual) from the senderNonce in the
original request message. The PKI management entity that initiated
the delayed delivery may replace the recipNonce in the response
message with the senderNonce of the last received pollReq because the
downstream entities, including the EE, might expect it in this way.
Yet the check specified in Section 3.5 allows to alternatively use
the senderNonce of the original request.
No specific prerequisites apply in addition to those of the
respective PKI management operation.
5.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.
Any received response message or error message MUST be forwarded to Any received response message or error message MUST be forwarded to
the next (downstream) PKI entity. the next (downstream) PKI entity.
In addition to the checks described in Section 3.5, the forwarding In addition to the checks described in Section 3.5, the forwarding
skipping to change at page 69, line 13 skipping to change at page 69, line 13
certificate request messages. certificate request messages.
Note that the message protection covers only the header and the body Note that the message protection covers only the header and the body
and not the extraCerts. The PKI management entity MAY change the and not the extraCerts. The PKI management entity MAY change the
extraCerts in any of the following message adaptations, e.g., to extraCerts in any of the following message adaptations, e.g., to
sort, add, or delete certificates to support subsequent PKI entities. sort, add, or delete certificates to support subsequent PKI entities.
This may be particularly helpful to augment upstream messages with This may be particularly helpful to augment upstream messages with
additional certificates or to reduce the number of certificates in additional certificates or to reduce the number of certificates in
downstream messages when forwarding to constrained devices. downstream messages when forwarding to constrained devices.
5.2.1. Not changing protection 5.2.1. Not Changing Protection
This variant means that a PKI management entity forwards a CMP This variant means that a PKI management entity forwards a CMP
message without changing the header, body, or protection. In this message without changing the header, body, or protection. In this
case the PKI management entity acts more like a proxy, e.g., on a case the PKI management entity acts more like a proxy, e.g., on a
network boundary, implementing no specific RA-like security network boundary, implementing no specific RA-like security
functionality that requires an authentic indication to the PKI. functionality that requires an authentic indication to the PKI.
Still the PKI management entity might implement checks that result in Still the PKI management entity might implement checks that result in
refusing to forward the request message and instead responding as refusing to forward the request message and instead responding as
specified in Section 3.6. specified in Section 3.6.
This variant of forwarding a message or the one described in This variant of forwarding a message or the one described in
Section 5.2.2.1 SHOULD be used for kur messages and for central key Section 5.2.2.1 SHOULD be used for kur messages and for central key
generation. generation.
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.2. Adding protection and batching of messages 5.2.2. Adding Protection and Batching of Messages
This variant of forwarding a message means that a PKI management This variant of forwarding a message means that a PKI management
entity adds another protection to PKI management messages before entity adds another protection to PKI management messages before
forwarding them. forwarding them.
The nested message is a PKI management message containing a The nested message is a PKI management message containing a
PKIMessages sequence as its body containing one or more CMP messages. PKIMessages sequence as its body containing one or more CMP messages.
As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210] As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210]
(see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there (see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there
are various use cases for adding another protection by a PKI are various use cases for adding another protection by a PKI
management entity. Specific procedures are described in more detail management entity. Specific procedures are described in more detail
in the following sections. in the following sections.
Detailed message description: Detailed Message Description:
Nested Message - nested Nested Message - nested
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- Container to provide additional protection to original -- Container to provide additional protection to original
skipping to change at page 70, line 26 skipping to change at page 70, line 26
PKIMessages REQUIRED PKIMessages REQUIRED
-- MUST be a sequence of one or more CMP messages -- MUST be a sequence of one or more CMP messages
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 using the CMP protection key of -- As described in Section 3.2 using the CMP protection key of
-- the PKI management entity -- the PKI management entity
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
5.2.2.1. Adding protection to a request message 5.2.2.1. Adding Protection to a Request Message
A PKI management entity may authentically indicate successful This variant means that a PKI management entity forwards a CMP
validation and approval of a request message by adding an extra message while authentically indicating successful validation and
signature to the original message. approval of a request message without changing the original message.
By adding a protection using its own CMP protecting key the PKI By adding a protection using its own CMP protecting key the PKI
management entity provides a proof of verifying and approving the management entity provides a proof of verifying and approving the
message as described above. Thus, the PKI management entity acts as message as described above. Thus, the PKI management entity acts as
an actual Registration Authority (RA), which implements important an actual Registration Authority (RA), which implements important
security functionality of the PKI. Applying an additional protection security functionality of the PKI. Applying an additional protection
is specifically relevant when forwarding a message that requests a is specifically relevant when forwarding a message that requests a
certificate update or central key generation. This is because the certificate update or central key generation. This is because the
original protection of the EE must be preserved while adding an original protection of the EE must be preserved while adding an
indication of approval by the PKI management entity. indication of approval by the PKI management entity.
skipping to change at page 71, line 19 skipping to change at page 71, line 19
Note: This form of nesting messages is characterized by the fact that Note: This form of nesting messages is characterized by the fact that
the transactionID in the header of the nested message is the same as the transactionID in the header of the nested message is the same as
the one used in the included message. the one used in the included message.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST be able to validate the respective * The PKI management entity MUST be able to validate the respective
request and have the authorization to perform approval of the request and have the authorization to perform approval of the
request according to the PKI policies. request according to the PKI policies.
Message flow: Message Flow:
Step# PKI management entity PKI management entity Step# PKI management entity PKI management entity
1 format nested 1 format nested
2 -> nested -> 2 -> nested ->
3 handle or forward nested 3 handle or forward nested
4 format or receive response 4 format or receive response
5 <- response <- 5 <- response <-
6 forward response 6 forward response
5.2.2.2. Batching messages 5.2.2.2. Batching Messages
A PKI management entity MAY bundle any number of PKI management A PKI management entity MAY bundle any number of PKI management
messages for batch processing or to transfer a bulk of PKI management messages for batch processing or to transfer a bulk of PKI management
messages 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
delivery. In this case the LRA needs to initiate delayed delivery as delivery. In this case the LRA needs to initiate delayed delivery as
described in Section 5.1.2. If the RA needs different routing described in Section 5.1.5. 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 72, line 39 skipping to change at page 72, line 39
the transactionID in the header of the nested message is different to the transactionID in the header of the nested message is different to
those used in the included messages. those used in the included messages.
The protection of the nested messages SHOULD NOT be regarded as an The protection of the nested messages SHOULD NOT be regarded as an
indication of verification or approval of the bundled PKI request indication of verification or approval of the bundled PKI request
messages. messages.
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.
Message flow: Message Flow:
Step# PKI management entity PKI management entity Step# PKI management entity PKI management entity
1 format nested 1 format nested
2 -> nested -> 2 -> nested ->
3 handle or forward nested 3 handle or forward nested
4 format or receive nested 4 format or receive nested
5 <- nested <- 5 <- nested <-
6 handle nested 6 handle nested
5.2.3. Replacing protection 5.2.3. Replacing Protection
The following two alternatives can be used by any PKI management The following two alternatives can be used by any PKI management
entity forwarding a CMP message with or without changes while entity forwarding a CMP message with or without changes while
providing its own protection and in this way asserting approval of providing its own protection and in this way asserting approval of
the message. the message.
By replacing the existing protection using its own CMP protecting key By replacing the existing protection using its own CMP protecting key
the PKI management entity provides a proof of verifying and approving the PKI management entity provides a proof of verifying and approving
the message as described above. Thus, the PKI management entity acts the message as described above. Thus, the PKI management entity acts
as an actual Registration Authority (RA), which implements important as an actual Registration Authority (RA), which implements important
skipping to change at page 73, line 45 skipping to change at page 73, line 45
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. nonces.
5.2.3.1. Not changing any included proof-of-possession 5.2.3.1. Not Changing 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.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST be able to validate the respective * The PKI management entity MUST be able to validate the respective
request and have the authorization to perform approval of the request and have the authorization to perform approval of the
request according to the PKI policies. request according to the PKI policies.
5.2.3.2. Breaking proof-of-possession 5.2.3.2. Using raVerified
This variant of forwarding a message needs to be used if a PKI This variant of forwarding a message needs to be used if a PKI
management entity breaks a signature-based proof-of-possession in a management entity breaks a signature-based proof-of-possession in a
certificate request message, for instance because it forwards an ir certificate request message, for instance because it forwards an ir
or cr message with modifications of the certTemplate, i.e., or cr message with modifications of the certTemplate, i.e.,
modification, addition, or removal of fields. modification, addition, or removal of fields.
The PKI management entity MUST verify the proof-of-possession The PKI management entity MUST verify the proof-of-possession
contained in the original message using the included public key. If contained in the original message using the included public key. If
successful, the PKI management entity MUST change the popo field successful, the PKI management entity MUST change the popo field
skipping to change at page 74, line 37 skipping to change at page 74, line 37
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* The PKI management entity MUST be authorized to replace the proof- * The PKI management entity MUST be authorized to replace the proof-
of-possession (after verifying it) with raVerified. of-possession (after verifying it) with raVerified.
* The PKI management entity MUST be able to validate the respective * The PKI management entity MUST be able to validate the respective
request and have the authorization to perform approval of the request and have the authorization to perform approval of the
request according to the PKI policies. request according to the PKI policies.
The new popo field MUST contain the raVerified choice in the certReq Detailed Description of popo Field of certReq Structure:
structure of the modified message as follows:
popo popo
raVerified REQUIRED raVerified REQUIRED
-- MUST have the value NULL and indicates that the PKI -- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original message -- management entity verified the popo of the original message
5.3. Acting on behalf of other PKI entities 5.3. Acting on Behalf of other PKI Entities
A PKI management entity may need to request a PKI management A PKI management entity may need to request a PKI management
operation on behalf of another PKI entity. In this case the PKI operation on behalf of another PKI entity. In this case the PKI
management entity initiates the respective PKI management operation management entity initiates the respective PKI management operation
as described in Section 4 acting in the role of the EE. as described in Section 4 acting in the role of the EE.
5.3.1. Requesting certificates 5.3.1. Requesting a Certificate
A PKI management entity may use on of the PKI management operations A PKI management entity may use on of the PKI management operations
described in Section 4.1 to request a certificate on behalf of described in Section 4.1 to request a certificate on behalf of
another PKI entity. It either generates the key pair itself and another PKI entity. It either generates the key pair itself and
inserts the new public key in the subjectPublicKey field of the inserts the new public key in the subjectPublicKey field of the
request certTemplate, or it uses a certificate request received from request certTemplate, or it uses a certificate request received from
downstream, e.g., by means of a different protocol. In the latter downstream, e.g., by means of a different protocol. In the latter
case it SHOULD verify the received proof-of-possession. case it SHOULD verify the received proof-of-possession.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
skipping to change at page 75, line 35 skipping to change at page 75, line 35
the following changes: the following changes:
1 The request messages MUST be signed using the CMP protection key 1 The request messages MUST be signed using the CMP protection key
of the PKI management entity taking the role of the EE in this of the PKI management entity taking the role of the EE in this
operation. operation.
2 If inclusion of a proper proof-of-possession is not possible the 2 If inclusion of a proper proof-of-possession is not possible the
PKI management entity MUST verify the POP provided from downstream PKI management entity MUST verify the POP provided from downstream
and use "raVerified" in its upstream request. and use "raVerified" in its upstream request.
5.3.2. Revoking a certificate 5.3.2. Revoking a Certificate
A PKI management entity may use the PKI management operation A PKI management entity may use the PKI management operation
described in Section 4.2 to revoke a certificate of another PKI described in Section 4.2 to revoke a certificate of another PKI
entity. This revocation request message MUST be signed by the PKI entity. This revocation request message MUST be signed by the PKI
management entity using its own CMP protection key to prove to the management entity using its own CMP protection key to prove to the
PKI authorization to revoke the certificate on behalf of that PKI PKI authorization to revoke the certificate on behalf of that PKI
entity. entity.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 4.2. Section 4.2.
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 acting on behalf of the EE in this
operation.
6. CMP message transfer mechanisms 6. CMP Message Transfer Mechanisms
CMP messages are designed to be self-contained, such that in CMP messages are designed to be self-contained, such that in
principle any reliable transfer mechanism can be used. HTTP SHOULD principle any reliable transfer mechanism can be used. HTTP SHOULD
and CoAP MAY be used for online transfer. CMP messages MAY also be and CoAP MAY be used for online transfer. CMP messages MAY also be
piggybacked on any other reliable transfer protocol. File-based piggybacked on any other reliable transfer protocol. File-based
transfer MAY be used in case offline transfer is required. transfer MAY be used in case offline transfer is required.
Independently of the means of transfer, 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
skipping to change at page 77, line 12 skipping to change at page 77, line 12
response message pairs. This may improve efficiency, though is not response message pairs. This may improve efficiency, though is not
required from a security point of view. required from a security point of view.
When conveying CMP messages in HTTP, CoAP, or MIME-based transfer 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 transfer 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].
6.1. HTTP transfer 6.1. HTTP Transfer
This transfer 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 transfer 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 URI paths consisting of '/.well- PKI management operations SHOULD use URI paths consisting of '/.well-
known/cmp/' followed by an operation label depending on the type of known/cmp/' or '/.well-known/cmp/p/<name>/' as specified in CMP
PKI management operation. Updates Section 3.3 [I-D.ietf-lamps-cmp-updates] followed by an
operation label depending on the type of PKI management operation.
+============================+=====================+=========+ +============================+====================+=========+
| PKI management operation | operation label | Details | | PKI Management Operation | URI Path Segment | Details |
+============================+=====================+=========+ +============================+====================+=========+
| Enroll client to new PKI | /initialization | Section | | Enrolling an End Entity to | initialization | Section |
| | | 4.1.1 | | a New PKI | | 4.1.1 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Enroll client to existing | /certification | Section | | Enrolling an End Entity to | certification | Section |
| PKI | | 4.1.2 | | a Known PKI | | 4.1.2 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Update client certificate | /keyupdate | Section | | Updating a Valid | keyupdate | Section |
| | | 4.1.3 | | Certificate | | 4.1.3 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Enroll client using | /p10 | Section | | Enrolling an End Entity | pkcs10 | Section |
| PKCS#10 | | 4.1.4 | | Using a PKCS#10 Request | | 4.1.4 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Revoke client certificate | /revocation | Section | | Revoking a Certificate | revocation | Section |
| | | 4.2 | | | | 4.2 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Get CA certificates | /getcacerts | Section | | Get CA Certificates | getcacerts | Section |
| | | 4.3.1 | | | | 4.3.1 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Get root CA certificate | /getrootupdate | Section | | Get Root CA Certificate | getrootupdate | Section |
| update | | 4.3.2 | | Update | | 4.3.2 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Get certificate request | /getcertreqtemplate | Section | | Get CA Certificates | getcertreqtemplate | Section |
| template | | 4.3.1 | | | | 4.3.1 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Get CRL updates | /getcrls | Section | | CRL Update Retrieval | getcrls | Section |
| | | 4.3.4 | | | | 4.3.4 |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
| Batching messages | /nested | Section | | Batching Messages | nested | Section |
| | | 5.2.2.2 | | | | 5.2.2.2 |
| Note: This path element is | | | | Note: This path element is | | |
| applicable only between | | | | applicable only between | | |
| PKI management entities. | | | | PKI management entities. | | |
+----------------------------+---------------------+---------+ +----------------------------+--------------------+---------+
Table 1: HTTP endpoints Table 1: HTTP URI Path Segment <operation>
Independently of any variants used (see Section 4.1.5, Section 4.1.6, 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 and Section 4.4) the operation label corresponding to the PKI
management operation SHALL be used. management operation SHALL be used.
Any certConf or pollReq messages are sent to the same endpoint as Any certConf or pollReq messages are sent to the same endpoint as
determined by the PKI management operation. determined by the PKI management operation.
When a single request message is nested as described in 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 Section 5.2.2.1, the label to use is the same as for the underlying
skipping to change at page 79, line 47 skipping to change at page 79, line 47
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 transfer 6.2. CoAP Transfer
This transfer 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 transfer 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 URI paths consisting of '/.well- PKI management operations SHOULD use URI paths consisting of '/.well-
known/cmp/' followed by an operation label depending on the type of known/cmp/' or '/.well-known/cmp/p/<name>/' as specified in CMP over
PKI management operation. CoAP Section 2.1 [I-D.ietf-ace-cmpv2-coap-transport] followed by an
operation label depending on the type of PKI management operation.
+=======================================+===========+=========+ +=======================================+=========+=========+
| PKI management operation | operation | Details | | PKI Management Operation | URI | Details |
| | label | | | | Path | |
+=======================================+===========+=========+ | | Segment | |
| Enroll client to new PKI | /ir | Section | +=======================================+=========+=========+
| | | 4.1.1 | | Enrolling an End Entity to a New PKI | ir | Section |
+---------------------------------------+-----------+---------+ | | | 4.1.1 |
| Enroll client to existing PKI | /cr | Section | +---------------------------------------+---------+---------+
| | | 4.1.2 | | Enrolling an End Entity to a Known | cr | Section |
+---------------------------------------+-----------+---------+ | PKI | | 4.1.2 |
| Update client certificate | /kur | Section | +---------------------------------------+---------+---------+
| | | 4.1.3 | | Updating a Valid Certificate | kur | Section |
+---------------------------------------+-----------+---------+ | | | 4.1.3 |
| Enroll client using PKCS#10 | /p10 | Section | +---------------------------------------+---------+---------+
| | | 4.1.4 | | Enrolling an End Entity Using a | p10 | Section |
+---------------------------------------+-----------+---------+ | PKCS#10 Request | | 4.1.4 |
| Revoke client certificate | /rr | Section | +---------------------------------------+---------+---------+
| | | 4.2 | | Revoking a Certificate | rr | Section |
+---------------------------------------+-----------+---------+ | | | 4.2 |
| Get CA certificates | /crts | Section | +---------------------------------------+---------+---------+
| | | 4.3.1 | | Get CA Certificates | crts | Section |
+---------------------------------------+-----------+---------+ | | | 4.3.1 |
| Get root CA certificate update | /rcu | Section | +---------------------------------------+---------+---------+
| | | 4.3.2 | | Get Root CA Certificate Update | rcu | Section |
+---------------------------------------+-----------+---------+ | | | 4.3.2 |
| Get certificate request template | /att | Section | +---------------------------------------+---------+---------+
| | | 4.3.3 | | Get Certificate Request Template | att | Section |
+---------------------------------------+-----------+---------+ | | | 4.3.3 |
| Get CRL updates | /crls | Section | +---------------------------------------+---------+---------+
| | | 4.3.4 | | CRL Update Retrieval | crls | Section |
+---------------------------------------+-----------+---------+ | | | 4.3.4 |
| 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 2: CoAP endpoints Table 2: CoAP URI Path Segment <operation>
Independently of any variants used (see Section 4.1.5, Section 4.1.6, 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 and Section 4.4) the operation label corresponding to the PKI
management operation SHALL be used. management operation SHALL be used.
Any certConf or pollReq messages are sent to the same endpoint as Any certConf or pollReq messages are sent to the same endpoint as
determined by the PKI management operation. determined by the PKI management operation.
When a single request message is nested as described in 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 Section 5.2.2.1, the label to use is the same as for the underlying
skipping to change at page 81, line 26 skipping to change at page 81, line 26
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 transfer , 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 transfer 6.3. Piggybacking on other Reliable Transfer
CMP messages MAY also be transfer on some other reliable protocol. CMP messages MAY also be transfer on some other reliable protocol,
Connection, delay, and error handling mechanisms similar to those e.g., EAP or MQTT. Connection, delay, and error handling mechanisms
specified for HTTP in Section 6.1 need to be implemented. similar to those specified for HTTP in Section 6.1 need to be
implemented.
A more detailed specification is out of scope of this document and A more detailed specification is out of scope of this document and
would need to be given for instance in the scope of the transfer would need to be given for instance in the scope of the transfer
protocol used. protocol used.
6.4. Offline transfer 6.4. Offline Transfer
For transferring 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 transfer 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 transfer 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 delivery. 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 transfer protocols 6.4.2. Other Asynchronous Transfer Protocols
Other asynchronous transfer 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 RFC 8551 Section 3.1 MIME wrapping in this section is specified in RFC 8551 Section 3.1
[RFC8551]. [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 RFC 2510 Section 5.3 [RFC2510]. A
MUST be included either in a "content-type" or a "content- filename 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. Conformance requirements 7. Conformance Requirements
This section defines which level of support for the various features This section defines which level of support for the various features
specified in this profile is required for which type of PKI entity. specified in this profile is required for which type of PKI entity.
7.1. PKI management operations 7.1. PKI Management Operations
The following table provides an overview of the PKI management The following table provides an overview of the PKI management
operations specified in Section 4 and Section 5 and states whether operations specified in Section 4 and Section 5 and states whether
support by conforming EE, RA, and CA implementations is mandatory, support by conforming EE, RA, and CA implementations is mandatory,
recommended, optional, or not applicable. Variants amend or change recommended, optional, or not applicable. Variants amend or change
behavior of base PKI management operations and are therefore also behavior of base PKI management operations and are therefore also
included. included.
The PKI management operation specifications in Section 4 assume that
either the RA or CA is the PKI management entity that terminates the
CMP protocol. If the RA terminates the CMP protocol it either
responds directly as described in Section 5.1 or forwards the
certificate management operation towards the CA not using CMP.
Section 5.2 describes different options how an RA can forward a CMP
message using CMP. Section 5.3 offers the option that an RA operates
on behalf on an EE and therefore takes the role of the EE in
Section 4.
+==========+=============================+========+========+========+ +==========+=============================+========+========+========+
| ID | PKI management operations | EE | RA | CA | | ID | PKI Management Operations | EE | RA | CA |
| | and variants | | | | | | and Variants | | | |
+==========+=============================+========+========+========+ +==========+=============================+========+========+========+
| Generic | generic aspects of PKI | MUST | MUST | MUST | | Generic | Generic Aspects of PKI | MUST | MAY | MUST |
| | management operations, | | | | | | Messages and PKI | | | |
| | Management Operations, | | | |
| | Section 3 | | | | | | Section 3 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| IR | Requesting a certificate | MUST | MUST | MUST | | IR | Enrolling an End Entity | MUST | MAY | MUST |
| | from a new PKI with | | | | | | to a New PKI, | | | |
| | signature-based | | | | | | Section 4.1.1 | | | |
| | protection, Section 4.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CR | Requesting an additional | MAY | MAY | MAY | | CR | Enrolling an End Entity | MAY | MAY | MAY |
| | certificate with | | | | | | to a Known PKI, | | | |
| | signature-based | | | | | | Section 4.1.2 | | | |
| | protection, Section 4.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| KUR | Updating an existing | MUST | MUST | MUST | | KUR | Updating a Valid | MUST | MAY | MUST |
| | certificate with | | | | | | Certificate, | | | |
| | signature-based | | | | | | Section 4.1.3 | | | |
| | protection, Section 4.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| P10CR | Requesting a certificate | MAY | MAY | MAY | | P10CR | Enrolling an End Entity | MAY | MAY | MAY |
| | from a legacy PKI using a | | | | | | Using a PKCS#10 Request, | | | |
| | PKCS#10 request, | | | |
| | Section 4.1.4 | | | | | | Section 4.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| MAC | Requesting a certificate | SHOULD | SHOULD | SHOULD | | MAC | Using MAC-Based | SHOULD | SHOULD | SHOULD |
| | from a PKI with MAC-based | | | | | | Protection for | | 1) | |
| | protection (IR, CR, KUR, | | | | | | Enrollment, with IR, CR, | | | |
| | and P10CR if supported), | | | | | | KUR, and P10CR if | | | |
| | Section 4.1.5 | | | | | | supported, Section 4.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CKeyGen | Adding central key | MAY | MAY | MAY | | CKeyGen | Adding Central Key Pair | MAY | MAY | MAY |
| | generation to a | | | | | | Generation to Enrollment, | | | |
| | certificate request (IR, | | | | | | IR, CR, KUR, and P10CR if | | | |
| | CR, KUR, and P10CR if | | | | | | supported, Section 4.1.6 | | | |
| | supported). (If | | | | | | | | | |
| | supported, key agreement | | | | | | If supported, key | | | |
| | key management technique | | | | | | agreement key management | | | |
| | is REQUIRED, and key | | | | | | technique is REQUIRED, | | | |
| | transport and password- | | | | | | and key transport and | | | |
| | based key management | | | | | | password-based key | | | |
| | techniques are | | | | | | management techniques are | | | |
| | OPTIONAL.), Section 4.1.6 | | | | | | OPTIONAL. | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| RR | Revoking a certificate, | SHOULD | SHOULD | SHOULD | | RR | Revoking a Certificate, | SHOULD | SHOULD | SHOULD |
| | Section 4.2 | | | | | | Section 4.2 | | 2) | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CACerts | Get CA certificates, | MAY | MAY | MAY | | CACerts | Get CA Certificates, | MAY | MAY | MAY |
| | Section 4.3.1 | | | | | | Section 4.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| RootUpd | Get root CA certificate | MAY | MAY | MAY | | RootUpd | Get Root CA Certificate | MAY | MAY | MAY |
| | update, Section 4.3.2 | | | | | | Update, Section 4.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| ReqTempl | Get certificate request | MAY | MAY | MAY | | ReqTempl | Get Certificate Request | MAY | MAY | MAY |
| | template, Section 4.3.3 | | | | | | Template, Section 4.3.3 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CRLUpd | CRL update retrieval, | MAY | MAY | MAY | | CRLUpd | CRL Update Retrieval, | MAY | MAY | MAY |
| | Section 4.3.4 | | | | | | Section 4.3.4 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| Polling | Handling delayed | MAY | MAY | MAY | | Polling | Handling Delayed | MAY | MAY | MAY |
| | delivery, Section 4.4 | | | | | | Delivery, Section 4.4 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CertResp | Responding to a | N/A | MAY | MUST | | CertResp | Responding to a | N/A | MAY | MUST |
| | certificate request (IR, | | | | | | Certificate Request (IR, | | | |
| | CR, KUR, and P10CR if | | | | | | CR, KUR, and P10CR if | | | |
| | supported), Section 5.1.1 | | | | | | supported), Section 5.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| InitPoll | Initiating delayed | N/A | MAY | MAY | | CertConf | Responding to a | N/A | MAY | MUST |
| | delivery, Section 5.1.2 | | | | | | Confirmation Message, | | | |
+----------+-----------------------------+--------+--------+--------+ | | Section 5.1.2 | | | |
| CertConf | Responding to a | MUST | MAY | MUST |
| | confirmation message, | | | |
| | Section 5.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| RevResp | Responding to a | N/A | MAY | SHOULD | | RevResp | Responding to a | N/A | MAY | SHOULD |
| | revocation request, | | | | | | Revocation Request, | | | |
| | Section 5.1.4 | | | | | | Section 5.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| GenResp | Responding to a support | N/A | MAY | MAY | | GenResp | Responding to a Support | N/A | MAY | MAY |
| | message (CACerts, | | | | | | Message (CACerts, | | | |
| | RootUpd, ReqTempl, CRLUpd | | | | | | RootUpd, ReqTempl, CRLUpd | | | |
| | if supported), | | | | | | if supported), | | | |
| | Section 5.1.5 | | | | | | Section 5.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdKeep | Forwarding messages - not | N/A | MUST | N/A | | InitPoll | Initiating Delayed | N/A | MAY | MAY |
| | changing protection, | | | | | | Delivery, Section 5.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdKeep | Forwarding Messages - Not | N/A | MUST | N/A |
| | Changing Protection, | | | |
| | Section 5.2.1 | | | | | | Section 5.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdAddS | Adding protection to a | N/A | MUST | MUST | | FwdAddS | Forwarding Messages - | N/A | MUST | MUST |
| | request message, | | | | | | Adding Protection to a | | | |
| | Request Message, | | | |
| | Section 5.2.2.1 | | | | | | Section 5.2.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdAddB | Batching messages, | N/A | MAY | MAY | | FwdAddB | Forwarding Messages - | N/A | MAY | MAY |
| | Batching Messages, | | | |
| | Section 5.2.2.2 | | | | | | Section 5.2.2.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdRepKP | Forwarding messages - | N/A | MAY | N/A | | FwdRepKP | Forwarding Messages - Not | N/A | SHOULD | N/A |
| | replacing protection, not | | | | | | Changing | | 1) | |
| | changing any included | | | | | | Proof-of-Possession, | | | |
| | proof-of-possession, | | | |
| | Section 5.2.3.1 | | | | | | Section 5.2.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdRepBP | Forwarding messages - | N/A | MAY | MAY | | FwdRepBP | Forwarding Messages - | N/A | MAY | MAY |
| | replacing protection, | | | | | | Using raVerified, | | | |
| | breaking proof-of- | | | |
| | possession, | | | |
| | Section 5.2.3.2 | | | | | | Section 5.2.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CertOnB | Acting on behalf of other | N/A | MAY | N/A | | CertOnB | Acting on Behalf of other | N/A | MAY | N/A |
| | PKI entities - requesting | | | | | | PKI Entities - Requesting | | | |
| | certificates, | | | | | | a Certificate, | | | |
| | Section 5.3.1 | | | | | | Section 5.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| RevROnB | Acting on behalf of other | N/A | SHOULD | SHOULD | | RevROnB | Acting on Behalf of other | N/A | SHOULD | SHOULD |
| | PKI entities - revoking a | | | | | | PKI Entities - Revoking a | | 2) | |
| | certificate, | | | | | | Certificate, | | | |
| | Section 5.3.2 | | | | | | Section 5.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
Table 3: Level of support for PKI management operations and variants Table 3: Level of Support for PKI Management Operations and Variants
7.2. Message transfer 1) The RA should be able to change the CMP message protection from
MAC-based to signature-based protection, see Section 5.2.3.1.
2) The RA should be able to request certificate revocation on behalf
of an EE, see Section 5.3.2.
7.2. Message Transfer
CMP does not have specific needs regarding message transfer, except CMP does not have specific needs regarding message transfer, except
that for each request message sent, eventually exactly one response that for each request message sent, eventually exactly one response
message should be received. Therefore, virtually any reliable message should be received. Therefore, virtually any reliable
transfer mechanism can be used, such as HTTP, CoAP, and file-based transfer mechanism can be used, such as HTTP, CoAP, and file-based
offline transfer. Thus, this document does not require any specific offline transfer. Thus, this document does not require any specific
transfer protocol to be supported by conforming implementations. transfer protocol to be supported by conforming implementations.
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 transfer mechanisms as specified in Section 6 may be used. different transfer mechanisms as specified in Section 6 may be used.
skipping to change at page 86, line 6 skipping to change at page 86, line 9
HTTP transfer is RECOMMENDED to use for all PKI entities for HTTP transfer is RECOMMENDED to use for all PKI entities for
maximizing general interoperability at transfer level, yet full maximizing general interoperability at transfer level, yet full
flexibility is retained to choose whatever transfer mechanism is flexibility is retained to choose whatever transfer mechanism is
suitable, for instance for devices and system architectures with suitable, for instance for devices and system architectures with
specific constraints. specific constraints.
The following table lists the name and level of support specified for The following table lists the name and level of support specified for
each transfer mechanism. each transfer mechanism.
+=========+=======================+========+========+========+ +=========+=======================+========+========+========+
| ID | Message transfer type | EE | RA | CA | | ID | Message Transfer Type | EE | RA | CA |
+=========+=======================+========+========+========+ +=========+=======================+========+========+========+
| HTTP | HTTP transfer, | SHOULD | SHOULD | SHOULD | | HTTP | HTTP Transfer, | SHOULD | SHOULD | SHOULD |
| | Section 6.1 | | | | | | Section 6.1 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
| CoAP | CoAP transfer, | MAY | MAY | MAY | | CoAP | CoAP Transfer, | MAY | MAY | MAY |
| | Section 6.2 | | | | | | Section 6.2 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
| Piggyb | Piggybacking on other | MAY | MAY | MAY | | Piggyb | Piggybacking on other | MAY | MAY | MAY |
| | reliable transfer, | | | | | | Reliable Transfer, | | | |
| | Section 6.3 | | | | | | Section 6.3 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
| Offline | Offline transfer, | MAY | MAY | MAY | | Offline | Offline Transfer, | MAY | MAY | MAY |
| | Section 6.4 | | | | | | Section 6.4 | | | |
+---------+-----------------------+--------+--------+--------+ +---------+-----------------------+--------+--------+--------+
Table 4: Level of support for message transfer types Table 4: Level of Support for Message Transfer Types
8. IANA Considerations 8. IANA Considerations
This document does not request changes to the IANA registry. This document defines new entries with the following content in the
"CMP Well-Known URI Path Segments" registry (see
https://www.iana.org/assignments/cmp/) as defined in RFC 8615
[RFC8615].
+====================+===============================+===========+
| Path Segment | Description | Reference |
+====================+===============================+===========+
| initialization | Enrolling an End Entity to a | [thisRFC] |
| | New PKI over HTTP | |
+--------------------+-------------------------------+-----------+
| certification | Enrolling an End Entity to a | [thisRFC] |
| | Known PKI over HTTP | |
+--------------------+-------------------------------+-----------+
| keyupdate | Updating a Valid Certificate | [thisRFC] |
| | over HTTP | |
+--------------------+-------------------------------+-----------+
| pkcs10 | Enrolling an End Entity Using | [thisRFC] |
| | a PKCS#10 Request over HTTP | |
+--------------------+-------------------------------+-----------+
| revocation | Revoking a Certificate over | [thisRFC] |
| | HTTP | |
+--------------------+-------------------------------+-----------+
| getcacerts | Get CA Certificates over HTTP | [thisRFC] |
+--------------------+-------------------------------+-----------+
| getrootupdate | Get Root CA Certificate | [thisRFC] |
| | Update over HTTP | |
+--------------------+-------------------------------+-----------+
| getcertreqtemplate | Get CA Certificates over HTTP | [thisRFC] |
+--------------------+-------------------------------+-----------+
| getcrls | CRL Update Retrieval over | [thisRFC] |
| | HTTP | |
+--------------------+-------------------------------+-----------+
| nested | Batching Messages over HTTP | [thisRFC] |
+--------------------+-------------------------------+-----------+
| ir | Enrolling an End Entity to a | [thisRFC] |
| | New PKI over CoAP | |
+--------------------+-------------------------------+-----------+
| cr | Enrolling an End Entity to a | [thisRFC] |
| | Known PKI over CoAP | |
+--------------------+-------------------------------+-----------+
| kur | Updating a Valid Certificate | [thisRFC] |
| | over CoAP | |
+--------------------+-------------------------------+-----------+
| p10 | Enrolling an End Entity Using | [thisRFC] |
| | a PKCS#10 Request over CoAP | |
+--------------------+-------------------------------+-----------+
| rr | Revoking a Certificate over | [thisRFC] |
| | CoAP | |
+--------------------+-------------------------------+-----------+
| crts | Get CA Certificates over CoAP | [thisRFC] |
+--------------------+-------------------------------+-----------+
| rcu | Get Root CA Certificate | [thisRFC] |
| | Update over CoAP | |
+--------------------+-------------------------------+-----------+
| att | Get Certificate Request | [thisRFC] |
| | Template over CoAP | |
+--------------------+-------------------------------+-----------+
| crls | CRL Update Retrieval over | [thisRFC] |
| | CoAP | |
+--------------------+-------------------------------+-----------+
| nest | Batching Messages over CoAP | [thisRFC] |
+--------------------+-------------------------------+-----------+
Table 5: New "CMP Well-Known URI Path Segments" Registry Entries
< TBD: New entries must be added to the registry "CMP Well-Known URI
Path Segments". >
9. Security Considerations 9. Security Considerations
The security considerations as laid out in CMP [RFC4210] updated by The security considerations as laid out in CMP [RFC4210] updated by
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], CRMF [RFC4211] updated by Algorithm [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm
Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over
CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply. CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply.
For TLS using shared secret information-based authentication, both For TLS using shared secret information-based authentication, both
skipping to change at page 87, line 4 skipping to change at page 88, line 29
decryption, where a PSK-based cipher suite only provides security decryption, where a PSK-based cipher suite only provides security
according to the entropy of the shared secret, while a PAKE-based according to the entropy of the shared secret, while a PAKE-based
cipher suite provides full security independent of the entropy of the cipher suite provides full security independent of the entropy of the
shared secret. shared secret.
10. Acknowledgements 10. Acknowledgements
We thank the various reviewers of this document. We thank the various reviewers of this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ace-cmpv2-coap-transport] [I-D.ietf-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transfer for the Sahni, M. and S. Tripathi, "CoAP Transfer for the
Certificate Management Protocol", Work in Progress, Certificate Management Protocol", Work in Progress,
Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8
November 2021, <https://datatracker.ietf.org/doc/html/ November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-ace-cmpv2-coap-transport-04>. draft-ietf-ace-cmpv2-coap-transport-04>.
[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-09, 22 December 2021, algorithms-12, 6 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-09>. cmp-algorithms-12>.
[I-D.ietf-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
Management Protocol (CMP) Updates", Work in Progress, Management Protocol (CMP) Updates", Work in Progress,
Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12 Internet-Draft, draft-ietf-lamps-cmp-updates-18, 6 April
January 2022, <https://datatracker.ietf.org/doc/html/ 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
draft-ietf-lamps-cmp-updates-17>. lamps-cmp-updates-18>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
skipping to change at page 88, line 29 skipping to change at page 89, line 50
[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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax
(CMS) for Algorithm Identifier Protection", RFC 8933, (CMS) for Algorithm Identifier Protection", RFC 8933,
DOI 10.17487/RFC8933, October 2020, DOI 10.17487/RFC8933, October 2020,
<https://www.rfc-editor.org/info/rfc8933>. <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>.
11.2. Informative References 11.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-ae]
Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear, Oheimb, D. V., Fries, S., Brockhaus, H., and E. Lear,
"Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)", "BRSKI-AE: Alternative Enrollment Protocols in BRSKI",
Work in Progress, Internet-Draft, draft-ietf-anima-brski- Work in Progress, Internet-Draft, draft-ietf-anima-brski-
async-enroll-04, 25 October 2021, ae-01, 6 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima- <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
brski-async-enroll-04>. brski-ae-01>.
[I-D.ietf-anima-brski-prm] [I-D.ietf-anima-brski-prm]
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI Fries, S., Werner, T., Lear, E., and M. C. Richardson,
with Pledge in Responder Mode (BRSKI-PRM)", Work in "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, Progress, Internet-Draft, draft-ietf-anima-brski-prm-02, 4
25 October 2021, <https://datatracker.ietf.org/doc/html/ March 2022, <https://datatracker.ietf.org/doc/html/draft-
draft-ietf-anima-brski-prm-00>. ietf-anima-brski-prm-02>.
[I-D.ietf-netconf-sztp-csr] [I-D.ietf-netconf-sztp-csr]
Watsen, K., Housley, R., and S. Turner, "Conveying a Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-13, Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14,
31 January 2022, <https://datatracker.ietf.org/doc/html/ 2 March 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-13>. draft-ietf-netconf-sztp-csr-14>.
[IEC.62443-3-3] [IEC.62443-3-3]
IEC, "Industrial communication networks - Network and IEC, "Industrial communication networks - Network and
system security - Part 3-3: System security requirements system security - Part 3-3: System security requirements
and security levels", IEC 62443-3-3, August 2013, and security levels", IEC 62443-3-3, August 2013,
<https://webstore.iec.ch/publication/7033>. <https://webstore.iec.ch/publication/7033>.
[IEEE.802.1AR_2018] [IEEE.802.1AR_2018]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", IEEE 802.1AR-2018, networks - Secure Device Identity", IEEE 802.1AR-2018,
skipping to change at page 93, line 4 skipping to change at page 94, line 35
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 12) 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 10 -> 11:
* Updated Section 3.2, 3.5, and 3.6.4 to define more clearly
signature-based protection as the default and the exception for
not protecting error messages as mentioned at IETF 113
* Streamlined headlines in Section 4.1
* Updates Section 6.1 and Section 6.2 regarding new well-known path
segment for profile labels as discussed during IETF 113
* Updated Section 7.1. on the support of PKI management operations
required for EEs, RAs, and CAs as mentioned at IETF 113
* Updates Section 8 adding well-known path segments on PKI
management operations to be used with HTTP and CoAP
* Capitalized all headlines
From version 09 -> 10: From version 09 -> 10:
* Resolved some nits reported by I-D nit checker tool * Resolved some nits reported by I-D nit checker tool
* Resolve some wording issues * Resolve some wording issues
From version 08 -> 09: From version 08 -> 09:
* Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into * Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into
more detailed tables in Section 7 (see thread "WG Last Call for more detailed tables in Section 7 (see thread "WG Last Call for
draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-
skipping to change at page 94, line 4 skipping to change at page 95, line 49
keyEncryptionAlgorithm fields (see thread "AD review of draft- keyEncryptionAlgorithm fields (see thread "AD review of draft-
ietf-lamps-cmp-algorithms-07") ietf-lamps-cmp-algorithms-07")
* Rolled back part of the changes on root CA certificate updates in * Rolled back part of the changes on root CA certificate updates in
Section 4.3.2 (see thread "Allocation of OIDs for CRL update Section 4.3.2 (see thread "Allocation of OIDs for CRL update
retrieval (draft-ietf-lamps-cmp-updates-13)") retrieval (draft-ietf-lamps-cmp-updates-13)")
From version 06 -> 07: From version 06 -> 07:
* Added references to [draft-ietf-netconf-sztp-csr] in new * Added references to [draft-ietf-netconf-sztp-csr] in new
Section 1.5 and Section 4.1.4 Section 1.5 and Section 4.1.4
* Added reference to [I-D.ietf-anima-brski-ae] in new Section 1.5
and Section 4.1.1
* 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 * 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 PUSH use case is continued to be discussed in this draft after
the split of BRSKI-AE the split of BRSKI-AE
* Improved note regarding UNISIG Subset-137 in Section 1.6 * Improved note regarding UNISIG Subset-137 in Section 1.6
* Removed "rootCaCert" in Section 3.1 and updated the structure of * Removed "rootCaCert" in Section 3.1 and updated the structure of
the genm request for root CA certificate updates in Section 4.3.2. the genm request for root CA certificate updates in Section 4.3.2.
* Simplified handling of sender and recipient nonces in case of * Simplified handling of sender and recipient nonces in case of
delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2 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 * Changed the order of Sections 4.1.4 and 4.1.5
* Added reference on RFC 8933 regarding CMS signedAttrs to * Added reference on RFC 8933 regarding CMS signedAttrs to
 End of changes. 176 change blocks. 
446 lines changed or deleted 543 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/