rfc9483.original   rfc9483.txt 
LAMPS Working Group H. Brockhaus Internet Engineering Task Force (IETF) H. Brockhaus
Internet-Draft D. von Oheimb Request for Comments: 9483 D. von Oheimb
Intended status: Standards Track S. Fries Category: Standards Track S. Fries
Expires: 21 August 2023 Siemens ISSN: 2070-1721 Siemens
17 February 2023 October 2023
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-21
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 Internet of Things (IoT) scenarios. This is achieved by profiling
Management Protocol (CMP), the related Certificate Request Message the Certificate Management Protocol (CMP), the related Certificate
Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct Request Message Format (CRMF), and transfer based on HTTP or
but sufficiently detailed and self-contained way. To make secure Constrained Application Protocol (CoAP) in a succinct but
sufficiently detailed and self-contained way. To make secure
certificate management for simple scenarios and constrained devices certificate management for simple scenarios and constrained devices
as lightweight as possible, only the most crucial types of operations as lightweight as possible, only the most crucial types of operations
and options are specified as mandatory. More specialized or complex and options are specified as mandatory. More specialized or complex
use cases are supported with optional features. use cases are supported with optional features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 August 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9483.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. How to Read This Document . . . . . . . . . . . . . . . . 5 1.1. How to Read This Document
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 5 1.2. Conventions and Terminology
1.3. Motivation for a Lightweight Profile of CMP . . . . . . . 6 1.3. Motivation for a Lightweight Profile of CMP
1.4. Special Requirements of Industrial and IoT Scenarios . . 8 1.4. Special Requirements of Industrial and IoT Scenarios
1.5. Existing CMP Profiles . . . . . . . . . . . . . . . . . . 9 1.5. Existing CMP Profiles
1.6. Compatibility with Existing CMP Profiles . . . . . . . . 9 1.6. Compatibility with Existing CMP Profiles
1.7. Use of CMP in SZTP and BRSKI Environments . . . . . . . . 11 1.7. Use of CMP in SZTP and BRSKI Environments
1.8. Scope of this Document . . . . . . . . . . . . . . . . . 11 1.8. Scope of This Document
1.9. Structure of this Document . . . . . . . . . . . . . . . 12 1.9. Structure of This Document
2. Solution Architecture . . . . . . . . . . . . . . . . . . . . 13 2. Solution Architecture
3. Generic Aspects of PKI Messages and PKI Management 3. Generic Aspects of PKI Messages and PKI Management Operations
Operations . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. General Description of the CMP Message Header
3.1. General Description of the CMP Message Header . . . . . . 16 3.2. General Description of the CMP Message Protection
3.2. General Description of the CMP Message Protection . . . . 18 3.3. General Description of CMP Message ExtraCerts
3.3. General Description of CMP Message ExtraCerts . . . . . . 19 3.4. Generic PKI Management Operation Prerequisites
3.4. Generic PKI Management Operation Prerequisites . . . . . 19 3.5. Generic Validation of a PKI Message
3.5. Generic Validation of a PKI Message . . . . . . . . . . . 21 3.6. Error Handling
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 3.6.1. Reporting Error Conditions Upstream
3.6.1. Reporting Error Conditions Upstream . . . . . . . . . 23 3.6.2. Reporting Error Conditions Downstream
3.6.2. Reporting Error Conditions Downstream . . . . . . . . 24
3.6.3. Handling Error Conditions on Nested Messages Used for 3.6.3. Handling Error Conditions on Nested Messages Used for
Batching . . . . . . . . . . . . . . . . . . . . . . 24 Batching
3.6.4. PKIStatusInfo and Error Messages . . . . . . . . . . 25 3.6.4. PKIStatusInfo and Error Messages
4. PKI Management Operations . . . . . . . . . . . . . . . . . . 27 4. PKI Management Operations
4.1. Enrolling End Entities . . . . . . . . . . . . . . . . . 29 4.1. Enrolling End Entities
4.1.1. Enrolling an End Entity to a New PKI . . . . . . . . 30 4.1.1. Enrolling an End Entity to a New PKI
4.1.2. Enrolling an End Entity to a Known PKI . . . . . . . 37 4.1.2. Enrolling an End Entity to a Known PKI
4.1.3. Updating a Valid Certificate . . . . . . . . . . . . 37 4.1.3. Updating a Valid Certificate
4.1.4. Enrolling an End Entity Using a PKCS#10 Request . . . 39 4.1.4. Enrolling an End Entity Using a PKCS #10 Request
4.1.5. Using MAC-Based Protection for Enrollment . . . . . . 41 4.1.5. Using MAC-Based Protection for Enrollment
4.1.6. Adding Central Key Pair Generation to Enrollment . . 42 4.1.6. Adding Central Key Pair Generation to Enrollment
4.1.6.1. Using Key Transport Key Management Technique . . 48 4.1.6.1. Using the Key Transport Key Management Technique
4.1.6.2. Using Key Agreement Key Management Technique . . 48 4.1.6.2. Using the Key Agreement Key Management Technique
4.1.6.3. Using Password-Based Key Management Technique . . 50 4.1.6.3. Using the Password-Based Key Management Technique
4.2. Revoking a Certificate . . . . . . . . . . . . . . . . . 50 4.2. Revoking a Certificate
4.3. Support Messages . . . . . . . . . . . . . . . . . . . . 53 4.3. Support Messages
4.3.1. Get CA Certificates . . . . . . . . . . . . . . . . . 54 4.3.1. Get CA Certificates
4.3.2. Get Root CA Certificate Update . . . . . . . . . . . 55 4.3.2. Get Root CA Certificate Update
4.3.3. Get Certificate Request Template . . . . . . . . . . 57 4.3.3. Get Certificate Request Template
4.3.4. CRL Update Retrieval . . . . . . . . . . . . . . . . 59 4.3.4. CRL Update Retrieval
4.4. Handling Delayed Delivery . . . . . . . . . . . . . . . . 61 4.4. Handling Delayed Delivery
5. PKI Management Entity Operations . . . . . . . . . . . . . . 66 5. PKI Management Entity Operations
5.1. Responding to Requests . . . . . . . . . . . . . . . . . 66 5.1. Responding to Requests
5.1.1. Responding to a Certificate Request . . . . . . . . . 67 5.1.1. Responding to a Certificate Request
5.1.2. Responding to a Confirmation Message . . . . . . . . 67 5.1.2. Responding to a Confirmation Message
5.1.3. Responding to a Revocation Request . . . . . . . . . 68 5.1.3. Responding to a Revocation Request
5.1.4. Responding to a Support Message . . . . . . . . . . . 68 5.1.4. Responding to a Support Message
5.1.5. Initiating Delayed Delivery . . . . . . . . . . . . . 68 5.1.5. Initiating Delayed Delivery
5.2. Forwarding Messages . . . . . . . . . . . . . . . . . . . 69 5.2. Forwarding Messages
5.2.1. Not Changing Protection . . . . . . . . . . . . . . . 71 5.2.1. Not Changing Protection
5.2.2. Adding Protection and Batching of Messages . . . . . 71 5.2.2. Adding Protection and Batching of Messages
5.2.2.1. Adding Protection to a Request Message . . . . . 72 5.2.2.1. Adding Protection to a Request Message
5.2.2.2. Batching Messages . . . . . . . . . . . . . . . . 73 5.2.2.2. Batching Messages
5.2.3. Replacing Protection . . . . . . . . . . . . . . . . 75 5.2.3. Replacing Protection
5.2.3.1. Not Changing Proof-of-Possession . . . . . . . . 76 5.2.3.1. Not Changing Proof-of-Possession
5.2.3.2. Using raVerified . . . . . . . . . . . . . . . . 76 5.2.3.2. Using raVerified
5.3. Acting on Behalf of other PKI Entities . . . . . . . . . 77 5.3. Acting on Behalf of Other PKI Entities
5.3.1. Requesting a Certificate . . . . . . . . . . . . . . 77 5.3.1. Requesting a Certificate
5.3.2. Revoking a Certificate . . . . . . . . . . . . . . . 78 5.3.2. Revoking a Certificate
6. CMP Message Transfer Mechanisms . . . . . . . . . . . . . . . 78 6. CMP Message Transfer Mechanisms
6.1. HTTP Transfer . . . . . . . . . . . . . . . . . . . . . . 79 6.1. HTTP Transfer
6.2. CoAP Transfer . . . . . . . . . . . . . . . . . . . . . . 82 6.2. CoAP Transfer
6.3. Piggybacking on Other Reliable Transfer . . . . . . . . . 84 6.3. Piggybacking on Other Reliable Transfer
6.4. Offline Transfer . . . . . . . . . . . . . . . . . . . . 84 6.4. Offline Transfer
6.4.1. File-Based Transfer . . . . . . . . . . . . . . . . . 85 6.4.1. File-Based Transfer
6.4.2. Other Asynchronous Transfer Protocols . . . . . . . . 85 6.4.2. Other Asynchronous Transfer Protocols
7. Conformance Requirements . . . . . . . . . . . . . . . . . . 85 7. Conformance Requirements
7.1. PKI Management Operations . . . . . . . . . . . . . . . . 85 7.1. PKI Management Operations
7.2. Message Transfer . . . . . . . . . . . . . . . . . . . . 88 7.2. Message Transfer
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 8. IANA Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 91 9. Security Considerations
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 91 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 93 Appendix A. Example CertReqTemplate
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 96 Acknowledgements
Appendix B. History of Changes . . . . . . . . . . . . . . . . . 98 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
1. Introduction 1. Introduction
[RFC Editor:
Please perform the following substitution.
* RFCXXXX --> the assigned numerical RFC value for this draft
* RFCAAAA --> the assigned numerical RFC value for
[I-D.ietf-lamps-cmp-updates]
* RFCBBBB --> the assigned numerical RFC value for
[I-D.ietf-lamps-cmp-algorithms]
Please also update the following references to associated drafts in
progress to reflect their final RFC assignments, if available:
* [I-D.ietf-lamps-cmp-updates]
* [I-D.ietf-lamps-cmp-algorithms]
* [I-D.ietf-ace-cmpv2-coap-transport]
* [I-D.ietf-netconf-sztp-csr]
* [I-D.ietf-anima-brski-ae]
* [I-D.ietf-anima-brski-prm]
]
This document specifies PKI management operations supporting machine- This document specifies PKI management operations supporting machine-
to-machine and IoT use cases. Its focus is to maximize automation to-machine and IoT use cases. Its focus is to maximize automation
and interoperability between all involved PKI entities, ranging from and interoperability between all involved PKI entities, ranging from
end entities (EE) over any number of intermediate PKI management end entities (EEs) over any number of intermediate PKI management
entities such as Registration Authorities (RA) to the CMP endpoints entities, such as registration authorities (RAs), to the Certificate
of Certification Authority (CA) systems. This profile makes use of Management Protocol (CMP) [RFC4210] endpoints of certification
the concepts and syntax specified in CMP [RFC4210], authority (CA) systems. This profile makes use of the concepts and
[I-D.ietf-lamps-cmp-updates], and [I-D.ietf-lamps-cmp-algorithms], syntax specified in CMP [RFC4210] [RFC9480] [RFC9481], Certificate
CRMF [RFC4211] and [RFC9045], CMS [RFC5652] and [RFC8933], HTTP Request Message Format (CRMF) [RFC4211] [RFC9045], Cryptographic
transfer for CMP [RFC6712], and CoAP transfer for CMP Message Syntax (CMS) [RFC5652] [RFC8933], HTTP transfer for CMP
[I-D.ietf-ace-cmpv2-coap-transport]. CMP, CRMF and CMS are feature- [RFC6712], and CoAP transfer for CMP [RFC9482]. CMP, CRMF, and CMS
rich specifications, but most application scenarios use only a are feature-rich specifications, but most application scenarios use
limited subset of the same specified functionality. Additionally, only a limited subset of the same specified functionality.
the standards are not always precise enough on how to interpret and Additionally, the standards are not always precise enough on how to
implement the described concepts. Therefore, this document aims to interpret and implement the described concepts. Therefore, this
tailor the available options and specify how to use them in adequate document aims to tailor the available options and specify how to use
detail to make the implementation of interoperable automated them in adequate detail to make the implementation of interoperable
certificate management as straightforward and lightweight as automated certificate management as straightforward and lightweight
possible. as possible.
Note: In the meantime RFC4210bis [I-D.ietf-lamps-rfc4210bis] and While this document was being developed, documents intended to
RFC6712bis [I-D.ietf-lamps-rfc6712bis] drafts were submitted obsolete RFC 4210 [PKIX-CMP] and RFC 6712 [HTTP-CMP] were posted, and
incorporating the changes listed in CMP Updates they include the full set of changes described in CMP Updates
[I-D.ietf-lamps-cmp-updates] into the original RFC text. [RFC9480].
1.1. How to Read This Document 1.1. How to Read This Document
This document has become longer than the authors would have liked it This document has become longer than the authors would have liked it
to be. Yet apart from studying Section 3, which contains general to be. Yet apart from studying Section 3, which contains general
requirements, the reader does not have to work through the whole requirements, the reader does not have to work through the whole
document. The guidance in Sections 1.9 and 7 should be used to document. The guidance in Sections 1.9 and 7 should be used to
figure out which parts of Section 4 to Section 6 are relevant for the figure out which parts of Sections 4 to 6 are relevant for the target
target certificate management solution depending on the PKI certificate management solution, depending on the PKI management
management operations, their variants, and types of message transfer 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. Conventions and Terminology 1.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The key word "PROHIBITED" is to be interpreted to mean that the The term "PROHIBITED" is to be interpreted to mean that the
respective ASN.1 field SHALL NOT be present or used. respective ASN.1 field SHALL NOT be present or used.
Technical terminology is used in conformance with RFC 4210 [RFC4210], Technical terminology is used in conformance with [RFC4210],
RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR [RFC4211], [RFC5280], and IEEE 802.1AR [IEEE.802.1AR_2018]. The
[IEEE.802.1AR_2018]. The following key words are used: following terminology is used:
CA: Certification authority, which issues certificates. CA: Certification authority, which issues certificates.
RA: Registration authority, an optional PKI component to which a RA: Registration authority, an optional PKI component to which a
CA delegates certificate management functions such as end CA delegates certificate management functions, such as end
entity authentication and authorization checks for incoming entity authentication and authorization checks for incoming
requests. An RA can also provide conversion between various requests. An RA can also provide conversion between various
certificate management protocols and other protocols providing certificate management protocols and other protocols providing
some operations related to certificate management. some operations related to certificate management.
LRA: Local registration authority, a specific form of RA with LRA: Local registration authority, a specific form of RA with
proximity to the end entities. proximity to the end entities.
Note: For ease of reading, this document uses the term "RA" Note: For ease of reading, this document also uses the term
also for LRAs in all cases where the difference is not "RA" for LRAs in all cases where the difference is not
relevant. relevant.
KGA: Key generation authority, an optional system component, KGA: Key generation authority, an optional system component,
typically co-located with an RA or CA, that offers key typically colocated with an RA or CA, that offers key
generation services to end entities. generation services to end entities.
EE: End entity, typically a device or service that holds a public- EE: End entity, typically a device or service that holds a public-
private key pair for which it manages a public-key private key pair for which it manages a public key
certificate. An identifier for the EE is given as the subject certificate. An identifier for the EE is given as the subject
of its certificate. of its certificate.
The following terminology is reused from RFC 4210 [RFC4210], as The following terminology is reused from [RFC4210] as follows:
follows:
PKI management operation: All CMP messages belonging to a single PKI management operation: All CMP messages belonging to a single
transaction. The transaction is transaction. The transaction is
identified by the transactionID field of identified by the transactionID field of
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., an RA or a
CA.
PKI entity: An EE or PKI management entity. PKI entity: An EE or PKI management entity.
CMP messages are referred to by the names of PKIBody choices defined CMP messages are referred to by the names of PKIBody choices defined
in RFC 4210 Section 5.1.2 [RFC4210] and are further described in in Section 5.1.2 of [RFC4210] and are further described in Section 4
Section 4 of this document. of this document.
The following terms are introduced in this document: The following terms are introduced in this document:
CMP protection key: The private key used to sign a CMP CMP protection key: The private key used to sign a CMP
message. message.
CMP protection certificate: The certificate related to the CMP CMP protection certificate: The certificate related to the CMP
protection key. If the keyUsage protection key. If the keyUsage
extension is present, it MUST include extension is present, it MUST include
digitalSignature. digitalSignature.
1.3. Motivation for a Lightweight Profile of CMP 1.3. 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.
CMP is a capable protocol and could be used more widely. RFC 4210 CMP is a capable protocol and could be used more widely. CMP
[RFC4210] and CMP Updates [I-D.ietf-lamps-cmp-updates] offer a very [RFC4210] and CMP Updates [RFC9480] offer a very large set of
large set of features and options. On the one hand, this makes CMP features and options. On one hand, this makes CMP applicable to a
applicable to a very wide range of scenarios, but on the other hand, very wide range of scenarios; on the other hand, a full
a full implementation supporting all options is not realistic because implementation supporting all options is not realistic because this
this would take undue effort. would take undue effort.
In order to reduce complexity, the set of mandatory PKI management In order to reduce complexity, the set of mandatory PKI management
operations and variants required by this specification has been kept operations and variants required by this specification has been kept
lean. This limits development effort and minimizes resource needs, lean. This limits development efforts and minimizes resource needs,
which is particularly important for memory-constrained devices. To which is particularly important for memory-constrained devices. To
this end, when there was design flexibility to either have necessary this end, when there was design flexibility to either have necessary
complexity on the EE or in the PKI management entity, this profile complexity on the EE or in the PKI management entity, this profile
chose to include it in the PKI management entities where typically chose to include it in the PKI management entities where typically
more computational resources are available. Additional recommended more computational resources are available. Additional recommended
PKI management operations and variants support some more complex PKI management operations and variants support some more complex
scenarios that are considered beneficial for environments with more scenarios that are considered beneficial for environments with more
specific demands or boundary conditions. The optional PKI management specific demands or boundary conditions. The optional PKI management
operations support less common scenarios and requirements. operations support less common scenarios and requirements.
Moreover, many details of the CMP protocol have been left open or Moreover, many details of the Certificate Management Protocol have
have not been specified in full preciseness. The profiles specified been left open or have not been specified in full preciseness. The
in Appendix D and E of RFC 4210 [RFC4210] define some more detailed profiles specified in Appendices D and E of [RFC4210] define some
PKI management operations. Yet, the specific needs of highly more detailed PKI management operations. Yet the specific needs of
automated scenarios for a machine-to-machine communication are not highly automated scenarios for machine-to-machine communication are
covered sufficiently. not covered sufficiently.
Profiling is a way to reduce feature richness and complexity of Profiling is a way to reduce feature richness and complexity of
standards to what is needed for specific use cases. 3GPP and UNISIG standards to what is needed for specific use cases. 3GPP and UNISIG
already use profiling of CMP as a way to cope with these challenges. already use profiling of CMP as a way to cope with these challenges.
To profile means to take advantage of the strengths of the given To profile means to take advantage of the strengths of the given
protocol, while explicitly narrowing down the options it provides to protocol while explicitly narrowing down the options it provides to
those needed for the purpose(s) at hand and eliminating all those needed for the purpose(s) at hand and eliminating all
identified ambiguities. In this way the general aspects of the identified ambiguities. In this way, the general aspects of the
protocol are utilized and only the special requirements of the target protocol are utilized and only the special requirements of the target
scenarios need to be dealt with using distinct features the protocol scenarios need to be dealt with using distinct features the protocol
offers. offers.
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 further Other standardization bodies can reference this document and further
tailor the PKI management operations to their needs to avoid coming tailor the PKI management operations to their needs to avoid coming
up with individual profiles from scratch. up with individual profiles from scratch.
1.4. Special Requirements of Industrial and IoT Scenarios 1.4. Special Requirements of Industrial and IoT Scenarios
The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have The profiles specified in Appendices D and E of [RFC4210] have been
been developed particularly for managing certificates of human end developed particularly for managing certificates of human end
entities. With the evolution of distributed systems and client- entities. With the evolution of distributed systems and client-
server architectures, certificates for machines and applications on server architectures, certificates for machines and applications on
them have become widely used. This trend has strengthened even more them have become widely used. This trend has strengthened even more
in emerging industrial and IoT scenarios. CMP is sufficiently in emerging industrial and IoT scenarios. CMP is sufficiently
flexible to support them well. flexible to support them well.
Today's IT security architectures for industrial solutions typically Today's IT security architectures for industrial solutions typically
use certificates for endpoint authentication within protocols like use certificates for endpoint authentication within protocols like
IPsec, TLS, or SSH. Therefore, the security of these architectures IPsec, TLS, or Secure Shell (SSH). Therefore, the security of these
highly relies upon the security and availability of the implemented architectures highly relies upon the security and availability of the
certificate management operations. implemented certificate management operations.
Due to increasing security and availability needs in operational Due to increasing security and availability needs in operational
technology, especially when used for critical infrastructures and technology, especially when used for critical infrastructures and
systems with a high number of certificates, a state-of-the-art systems with a high number of certificates, a state-of-the-art
certificate management system must be constantly available and cost- certificate management system must be constantly available and cost-
efficient, which calls for high automation and reliability. efficient, which calls for high automation and reliability.
Consequently, the NIST Framework for Improving Critical Consequently, "Framework for Improving Critical Infrastructure
Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper Cybersecurity" [NIST.CSWP.04162018] refers to proper processes for
processes for issuance, management, verification, revocation, and issuance, management, verification, revocation, and audit of
audit for authorized devices, users, and processes involving identity authorized devices, users, and processes involving identity and
and credential management. Such PKI management operations according credential management. According to commonly accepted best
to commonly accepted best practices are also required in practices, such PKI management operations are also required in
IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher. [IEC.62443-3-3] for security level 2 and higher.
Further challenges in many industrial systems are network Further challenges in many industrial systems are network
segmentation and asynchronous communication. Also, PKI management segmentation and asynchronous communication. Also, PKI management
entities like Certification Authorities (CA) typically are not entities like certification authorities (CAs) are not typically
deployed on-site but in a highly protected data center environment, deployed on-site but in a highly protected data center environment,
e.g., operated according to ETSI Policy and security requirements for e.g., operated according to ETSI Policy and security requirements for
Trust Service Providers issuing certificates [ETSI-EN.319411-1]. Trust Service Providers issuing certificates [ETSI-EN.319411-1].
Certificate management must be able to cope with such network Certificate management must be able to cope with such network
architectures. CMP offers the required flexibility and architectures. CMP offers the required flexibility and
functionality, namely authenticated self-contained messages, functionality, namely authenticated self-contained messages,
efficient polling, and support for asynchronous message transfer efficient polling, and support for asynchronous message transfer
while retaining end-to-end authentication. while retaining end-to-end authentication.
1.5. Existing CMP Profiles 1.5. Existing CMP Profiles
As already stated, RFC 4210 [RFC4210] contains profiles with As already stated, [RFC4210] contains profiles with mandatory and
mandatory and optional PKI management operations in Appendix D and E. optional PKI management operations in Appendices D and E of
Those profiles focus on management of human user certificates and [RFC4210]. Those profiles focus on management of human user
only partly address the specific needs of certificate management certificates and only partly address the specific needs of
automation for unattended devices or machine-to-machine application certificate management automation for unattended devices or machine-
scenarios. to-machine application scenarios.
Both Appendixes D and E focus on EE-to-RA/CA PKI management Both Appendices D and E of [RFC4210] focus on PKI management
operations and do not address further profiling of RA-to-CA operations between an EE and an RA or CA. They do not address
communication as typically needed for full backend automation. All further profiling of RA-to-CA communication, which is typically
requirements regarding algorithm support for RFC 4210 Appendix D and needed for full backend automation. All requirements regarding
E [RFC4210] have been updated by CMP Algorithms Section 7.1 algorithm support for Appendices D and E of [RFC4210] have been
[I-D.ietf-lamps-cmp-algorithms]. updated by Section 7.1 of CMP Algorithms [RFC9481].
3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310
[ETSI-3GPP.33.310] for automatic management of IPsec certificates in [ETSI-3GPP.33.310] for automatic management of IPsec certificates in
3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP
profile for initial certificate enrollment and certificate update profile for initial certificate enrollment and certificate update
operations between EE and RA/CA is specified in that document. operations between EEs and RAs/CAs is specified in that document.
UNISIG has included a CMP profile for enrollment of TLS certificates In 2015, UNISIG included a CMP profile for enrollment of TLS
in the Subset-137 specifying the ETRAM/ETCS on-line key management certificates in the Subset-137 specifying the ETRAM/ETCS online key
for train control systems [UNISIG.Subset-137] in 2015. management for train control systems [UNISIG.Subset-137].
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.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 Appendices
Appendixes D and E (PKI Management Message Profiles) [RFC4210], with D and E of [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 protection based on the
message authentication code (MAC),
* certification of a second key pair within the same PKI management * certification of a second key pair within the same PKI management
operation is not supported, operation is not supported,
* proof-of-possession (POPO) with self-signature of the certTemplate * proof-of-possession (POP) with the self-signature of the certReq
according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the containing the certTemplate (according to [RFC4211], Section 4.1,
recommended default POPO method (deviations are possible for EEs clause 3) is the recommended default POP method (deviations are
when requesting central key generation, for RAs when using possible for EEs when requesting central key generation, for RAs
raVerified, and if the newly generated keypair is technically not when using raVerified, and if the newly generated keypair is
capable to generate digital signatures), technically not capable to generate digital signatures),
* confirmation of newly enrolled certificates may be omitted, and * confirmation of newly enrolled certificates may be omitted, and
* all PKI management operations consist of request-response message * all PKI management operations consist of request-response message
pairs originating at the EE, i.e., announcement messages pairs originating at the EE, i.e., announcement messages
(requiring a push model, a CMP server on the EE) are excluded in (requiring a push model, a CMP server on the EE) are excluded in
favor of a lightweight implementation on the EE. favor of a lightweight implementation on the EE.
The profile specified in this document is compatible with the CMP The profile specified in this document is compatible with the CMP
profile for 3G, LTE, and 5G network domain security and profile for 3G, LTE, and 5G network domain security and
authentication framework [ETSI-3GPP.33.310], except that: authentication framework [ETSI-3GPP.33.310], except that:
* protection of initial PKI management operations may be MAC-based, * protection of initial PKI management operations may be MAC-based,
* the subject field is mandatory in certificate templates, and * the subject field is mandatory in certificate templates, and
* confirmation of newly enrolled certificates may be omitted. * confirmation of newly enrolled certificates may be omitted.
The profile specified in this document is compatible with the CMP The profile specified in this document is compatible with the CMP
profile for on-line key management in rail networks as specified in profile for online key management in rail networks as specified in
UNISIG Subset-137 [UNISIG.Subset-137], except that: [UNISIG.Subset-137], except that:
* A certificate enrollment request message consists of only one * A certificate enrollment request message consists of only one
certificate request (CertReqMsg). certificate request (CertReqMsg).
* RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean * [RFC4210] requires that the messageTime is Greenwich Mean Time
Time coded as generalizedTime. coded as generalizedTime.
Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly Note: As Table 5 of [UNISIG.Subset-137] explicitly states that the
states that the messageTime in required to be "UTC time", it is messageTime is required to be "UTC time", it is not clear if this
not clear if this means a coding as UTCTime or generalizedTime and means a coding as UTCTime or generalizedTime and if time zones
if other time zones than Greenwich Mean Time shall be allowed. other than Greenwich Mean Time shall be allowed. Both time
Both time formats are described in RFC 5280 Section 4.1.2.5 formats are described in Section 4.1.2.5 of [RFC5280].
[RFC5280].
* The same type of protection is required to be used for all * The same type of protection is required to be used for all
messages of one PKI management operation. This means, in case the messages of one PKI management operation. This means, in case the
request message protection is MAC-based, also the response, request message protection is MAC-based, the response, certConf,
certConf, and pkiConf messages must have a MAC-based protection. and pkiConf messages must also have MAC-based protection.
* Use of caPubs is not required but typically allowed in combination * Use of caPubs is not required but is typically allowed in
with MAC-based protected PKI management operations. On the other combination with MAC-based protected PKI management operations.
hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using On the other hand, Table 12 of [UNISIG.Subset-137] requires using
caPubs. caPubs.
Note: It remains unclear from UNISIG Subset-137 for which Note: It remains unclear from UNISIG Subset-137 which
certificate(s) the caPubs field should be used. For security certificate(s) for the caPubs field should be used. For security
reasons, it cannot be used for delivering the root CA certificate reasons, it cannot be used for delivering the root CA certificate
needed for validating the signature-based protection of the given needed to validate the signature-based protection of the given
response message (as stated indirectly also in its UNISIG response message (as stated indirectly also in Section 6.3.1.5.2 b
Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]). of [UNISIG.Subset-137]).
* This profile requires that the certConf message has one CertStatus * This profile requires that the certConf message have one
element where the statusInfo field is recommended. CertStatus element where the statusInfo field is recommended.
Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137] Note: In contrast, Table 18 of [UNISIG.Subset-137] requires that
requires that the certConf message has one CertStatus element the certConf message has one CertStatus element where the
where the statusInfo field must be absent. This precludes sending statusInfo field must be absent. This precludes sending a
a negative certConf message in case the EE rejects the newly 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 (moreover, since using implicitConfirm is not allowed
there, either). there either).
1.7. Use of CMP in SZTP and BRSKI Environments 1.7. 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 Network Configuration Protocol (NETCONF) / YANG
[I-D.ietf-netconf-sztp-csr] offers a YANG module that includes modules, [SZTP-CSR] offers a YANG module that includes several types
several types of certificate requests to obtain a public-key of certificate requests to obtain a public key certificate for a
certificate for a locally generated key pair. Such messages are of locally generated key pair. Such messages are of the form ietf-ztp-
the form ietf-ztp-types:cmp-csr from module ietf-ztp-csr and offer types:cmp-csr from module ietf-ztp-csr and offer both proof-of-
both proof-of-possession and proof-of-identity. To allow PKI possession and proof-of-identity. To allow PKI management entities
management entities that use the module ietf-ztp-csr and also wish to that use the module ietf-ztp-csr and also wish to comply with this
comply with this profile, the ir, cr, kur, or p10cr message MUST be profile, the ir, cr, kur, or p10cr message MUST be formatted by the
formatted by the EE as described in Section 4.1, and it MAY be EE as described in Section 4.1, and it MAY be forwarded, as specified
forwarded as specified in Section 5.2. in Section 5.2.
In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
environments, BRSKI-AE: Alternative Enrollment Protocols in BRSKI environments, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI"
[I-D.ietf-anima-brski-ae] describes a generalization regarding the [BRSKI-AE] describes a generalization regarding the employed
employed enrollment protocols to allow alternatives to EST [RFC7030]. enrollment protocols to allow alternatives to Enrollment over Secure
For the use of CMP, it requires adherence to this profile. Transport (EST) [RFC7030]. For the use of CMP, it requires adherence
to this profile.
1.8. Scope of this Document 1.8. Scope of This Document
This profile on the one hand intends to reduce the flexibility of CMP On one hand, this profile intends to reduce the flexibility of CMP to
to the generic needs of automated certificate management of machine the generic needs of automated certificate management of machine end
end entities. On the other hand, it offers a variety of PKI entities. On the other hand, it offers a variety of PKI management
management operations and options relevant for industrial use cases. operations and options relevant for industrial use cases. Therefore,
Therefore, it is still a framework that supports further profiling by it is still a framework that supports further profiling by those
those addressing a specific use case or scenario, e.g., 3GPP/ETSI or addressing a specific use case or scenario, e.g., 3GPP/ETSI or
UNISIG. There is room for further tailoring this profile. This UNISIG. There is room to further tailor this profile. This enables
enables stricter profiling to the needs of concrete application stricter profiling to meet the concrete needs in application areas.
areas.
To minimize ambiguity and complexity through needless variety, this To minimize ambiguity and complexity through needless variety, this
document specifies exhaustive requirements for generating PKI document specifies exhaustive requirements for generating PKI
management messages on the sender side. On the other hand, it gives management messages on the sender side. However, it gives only
only minimal requirements on checks by the receiving side and how to 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 operation implementations are reduced to a reasonable minimum to
support typical certificate management use cases in industrial support typical certificate management use cases in industrial
machine-to-machine environments. On the EE side only limited machine-to-machine environments. On the EE side, only limited
resources are expected, while on the side of the PKI management resources are expected, while on the side of the PKI management
entities the profile accepts higher requirements. entities, the profile accepts higher requirements.
For the sake of interoperability and robustness, implementations For the sake of interoperability and robustness, implementations
should, as far as security is not affected, adhere to Postel's law: should, so long as security is not affected, adhere to Postel's law:
"Be conservative in what you do, be liberal in what you accept from "Be conservative in what you do, be liberal in what you accept from
others" (often reworded as: "Be conservative in what you send, be others" (often reworded as: "Be conservative in what you send, be
liberal in what you receive"). liberal in what you receive").
Fields used in ASN.1 syntax in Section 3, Section 4, or Section 5 are Fields used in ASN.1 syntax in Sections 3, 4, or 5 are specified in
specified in CMP [RFC4210] [I-D.ietf-lamps-cmp-updates], CRMF CMP [RFC4210] [RFC9480], CRMF [RFC4211], and CMS [RFC5652] [RFC8933].
[RFC4211], and CMS [RFC5652] [RFC8933]. When these sections do not When these sections do not explicitly discuss a field, then the field
explicitly discuss a field, then the field SHOULD NOT be used by the SHOULD NOT be used by the sending entity. The receiving entity MUST
sending entity. The receiving entity MUST NOT require the absence of NOT require the absence of such a field and, if the field is present,
such a field, and if the field is present, MUST handle it gracefully. MUST handle it gracefully.
1.9. Structure of this Document 1.9. 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. certificate management that is assumed in this document.
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 Sections 4 and 5 to minimize operations specified in detail in Sections 4 and 5 to minimize
redundancy in the description and to ease implementation. This redundancy in the description and to ease implementation. This
covers the general structure and protection of messages, as well as covers the general structure and protection of messages, as well as
generic prerequisites, validation, and error handling. generic prerequisites, validation, and error handling.
skipping to change at page 13, line 11 skipping to change at line 531
PKI management entity. There are various flavors of certificate PKI management entity. There are various flavors of certificate
enrollment requests, optionally with polling, central key generation, enrollment requests, optionally with polling, central key generation,
revocation, and general support PKI management operations. revocation, and general support PKI management operations.
Section 5 profiles responding to requests, exchanges between PKI Section 5 profiles responding to requests, exchanges between PKI
management entities, and operations on behalf of other PKI entities. management entities, and operations on behalf of other PKI entities.
This may include delayed delivery of messages, which involves polling This may include delayed delivery of messages, which involves polling
for responses, and nesting of messages. for responses, and nesting of messages.
Section 6 outlines several mechanisms for CMP message transfer, Section 6 outlines several mechanisms for CMP message transfer,
including HTTP-based transfer [RFC6712] optionally using TLS, and including HTTP-based transfer [RFC6712] optionally using TLS, CoAP-
CoAP-based transfer [I-D.ietf-ace-cmpv2-coap-transport] optionally based transfer [RFC9482] optionally using DTLS, and offline file-
using DTLS, and offline file-based transport. based transport.
Section 7 defines which parts of the profile are mandatory, Section 7 defines which parts of the profile are mandatory,
recommended, optional, or not relevant to implement for which type of recommended, optional, or not relevant to implement for which type of
entity. 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
components for operational use, e.g., in a security protocol like components for operational use, e.g., in a security protocol like
IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018], a
manufacturer-issued device certificate is called IDevID certificate manufacturer-issued device certificate is called an Initial Device
and an operational certificate is called LDevID certificate. Identifier (IDevID) certificate and an operational certificate is
called a Locally Significant Device Identifier (LDevID) certificate.
Note: The owner or operator using the manufacturer-issued device Note: The owner or operator using the manufacturer-issued device
certificate for authenticating the device during initial enrollment certificate for authenticating the device during initial enrollment
of operational certificates MUST trust the respective trust anchor of operational certificates MUST trust the respective trust anchor
provided by the manufacturer. provided by the manufacturer.
Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises Note: According to IEEE 802.1AR [IEEE.802.1AR_2018], a DevID
the triple of the certificate, the corresponding private key, and the comprises the triple of the certificate, the corresponding private
certificate chain. key, and the certificate chain.
All certificate management operations specified in this document All certificate management operations specified in this document
follow the pull model, i.e., are initiated by an EE (or by an RA follow the pull model, i.e., they are initiated by an EE (or by an RA
acting as an EE). The EE creates a CMP request message, protects it acting as an EE). The EE creates a CMP request message, protects it
using some asymmetric credential or shared secret information and using some asymmetric credential or shared secret information, and
sends it to a PKI management entity. This PKI management entity may sends it to a PKI management entity. This PKI management entity may
be a CA or more typically an RA, which checks the request, responds be a CA or more typically an RA, which checks the request and
to it itself, or forwards the request upstream to the next PKI responds to it itself or forwards the request upstream to the next
management entity. In case an RA changes the CMP request message PKI management entity. In case an RA changes the CMP request message
header or body or wants to demonstrate successful verification or header or body or wants to demonstrate successful verification or
authorization, it can apply a protection of its own. The authorization, it can apply a protection of its own. The
communication between an LRA and RA can be performed synchronously or communication between an LRA and RA can be performed synchronously or
asynchronously. Asynchronous communication typically leads to asynchronously. Asynchronous communication typically leads to
delayed message delivery as described in Section 4.4. delayed message delivery as described in Section 4.4.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| EE |<---------->| LRA |<-------------->| RA |<---------->| CA | | EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
| | | | | | | | | | | | | | | |
skipping to change at page 14, line 25 skipping to change at line 595
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--+
<--- downstream <--- | ---> upstream ---> <--- downstream <--- | ---> upstream --->
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 protect CMP messages it protection key and certificate, allowing it to protect CMP messages
processes using its own credentials. The figure above shows an it processes using its own credentials. The figure above shows an
architectural example with one LRA, RA, and CA. It is also possible architectural example with 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. not to have an RA or LRA or that there is no CA with a CMP interface.
Depending on the network infrastructure, the message transfer between Depending on the network infrastructure, the message transfer between
PKI management entities may be based on synchronous online PKI management entities may be based on synchronous online
connections, asynchronous connections, or even offline (e.g., file- connections, asynchronous connections, or even offline (e.g., file-
based) transfer. based) transfer.
Note: In contrast to the pull model used in this document, other Note: In contrast to the pull model used in this document, other
specifications could use the messages specified in this document specifications could use the messages specified in this document to
implementing the push model. In this case the EE is pushed implement the push model. In this case, the EE is pushed (triggered)
(triggered) by the PKI management entity to provide the CMP request, by the PKI management entity to provide the CMP request; therefore,
and therefore, EE acts as the receiver, not initiating the the EE acts as the receiver, not initiating the interaction with the
interaction with the PKI. For example, when the device itself does PKI. For example, when the device itself only acts (as a server as
only act as a server as described in BRSKI with Pledge in Responder described in BRSKI with Pledge in Responder Mode [BRSKI-PRM]),
Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm], support of certificate support of certificate enrollment in a push model is needed. While
enrollment in a push model is needed. While BRSKI-PRM currently BRSKI-PRM currently utilizes its own format for the exchanges, CMP in
utilizes its own format for the exchanges, CMP in general and the general and the messages specified in this profile offer all required
messages specified in this profile offer all required capabilities. capabilities. Nevertheless, the message flow and state machine as
Nevertheless, the message flow and state machine as described in described in Section 4 must be adapted to implement a push model.
Section 4 must be adapted to implement a push model.
Note: Third-party CAs, not conforming to this document, may implement Note: Third-party CAs not conforming to this document may implement
other variants of CMP, different standardized protocols, or even other variants of CMP, different standardized protocols, or even
proprietary interfaces for certificate management. In such cases, an proprietary interfaces for certificate management. In such cases, an
RA needs to adapt the exchanged CMP messages to the flavor of RA needs to adapt the exchanged CMP messages to the flavor of
certificate management interaction required by such a non-conformant certificate management interaction required by such a nonconformant
CA. CA.
3. Generic Aspects of PKI Messages and PKI Management Operations 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 Sections 4 and 5 as upfront general operations specified in Sections 4 and 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 [RFC4210], all CMP messages have the
have the following general structure: following general structure:
+--------------------------------------------+ +--------------------------------------------+
| PKIMessage | | PKIMessage |
| +----------------------------------------+ | | +----------------------------------------+ |
| | header | | | | header | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | body | | | | body | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
skipping to change at page 16, line 5 skipping to change at line 671
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 of Sections 4 and 5. described in the respective subsections of Sections 4 and 5.
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 Sections 4 and 5. information. It is described in Sections 4 and 5.
Note: In the description of CMP messages, the presence of some fields Note: In the description of CMP messages, the presence of some fields
is stated as OPTIONAL or RECOMMENDED. The following text that states is stated as OPTIONAL or RECOMMENDED. The following text that states
requirements on such a field applies only if the field is present. requirements on such a field applies only if the field is present.
The generic prerequisites needed by the PKI entities in order to be The generic prerequisites needed by the PKI entities in order to
able to perform PKI management operations are described in 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 upon
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.
Any PKI management operation-specific fields or variations are Any fields or variations specific to PKI management operation are
described in Sections 4 and 5. described in Sections 4 and 5.
header header
pvno REQUIRED pvno REQUIRED
-- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
-- is supported and expected to be used in the current -- is supported and expected to be used in the current
-- PKI management operation -- PKI management operation
-- MUST be 3 to indicate CMP v3 in certConf messages when using -- MUST be 3 to indicate CMP v3 in certConf messages when using
-- the hashAlg field -- the hashAlg field
-- MUST be 2 to indicate CMP v2 in all other cases -- MUST be 2 to indicate CMP v2 in all other cases
-- For details on version negotiation see RFCAAAA -- For details on version negotiation, see [RFC9480]
sender REQUIRED sender REQUIRED
-- Contains a name representing the originator which also -- Contains a name representing the originator, which also
-- protects the message -- protects the message
-- For signature-based protection MUST be the subject of the CMP -- For signature-based protection, MUST be the subject field of
-- protection certificate -- the CMP protection certificate
-- For MAC-based protection MUST be the subject name of the -- For MAC-based protection, MUST contain a name the PKI
-- certificate request, if available; otherwise, the NULL-DN -- management entity can use to identify the shared secret
-- (a zero-length SEQUENCE OF RelativeDistinguishedNames) MUST -- information. This name MUST be placed in the commonName
-- be used -- field of the directoryName choice.
-- In a multi-hop scenario, the receiving entity cannot rely -- In a multihop scenario, the receiving entity cannot rely
-- on the correctness of the sender field. -- on the correctness of the sender field.
recipient REQUIRED recipient REQUIRED
-- SHOULD be the name of the intended recipient; otherwise, the -- SHOULD be the name of the intended recipient; otherwise, the
-- NULL-DN MUST be used -- NULL-DN MUST be used
-- In the first message of a PKI management operation: SHOULD be -- In the first message of a PKI management operation, SHOULD be
-- the subject DN of the CA the PKI management operation is -- the subject DN of the CA the PKI management operation is
-- requested from -- requested from
-- In all other messages: SHOULD contain the value of the sender -- In all other messages, SHOULD contain the value of the sender
-- field of the previous message in the same PKI management -- field of the previous message in the same PKI management
-- operation -- operation
-- The recipient field shall be handled gracefully by the -- The recipient field shall be handled gracefully by the
-- receiving entity, because in a multi-hop scenario its -- receiving entity, because in a multihop scenario, its
-- correctness cannot be guaranteed. -- correctness cannot be guaranteed.
messageTime OPTIONAL messageTime OPTIONAL
-- MUST be present if the confirmWaitTime field is present -- MUST be present if the confirmWaitTime field is present
-- MUST be the time at which the message was produced, if present -- MUST be the time at which the message was produced, if present
-- MAY be set by a PKI management entity to provide the current -- MAY be set by a PKI management entity to provide the current
-- time -- time
-- MAY be used by the end entity for time synchronization if the -- MAY be used by the end entity for time synchronization if the
-- response was received within a short time frame -- response was received within a short time frame
protectionAlg REQUIRED protectionAlg REQUIRED
-- MUST be an algorithm identifier indicating the algorithm -- MUST be an algorithm identifier indicating the algorithm
-- used for calculating the protection bits -- used for calculating the protection bits
-- If it is a signature algorithm its type MUST be a -- If it is a signature algorithm, its type MUST be
-- MSG_SIG_ALG as specified in [RFCBBBB] Section 3 and -- MSG_SIG_ALG as specified in Section 3 of [RFC9481] and
-- MUST be consistent with the subjectPublicKeyInfo field of -- MUST be consistent with the subjectPublicKeyInfo field of
-- the CMP protection certificate -- the CMP protection certificate
-- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as -- If it is a MAC algorithm, its type MUST be MSG_MAC_ALG, as
-- specified in [RFCBBBB] Section 6.1 -- specified in [RFC9481], Section 6.1
senderKID RECOMMENDED senderKID RECOMMENDED
-- For signature-based protection MUST be used and contain the -- For signature-based protection, MUST be used and contain the
-- value of the SubjectKeyIdentifier if present in the CMP -- value of the SubjectKeyIdentifier if present in the CMP
-- protection certificate -- protection certificate
-- For MAC-based protection MUST be used and contain a name the -- For MAC-based protection, MUST be used and contain the same
-- PKI management entity can use to identify the shared secret -- name as in the commonName field of the sender field
-- information
transactionID REQUIRED transactionID REQUIRED
-- In the first message of a PKI management operation: MUST be -- In the first message of a PKI management operation, MUST be
-- 128 bits of random data, to minimize the probability of -- 128 bits of random data to minimize the probability of
-- having the transactionID already in use at the server -- having the transactionID already in use at the server
-- In all other messages: MUST be the value from the previous -- In all other messages, MUST be the value from the previous
-- message in the same PKI management operation -- message in the same PKI management operation
senderNonce REQUIRED senderNonce REQUIRED
-- MUST be cryptographically secure and fresh 128 random bits -- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED recipNonce RECOMMENDED
-- If this is the first message of a transaction: MUST be absent -- If this is the first message of a transaction, MUST be absent
-- If this is a delayed response message: MUST be present and -- If this is a delayed response message, MUST be present and
-- contain the value of the senderNonce of the respective -- contain the value of the senderNonce of the respective
-- request message in the same transaction -- request message in the same transaction
-- In all other messages: MUST be present and contain the value -- In all other messages, MUST be present and contain the value
-- of the senderNonce of the previous message in the same -- of the senderNonce of the previous message in the same
-- transaction -- transaction
generalInfo OPTIONAL generalInfo OPTIONAL
implicitConfirm OPTIONAL implicitConfirm OPTIONAL
-- RECOMMENDED in ir/cr/kur/p10cr messages, -- RECOMMENDED in ir/cr/kur/p10cr messages,
-- OPTIONAL in ip/cp/kup response messages, and -- OPTIONAL in ip/cp/kup response messages, and
-- PROHIBITED in other types of messages -- PROHIBITED in other types of messages
-- Added to request messages to request omission of the certConf -- Added to request messages to request omission of the certConf
-- message -- message
-- Added to response messages to grant omission of the certConf -- Added to response messages to grant omission of the certConf
-- message -- message
-- See [RFC4210] Section 5.1.1.1. -- See [RFC4210], Section 5.1.1.1.
ImplicitConfirmValue REQUIRED ImplicitConfirmValue REQUIRED
-- ImplicitConfirmValue MUST be NULL -- ImplicitConfirmValue MUST be NULL
confirmWaitTime OPTIONAL confirmWaitTime OPTIONAL
-- RECOMMENDED in ip/cp/kup messages if implicitConfirm is -- RECOMMENDED in ip/cp/kup messages if implicitConfirm is
-- not included -- not included
-- PROHIBITED if implicitConfirm is included -- PROHIBITED if implicitConfirm is included
-- See [RFC4210] Section 5.1.1.2. -- See [RFC4210], Section 5.1.1.2.
ConfirmWaitTimeValue REQUIRED ConfirmWaitTimeValue REQUIRED
-- ConfirmWaitTimeValue MUST be a GeneralizedTime value -- ConfirmWaitTimeValue MUST be a GeneralizedTime value
-- specifying the point in time up to which the PKI management -- specifying the point in time up to which the PKI management
-- entity will wait for the certConf message. The accepted -- entity will wait for the certConf message. The accepted
-- length of the waiting period will vary by use case. -- length of the waiting period will vary by use case.
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 [RFCAAAA] -- See [RFC9480].
CertProfileValue REQUIRED CertProfileValue REQUIRED
-- MUST contain a sequence of one UTF8String element -- MUST contain a sequence of 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. For signature-based protection, which is the default CMP messages. For signature-based protection, which is the default
protection mechanism for all CMP messages described in this profile, protection mechanism for all CMP messages described in this profile,
the CMP protection key and CMP protection certificate are used. For the CMP protection key and CMP protection certificate are used. For
MAC-based protection shared secret information is used as described MAC-based protection, shared secret information is used as described
in Section 4.1.5. in Section 4.1.5.
protection protection
-- If present, the same kind of protection MUST be used for all -- If present, the same kind of protection MUST be used for all
-- messages of that PKI management operation. -- messages of that PKI management operation.
-- MUST be present, except if protection is not possible for -- MUST be present, except if protection is not possible for
-- error messages as described in Section 3.6.4. -- error messages as described in Section 3.6.4
-- For signature-based protection MUST contain the signature -- For signature-based protection, MUST contain the signature
-- calculated using the CMP protection key of the entity -- calculated using the CMP protection key of the entity
-- protecting the message. -- protecting the message
-- For MAC-based protection MUST contain a MAC calculated using -- For MAC-based protection, MUST contain a MAC calculated using
-- the shared secret information. -- the shared secret information
-- The protection algorithm used MUST be given in the -- The protection algorithm used MUST be given in the
-- protectionAlg field. -- protectionAlg field.
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 Section 2.2 of CMP Updates
[I-D.ietf-lamps-cmp-updates] can be used for authorization of a [RFC9480] can be used for authorization of a sending PKI management
sending PKI management entity. 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. Any specific requirements on the extraCerts are specified messages. Any specific requirements on the extraCerts are specified
in the respective PKI management operation. in the respective PKI management operation.
extraCerts extraCerts
-- MUST be present for signature-based protection and contain the -- MUST be present for signature-based protection and contain the
-- CMP protection certificate together with its chain for the -- CMP protection certificate together with its chain for the
-- first request and response message of a PKI management -- first request and response message of a PKI management
-- operation. MAY be omitted in certConf, PKIConf, pollReq, and -- operation. MAY be omitted in certConf, PKIConf, pollReq,
-- pollRep messages. The first certificate in this field MUST -- and pollRep messages. The first certificate in this field
-- be the CMP protection certificate followed by its chain -- MUST be the CMP protection certificate followed by its
-- where each element should directly certify the one -- chain, where each element should directly certify the one
-- immediately preceding it. -- immediately preceding it.
-- MUST be present in ip, cp, and kup messages and contain the -- MUST be present in ip, cp, and kup messages and contain the
-- chain of a newly issued certificate. -- chain of a newly issued certificate.
-- Self-signed certificates should be omitted from extraCerts and -- Self-signed certificates should be omitted from extraCerts and
-- MUST NOT be trusted based on their inclusion in any case -- MUST NOT be trusted based on their inclusion in any case
Note: One reason for adding a self-signed certificate to extraCerts Note: One reason for adding a self-signed certificate to extraCerts
is if it is the CMP protection certificate or a successor root CA is if it is the CMP protection certificate or a successor root CA
self-signed certificate as indicated in the HashOfRootKey extension self-signed certificate as indicated in the HashOfRootKey extension
of the current root CA certificate, see [RFC8649]. Another reason of the current root CA certificate; see [RFC8649]. Another reason
for including self-signed certificates in the extraCerts is, for for including self-signed certificates in the extraCerts is, for
instance due to storage limitations, a receiving PKI entity may not instance, due to storage limitations. A receiving PKI entity may not
have the complete trust anchor as self-signed certificate available have the complete trust anchor information available but just a
but just unique identification of it, and thus needs the full self- unique identification of it and thus needs the full trust anchor
signed certificate for further processing (see also Section 9). information carried in a self-signed certificate for further
processing (see Section 9).
For maximum interoperability, all implementations SHOULD be prepared For maximum interoperability, all implementations SHOULD be prepared
to handle potentially additional certificates and arbitrary orderings to handle potentially additional certificates and arbitrary orderings
of the certificates. 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:
* For signature-based protection each EE knows its own identity from * For signature-based protection, each EE knows its own identity
the CMP protection certificate and for MAC-based protection it MAY from the CMP protection certificate; for MAC-based protection, it
know its identity to fill the sender field. MAY know its identity to fill the sender field.
* Each EE MAY know the intended recipient of its requests to fill * Each EE MAY know the intended recipient of its requests to fill
the recipient field, e.g., the name of the addressed CA. the recipient field, e.g., the name of the addressed CA.
Note: This name may be established using an enrollment voucher, Note: This name may be established using an enrollment voucher (as
e.g., [RFC8366], the issuer field from a CertReqTemplate response described in [RFC8366]), the issuer field from a CertReqTemplate
message content, or by other configuration means. response message content, or by other configuration means.
Routing of CMP messages: Routing of CMP messages:
* Each PKI entity sending messages upstream MUST know the address * Each PKI entity sending messages upstream MUST know the address
needed for transferring messages to the next PKI management entity needed for transferring messages to the next PKI management entity
in case online-transfer is used. in case online transfer is used.
Note: This address may depend on the recipient, the certificate Note: This address may depend on the recipient, the certificate
profile, and on the used transfer mechanism. profile, and the used transfer mechanism.
Authentication of PKI entities: Authentication of PKI entities:
* Each PKI entity MUST have credentials to authenticate itself. For * Each PKI entity MUST have credentials to authenticate itself. For
signature-based protection it MUST have a private key and the signature-based protection, it MUST have a private key and the
corresponding certificate along with its chain. corresponding certificate along with its chain.
* Each PKI entity MUST be able to establish trust in PKI it receives * Each PKI entity MUST be able to establish trust in the PKI it
responses from. When signature-based protection is used, it MUST receives responses from. When signature-based protection is used,
have the trust anchor(s) and any certificate status information it MUST have the trust anchor(s) and any certificate status
needed to perform path validation of CMP protection certificates information needed to perform path validation of CMP protection
used for signature-based protection. certificates used for signature-based protection.
Note: A trust anchor usually is a root certificate of the PKI Note: A trust anchor is usually a root certificate of the PKI
addressed by the requesting EE. It may be established by addressed by the requesting EE. It may be established by
configuration or in an out-of-band manner. For an EE it may be configuration or in an out-of-band manner. For an EE, it may be
established using an enrollment voucher [RFC8366] or in-band of established using an enrollment voucher [RFC8366] or in-band of
CMP by the caPubs field in a certificate response message. CMP by the caPubs field in a certificate response message.
Authorization of PKI management operations: Authorization of PKI management operations:
* Each EE or RA MUST have sufficient information to be able to * Each EE or RA MUST have sufficient information to be able to
authorize the PKI management entity for performing the upstream authorize the PKI management entity to perform the upstream PKI
PKI management operation. management operation.
Note: This may be achieved for example by using the cmcRA extended Note: This may be achieved, for example, by using the cmcRA
key usage in server certificates, by local configuration such as extended key usage in server certificates, by local configuration
specific name patterns for subject DN or SAN portions that may (such as specific name patterns for subject Distinguished Name
identify an RA, and/or by having a dedicated root CA usable only (DN) or Subject Alternative Name (SAN) portions that may identify
for authenticating PKI management entities. an RA) and/or by having a dedicated root CA usable only 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.
authorization of EEs can be very specific to the application The 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; also see Appendix F of [RFC4210].
All PKI message header fields not mentioned in this section like the All PKI message header fields not mentioned in this section, like the
recipient and generalInfo fields SHOULD be handled gracefully on recipient and generalInfo fields, SHOULD be handled gracefully upon
reception. receipt.
The following list describes the basic set of message input The following list describes the basic set of message input
validation steps. Without these checks the protocol becomes validation steps. Without these checks, the protocol becomes
dysfunctional. dysfunctional.
* The formal ASN.1 syntax of the whole message MUST be compliant * The formal ASN.1 syntax of the whole message MUST be compliant
with the definitions given in CMP [RFC4210] and with the definitions given in CMP [RFC4210] [RFC9480], CRMF
[I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] [RFC4211], and CMS [RFC5652] [RFC8933]. (failInfo: badDataFormat)
and [RFC8933]. (failInfo: badDataFormat)
* The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: * The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit:
unsupportedVersion) unsupportedVersion)
* The transactionID MUST be present. (failInfo bit: badDataFormat) * The transactionID MUST be present. (failInfo bit: badDataFormat)
* The PKI message body type MUST be one of the message types * The PKI message body type MUST be one of the message types
supported by the receiving PKI entity and MUST be allowed in the supported by the receiving PKI entity and MUST be allowed in the
current state of the PKI management operation identified by the current state of the PKI management operation identified by the
given transactionID. (failInfo bit: badRequest) given transactionID. (failInfo bit: badRequest)
skipping to change at page 22, line 17 skipping to change at line 970
- 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)
* Messages without protection MUST be rejected except for error * Messages without protection MUST be rejected except for error
messages as described in Section 3.6.4. messages as described in Section 3.6.4.
* The message protection MUST be validated when present and messages * The message protection MUST be validated when present, and
with an invalid protection MUST be rejected. messages with an invalid protection MUST be rejected.
- The protection MUST be signature-based except if MAC-based - The protection MUST be signature-based except if MAC-based
protection is used as described in Section 4.1.5 and protection is used as described in Sections 4.1.5 and 4.1.6.3.
Section 4.1.6.3. (failInfo bit: wrongIntegrity) (failInfo bit: wrongIntegrity)
- If present, the senderKID MUST identify the key material needed - If present, the senderKID MUST identify the key material needed
for verifying the message protection. (failInfo bit: for verifying the message protection. (failInfo bit:
badMessageCheck) badMessageCheck)
- If signature-based protection is used, the CMP protection - If 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
present in the CMP protection certificate the digitalSignature present in the CMP protection certificate, the digitalSignature
bit MUST be set. (failInfo bit: badAlg, badMessageCheck, or bit MUST be set. (failInfo bit: badAlg, badMessageCheck, or
signerNotTrusted) signerNotTrusted)
- The sender of a request message MUST be authorized for - The sender of a request message MUST be authorized to request
requesting the operation according to PKI policies. (failInfo the operation according to PKI policies. (failInfo bit:
bit: notAuthorized) notAuthorized)
Note: The requirements for checking certificates given in RFC 5280 Note: The requirements for checking certificates given in [RFC5280]
[RFC5280] MUST be followed for signature-based CMP message MUST be followed for signature-based CMP message protection. Unless
protection. Unless the message is a positive ip/cp/kup where the the message is a positive ip/cp/kup, where the issuing CA certificate
issuing CA certificate of the newly enrolled certificate is the same of the newly enrolled certificate is the same as the CMP protection
as the CMP protection certificate of that message, certificate status certificate of that message, certificate status checking SHOULD be
checking SHOULD be performed on the CMP protection certificates. If performed on the CMP protection certificates. If the response
the response message contains the caPubs field to transfer new trust message contains the caPubs field to transfer new trust anchor
anchor information, the CMP protection is crucial and certificate information, the CMP protection is crucial and certificate status
status checking is REQUIRED. For other cases it MAY be acceptable to checking is REQUIRED. For other cases, it MAY be acceptable to omit
omit certificate status checking when respective information is not certificate status checking when respective information is not
available. available.
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 MUST match * If signature-based protection is used, the sender field MUST match
the subject of the CMP protection certificate. (failInfo bit: the subject of the CMP protection certificate. (failInfo bit:
badMessageCheck) badMessageCheck)
* If the messageTime is present and * If the messageTime is present and
skipping to change at page 23, line 31 skipping to change at line 1031
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 to allow root-cause analysis of failure cases. appropriately to allow root-cause analysis of failure cases.
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 the upstream direction, either. NOT send error messages in the 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
PKI management entity MUST regard the current PKI management PKI management entity MUST regard the current PKI management
operation as terminated with failure. The error conditions include operation as terminated with failure. The error conditions include:
* invalid response message header, body type, protection, or * invalid response message header, body type, protection, or
extraCerts according to the checks described in Section 3.5, extraCerts, according to the checks described in Section 3.5,
* any issue detected with response message contents, * any issue detected with response message contents,
* receipt of an error message from upstream, * receipt of an error message from upstream,
* timeout occurred while waiting for a response, * timeout occurred while waiting for a response, and
* 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. The value set for such timeouts will vary by or timeout will occur. The value set for such timeouts will vary by
use case. Then they also MUST regard the current PKI management use case. Then they MUST also regard the current PKI management
operation as terminated with failure and MUST NOT attempt to send an operation as terminated with failure and MUST NOT attempt to send an
error message downstream. 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 MUST cr, p10cr, kur, or rr message received from downstream, it MUST
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 Sections 4.1.1
Section 4.2. This can also happen in case of polling. and 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
according to the checks described in Section 3.5 it MUST report them extraCerts, according to the checks described in Section 3.5), it
downstream in the form of an error message as described in MUST report them downstream in the form of an error message as
Section 3.6.4. described in 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, but to the nested message itself. requests included in it but to the nested message itself.
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 and the body of the received nested message still parses, sent before and the body of the received nested message still parses,
it MAY ignore this error condition and handle the included responses it MAY ignore this error condition and handle the included responses
as described in Section 5.2.2.2. Otherwise, it MUST propagate the as described in Section 5.2.2.2. Otherwise, it MUST propagate the
error by responding with an error message to each of the requests error by responding with an error message to each of the requests
contained in the nested message it sent originally. contained in the nested message it sent originally.
3.6.4. PKIStatusInfo and Error Messages 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. Then it 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: ip, cp, kup, certConf, and of various message types, in particular, ip, cp, kup, certConf, and
error. The PKIStatusInfo structure consists of the following fields: error. The PKIStatusInfo structure consists of the following fields:
* status: Here the PKIStatus value "rejection" MUST be used in case status: Here, the PKIStatus value "rejection" MUST be used in case
an error was detected. When a PKI management entity indicates an error was detected. When a PKI management entity indicates
delayed delivery of a CMP response message to the EE with an error delayed delivery of a CMP response message to the EE with an error
message as described in Section 4.4, the status "waiting" MUST be message as described in Section 4.4, the status "waiting" MUST be
used there. used there.
* statusString: Here any human-readable valid value for logging or statusString: Here, any human-readable valid value for logging or to
to display via a user interface should be added. display via a user interface should be added.
* failInfo: Here the PKIFailureInfo bits MAY be used in the way failInfo: Here, the PKIFailureInfo bits MAY be used in the way
explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo explained in Appendix F of [RFC4210]. PKIFailureInfo bits
bits regarding the validation described in Section 3.5 are regarding the validation described in Section 3.5 are referenced
referenced there. The PKIFailureInfo bits referenced in Sections there. The PKIFailureInfo bits referenced in Sections 5.1 and 6
5.1 and 6 are described here: are described here:
- badCertId: A kur, certConf, or rr message references an unknown badCertId: A kur, certConf, or rr message references an unknown
certificate certificate.
- badPOP: An ir/cr/kur/p10cr contains an invalid proof-of- badPOP: An ir/cr/kur/p10cr contains an invalid proof-of-
possession possession.
- certRevoked: Revocation requested for a certificate already certRevoked: Revocation is requested for a certificate that is
revoked already revoked.
- badCertTemplate: The contents of a certificate request are not badCertTemplate: The contents of a certificate request are not
accepted, e.g., a field is missing or has a non-acceptable accepted, e.g., a field is missing or has an unacceptable value
value or the given public key is already in use in some other or the given public key is already in use in some other
certificate (depending on policy). certificate (depending on policy).
- transactionIdInUse: This is sent by a PKI management entity in transactionIdInUse: This is sent by a PKI management entity in
case the received request contains a transactionID that is case the received request contains a transactionID that is
currently in use for another transaction. An EE receiving such currently in use for another transaction. An EE receiving such
error message should resend the request in a new transaction an error message should resend the request in a new transaction
using a different transactionID. using a different transactionID.
- notAuthorized: The sender of a request message is not notAuthorized: The sender of a request message is not authorized
authorized for requesting the operation. for requesting the operation.
- systemUnavail: This is sent by a PKI management entity in case systemUnavail: This is sent by a PKI management entity in case a
a back-end system is not available. 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
a back-end system is currently not functioning correctly. 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 Message Description: Detailed Message Description:
Error Message -- error Error Message -- error
Field Value Field Value
skipping to change at page 26, line 34 skipping to change at line 1177
-- 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 OPTIONAL statusString OPTIONAL
-- This field should contain any human-readable text for -- This field should contain any human-readable text for
-- debugging, logging or to display in a GUI -- debugging, for logging, 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 RECOMMENDED protection RECOMMENDED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
Protecting the error message may not be technically feasible if it is Protecting the error message may not be technically feasible if it is
not clear which credential the recipient will be able to use when not clear which credential the recipient will be able to use when
validating this protection, e.g., in case the request message was validating this protection, e.g., in case the request message was
fundamentally broken. In these exceptional cases the protection of fundamentally broken. In these exceptional cases, the protection of
the error message MAY be omitted. the error message MAY be omitted.
4. PKI Management Operations 4. PKI Management Operations
This chapter focuses on the communication of an EE with the PKI This section 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,
certificate updates, central key generation, and MAC-based certificate updates, central key generation, and MAC-based
protection protection
* Revoking a certificate * revoking a certificate
* Support messages * support messages
* Polling for delayed response messages * polling for delayed response messages
These operations mainly specify the message body of the CMP messages These operations mainly specify the message body of the CMP messages
and utilize the specification of the message header, protection and and utilize the specification of the message header, protection, and
extraCerts as specified in Section 3. The messages are named by the extraCerts, as specified in Section 3. The messages are named by the
respective field names in PKIBody like ir, ip, cr, cp, etc., see respective field names in PKIBody, like ir, ip, cr, cp, etc.; see
RFC 4210 Section 5.1.2 [RFC4210]. Section 5.1.2 of [RFC4210].
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, ip/cp/kup/error
ip/cp/kup/error messages with status "waiting", pollReq, and pollRep messages with status "waiting", and pollReq and pollRep messages as
messages as described in Section 4.4. 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. In case an error occurs,
error occurs is described in Section 3.6. the behavior is described in Section 3.6.
End Entity State Machine: End Entity State Machine:
start start
| |
| send ir/cr/kur/p10cr/rr/genm | send ir/cr/kur/p10cr/rr/genm
v v
waiting for response waiting for response
v v
+--------------------------+--------------------------+ +--------------------------+--------------------------+
| | | | | |
| 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 28, line 49 skipping to change at line 1274
| v | | | v | |
| waiting for pkiConf*) | | | waiting for pkiConf*) | |
| | | | | | | |
| | received | | | | received | |
| v pkiConf v | | v pkiConf v |
+---------------->+------->+<-------+<----------------+ +---------------->+------->+<-------+<----------------+
| |
v v
end end
*) In case of a delayed delivery of pkiConf responses the same *) In case of a delayed delivery of pkiConf responses, the same
polling mechanism is initiated as for rp or genp messages, by polling mechanism is initiated as for rp or genp messages by
sending an error message with status "waiting". sending an error message with status "waiting".
Note: All CMP messages belonging to the same PKI management operation Note: All CMP messages belonging to the same PKI management operation
MUST have the same transactionID because the message receiver MUST have the same transactionID because the message receiver
identifies the elements of the operation in this way. identifies the elements of the operation in this way.
This section is aligned with CMP [RFC4210], CMP Updates This section is aligned with CMP [RFC4210], CMP Updates [RFC9480],
[I-D.ietf-lamps-cmp-updates], and CMP Algorithms and CMP Algorithms [RFC9481].
[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 [RFC9481].
4.1. Enrolling End Entities 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
* Using a private key and certificate issued from the same PKI that * using a private key and certificate issued from the same PKI that
is addressed for requesting a certificate is addressed for requesting a certificate
* Using the certificate to be updated and the corresponding private * using the certificate to be updated and the corresponding private
key key
* Using shared secret information known to the EE and the PKI * using shared secret information known to the EE and the PKI
management entity 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 MUST then
handle it as described in Section 5.1.2 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. The public key and the subject name identifying
proof-of-possession of the private key associated with the public key the EE MUST be present in the certTemplate of the certificate request
contained in the certificate request as defined by RFC 4211 message.
Section 4.1 [RFC4211] case 3. To this end it is assumed that the
private key can technically be used for signing. This is the case
for the most common algorithms RSA, ECDSA, and EdDSA regardless of
potentially intended restrictions of the key usage.
Note: RFC 4211 Section 4 [RFC4211] allows for providing proof-of- Note: If the EE does not know for which subject name to request the
possession using any method that a key can be used for. In certificate, it can use the subject name from the CMP protection
conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 certificate in case of signature-based protection or the identifier
[NIST.SP.800-57p1r5] the newly generated private key may be used for of the shared secret in case of MAC-based protection.
self-signature, if technically possible, even if the keyUsage
extension requested in the certificate request prohibits generation Typically, the EE provides a signature-based proof-of-possession of
of digital signatures. the private key associated with the public key contained in the
certificate request, as defined by [RFC4211], Section 4.1, clause 3.
To this end, it is assumed that the private key can technically be
used for signing. This is the case for the most common algorithms
RSA, ECDSA, and EdDSA, regardless of potentially intended
restrictions of the key usage.
Note: Section 4 of [RFC4211] allows for providing proof-of-possession
using any method that a key can be used for. In conformance with
Section 8.1.5.1.1.2 of [NIST.SP.800-57p1r5], the newly generated
private key may be used for self-signature, if technically possible,
even if the keyUsage extension requested in the certificate request
prohibits generation of digital signatures.
The requesting EE provides the binding of the proof-of-possession to The requesting EE provides the binding of the proof-of-possession to
its identity by signature-based or MAC-based protection of the CMP its identity by signature-based or MAC-based protection of the CMP
request message containing that POP. An upstream PKI management request message containing that POP. An upstream PKI management
entity should verify whether this EE is authorized to obtain a entity should verify whether this EE is authorized to obtain a
certificate with the requested subject and other fields and certificate with the requested subject and other fields and
extensions. extensions.
The proof-of-possession is provided by signing the certReq containing
the certTemplate with the subject name and public key. To bind this
proof-of-possession to the proof-of-identity of the requesting EE,
the subject name in the certTemplate needs to identify the same
entity as the subject name in the CMP protection certificate or match
the identifier used with MAC-based protection.
Note: This binding may be lost if a PKI management entity reprotects
this request message.
The EE MAY indicate the certificate profile to use in the certProfile The EE MAY indicate the certificate profile to use in the certProfile
extension of the generalInfo field in the PKIHeader of the extension of the generalInfo field in the PKIHeader of the
certificate request message as described in Section 3.1. certificate request message as described in Section 3.1.
In case the EE receives a CA certificate in the caPubs field for In case the EE receives a CA certificate in the caPubs field for
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 a 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 (ip)
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. Enrolling an End Entity to a New PKI 4.1.1. Enrolling an End Entity to a New PKI
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-AE: Alternative Enrollment Protocols in [RFC8995] environments, "BRSKI-AE: Alternative Enrollment Protocols
BRSKI [I-D.ietf-anima-brski-ae] describes a generalization regarding in BRSKI" [BRSKI-AE] describes a generalization regarding enrollment
enrollment protocols alternative to EST [RFC7030]. As replacement of protocols alternative to EST [RFC7030]. As replacement of EST
EST simpleenroll, BRSKI-AE uses this PKI management operation for simpleenroll, BRSKI-AE uses this PKI management 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
are as follows:
* The certificate of the EE MUST have been enrolled by an external * The certificate of the EE MUST have been enrolled by an external
PKI, e.g., a manufacturer-issued device certificate. PKI, e.g., a manufacturer-issued device certificate.
* The PKI management entity MUST have the trust anchor of the * The PKI management entity MUST have the trust anchor of the
external PKI. external PKI.
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
skipping to change at page 31, line 52 skipping to change at line 1430
11 format or receive pkiConf 11 format or receive pkiConf
12 <- pkiConf <- 12 <- pkiConf <-
13 handle pkiConf 13 handle pkiConf
For this PKI management operation, the EE MUST include a sequence of For this PKI management operation, the EE MUST include a sequence of
one CertReqMsg in the ir. If more certificates are required, further one CertReqMsg in the ir. If more certificates are required, further
requests MUST be sent using separate PKI management operations. requests MUST be sent using separate PKI management operations.
The EE MUST include the generalInfo field implicitConfirm in the The EE MUST include the generalInfo field implicitConfirm in the
header of the ir message as described in Section 3.1, unless it header of the ir message as described in Section 3.1, unless it
requires certificate confirmation. This leaves the choice to the PKI requires certificate confirmation. This leaves the PKI management
management entities whether the EE must send a certConf message on entities the choice of whether or not the EE must send a certConf
receiving a new certificate. Depending on the PKI policy and message upon receiving a new certificate. Depending on the PKI
requirements for managing EE certificates, it can be important for policy and requirements for managing EE certificates, it can be
PKI management entities to learn if the EE accepted the new important for PKI management entities to learn if the EE accepted the
certificate. In such cases, when responding with an ip message, the new certificate. In such cases, when responding with an ip message,
PKI management entity MUST NOT include the implicitConfirm extension. the PKI management entity MUST NOT include the implicitConfirm
In case the EE included the generalInfo field implicitConfirm in the extension. In case the EE included the generalInfo field
request message and the PKI management entity does not need any implicitConfirm in the request message and the PKI management entity
explicit confirmation from the EE, the PKI management entity MUST does not need any explicit confirmation from the EE, the PKI
include the generalInfo field implicitConfirm in the response management entity MUST include the generalInfo field implicitConfirm
message. This prevents explicit certificate confirmation and saves in the response message. This prevents explicit certificate
the overhead of a further message round-trip. Otherwise, the PKI confirmation and saves the overhead of a further message round trip.
management entity SHOULD include confirmWaitTime as described in Otherwise, the PKI management entity SHOULD include confirmWaitTime
Section 3.1. as described in Section 3.1.
If the EE did not request implicit confirmation or implicit If the EE did not request implicit confirmation or implicit
confirmation was not granted by the PKI management entity, confirmation was not granted by the PKI management entity,
certificate confirmation MUST be performed as follows. If the EE certificate confirmation MUST be performed as follows. If the EE
successfully received the certificate, it MUST send a certConf successfully received the certificate, it MUST send a certConf
message in due time. On receiving a valid certConf message, the PKI message in due time. On receiving a valid certConf message, the PKI
management entity MUST respond with a pkiConf message. If the PKI management entity MUST respond with a pkiConf message. If the PKI
management entity does not receive the expected certConf message in management entity does not receive the expected certConf message in
time it MUST handle this like a rejection by the EE. In case of time, it MUST handle this like a rejection by the EE. In case of
rejection, depending on its policy the PKI management entity MAY rejection, depending on its policy, the PKI management entity MAY
revoke the newly issued certificate, notify a monitoring system, or revoke the newly issued certificate, notify a monitoring system, or
log the event internally. log the event internally.
Note: Depending on PKI policy, a new certificate may be published by Note: Depending on PKI policy, a new certificate may be published by
a PKI management entity, and explicit confirmation may be required. a PKI management entity, and explicit confirmation may be required.
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 can be need to revoke the certificate on negative confirmation can be
avoided. 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 the certifiedKeyPair "rejection" as described in Section 3.6, and the certifiedKeyPair
field SHALL be omitted. The EE MUST NOT react to such an ip message field SHALL be omitted. The EE MUST NOT react to such an ip message
with a certConf message and the PKI management operation MUST be with a certConf message, and the PKI management operation MUST be
terminated. 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
skipping to change at page 33, line 25 skipping to change at line 1494
-- MUST contain a sequence of one CertReqMsg -- MUST contain a sequence of one CertReqMsg
-- If more certificates are required, further PKI management -- If more certificates are required, further PKI management
-- operations needs to be initiated -- operations needs to be initiated
certReq REQUIRED certReq REQUIRED
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
certTemplate REQUIRED certTemplate REQUIRED
version OPTIONAL version OPTIONAL
-- MUST be 2 if supplied -- MUST be 2 if supplied
subject REQUIRED subject REQUIRED
-- The EE subject name MUST be carried in the subject field -- The EE's identity MUST be carried in the subject field
-- and/or the subjectAltName extension. -- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName -- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN -- extension, then the subject field MUST be NULL-DN
publicKey OPTIONAL publicKey OPTIONAL
-- MUST be present if local key generation is used -- MUST be present if local key generation is used
-- MAY be absent if central key generation is requested -- MAY be absent if central key generation is requested
algorithm OPTIONAL algorithm OPTIONAL
-- MUST be present if local key generation is used and MUST -- MUST be present if local key generation is used and MUST
-- include the subject public key algorithm identifier -- include the subject public key algorithm identifier
-- MAY be present if central key generation is requested and -- MAY be present if central key generation is requested and,
-- if present, informs the KGA of algorithm and parameter -- if present, informs the KGA of algorithm and parameter
-- preferences regarding the to-be-generated key pair -- preferences regarding the to-be-generated key pair
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST contain the public key to be certified in case of local -- MUST contain the public key to be certified in case of local
-- key generation -- key generation
-- MUST be a zero-length BIT STRING if central key generation -- MUST be a zero-length BIT STRING if central key generation
-- is requested -- is requested
extensions OPTIONAL extensions OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the -- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name, key -- requested certificate, like subject alternative name, key
-- usage, and extended key usage -- usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE subject -- The subjectAltName extension MUST be present if the EE subject
-- name includes a subject alternative name. -- name includes a subject alternative name.
popo OPTIONAL popo OPTIONAL
-- MUST be present if local key generation is used -- MUST be present if local key generation is used
-- MUST be absent if central key generation is requested -- MUST be absent if central key generation is requested
signature OPTIONAL signature OPTIONAL
-- MUST be used by an EE if the key can be used for signing, and
-- MUST be used by an EE if the key can be used for signing and -- if used, it MUST have the type POPOSigningKey
-- if used it MUST have the type POPOSigningKey
poposkInput PROHIBITED poposkInput PROHIBITED
-- MUST NOT be used; it is not needed because subject and -- MUST NOT be used; it is not needed because subject and
-- publicKey are both present in the certTemplate -- publicKey are both present in the certTemplate
algorithmIdentifier REQUIRED algorithmIdentifier REQUIRED
-- The signature algorithm MUST be consistent with the publicKey -- The signature algorithm MUST be consistent with the publicKey
-- algorithm field of the certTemplate -- algorithm field of the certTemplate
signature REQUIRED signature REQUIRED
-- MUST contain the signature value computed over the DER-encoded -- MUST contain the signature value computed over the DER-encoded
-- certTemplate -- certReq
raVerified OPTIONAL raVerified OPTIONAL
-- MAY be used by an RA after verifying the proof-of-possession -- MAY be used by an RA after verifying the proof-of-possession
-- provided by the EE -- provided by the EE
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
skipping to change at page 34, line 38 skipping to change at line 1555
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The response of the CA to the request as appropriate -- The response of the CA to the request as appropriate
ip REQUIRED ip REQUIRED
caPubs OPTIONAL caPubs OPTIONAL
-- MAY be used if the certifiedKeyPair field is present -- MAY be used if the certifiedKeyPair field is present
-- If used it MUST contain only a trust anchor, e.g., root -- If used, it MUST contain only a trust anchor, e.g., root
-- certificate, of the certificate contained in certOrEncCert -- certificate, of the certificate contained in certOrEncCert
response REQUIRED response REQUIRED
-- MUST contain a sequence of one CertResponse -- MUST contain a sequence of one CertResponse
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
status REQUIRED status REQUIRED
-- PKIStatusInfo structure MUST be present -- PKIStatusInfo structure MUST be present
status REQUIRED status REQUIRED
-- positive values allowed: "accepted", "grantedWithMods" -- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
-- "waiting" only allowed with polling use case as described in -- "waiting" only allowed with a polling use case as described
-- Section 4.4 -- in Section 4.4
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- MAY be any human-readable text for debugging, logging or to -- to display in a GUI
-- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" or "grantedWithMods" -- MUST be absent if status is "accepted" or "grantedWithMods"
certifiedKeyPair OPTIONAL certifiedKeyPair OPTIONAL
-- MUST be present if status is "accepted" or "grantedWithMods" -- MUST be present if status is "accepted" or "grantedWithMods"
-- MUST be absent if status is "rejection" -- MUST be absent if status is "rejection"
certOrEncCert REQUIRED certOrEncCert REQUIRED
-- MUST be present if status is "accepted" or "grantedWithMods" -- MUST be present if status is "accepted" or "grantedWithMods"
certificate REQUIRED certificate REQUIRED
-- MUST be present when certifiedKeyPair is present -- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate -- MUST contain the newly enrolled X.509 certificate
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be absent in case of local key generation or "rejection" -- MUST be absent in case of local key generation or "rejection"
-- MUST contain the encrypted private key in an EnvelopedData -- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in Section 4.1.6 in case the private -- structure as specified in Section 4.1.6 in case the
-- key was generated centrally -- private key was generated centrally
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
-- MUST contain the chain of the certificate present in -- MUST contain the chain of the certificate present in
-- certOrEncCert -- certOrEncCert
-- Duplicate certificates MAY be omitted -- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf Certificate Confirmation -- certConf
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The message of the EE sends as confirmation to the PKI -- The message of the EE sends a confirmation to the PKI
-- management entity to accept or reject the issued -- management entity to accept or reject the issued
-- certificates -- certificates
certConf REQUIRED certConf REQUIRED
-- MUST contain a sequence of one CertStatus -- MUST contain a sequence of one CertStatus
CertStatus REQUIRED CertStatus REQUIRED
certHash REQUIRED certHash REQUIRED
-- MUST be the hash value of the certificate.
-- The hash algorithm to use MUST be the hash algorithm indicated -- The hash algorithm to use MUST be the hash algorithm indicated
-- in the below hashAlg field. If the hashAlg field is not -- in the below hashAlg field. If the hashAlg field is not
-- set, it MUST be the hash algorithm defined by the algorithm -- set, it MUST be the hash algorithm defined by the algorithm
-- identifier of the certificate signature or the dedicated -- identifier of the certificate signature or the dedicated
-- hash algorithm defined in RFCBBBB for the used certificate -- hash algorithm defined in [RFC9481] for the used certificate
-- signature algorithm. -- signature algorithm.
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 -- MUST be 0
statusInfo OPTIONAL statusInfo OPTIONAL
-- PKIStatusInfo structure should be present -- PKIStatusInfo structure should be present
-- Omission indicates acceptance of the indicated certificate -- Omission indicates acceptance of the indicated certificate
status REQUIRED status REQUIRED
-- positive values allowed: "accepted" -- positive values allowed: "accepted"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging, or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if status is "rejection" -- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" -- MUST be absent if status is "accepted"
hashAlg OPTIONAL hashAlg OPTIONAL
-- The hash algorithm to use for calculating the above certHash -- The hash algorithm to use for calculating the above certHash
-- If used, the pvno field in the header MUST be cmp2021 (3). For -- If used, the pvno field in the header MUST be cmp2021 (3).
-- backward compatibility it is NOT RECOMMENDED to use this -- For backward compatibility, use of this field is
-- field, if the hash algorithm to use can be identified by -- NOT RECOMMENDED if the hash algorithm to use can be
-- other means, see above. -- identified by other means; see above.
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first request message -- MUST use the same credentials as in the first request message
-- of this PKI management operation -- of this PKI management operation
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- As described in Section 3.3 -- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI -- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from -- management entity caches the CMP protection certificate from
skipping to change at page 37, line 22 skipping to change at line 1680
-- response message of this PKI management operation -- response message of this PKI management operation
4.1.2. Enrolling an End Entity to a Known PKI 4.1.2. Enrolling an End Entity to a Known PKI
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
are as follows:
* 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
it requests another certificate from. it requests another certificate from.
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
1 The body of the first request and response SHOULD be cr and cp. 1. The body of the first request and response SHOULD be cr and cp.
Otherwise ir and ip MUST be used. Otherwise, ir and ip MUST be used.
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 MUST be 2. The caPubs field in the certificate response message MUST be
absent. absent.
4.1.3. Updating a Valid Certificate 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 CMP protection the certificate it wishes to update as the CMP protection
certificate. Both for authenticating itself and for proving certificate. Both for authenticating itself and for proving
ownership of the certificate to be updated, it signs the request ownership of the certificate to be updated, it signs the request
messages with the corresponding private key. messages with the corresponding private key.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4
are as follows:
* The certificate the EE wishes to update MUST NOT be expired or * The certificate the EE wishes to update MUST NOT be expired or
revoked and MUST have been issued by the addressed CA. revoked and MUST have been issued by the addressed CA.
* A new public-private key pair should be used. * A new public-private key pair should be used.
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
1 The body of the first request and response MUST be kur and kup, 1. The body of the first request and response MUST be kur and kup,
respectively. respectively.
2 Protection of the kur MUST be performed using the certificate to 2. Protection of the kur MUST be performed using the certificate to
be updated. be updated.
3 The subject field and/or the subjectAltName extension of the 3. The subject field and/or the subjectAltName extension of the
certTemplate MUST contain the EE subject name of the existing certTemplate MUST contain the EE subject name of the existing
certificate to be updated, without modifications. certificate to be updated, without modifications.
4 The certTemplate SHOULD contain the subject and/or subjectAltName 4. The certTemplate SHOULD contain the subject and/or subjectAltName
extension and publicKey of the EE only. extension and publicKey of the EE only.
5 The oldCertId control MAY be used to make clear which certificate 5. The oldCertId control MAY be used to make clear which certificate
is to be updated. is to be updated.
6 The caPubs field in the kup message MUST be absent. 6. The caPubs field in the kup message MUST be absent.
As part of the certReq structure of the kur the oldCertId control is As part of the certReq structure of the kur, the oldCertId control is
added after the certTemplate field. added after the certTemplate field.
controls controls
type RECOMMENDED type RECOMMENDED
-- MUST be the value id-regCtrl-oldCertID, if present -- MUST be the value id-regCtrl-oldCertID, if present
value value
issuer REQUIRED issuer REQUIRED
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the issuer and serialNumber of the certificate -- MUST contain the issuer and serialNumber of the certificate
-- to be updated -- to be updated
4.1.4. Enrolling an End Entity Using a PKCS#10 Request 4.1.4. Enrolling an End Entity Using a PKCS #10 Request
This PKI management operation can be used by an EE to request a This PKI management operation can be used by an EE to request a
certificate using PKCS#10 [RFC2986] format to interoperate with CAs certificate using the PKCS #10 [RFC2986] format to interoperate with
not supporting CRMF [RFC4211]. This offers a variation of the PKI CAs not supporting CRMF [RFC4211]. This offers a variation of the
management operations specified in Sections 4.1.1 to 4.1.3. PKI management operations specified in Sections 4.1.1 to 4.1.3.
In this PKI management operation, the public key and all further In this PKI management operation, the public key and all further
certificate template data MUST be contained in the subjectPKInfo and certificate template data MUST be contained in the subjectPKInfo and
other certificationRequestInfo fields of the PKCS#10 structure. other certificationRequestInfo fields of the PKCS #10 structure.
The prerequisites are the same as given in Section 4.1.2. The prerequisites are the same as given in Section 4.1.2.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Sections 4.1.1 to 4.1.3, with the following changes: to that given in Sections 4.1.1 to 4.1.3, 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.
Detailed Message Description: 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
-- certificate request -- certificate request
p10cr REQUIRED p10cr REQUIRED
certificationRequestInfo REQUIRED certificationRequestInfo REQUIRED
version REQUIRED version REQUIRED
-- MUST be 0 to indicate PKCS#10 V1.7 -- MUST be 0 to indicate PKCS #10 v1.7
subject REQUIRED subject REQUIRED
-- The EE subject name MUST be carried in the subject field -- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension. -- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName -- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN -- extension, then the subject field MUST be NULL-DN
subjectPKInfo REQUIRED subjectPKInfo REQUIRED
algorithm REQUIRED algorithm REQUIRED
-- MUST include the subject public key algorithm identifier -- MUST include the subject public key algorithm identifier
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST include the public key to be certified -- MUST include the public key to be certified
attributes OPTIONAL attributes OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the -- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name, -- requested certificate like subject alternative name,
-- key usage, and extended key usage -- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE -- The subjectAltName extension MUST be present if the EE
skipping to change at page 41, line 8 skipping to change at line 1823
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- 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. Using MAC-Based Protection for Enrollment 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
Sections 4.1.1, 4.1.2 and 4.1.4. It should be used by an EE to Sections 4.1.1, 4.1.2, and 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 MUST replace this protection according to based protection MUST replace this protection according to
Section 5.2.3 as the next hop may not know the shared secret Section 5.2.3, as the next hop may not know the shared secret
information. information.
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 MAC-based protection. Further level of protection when using MAC-based protection. Further
guidance is available in the security considerations of CMP updated guidance is available in the security considerations updated by CMP
by [I-D.ietf-lamps-cmp-updates]. Updates [RFC9480].
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4
are as follows:
* Rather than using private keys, certificates, and trust anchors, * Rather than using private keys, certificates, and trust anchors,
the EE and the PKI management entity MUST share secret the EE and the PKI management entity MUST share secret
information. information.
Note: The shared secret information MUST be established out-of- Note: The shared secret information MUST be established out of
band, e.g., by a service technician during initial local band, e.g., by a service technician during initial local
configuration. configuration.
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Sections 4.1.1, 4.1.2 and 4.1.4, with the following to that given in Sections 4.1.1, 4.1.2, and 4.1.4, with the following
changes: changes:
1 The protection of all messages MUST be MAC-based. Therefore, 1. The protection of all messages MUST be MAC-based. Therefore,
extraCerts fields of all messages do not contain CMP protection extraCerts fields of all messages do not contain CMP protection
certificates and associated chains. certificates and associated chains.
2 In case the sending entity does not know its own name by now, it 2. The sender field MUST contain a name the PKI management entity
MUST put the NULL-DN into the sender field. The senderKID MUST can use to identify the shared secret information used for
contain a reference the recipient can use to identify the shared message protection. This name MUST be placed in the commonName
secret information used for the protection, e.g., the username of field of the directoryName choice. The senderKID MUST contain
the EE. the same name as in the commonName field of the sender field. In
case the sending entity does not yet know for which name to
request the certificate, it can use this commonName in the
subject field of the certTemplate.
See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for See Section 6 of CMP Algorithms [RFC9481] for details on message
details on message authentication code algorithms (MSG_MAC_ALG) to authentication code algorithms (MSG_MAC_ALG) to use. Typically,
use. Typically, parameters are part of the protectionAlg field, parameters are part of the protectionAlg field, e.g., used for key
e.g., used for key derivation, like a salt and an iteration count. derivation, like a salt and an iteration count. Such parameters
Such parameters should remain constant for message protection should remain constant for message protection throughout this PKI
throughout this PKI management operation to reduce the computational management operation to reduce the computational overhead.
overhead.
4.1.6. Adding Central Key Pair Generation to Enrollment 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 Sections 4.1.1 to 4.1.4 and the variant described in Section 4.1.5.
Section 4.1.5. It needs to be used in case an EE is not able to It needs to be used in case an EE is not able to generate its new
generate its new public-private key pair itself or central generation public-private key pair itself or central generation of the EE key
of the EE key material is preferred. It is a matter of the local material is preferred. Which PKI management entity will act as Key
implementation which PKI management entity will act as Key Generation Generation Authority (KGA) and perform the key generation is a matter
Authority (KGA) and performs the key generation. This PKI management of the local implementation. This PKI management entity MUST use a
entity MUST use a certificate containing the additional extended key certificate containing the additional extended key usage extension
usage extension id-kp-cmKGA in order to be accepted by the EE as a id-kp-cmKGA in order to be accepted by the EE as a legitimate key
legitimate key generation authority. generation authority.
Note: As described in Section 5.3.1, the KGA can use the PKI Note: As described in Section 5.3.1, the KGA can use the PKI
management operation described in Section 4.1.2 to request the management operation described in Section 4.1.2 to request the
certificate for this key pair on behalf of the EE. certificate for this key pair on behalf of the EE.
When an EE requests central key generation for a certificate update When an EE requests central key generation for a certificate update
using a kur message, the KGA cannot use a kur message to request the using a kur message, the KGA cannot use a kur message to request the
certificate on behalf of the EE as the old EE credential is not certificate on behalf of the EE, as the old EE credential is not
available to the KGA for protecting this message. Therefore, if the available to the KGA for protecting this message. Therefore, if the
EE uses the PKI management operation described in Section 4.1.3, the EE uses the PKI management operation described in Section 4.1.3, the
KGA MUST act as described in Section 4.1.2 to request the certificate KGA MUST act as described in Section 4.1.2 to request the certificate
for the newly generated key pair on behalf of the EE from the CA. for the newly generated key pair on behalf of the EE from the CA.
Generally speaking, it is strongly preferable to generate public- Generally speaking, it is strongly preferable to generate public-
private key pairs locally at the EE. This is advisable to make sure private key pairs locally at the EE. This is advisable to make sure
that the entity identified in the newly issued certificate is the that the entity identified in the newly issued certificate is the
only entity that knows the private key. only entity that knows the private key.
Reasons for central key generation may include the following: Reasons for central key generation may include the following:
* Lack of sufficient initial entropy. * lack of sufficient initial entropy
Note: Good random numbers are needed not only for key generation Note: Good random numbers are not only needed for key generation
but also for session keys and nonces in any security protocol. but also for session keys and nonces in any security protocol.
Therefore, a decent security architecture should anyways support Therefore, a decent security architecture should anyways support
good random number generation on the EE side or provide enough good random number generation on the EE side or provide enough
initial entropy for the RNG seed to guarantee good pseudo-random initial entropy for the random number generator seed to guarantee
number generation. Yet maybe this is not the case at the time of good pseudorandom number generation. Yet maybe this is not the
requesting an initial certificate during manufacturing. case at the time of requesting an initial certificate during
manufacturing.
* Lack of computational resources, in particular for RSA key * lack of computational resources, in particular, for RSA key
generation. generation
Note: Since key generation could be performed in advance to the Note: Since key generation could be performed in advance to the
certificate enrollment communication, it is often not time certificate enrollment communication, it is often not time
critical. critical.
Note: As mentioned in Section 2, central key generation may be Note: As mentioned in Section 2, central key generation may be
required in a push model, where the certificate response message is required in a push model, where the certificate response message is
transferred by the PKI management entity to the EE without a previous transferred by the PKI management entity to the EE without a previous
request message. request message.
The EE requesting central key generation MUST omit the publicKey The EE requesting central key generation MUST omit the publicKey
field from the certTemplate or, in case it has a preference on the field from the certTemplate or, in case it has a preference on the
key type to be generated, provide this preference in the algorithm key type to be generated, provide this preference in the algorithm
sub-field and fill the subjectPublicKey sub-field with a zero-length sub-field and fill the subjectPublicKey sub-field with a zero-length
BIT STRING. Both variants indicate to the PKI management entity that BIT STRING. Both variants indicate to the PKI management entity that
a new key pair shall be generated centrally on behalf of the EE. a new key pair shall be generated centrally on behalf of the EE.
Note: As the protection of centrally generated keys in the response Note: As the protection of centrally generated keys in the response
message has been extended to EncryptedKey by CMP Updates Section 2.7 message has been extended to EncryptedKey by Section 2.7 of CMP
[I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred Updates [RFC9480], EnvelopedData is the preferred alternative to
alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the EncryptedValue. In CRMF [RFC4211], Section 2.1, point 9, the use of
use of EncryptedValue has been deprecated in favor of the EncryptedValue has been deprecated in favor of the EnvelopedData
EnvelopedData structure. Therefore, this profile requires using structure. Therefore, this profile requires using EnvelopedData, as
EnvelopedData as specified in CMS Section 6 [RFC5652]. When specified in Section 6 of CMS [RFC5652]. When EnvelopedData is to be
EnvelopedData is to be used in a PKI management operation, CMP v3 used in a PKI management operation, CMP v3 MUST be indicated in the
MUST be indicated in the message header already for the initial message header already for the initial request message; see
request message, see CMP Updates Section 2.20 Section 2.20 of CMP Updates [RFC9480].
[I-D.ietf-lamps-cmp-updates].
+----------------------------------+ +----------------------------------+
| EnvelopedData | | EnvelopedData |
| [RFC5652] Section 6 | | [RFC5652], Section 6 |
| +------------------------------+ | | +------------------------------+ |
| | SignedData | | | | SignedData | |
| | [RFC5652] Section 5 | | | | [RFC5652], Section 5 | |
| | +--------------------------+ | | | | +--------------------------+ | |
| | | AsymmetricKeyPackage | | | | | | AsymmetricKeyPackage | | |
| | | [RFC5958] | | | | | | [RFC5958] | | |
| | | +----------------------+ | | | | | | +----------------------+ | | |
| | | | private key | | | | | | | | private key | | | |
| | | +----------------------+ | | | | | | +----------------------+ | | |
| | +--------------------------+ | | | | +--------------------------+ | |
| +------------------------------+ | | +------------------------------+ |
+----------------------------------+ +----------------------------------+
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 [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 Section 5 of CMS [RFC5652] and [RFC8933],
signed by the KGA generating the key pair. The signature MUST be and signed by the KGA generating the key pair. The signature MUST be
performed using a private key related to a certificate asserting the performed using a private key related to a certificate asserting the
extended key usage id-kp-cmKGA as described in CMP Updates extended key usage id-kp-cmKGA, as described in Section 2.2 of CMP
Section 2.2 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization Updates [RFC9480], to demonstrate authorization to generate key pairs
to generate key pairs on behalf of an EE. For response messages on behalf of an EE. For response messages using signature-based
using signature-based protection, the EE MUST validate the signer protection, the EE MUST validate the signer certificate contained in
certificate contained in the SignedData structure and SHOULD the SignedData structure and SHOULD authorize the KGA considering any
authorize the KGA considering any given id-kp-cmKGA extended key given id-kp-cmKGA extended key usage in the signer certificate. For
usage in the signer certificate. For response messages using MAC- response messages using MAC-based protection, the EE MAY omit the
based protection the EE MAY omit the validation as it may not be validation as it may not be possible or meaningful to the EE. In
possible or meaningful to the EE. In this case the EE authorizes the this case, the EE authorizes the KGA using the shard secret
KGA using the shard secret information. information.
The SignedData structure MUST be wrapped in an EnvelopedData The SignedData structure MUST be wrapped in an EnvelopedData
structure, as specified in CMS Section 6 [RFC5652], encrypting it structure, as specified in Section 6 of CMS [RFC5652], encrypting it
using a newly generated symmetric content-encryption key. using a newly generated symmetric content-encryption key.
This content-encryption key MUST be securely provided as part of the This content-encryption key MUST be securely provided as part of the
EnvelopedData structure to the EE using one of three key management EnvelopedData structure to the EE using one of three key management
techniques. The choice of the key management technique to be used by techniques. The choice of the key management technique to be used by
the PKI management entity depends on the authentication mechanism the the PKI management entity depends on the authentication mechanism the
EE chose to protect the request message. See CMP Updates Section 2.7 EE chose to protect the request message. See Section 2.7 of CMP
[I-D.ietf-lamps-cmp-updates] for details on which key management Updates [RFC9480] for details on which key management technique to
technique to use. use.
* Signature-based protection of the request message: * Signature-based protection of the request message:
In this case the choice depends on the type of the public key in In this case, the choice depends on the type of public key in the
the CMP protection certificate used by the EE in its request. CMP protection certificate used by the EE in its request.
- The content-encryption key SHALL be protected using the key - The content-encryption key SHALL be protected using the key
transport key management technique, see Section 4.1.6.1, if the transport key management technique (see Section 4.1.6.1) if the
key type supports this. key type supports this.
- The content-encryption key SHALL be protected using the key - The content-encryption key SHALL be protected using the key
agreement key management technique, see Section 4.1.6.2, if the agreement key management technique (see Section 4.1.6.2) if the
key type supports this. key type supports this.
* MAC-based protected of the request message: * MAC-based protection of the request message:
- The content-encryption key SHALL be protected using the - The content-encryption key SHALL be protected using the
password-based key management technique, see Section 4.1.6.3, password-based key management technique (see Section 4.1.6.3)
if and only if the EE used MAC-based protection for the request if and only if the EE used MAC-based protection for the request
message. message.
Specific prerequisites augmenting those of the respective certificate Specific prerequisites augmenting those of the respective certificate
enrollment PKI management operations: enrollment PKI management operations are as follows:
* If signature-based protection is used, the EE MUST be able to * If signature-based protection is used, the EE MUST be able to
authenticate and authorize the KGA, using suitable information, authenticate and authorize the KGA using suitable information,
which includes a trust anchor. which includes a trust anchor.
* If MAC-based protection is used, the KGA MUST also know the shared * If MAC-based protection is used, the KGA MUST also know the shared
secret information to protect the encrypted transport of the newly secret information to protect the encrypted transport of the newly
generated key pair. Consequently, the EE can also authorize the generated key pair. Consequently, the EE can also authorize the
KGA. KGA.
* The PKI management entity MUST have a certificate containing the * The PKI management entity MUST have a certificate containing the
additional extended key usage extension id-kp-cmKGA for signing additional extended key usage extension id-kp-cmKGA for signing
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-
key to be used by the symmetric encryption algorithm MUST be encryption key to be used by the symmetric encryption algorithm
generated with sufficient entropy. MUST be 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.
Detailed Description of privateKey Field: Detailed Description of the privateKey Field:
privateKey REQUIRED privateKey REQUIRED
-- MUST be an EnvelopedData structure as specified in CMS -- MUST be an EnvelopedData structure, as specified in
-- Section 6 [RFC5652] -- Section 6 of CMS [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 a sequence of one RecipientInfo, which MUST be -- MUST contain a sequence of one RecipientInfo, which MUST be
-- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), -- ktri of type KeyTransRecipientInfo (see Section 4.1.6.1),
-- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or -- kari of type KeyAgreeRecipientInfo (see Section 4.1.6.2), or
-- pwri of type PasswordRecipientInfo (see section 4.1.6.3) -- pwri of type PasswordRecipientInfo (see Section 4.1.6.3)
encryptedContentInfo encryptedContentInfo
REQUIRED REQUIRED
contentType REQUIRED contentType REQUIRED
-- MUST be id-signedData -- MUST be id-signedData
contentEncryptionAlgorithm contentEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the algorithm used for -- MUST be the algorithm identifier of the algorithm used for
-- content encryption -- content encryption
-- The algorithm type MUST be a PROT_SYM_ALG as specified in -- The algorithm type MUST be PROT_SYM_ALG as specified in
-- RFCBBBB Section 5 -- [RFC9481], Section 5
encryptedContent REQUIRED encryptedContent REQUIRED
-- MUST be the SignedData structure as specified in CMS -- MUST be the SignedData structure, as specified in Section 5
-- Section 5 [RFC5652] and [RFC8933] in encrypted form -- of CMS [RFC5652] and [RFC8933], in encrypted form
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
digestAlgorithms digestAlgorithms
REQUIRED REQUIRED
-- MUST contain a sequence of one AlgorithmIdentifier element -- MUST contain a sequence of one AlgorithmIdentifier element
-- MUST be the algorithm identifier of the digest algorithm -- MUST be the algorithm identifier of the digest algorithm
-- used for generating the signature and match the signature -- used for generating the signature and match the signature
-- algorithm specified in signatureAlgorithm, see [RFC8933] -- algorithm specified in signatureAlgorithm; see [RFC8933]
encapContentInfo encapContentInfo
REQUIRED REQUIRED
-- MUST contain the content that is to be signed -- MUST contain the content that is to be signed
eContentType REQUIRED eContentType REQUIRED
-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
eContent REQUIRED eContent REQUIRED
-- MUST be of type AsymmetricKeyPackage and -- MUST be of type AsymmetricKeyPackage and
-- MUST contain a sequence of one OneAsymmetricKey element -- MUST contain a sequence of one OneAsymmetricKey element
version REQUIRED version REQUIRED
-- MUST be 1 (indicating v2) -- MUST be 1 (indicating v2)
skipping to change at page 47, line 34 skipping to change at line 2124
digestAlgorithm digestAlgorithm
REQUIRED REQUIRED
-- MUST be the same as in the digestAlgorithms field of -- MUST be the same as in the digestAlgorithms field of
-- encryptedContent -- encryptedContent
signedAttrs REQUIRED signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the value -- MUST contain an id-contentType attribute containing the value
-- id-ct-KP-aKeyPackage -- id-ct-KP-aKeyPackage
-- MUST contain an id-messageDigest attribute containing the -- MUST contain an id-messageDigest attribute containing the
-- message digest of eContent -- message digest of eContent
-- MAY contain an id-signingTime attribute containing the time -- MAY contain an id-signingTime attribute containing the time
-- of signature. It SHOULD be omitted if the transactionTime -- of a signature. It SHOULD be omitted if the transactionTime
-- field is not present in the PKIHeader. -- field is not present in the PKIHeader.
-- For details on the signed attributes see CMS Section 5.3 and -- For details on the signed attributes, see Sections 5.3 and
-- Section 11 [RFC5652] and [RFC8933] -- 11 of CMS [RFC5652] and [RFC8933]
signatureAlgorithm signatureAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the signature algorithm -- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits -- used for calculation of the signature bits
-- The signature algorithm type MUST be a MSG_SIG_ALG as -- The signature algorithm type MUST be MSG_SIG_ALG, as
-- specified in RFCBBBB Section 3 and MUST be consistent -- specified in [RFC9481], 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
As stated in Section 1.5, all fields of the ASN.1 syntax that are As stated in Section 1.8, all fields of the ASN.1 syntax that are
defined in RFC 5652 [RFC5652] but are not explicitly specified here defined in [RFC5652] but are not explicitly specified here SHOULD NOT
SHOULD NOT be used. be used.
4.1.6.1. Using Key Transport Key Management Technique 4.1.6.1. Using the Key Transport Key Management Technique
This variant can be applied in combination with the PKI management This variant can be applied in combination with the PKI management
operations specified in Section 4.1.1 to Section 4.1.3 using operations specified in Sections 4.1.1 to 4.1.3 using signature-based
signature-based protection of CMP messages. The EE certificate used protection of CMP messages. The EE certificate used for the
for the signature-based protection of the request message MUST signature-based protection of the request message MUST contain a
contain a public key supporting key transport and allow for the key public key supporting key transport and allow for the key usage
usage "keyEncipherment". The related key pair MUST be used for "keyEncipherment". The related key pair MUST be used for
encipherment of the content-encryption key. For this key management encipherment of the content-encryption key. For this key management
technique, the KeyTransRecipientInfo structure MUST be used in the technique, the KeyTransRecipientInfo structure MUST be used in the
contentInfo field. contentInfo 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 Section 6.2.1 of CMS [RFC5652].
Detailed Description of KeyTransRecipientInfo Structure: Detailed Description of the KeyTransRecipientInfo Structure:
ktri REQUIRED ktri REQUIRED
-- MUST be a KeyTransRecipientInfo as specified in CMS -- MUST be KeyTransRecipientInfo as specified in Section 6.2.1
-- Section 6.2.1 [RFC5652] -- of CMS [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 2 -- MUST be 2
rid REQUIRED rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection -- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice and the -- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the -- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader. -- PKIHeader.
-- If the CMP protection certificate does not contain a -- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST -- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used. -- be used.
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key transport -- MUST be the algorithm identifier of the key transport
-- algorithm. The algorithm type MUST be a KM_KT_ALG as -- algorithm. The algorithm type MUST be KM_KT_ALG as
-- specified in RFCBBBB Section 4.2 -- specified in [RFC9481], Section 4.2
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
4.1.6.2. Using Key Agreement Key Management Technique 4.1.6.2. Using the 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 Sections 4.1.1 to 4.1.3, using signature-
signature-based protection of CMP messages. The EE certificate used based protection of CMP messages. The EE certificate used for the
for the signature-based protection of the request message MUST signature-based protection of the request message MUST contain a
contain a public key supporting key agreement and allow for the key public key supporting key agreement and allow for the key usage
usage "keyAgreement". The related key pair MUST be used for "keyAgreement". The related key pair MUST be used for establishment
establishment of the content-encryption key. For this key management of the content-encryption key. For this key management technique,
technique the KeyAgreeRecipientInfo structure MUST be used in the the KeyAgreeRecipientInfo structure MUST be used in the contentInfo
contentInfo field. 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 Section 6.2.2 of CMS [RFC5652].
Detailed Description of KeyAgreeRecipientInfo Structure: Detailed Description of the KeyAgreeRecipientInfo Structure:
kari REQUIRED kari REQUIRED
-- MUST be a KeyAgreeRecipientInfo as specified in CMS Section -- MUST be KeyAgreeRecipientInfo as specified in Section
-- 6.2.2 [RFC5652] -- 6.2.2 of CMS [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
originator REQUIRED originator REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection -- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the subjectKeyIdentifier -- certificate, if available, in the subjectKeyIdentifier
-- choice and the subjectKeyIdentifier MUST equal the senderKID -- choice, and the subjectKeyIdentifier MUST equal the
-- in the PKIHeader. -- senderKID in the PKIHeader.
-- If the CMP protection certificate does not contain a -- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST -- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used. -- be used.
ukm RECOMMENDED ukm RECOMMENDED
-- MUST be used when 1-pass ECMQV is used, see [RFC5753] -- MUST be used when 1-Pass Elliptic Curve Menezes-Qu-Vanstone
-- (ECMQV) is used; see [RFC5753]
-- SHOULD be present to ensure uniqueness of the key -- SHOULD be present to ensure uniqueness of the key
-- encryption key -- encryption key
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key agreement -- MUST be the algorithm identifier of the key agreement
-- algorithm -- algorithm
-- The algorithm type MUST be a KM_KA_ALG as specified in -- The algorithm type MUST be KM_KA_ALG as specified in
-- RFCBBBB Section 4.1 -- [RFC9481], Section 4.1
-- The parameters field of the key agreement algorithm MUST -- The parameters field of the key agreement algorithm MUST
-- contain the key wrap algorithm. The algorithm type -- contain the key wrap algorithm. The algorithm type
-- MUST be a KM_KW_ALG as specified in RFCBBBB Section 4.3 -- MUST be KM_KW_ALG as specified in [RFC9481], Section 4.3
recipientEncryptedKeys recipientEncryptedKeys
REQUIRED REQUIRED
-- MUST contain a sequence of one RecipientEncryptedKey -- MUST contain a sequence of one RecipientEncryptedKey
rid REQUIRED rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection -- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice and the -- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the -- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader. -- PKIHeader.
-- If the CMP protection certificate does not contain a -- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST -- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used -- be used
encryptedKey encryptedKey
REQUIRED 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 the 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 Section 6.2.4 of CMS [RFC5652].
Detailed Description of PasswordRecipientInfo Structure: Detailed Description of the PasswordRecipientInfo Structure:
pwri REQUIRED pwri REQUIRED
-- MUST be a PasswordRecipientInfo as specified in CMS -- MUST be PasswordRecipientInfo as specified in
-- Section 6.2.4 [RFC5652] -- Section 6.2.4 of CMS [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 KM_KD_ALG as specified in
-- RFCBBBB Section 4.4 -- [RFC9481], 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 KM_KW_ALG as specified in
-- RFCBBBB Section 4.3 -- [RFC9481], 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 revoking a certificate of its own at the CA that An EE requests revoking a certificate of its own 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.3 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: The specific prerequisite augmenting the prerequisites in Section 3.4
is as follows:
* 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
skipping to change at page 52, line 14 skipping to change at line 2346
certDetails REQUIRED certDetails REQUIRED
-- MUST be present and is of type CertTemplate -- MUST be present and is of type CertTemplate
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the certificate serialNumber attribute of the -- MUST contain the certificate serialNumber attribute of the
-- certificate to be revoked -- certificate to be revoked
issuer REQUIRED issuer REQUIRED
-- MUST contain the issuer attribute of the certificate to be -- MUST contain the issuer attribute of the certificate to be
-- revoked -- revoked
crlEntryDetails REQUIRED crlEntryDetails REQUIRED
-- MUST contain a sequence of one reasonCode of type CRLReason -- MUST contain a sequence of one reasonCode of type CRLReason
-- (see [RFC5280] section 5.3.1) -- (see [RFC5280], Section 5.3.1)
-- If the reason for this revocation is not known or shall not -- If the reason for this revocation is not known or shall not
-- be published the reasonCode MUST be 0 (unspecified) -- be published, the reasonCode MUST be 0 (unspecified)
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 and using the private key related -- As described in Section 3.2 and using the private key related
-- to the certificate to be revoked -- to the certificate to be revoked
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
Revocation Response -- rp Revocation Response -- rp
Field Value Field Value
header header
-- As described in Section 3.1 -- As described in Section 3.1
body body
-- The responds of the PKI management entity to the request as -- The response of the PKI management entity to the request as
-- appropriate -- appropriate
rp REQUIRED rp REQUIRED
status REQUIRED status REQUIRED
-- MUST contain a sequence of one element of type PKIStatusInfo -- MUST contain a sequence of one element of type PKIStatusInfo
status REQUIRED status REQUIRED
-- positive value allowed: "accepted" -- positive value allowed: "accepted"
-- negative value allowed: "rejection" -- negative value allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if status is "rejection" -- MAY be present if the 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.4). 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 [RFC4210] and CMP Updates [RFC9480], further OIDs MAY be
[I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new used to define new PKI management operations or new general-purpose
PKI management operations or new general-purpose support messages as 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 Certificate Revocation Lists (CRLs).
The following message flow and contents are common to all general The following message flow and contents are common to all general
message (genm) and general response (genp) messages. message (genm) and general response (genp) messages.
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
skipping to change at page 55, line 5 skipping to change at line 2478
-- 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 a
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.14 caCerts, as specified in Section 2.14 of CMP Updates [RFC9480]. The
[I-D.ietf-lamps-cmp-updates]. The PKI management entity responds PKI management entity responds with a general response with the same
with a general response with the same OID that either contains a OID that either contains a SEQUENCE of certificates populated with
SEQUENCE of certificates populated with the available intermediate the available intermediate and issuing CA certificates or no content
and issuing CA certificates or with no content in case no CA in case no CA certificate is available.
certificate is available.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 3.4. Section 3.4.
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-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
Detailed Description of infoValue Field of genp: Detailed Description of the infoValue Field of genp:
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
-- if present, MUST be a sequence of CMPCertificate -- if present, 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 [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. If needed for unique identification, the EE MUST include rootCaCert. If needed for unique identification, the EE MUST include
the old root CA certificate in the message body, as specified in CMP the old root CA certificate in the message body as specified in
Updates Section 2.15 [I-D.ietf-lamps-cmp-updates]. The PKI Section 2.15 of CMP Updates [RFC9480]. The PKI management entity
management entity responds with a general response with OID id-it- responds with a general response with OID id-it-rootCaKeyUpdate that
rootCaKeyUpdate that either contains the update of the root CA either contains the update of the root CA certificate consisting of
certificate consisting of up to three certificates, or with no up to three certificates or no content in case no update is
content in case no update is available. available.
Note: This mechanism may also be used to update trusted non-root Note: This mechanism may also be used to update trusted non-root
certificates, i.e., directly trusted intermediate CA or issuing CA certificates, e.g., directly trusted intermediate or issuing CA
certificates. certificates.
The newWithNew certificate is the new root CA certificate and is The newWithNew certificate is the new root CA certificate and is
REQUIRED to be present if available. The newWithOld certificate is REQUIRED to be present if available. The newWithOld certificate is
REQUIRED to be present in the response message because it is needed REQUIRED to be present in the response message because it is needed
for the receiving entity trusting the old root CA certificate to gain for the receiving entity trusting the old root CA certificate to gain
trust in the new root CA certificate. The oldWithNew certificate is trust in the new root CA certificate. The oldWithNew certificate is
OPTIONAL because it is only needed in rare scenarios where other OPTIONAL because it is only needed in rare scenarios where other
entities may not already trust the old root CA. entities may not already trust the old root CA.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 3.4. Section 3.4.
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-rootCaCert in the request and id- 1. the infoType OID to use is id-it-rootCaCert in the request and
it-rootCaKeyUpdate in the response id-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
Detailed Description of infoValue Field of genm: Detailed Description of the infoValue Field of genm:
infoValue RECOMMENDED infoValue RECOMMENDED
-- MUST contain the root CA certificate to be updated if needed -- MUST contain the root CA certificate to be updated if needed
-- for unique identification -- for unique identification
Detailed Description of infoValue Field of genp: Detailed Description of the infoValue Field of genp:
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
skipping to change at page 57, line 12 skipping to change at line 2580
-- 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.16 [I-D.ietf-lamps-cmp-updates]. specified in Section 2.16 of CMP Updates [RFC9480]. The EE MAY
The EE MAY indicate the certificate profile to use in the id-it- indicate the certificate profile to use in the id-it-certProfile
certProfile extension of the generalInfo field in the PKIHeader of extension of the generalInfo field in the PKIHeader of the general
the general message as described in Section 3.1. The PKI management message as described in Section 3.1. The PKI management entity
entity responds with a general response with the same OID that either responds with a general response with the same OID that either
contains requirements on the certificate request template, or with no contains requirements on the certificate request template or no
content in case no specific requirements are imposed by the PKI. The content in case no specific requirements are imposed by the PKI. The
CertReqTemplateValue contains requirements on certificate fields and CertReqTemplateValue contains requirements on certificate fields and
extensions in a certTemplate. Optionally it contains a keySpec field extensions in a certTemplate. Optionally, it contains a keySpec
containing requirements on algorithms acceptable for key pair field containing requirements on algorithms acceptable for key pair
generation. generation.
The EE SHOULD follow the requirements from the received CertTemplate, The EE SHOULD follow the requirements from the received CertTemplate
by including in the certificate requests all the fields requested, by including in the certificate requests all the fields requested,
taking over all the field values provided and filling in any taking over all the field values provided and filling in any
remaining fields values. The EE SHOULD NOT add further fields, name remaining fields values. The EE SHOULD NOT add further fields, name
components, and extensions or their (sub-)components. If deviating components, and extensions or their (sub)components. If deviating
from the recommendations of the template, the certificate request from the recommendations of the template, the certificate request
might be rejected. might be rejected.
Note: We deliberately do not use "MUST" or "MUST NOT" here in order Note: We deliberately do not use "MUST" or "MUST NOT" here in order
to allow more flexibility in case the rules given here are not to allow more flexibility in case the rules given here are not
sufficient for specific scenarios. The EE can populate the sufficient for specific scenarios. The EE can populate the
certificate request as wanted and ignore any of the requirements certificate request as wanted and ignore any of the requirements
contained in the CertReqTemplateValue. On the other hand, a PKI contained in the CertReqTemplateValue. On the other hand, a PKI
management entity is free to ignore or replace any parts of the management entity is free to ignore or replace any parts of the
content of the certificate request provided by the EE. The content of the certificate request provided by the EE. The
CertReqTemplate PKI management operation offers means to ease a joint CertReqTemplate PKI management operation offers means to ease a joint
understanding which fields and/or which field values should be used. understanding of which fields and/or which field values should be
An example is provided in Appendix A. used. An example is provided in Appendix A.
In case a field of type Name, e.g., subject, is present in the In case a field of type Name, e.g., subject, is present in the
CertTemplate but has the value NULL-DN (i.e., has an empty list of CertTemplate but has the value NULL-DN (i.e., has an empty list of
RDN components), the field SHOULD be included in the certificate relative distinguished name (RDN) components), the field SHOULD be
request and filled with content provided by the EE. Similarly, in included in the certificate request and filled with content provided
case an X.509v3 extension is present but its extnValue is empty, this by the EE. Similarly, in case an X.509v3 extension is present but
means that the extension SHOULD be included and filled with content its extnValue is empty, this means that the extension SHOULD be
provided by the EE. In case a Name component, for instance a common included and filled with content provided by the EE. In case a Name
name or serial number, is given but has an empty string value, the EE component, for instance, a common name or serial number, is given but
SHOULD fill in a value. Similarly, in case an extension has sub- has an empty string value, the EE SHOULD fill in a value. Similarly,
components (e.g., an IP address in a SubjectAltName field) with empty in case an extension has subcomponents (e.g., an IP address in a
value, the EE SHOULD fill in a value. SubjectAltName field) with empty values, the EE SHOULD fill in a
value.
The EE MUST ignore (i.e., not include and fill in) empty fields, The EE MUST ignore (i.e., not include) empty fields, extensions, and
extensions, and sub-components that it does not understand or does subcomponents that it does not understand or does not know suitable
not know suitable values to be filled in. values to fill in.
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate The publicKey field of type SubjectPublicKeyInfo in the CertTemplate
of the CertReqTemplateValue MUST be omitted. In case the PKI of the CertReqTemplateValue MUST be omitted. In case the PKI
management entity wishes to make stipulation on algorithms the EE may management entity wishes to make a stipulation on algorithms the EE
use for key generation, this MUST be specified using the keySpec may use for key generation, this MUST be specified using the keySpec
field as specified in CMP Updates Section 2.16 field as specified in Section 2.16 of CMP Updates [RFC9480].
[I-D.ietf-lamps-cmp-updates].
The keySpec field, if present, specifies the public key types The keySpec field, if present, specifies the public key types
optionally with parameters, and/or RSA key lengths for which a optionally with parameters and/or RSA key lengths for which a
certificate may be requested. certificate may be requested.
The value of a keySpec element with the OID id-regCtrl-algId, as The value of a keySpec element with the OID id-regCtrl-algId, as
specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates], specified in Section 2.16 of CMP Updates [RFC9480], MUST be of type
MUST be of type AlgorithmIdentifier and give an algorithm other than AlgorithmIdentifier and give an algorithm other than RSA. For
RSA. For EC keys the curve information MUST be specified as Elliptic Curve (EC) keys, the curve information MUST be specified as
described in the respective standard documents. described in the respective standard documents.
The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as
specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates], specified in Section 2.16 of CMP Updates [RFC9480], MUST be a
MUST be a positive integer value and give an RSA key length. positive integer value and give an RSA key length.
In the CertTemplate of the CertReqTemplateValue the serialNumber, In the CertTemplate of the CertReqTemplateValue, the serialNumber,
signingAlg, issuerUID, and subjectUID fields MUST be omitted. signingAlg, issuerUID, and subjectUID fields MUST be omitted.
Specific prerequisites augmenting the prerequisites in Section 3.4: The specific prerequisites augmenting the prerequisites in
Section 3.4 is as follows:
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-certReqTemplate 1. the infoType OID to use is id-it-certReqTemplate
2 the 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
Detailed Description of infoValue Field of genp: Detailed Description of the infoValue Field of genp:
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
skipping to change at page 59, line 40 skipping to change at line 2695
-- 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 a sequence of one AttributeTypeAndValue per -- MUST contain a sequence of one AttributeTypeAndValue per
-- supported algorithm with attribute id-regCtrl-algId or -- supported 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 into
specified in RFC 5280 [RFC5280] into the issued certificates. In the issued certificates as specified in [RFC5280]. In addition, CMP
addition, CMP offers CRL provisioning functionality as part of the offers CRL provisioning functionality as part of the PKI management
PKI management operation. 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
the CRL source identifying the requested CRL and, if available, the the CRL source identifying the requested CRL and, if available, the
thisUpdate time of the most current CRL instance it already has, as thisUpdate time of the most current CRL instance it already has, as
specified in CMP Updates Section 2.17 [I-D.ietf-lamps-cmp-updates]. specified in Section 2.17 of CMP Updates [RFC9480]. The PKI
The PKI management entity MUST respond with a general response with management entity MUST respond with a general response with OID id-
OID id-it-crls. it-crls.
The EE MUST identify the requested CRL either by a CRL distribution The EE MUST identify the requested CRL either by a CRL distribution
point name or issuer name. point name or issuer name.
Note: CRL distribution point names can be obtained from a Note: CRL distribution point names can be obtained from a
cRLDistributionPoints extension of a certificate to be validated or cRLDistributionPoints extension of a certificate to be validated or
from an issuingDistributionPoint extension of the CRL to be updated. from an issuingDistributionPoint extension of the CRL to be updated.
CRL issuer names can be obtained from the cRLDistributionPoints CRL issuer names can be obtained from the cRLDistributionPoints
extension of a certificate, from the issuer field of the authority extension of a certificate, from the issuer field of the authority
key identifier extension of a certificate or CRL, and from the issuer key identifier extension of a certificate or CRL, and from the issuer
field of a certificate or CRL. field of a certificate or CRL.
If a thisUpdate value was given, the PKI management entity MUST If a thisUpdate value was given, the PKI management entity MUST
return the latest CRL available from the referenced source if this return the latest CRL available from the referenced source if this
CRL is more recent than the given thisUpdate time. If no thisUpdate CRL is more recent than the given thisUpdate time. If no thisUpdate
value was given, it MUST return the latest CRL available from the value was given, it MUST return the latest CRL available from the
referenced source. In all other cases the infoValue in the response referenced source. In all other cases, the infoValue in the response
message MUST be absent. message MUST be absent.
The PKI management entity should treat a CRL distribution point name The PKI management entity should treat a CRL distribution point name
as an internal pointer to identify a CRL that is directly available as an internal pointer to identify a CRL that is directly available
at the PKI management entity. It is not intended as a way to fetch at the PKI management entity. It is not intended as a way to fetch
an arbitrary CRL from an external location, as this location may be an arbitrary CRL from an external location, as this location may be
unavailable to that PKI management entity. unavailable to that PKI management entity.
In addition to the prerequisites specified in Section 3.4, the EE In addition to the prerequisites specified in Section 3.4, the EE
MUST know which CRL to request. MUST know which CRL to request.
Note: If the EE does not want to request a specific CRL it MAY use Note: If the EE does not want to request a specific CRL, it MAY
instead a general message with OID id-it-currentCrl as specified in instead use a general message with OID id-it-currentCrl as specified
RFC 4210 Section 5.3.19.6 [RFC4210]. in Section 5.3.19.6 of [RFC4210].
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-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
sequence of one CRLStatus structure sequence of one CRLStatus structure
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 one CRL of one CRL
Detailed Description of infoValue Field of genm: Detailed Description of the infoValue Field of genm:
infoValue REQUIRED infoValue REQUIRED
-- MUST contain a sequence of one CRLStatus element -- MUST contain a sequence of one CRLStatus element
source REQUIRED source REQUIRED
-- 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
-- MUST contain the thisUpdate field of the latest CRL the EE -- MUST contain the thisUpdate field of the latest CRL the EE
-- has got from the issuer specified in the given dpn or -- has gotten from the issuer specified in the given dpn or
-- issuer field -- issuer field
-- MUST be omitted if the EE does not have any instance of the -- MUST be omitted if the EE does not have any instance of the
-- requested CRL -- requested CRL
Detailed Description of infoValue Field of genp: Detailed Description of the infoValue Field of genp:
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 a sequence of one CRL update from the referenced -- MUST contain a sequence of one CRL update from the referenced
-- source, if a thisUpdate value was not given or a more recent -- source if a thisUpdate value was not given or a more recent
-- CRL is available -- CRL is 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 Section 5.3.22 of [RFC4210] and updated by [RFC9480].
[I-D.ietf-lamps-cmp-updates].
Depending on the PKI architecture, the entity initiating delayed Depending on the PKI architecture, the entity initiating delayed
delivery is not necessarily the PKI management entity directly delivery is not necessarily the PKI management entity directly
addressed by the EE. addressed by the EE.
When initiating delayed delivery of a message received from an EE, When initiating delayed delivery of a message received from an EE,
the PKI management entity MUST respond with a message including the the PKI management entity MUST respond with a message including the
status "waiting". In response to an ir/cr/kur/p10cr message it must status "waiting". In response to an ir/cr/kur/p10cr message, it must
place the status "waiting" in an ip/cp/kup message, otherwise in an place the status "waiting" in an ip/cp/kup message and for responses
error message. On receiving this response, the EE MUST store in its to other request message types in an error message. On receiving
transaction context the senderNonce of the preceding request message this response, the EE MUST store in its transaction context the
because this value will be needed for checking the recipNonce of the senderNonce of the preceding request message because this value will
final response to be received after polling. It sends a poll request be needed for checking the recipNonce of the final response to be
with certReqId 0 if referring to the CertResponse element contained received after polling. It sends a poll request with certReqId 0 if
in the ip/cp/kup message, else -1 to refer to the whole message. In referring to the CertResponse element contained in the ip/cp/kup
case the final response is not yet available, the PKI management message, else -1 to refer to the whole message. In case the final
entity that initiated the delayed delivery MUST answer with a poll response is not yet available, the PKI management entity that
response, with the same certReqId. The included checkAfter time initiated the delayed delivery MUST answer with a poll response with
value indicates the minimum number of seconds that should elapse the same certReqId. The included checkAfter time value indicates the
before the EE sends a new pollReq message to the PKI management minimum number of seconds that should elapse before the EE sends a
entity. Polling earlier than indicated by the checkAfter value may new pollReq message to the PKI management entity. Polling earlier
increase the number of messages roundtrips. This is repeated until a than indicated by the checkAfter value may increase the number of
final response is available or any party involved gives up on the message round trips. This is repeated until a final response is
current PKI management operation, i.e., a timeout occurs. available or any party involved gives up on the current PKI
management operation, i.e., a timeout occurs.
When the PKI management entity that initiated delayed delivery can 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:
skipping to change at page 63, line 15 skipping to change at line 2830
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
immediate final response immediate final response
is available, is available
5 <- ip/cp/kup/error <- 5 <- ip/cp/kup/error <-
6 handle 6 handle
ip/cp/kup/error ip/cp/kup/error
with status with status
"waiting" "waiting"
-------------------------- start polling -------------------------- -------------------------- start polling --------------------------
7 format pollReq 7 format pollReq
8 -> pollReq -> 8 -> pollReq ->
skipping to change at page 63, line 45 skipping to change at line 2860
12 handle pollRep 12 handle pollRep
13 let checkAfter 13 let checkAfter
time elapse and time elapse and
continue with continue with
step 7 step 7
----------------- 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 the original request
15 <- response <- 15 <- response <-
16 handle final 16 handle final
response response
Detailed Message Description: Detailed Message Description:
Response with Status "waiting" -- ip/cp/kup/error Response with Status "waiting" -- ip/cp/kup/error
Field Value Field Value
skipping to change at page 64, line 21 skipping to change at line 2883
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
pKIStatusInfo REQUIRED -- in case of error response pKIStatusInfo REQUIRED -- in case of error response
-- PKIStatusInfo structure MUST be present -- PKIStatusInfo structure MUST be present
status REQUIRED status REQUIRED
-- MUST be status "waiting" -- MUST be status "waiting"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
failInfo PROHIBITED failInfo PROHIBITED
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
extraCerts OPTIONAL extraCerts OPTIONAL
-- As described in Section 3.3 -- As described in Section 3.3
Polling Request -- pollReq Polling Request -- pollReq
skipping to change at page 65, line 25 skipping to change at line 2935
body body
-- The message indicates the delay after which the EE SHOULD -- The message indicates the delay after which the EE SHOULD
-- send another pollReq message for this transaction -- send another pollReq message for this transaction
pollRep REQUIRED pollRep REQUIRED
certReqId REQUIRED certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1 -- MUST be 0 if referring to a CertResponse element, else -1
checkAfter REQUIRED checkAfter REQUIRED
-- MUST be the time in seconds to elapse before a new pollReq -- MUST be the time in seconds to elapse before a new pollReq
-- should be sent -- should be sent
reason OPTIONAL reason OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, for logging, or
-- display in a GUI -- to display in a GUI
protection REQUIRED protection REQUIRED
-- As described in Section 3.2 -- As described in Section 3.2
-- MUST use the same credentials as in the first 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 CMP protection certificate from the first -- cached the CMP protection certificate from the first
-- response message of the PKI management operation -- response message of 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
-- request as described in the respective PKI management -- request, as described in the respective PKI management
-- 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 MUST check that a request that initiates a new PKI management entity MUST check that a request that initiates a new
PKI management operation does not use a transactionID that is PKI management operation does not use a transactionID that is
currently in use. The failInfo bit value to use is currently in use. The failInfo bit value to use is
transactionIdInUse as described in Section 3.6.4. If any of these transactionIdInUse as described in Section 3.6.4. If any of these
verification steps or any of the essential checks described in verification steps or any of the essential checks described in
Section 3.5 and in the following subsections fails, the PKI Section 3.5 and in the following subsections fails, the PKI
management entity MUST proceed as described in Section 3.6. management entity MUST proceed as described in Section 3.6.
skipping to change at page 67, line 16 skipping to change at line 3020
An ir/cr/kur/p10cr message is used to request a certificate as An ir/cr/kur/p10cr 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.5. in Section 5.1.5.
The PKI management entity MUST check the message body according to The PKI management entity MUST 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. If a signature-based proof-of-possession is
is given, it should check that the request message was signed using a present, the PKI management entity MUST verify, based on local PKI
policy, that the subject name in the certTemplate identifies the same
entity as the subject name in the CMP protection certificate or
matches the identifier used with MAC-based protection. In case this
verification fails, the message MUST have been protected by an
authorized PKI management entity (failInfo bit: notAuthorized). If
the special POP value "raVerified" is given, the PKI management
entity 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 also perform any notAuthorized). The PKI management entity should also perform any
further checks on the certTemplate contents (failInfo: further checks on the certTemplate contents (failInfo:
badCertTemplate) according to any applicable PKI policy and badCertTemplate) according to any applicable PKI policy and
certificate profile. certificate profile.
If the requested certificate is available, the PKI management entity If the requested certificate is available, the PKI management entity
MUST respond with a positive ip/cp/kup message as described in MUST respond with a positive ip/cp/kup message as described in
Section 4.1. Section 4.1.
Note: If central key generation is performed by the responding PKI Note: If central key generation is performed by the responding PKI
management entity, the responding PKI management entity MUST include management entity, the responding PKI management entity MUST include
the private key in encrypted form in the response as specified in the private key in encrypted form in the response as specified in
Section 4.1.6. Section 4.1.6.
The prerequisites of the respective PKI management operation as The prerequisites of the respective PKI management operation
specified in Section 4.1 apply. specified in Section 4.1 apply.
If the EE requested omission of the certConf message, the PKI If the EE requested omission of the certConf message, the PKI
management entity MUST handle it as described in Section 4.1.1. management entity MUST handle it as described in Section 4.1.1.
Therefore, it MAY grant this by including the implicitConfirm Therefore, it MAY grant this by including the implicitConfirm
generalInfo field or include the confirmWaitTime field in the generalInfo field or including the confirmWaitTime field in the
response header. response header.
5.1.2. Responding to a Confirmation Message 5.1.2. 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
MUST react as described there. MUST react as described there.
The prerequisites of the respective PKI management operation as The prerequisites of the respective PKI management operation
specified in Section 4.1 apply. specified in Section 4.1 apply.
5.1.3. 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.4. 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 valid and current, such that further the contained information is valid and current, such that further
requests for the same contents can be answered immediately. requests for the same contents can be answered immediately.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 3.4. Section 3.4.
5.1.5. Initiating Delayed Delivery 5.1.5. Initiating Delayed Delivery
This functional extension can be used by a PKI management entity in 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 case the response to a request takes longer than usual. In this
the PKI management entity should completely validate the request as case, the PKI management entity should completely validate the
usual and then start processing the request itself or forward it request as usual and then start processing the request itself or
further upstream as soon as possible. In the meantime, it MUST forward it further upstream as soon as possible. In the meantime, it
respond with an ip/cp/kup/error message including the status MUST respond with an ip/cp/kup/error message including the status
"waiting" and handle subsequent polling as described in Section 4.4. "waiting" and handle subsequent polling as described in Section 4.4.
Typically, as stated in Section 5.2.3, an intermediate PKI management Typically, as stated in Section 5.2.3, an intermediate PKI management
entity should not change the sender and recipient nonces even in case 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 it modifies a request or a response message. In the special case of
delayed delivery initiated by an intermediate PKI management entity, delayed delivery initiated by an intermediate PKI management entity,
there is an exception. Between the EE and this PKI management there is an exception. Between the EE and this PKI management
entity, pollReq and pollRep messages are exchanged handling the entity, pollReq and pollRep messages are exchanged handling the
nonces as usual. Yet when the final response from upstream has nonces as usual. Yet when the final response from upstream has
arrived at the PKI management entity, this response contains the arrived at the PKI management entity, this response contains the
recipNonce copied (as usual) from the senderNonce in the original recipNonce copied (as usual) from the senderNonce in the original
request message. The PKI management entity that initiated the request message. The PKI management entity that initiated the
delayed delivery MAY replace the recipNonce in the response message delayed delivery MAY replace the recipNonce in the response message
with the senderNonce of the last received pollReq because the with the senderNonce of the last received pollReq because the
downstream entities, including the EE, might expect it in this way. downstream entities, including the EE, might expect it in this way.
Yet the check specified in Section 3.5 allows to alternatively use Yet the check specified in Section 3.5 allows alternate use of the
the senderNonce of the original request. senderNonce of the original request.
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.
5.2. Forwarding Messages 5.2. Forwarding Messages
In case the PKI solution consists of intermediate PKI management In case the PKI solution consists of intermediate PKI management
entities (i.e., LRA or RA), each CMP request message coming from an entities (i.e., LRA or RA), each CMP request message coming from an
EE or any other downstream PKI management entity MUST either be EE or any other downstream PKI management entity MUST either be
forwarded to the next (upstream) PKI management entity as described forwarded to the next (upstream) PKI management entity as described
in this section or answered as described in Section 5.1. Any in this section, or answered as described in Section 5.1. Any
received response message or a locally generated error message MUST received response message or a locally generated error message MUST
be forwarded to the next (downstream) PKI entity. be forwarded to 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
PKI management entity MAY verify the proof-of-possession for PKI management entity MAY verify the proof-of-possession for
ir/cr/kur/p10cr messages. If one of these verification procedures ir/cr/kur/p10cr messages. If one of these verification procedures
fails, the RA proceeds as described in Section 3.6. fails, the RA proceeds as described in Section 3.6.
A PKI management entity SHOULD NOT change the received message unless A PKI management entity SHOULD NOT change the received message unless
its role in the PKI system requires it. This is because changes to its role in the PKI system requires it. This is because changes to
the message header or body imply re-protection. Changes to the the message header or body imply reprotection. Changes to the
protection breaks end-to-end authentication of the message source. protection breaks end-to-end authentication of the message source.
Changes to the certificate template in a certificate request breaks Changes to the certificate template in a certificate request breaks
proof-of-possession. More details are available in the following proof-of-possession. More details are available in the following
sub-sections. Concrete PKI system specifications may define in more subsections. Concrete PKI system specifications may define when to
detail when to do so. do so in more detail.
This is particularly relevant in the upstream communication of a This is particularly relevant in the upstream communication of a
request message. request message.
Each forwarding PKI management entity has one or more Each forwarding PKI management entity has one or more
functionalities. It may functionalities. It may:
* verify the identities of EEs and make authorization decisions for * verify the identities of EEs and make authorization decisions for
certification request processing based on local PKI policy, certification request processing based on local PKI policy,
* add or modify fields of certificate request messages, * add or modify fields of certificate request messages,
* replace a MAC-based protection by a signature-based protection * replace a MAC-based protection with a signature-based protection
that can be verified also further upstream, and vice versa, that can also be verified further upstream and vice versa,
* double-check if the messages transferred back and forth are * double-check if the messages transferred back and forth are
properly protected and well-formed, properly protected and well-formed,
* provide an authentic indication that it has performed all required * provide an authentic indication that it has performed all required
checks, checks,
* initiate a delayed delivery due to delays transferring messages or * initiate a delayed delivery due to delays transferring messages or
handling requests, or handling requests, or
* collect messages from multiple RAs and forward them jointly. * collect messages from multiple RAs and forward them jointly.
Note: PKI management entities forwarding messages may also store data Note: PKI management entities forwarding messages may also store data
from a message in a database for later usage or audit purposes. They from a message in a database for later usage or audit purposes. They
may also support traversal of a network boundary. may also support traversal of a network boundary.
The decision if a message should be forwarded The decision if a message should be forwarded is:
* unchanged with the original protection, * unchanged with the original protection,
* unchanged with an additional protection, or * unchanged with an additional protection, or
* changed with an additional protection * changed with an additional protection
depends on the PKI solution design and the associated security policy depending on the PKI solution design and the associated security
(CP/CPS [RFC3647]). policy, e.g., as defined in the certificate policy (CP) /
certification practice statement (CPS) documents [RFC3647].
A PKI management entity SHOULD add or MAY replace a protection of a A PKI management entity SHOULD add or MAY replace a protection of a
message if it message if it
* needs to securely indicate that it has done checks or validations * needs to securely indicate that it has done checks or validations
on the message to one of the next (upstream) PKI management entity on the message to one of the next (upstream) PKI management
or entities or
* needs to protect the message using a key and certificate from a * needs to protect the message using a key and certificate from a
different PKI. different PKI.
If remaining end-to-end message authentication is required, an If retaining end-to-end message authentication is required, an
additional protection SHALL be added instead of replacing the additional protection SHALL be added instead of replacing the
original protection. original protection.
A PKI management entity MUST replace a protection of a message if it A PKI management entity MUST replace a protection of a message if it
* performs changes to the header or the body of the message or * performs changes to the header or the body of the message or
* needs to convert from or to a MAC-based protection. * needs to convert from or to a MAC-based protection.
This is particularly relevant in the upstream communication of This is particularly relevant in the upstream communication of
skipping to change at page 71, line 17 skipping to change at line 3224
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
refusing to forward the request message and instead responding as in 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 MUST be used for kur messages and for central key Section 5.2.2.1 MUST 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 [RFC4210] (also see
(see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there Section 2.6 of CMP Updates [RFC9480]), there are various use cases
are various use cases for adding another protection by a PKI for adding another protection by a PKI management entity. Specific
management entity. Specific procedures are described in more detail 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
-- messages and to bundle request messages or alternatively -- messages and to bundle request messages or alternatively
-- response messages -- response messages
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
This variant means that a PKI management entity forwards a CMP This variant means that a PKI management entity forwards a CMP
message while authentically indicating successful validation and message while authentically indicating successful validation and
approval of a request message without changing the original message approval of a request message without changing the original message
authentication. authentication.
By adding a protection using its own CMP protection key the PKI By adding a protection using its own CMP protection 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 needs to be preserved while adding an original protection of the EE needs to be preserved while adding an
indication of approval by the PKI management entity. indication of approval by the PKI management entity.
The PKI management entity wrapping the original request message in a The PKI management entity wrapping the original request message in a
nested message structure MUST copy the values of the recipient, nested message structure MUST copy the values of the senderNonce and
recipNonce, and transactionID header fields of the original message transactionID header fields of the original message to the respective
to the respective header fields of the nested message and apply header fields of the nested message and apply signature-based
signature-based protection. The additional signature serves as proof protection. The additional signature serves as proof of verification
of verification and authorization by this PKI management entity. and authorization by this PKI management entity.
The PKI management entity receiving such a nested message that The PKI management entity receiving such a nested message that
contains a single request message MUST validate the additional contains a single request message MUST validate the additional
protection signature on the nested message and check the protection signature on the nested message and check the
authorization for the approval it implies. authorization for the approval it implies. Other fields in the
header of the nested message can be ignored.
The PKI management entity responding to the request contained in the The PKI management entity responding to the request contained in the
nested message sends the response message as described in nested message sends the response message as described in
Section 5.1, without wrapping it in a nested message. Section 5.1, without wrapping it in a nested message.
Note: When responding to the inner request message, it must be
considered that the verification and approval activity described in
this section has already been performed by the PKI management entity
that protected the nested message.
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: The specific prerequisite augmenting the prerequisites in Section 3.4
is as follows:
* 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 ->
skipping to change at page 73, line 45 skipping to change at line 3347
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 for nested messages are used both on the upstream interface for
transferring request messages towards the next PKI management entity transferring request messages towards the next PKI management entity
and on its downstream interface for response messages. and on its downstream interface for response messages.
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 or between an LRA and an RA to bundle several messages for offline or
asynchronous delivery. In this case the LRA needs to initiate asynchronous delivery. In this case, the LRA needs to initiate
delayed delivery as described in Section 5.1.5. If the RA needs delayed delivery, as described in Section 5.1.5. If the RA needs
different routing information per nested PKI management message different routing information per the nested PKI management message
provided upstream, a suitable mechanism may need to be implemented to provided upstream, a suitable mechanism may need to be implemented to
ensure that the downstream delivery of the response is done to the ensure that the downstream delivery of the response is done to the
right requester. Since this mechanism strongly depends on the right requester. Since this mechanism strongly depends on the
requirements of the target architecture, it is out of scope of this requirements of the target architecture, it is out of scope of this
document. 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 endpoint; 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
messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm.
While building the upstream nested message the PKI management entity While building the upstream nested message, the PKI management entity
must store the sender, transactionID, and senderNonce fields of all must store the sender, transactionID, and senderNonce fields of all
bundled messages together with the transactionID of the upstream bundled messages together with the transactionID of the upstream
nested message. nested message.
Such an upstream nested message is sent to the next PKI management Such an upstream nested message is sent to the next PKI management
entity. The upstream PKI management entity that unbundles it MUST entity. The upstream PKI management entity that unbundles it MUST
handle each of the included request messages as usual. It MUST handle each of the included request messages as usual. It MUST
answer with a downstream nested message. This downstream nested answer with a downstream nested message. This downstream nested
message MUST use the transactionID of the upstream nested message and message MUST use the transactionID of the upstream nested message and
return the senderNonce of the upstream nested message as the return the senderNonce of the upstream nested message as the
recipNonce of the downstream nested message. The downstream nested recipNonce of the downstream nested message. The downstream nested
message MUST bundle all available individual response messages (e.g., message MUST bundle all available individual response messages (e.g.,
ip, cp, kup, pollRep, pkiConf, rp, genp, error) for all original ip, cp, kup, pollRep, pkiConf, rp, genp, or error) for all original
request messages of the upstream nested message. While unbundling request messages of the upstream nested message. While unbundling
the downstream nested message, the former PKI management entity must the downstream nested message, the former PKI management entity must
determine lost and unexpected responses based on the previously determine lost and unexpected responses based on the previously
stored transactionIDs. When it forwards the unbundled responses, any stored transactionIDs. When it forwards the unbundled responses, any
extra messages MUST be dropped, and any missing response message MUST extra messages MUST be dropped, and any missing response message MUST
be answered with an error message (failInfo bit: systemUnavail) to be answered with an error message (failInfo bit: systemUnavail) to
inform the respective requester about the failed certificate inform the respective requester about the failed certificate
management operation. management operation.
Note: This form of nesting messages is characterized by the fact that Note: This form of nesting messages is characterized by the fact that
skipping to change at page 75, line 17 skipping to change at line 3410
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.
If retaining end-to-end message authentication is required, an If retaining end-to-end message authentication is required, an
additional protection SHALL be added instead of replacing the additional protection SHALL be added instead of replacing the
original protection. original protection.
By replacing the existing protection using its own CMP protection key By replacing the existing protection using its own CMP protection
the PKI management entity provides a proof of verifying and approving key, the PKI management entity provides a proof of verifying and
the message as described above. Thus, the PKI management entity acts approving the message as described above. Thus, the PKI management
as an actual Registration Authority (RA), which implements important entity acts as an actual registration authority (RA), which
security functionality of the PKI. implements important security functionality of the PKI such as
verifying the proof of requester identity and authorization.
Before replacing the existing protection by a new protection, the PKI Note: By replacing the message protection, the binding of a
management entity signature-based proof-of-possession to the proof-of-identity given by
the original message protection gets lost. To enable the CA to
verify this binding, the original message can be provided in the
origPKIMessage generalInfo field.
Before replacing the existing protection with a new protection, the
PKI management entity:
* MUST validate the protection of the received message, * MUST validate the protection of the received message,
* should check the content of the message, * should check the content of the message,
* may do any modifications that it wants to perform, and * may do any modifications that it wants to perform, and
* MUST check that the sender of the original message, as * MUST check that the sender of the original message, as
authenticated by the message protection, is authorized for the authenticated by the message protection, is authorized for the
given operation. given operation.
* for certificate requests, MUST verify the binding of signature-
based proof-of-possession to the proof-of-identity as described in
Section 5.1.1.
These message adaptations MUST NOT be applied to kur messages These message adaptations MUST NOT be applied to kur messages
described in Section 4.1.3 since their original protection using the described in Section 4.1.3 since their original protection using the
key and certificate to be updated needs to be preserved. key and certificate to be updated needs to be preserved.
These message adaptations MUST NOT be applied to certificate request These message adaptations MUST NOT be applied to certificate request
messages described in Section 4.1.6 for central key generation since messages described in Section 4.1.6 for central key generation since
their original protection needs to be preserved up to the Key their original protection needs to be preserved up to the KGA, which
Generation Authority, which needs to use it for encrypting the new needs to use it for encrypting the new private key for the EE.
private key for the EE.
In both the kur and central key generation cases, if a PKI management In both the kur and central key generation cases, if a PKI management
entity needs to state its approval of the original request message it entity needs to state its approval of the original request message,
MUST provide this using a nested message as specified in it 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
MUST NOT change the transactionID, the senderNonce, or the recipNonce MUST NOT change the transactionID, the senderNonce, or the
- apart from the exception for the recipNonce given in Section 5.1.5. recipNonce, apart from the exception for the recipNonce given in
Section 5.1.5.
5.2.3.1. Not Changing 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.
This variant is typically used when an RA replaces an existing MAC- This variant is typically used when an RA replaces an existing MAC-
based protection by its own signature-based protection, because the based protection with its own signature-based protection; because the
upstream PKI management entity does not know the respective shared upstream PKI management entity does not know the respective shared
secret information, replacing the protection is useful. secret information, replacing the protection is useful.
Note: A signature-based proof-of-possession of a certificate request Note: A signature-based proof-of-possession of a certificate request
will be broken if any field in the certTemplate structure is changed. will be broken if any field in the certTemplate structure is changed.
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: The specific prerequisite augmenting the prerequisites in Section 3.4
is as follows:
* 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. Using raVerified 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 any included proof-of-possession in a management entity breaks any included 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
value to raVerified. value to raVerified.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4
are as follows:
* 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.
Detailed Description of popo Field of certReq Structure: Detailed Description of the popo Field of the certReq Structure:
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.
Note: The request message protection will not authenticate the EE, Note: The request message protection will not authenticate the EE,
but the RA acting on behalf of the EE. but it will authenticate the RA acting on behalf of the EE.
5.3.1. Requesting a Certificate 5.3.1. Requesting a Certificate
A PKI management entity may use one of the PKI management operations A PKI management entity may use one 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 MUST verify the received proof-of-possession if this proof case, it MUST verify the received proof-of-possession if this proof
breaks, e.g., due to transformation from PKCS#10 [RFC2986] to CRMF breaks, e.g., due to transformation from PKCS #10 [RFC2986] to CRMF
[RFC4211] certificate request format. [RFC4211]. It MUST also verify, based on local PKI policy, that the
subject name in the certTemplate identifies the EE.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 4.1. Section 4.1.
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 one described in differentiate this PKI management operation from the one described in
Section 5.2.3 because in both cases the message is protected by the Section 5.2.3 because, in both cases, the message is protected by the
PKI management entity. PKI management entity.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to the respective PKI management operation given in Section 4.1, with to the respective PKI management operation given in Section 4.1, with
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
and use "raVerified" in its upstream request. downstream and use "raVerified" in its upstream request.
3. The binding of the proof-of-possession to the proof-of-identity
of the requesting EE cannot be provided when acting on behalf of
the EE.
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 acting on behalf of the EE in this PKI management entity acting on behalf of the EE in this
operation. 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. EEs will principle, any reliable transfer mechanism can be used. EEs will
typically support only one transfer mechanism. PKI management typically support only one transfer mechanism. PKI management
entities SHOULD offer HTTP and MAY offer CoAP where required. entities SHOULD offer HTTP and MAY offer CoAP where required.
Piggybacking of CMP messages on any other reliable transfer protocol Piggybacking of CMP messages on any other reliable transfer protocol
MAY be used, and file-based transfer MAY be used in case offline MAY be used, and file-based transfer MAY be used in case offline
transfer is required. 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 PKI entity that sends CMP requests prevent waiting indefinitely, each PKI entity that sends CMP requests
should use a configurable per-request timeout, and each PKI should use a configurable per-request timeout, and each PKI
management entity that handles CMP requests should use a configurable management entity that handles CMP requests should use a configurable
timeout in case a further request message is to be expected from the timeout in case a further request message is to be expected from the
client side within the same transaction. In this way a hanging client side within the same transaction. In this way, a hanging
transaction can be closed cleanly with an error as described in transaction can be closed cleanly with an error as described in
Section 3.6 (failInfo bit: systemUnavail) and related resources (for Section 3.6 (failInfo bit: systemUnavail), and related resources (for
instance, any cached extraCerts) can be freed. instance, any cached extraCerts) can be freed.
Moreover, there are various situations where the delivery of messages Moreover, there are various situations where the delivery of messages
gets delayed. For instance, a serving PKI management entity might gets delayed. For instance, a serving PKI management entity might
take longer than expected to form a response due to administrative take longer than expected to form a response due to administrative
processes, resource constraints, or upstream message delivery delays. processes, resource constraints, or upstream message delivery delays.
The transport layer itself may cause delays, for instance due to The transport layer itself may cause delays, for instance, due to
offline transport, network segmentation, or intermittent network offline transport, network segmentation, or intermittent network
connectivity. Part of these issues can be detected and handled at connectivity. Part of these issues can be detected and handled at
CMP level using pollReq and pollRep messages as described in CMP level using pollReq and pollRep messages as described in
Section 4.4, while others are better handled at transfer level. Section 4.4, while others are better handled at transfer level.
Depending on the transfer protocol and system architecture, solutions Depending on the transfer protocol and system architecture, solutions
for handling delays at transfer level may be present and can be used for handling delays at transfer level may be present and can be used
for CMP connections, for instance connection re-establishment and for CMP connections, for instance, connection reestablishment and
message retransmission. message retransmission.
Note: Long timeout periods are helpful to maximize chances to handle Note: Long timeout periods are helpful to maximize chances to handle
minor delays at lower layers without the need for polling. minor delays at lower layers without the need for polling.
Note: When using TCP and similar reliable connection-oriented Note: When using TCP and similar reliable connection-oriented
transport protocols, which is typical in conjunction with HTTP, there transport protocols, which is typical in conjunction with HTTP, there
is the option to keep the connection alive over multiple request- is the option to keep the connection alive over multiple request-
response message pairs. This may improve efficiency. response message pairs. This may improve efficiency.
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 3.4 of CMP over HTTP for transfer encoding as specified in Section 3.4 of CMP over HTTP
[RFC6712] and Section 2.4 of CMP over CoAP [RFC6712] and Section 2.3 of CMP over CoAP [RFC9482].
[I-D.ietf-ace-cmpv2-coap-transport].
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
described in [RFC6712] and updated by CMP Updates described in [RFC6712] and updated by CMP Updates [RFC9480] MUST be
[I-D.ietf-lamps-cmp-updates] MUST be followed. followed.
PKI management operations MUST use an URI path consisting of '/.well- PKI management operations MUST use a URI path consisting of '/.well-
known/cmp/' or '/.well-known/cmp/p/<name>/' as specified in CMP known/cmp' or '/.well-known/cmp/p/<name>' as specified in Section 3.3
Updates Section 3.3 [I-D.ietf-lamps-cmp-updates]. It SHOULD be of CMP Updates [RFC9480]. It SHOULD be followed by an operation
followed by an operation label depending on the type of PKI label depending on the type of PKI management operation.
management operation.
+============================+====================+=========+ +============================+====================+=========+
| PKI Management Operation | URI Path Segment | Details | | PKI Management Operation | URI Path Segment | Details |
+============================+====================+=========+ +============================+====================+=========+
| Enrolling an End Entity to | initialization | Section | | Enrolling an End Entity to | initialization | Section |
| a New PKI | | 4.1.1 | | a New PKI | | 4.1.1 |
+----------------------------+--------------------+---------+ +----------------------------+--------------------+---------+
| Enrolling an End Entity to | certification | Section | | Enrolling an End Entity to | certification | Section |
| a Known PKI | | 4.1.2 | | a Known PKI | | 4.1.2 |
+----------------------------+--------------------+---------+ +----------------------------+--------------------+---------+
| Updating a Valid | keyupdate | Section | | Updating a Valid | keyupdate | Section |
| Certificate | | 4.1.3 | | Certificate | | 4.1.3 |
+----------------------------+--------------------+---------+ +----------------------------+--------------------+---------+
| Enrolling an End Entity | pkcs10 | Section | | Enrolling an End Entity | pkcs10 | Section |
| Using a PKCS#10 Request | | 4.1.4 | | Using a PKCS #10 Request | | 4.1.4 |
+----------------------------+--------------------+---------+ +----------------------------+--------------------+---------+
| Revoking a 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 |
+----------------------------+--------------------+---------+ +----------------------------+--------------------+---------+
skipping to change at page 80, line 46 skipping to change at line 3692
| | | 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 URI Path Segment <operation> Table 1: HTTP URI Path Segment <operation>
If operation labels are used: If operation labels are used:
* Independently of any variants used (see Sections 4.1.5, 4.1.6, and * independently of any variants used (see Sections 4.1.5, 4.1.6, and
4.4) the operation label corresponding to the PKI management 4.4), the operation label corresponding to the PKI management
operation SHALL be used. operation SHALL be used.
* Any certConf or pollReq messages SHALL be sent to the same * any certConf or pollReq messages SHALL be sent to the same
endpoint as determined by the PKI management operation. endpoint as 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 SHALL be the same as for the Section 5.2.2.1, the label to use SHALL be the same as for the
underlying PKI management operation. underlying PKI management operation.
By sending a request to its preferred endpoint, the PKI entity will By sending a request to its preferred endpoint, the PKI entity will
recognize via the HTTP response status code whether a configured URI recognize, via the HTTP response status code, whether a configured
is supported by the PKI management entity. URI is supported by the PKI management entity.
In case a PKI management entity receives an unexpected HTTP status In case a PKI management entity receives an unexpected HTTP status
code from upstream, it MUST respond downstream with an error message code from upstream, it MUST respond downstream with an error message
as described in Section 3.6 using a failInfo bit corresponding to the as described in Section 3.6, using a failInfo bit corresponding to
status code, e.g., systemFailure. the status code, e.g., systemFailure.
For certificate management the major security goal is integrity and For certificate management, the major security goal is integrity and
data origin authentication. For delivery of centrally generated data origin authentication. For delivery of centrally generated
keys, also confidentiality is a must. These goals are sufficiently keys, confidentiality is also a must. These goals are sufficiently
achieved by CMP itself, also in an end-to-end fashion. achieved by CMP itself, also in an end-to-end fashion.
If a second line of defense is required or general privacy concerns If a second line of defense is required or general privacy concerns
exist, TLS can be used to provide confidentiality on a hop-by-hop exist, TLS can be used to provide confidentiality on a hop-by-hop
basis. TLS should be used with certificate-based authentication to basis. TLS should be used with certificate-based authentication to
further protect the HTTP transfer as described in [RFC9110]. In further protect the HTTP transfer as described in [RFC9110]. In
addition, the recommendations provided in [RFC9325] should be addition, the recommendations provided in [RFC9325] should be
followed. followed.
Note: The requirements for checking certificates given in [RFC5280] Note: The requirements for checking certificates given in [RFC5280]
skipping to change at page 82, line 9 skipping to change at line 3748
Otherwise, a password-authenticated key exchange (PAKE) protocol is Otherwise, a password-authenticated key exchange (PAKE) protocol is
recommended. recommended.
Note: The provisioning of client certificates and PSKs is out of Note: The provisioning of client certificates and PSKs is out of
scope of this document. scope of this document.
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 described in CMP over CoAP
CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. [RFC9482] MUST be followed.
PKI management operations MUST use an URI path consisting of '/.well- PKI management operations MUST use a URI path consisting of '/.well-
known/cmp/' or '/.well-known/cmp/p/<name>/' as specified in CMP over known/cmp' or '/.well-known/cmp/p/<name>' as specified in Section 2.1
CoAP Section 2.1 [I-D.ietf-ace-cmpv2-coap-transport]. It SHOULD be of CMP over CoAP [RFC9482]. It SHOULD be followed by an operation
followed by an operation label depending on the type of PKI label depending on the type of PKI management operation.
management operation.
+=======================================+=========+=========+ +=======================================+=========+=========+
| PKI Management Operation | URI | Details | | PKI Management Operation | URI | Details |
| | Path | | | | Path | |
| | Segment | | | | Segment | |
+=======================================+=========+=========+ +=======================================+=========+=========+
| Enrolling an End Entity to a New PKI | ir | Section | | Enrolling an End Entity to a New PKI | ir | Section |
| | | 4.1.1 | | | | 4.1.1 |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
| Enrolling an End Entity to a Known | cr | Section | | Enrolling an End Entity to a Known | cr | Section |
| PKI | | 4.1.2 | | PKI | | 4.1.2 |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
| Updating a Valid Certificate | kur | Section | | Updating a Valid Certificate | kur | Section |
| | | 4.1.3 | | | | 4.1.3 |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
| Enrolling an End Entity Using a | p10 | Section | | Enrolling an End Entity Using a PKCS | p10 | Section |
| PKCS#10 Request | | 4.1.4 | | #10 Request | | 4.1.4 |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
| Revoking a Certificate | rr | Section | | Revoking a Certificate | rr | Section |
| | | 4.2 | | | | 4.2 |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
| Get CA Certificates | crts | Section | | Get CA Certificates | crts | Section |
| | | 4.3.1 | | | | 4.3.1 |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
| Get Root CA Certificate Update | rcu | Section | | Get Root CA Certificate Update | rcu | Section |
| | | 4.3.2 | | | | 4.3.2 |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
skipping to change at page 83, line 47 skipping to change at line 3798
| Batching Messages | nest | Section | | Batching Messages | nest | Section |
| | | 5.2.2.2 | | | | 5.2.2.2 |
| Note: This path element is applicable | | | | Note: This path element is applicable | | |
| only between PKI management entities. | | | | only between PKI management entities. | | |
+---------------------------------------+---------+---------+ +---------------------------------------+---------+---------+
Table 2: CoAP URI Path Segment <operation> Table 2: CoAP URI Path Segment <operation>
If operation labels are used: If operation labels are used:
* Independently of any variants used (see Sections 4.1.5, 4.1.6, and * independently of any variants used (see Sections 4.1.5, 4.1.6, and
4.4) the operation label corresponding to the PKI management 4.4), the operation label corresponding to the PKI management
operation SHALL be used. operation SHALL be used.
* Any certConf or pollReq messages SHALL be sent to the same * any certConf or pollReq messages SHALL be sent to the same
endpoint as determined by the PKI management operation. endpoint, as 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 SHALL be the same as for the Section 5.2.2.1, the label to use SHALL be the same as for the
underlying PKI management operation. underlying PKI management operation.
By sending a request to its preferred endpoint, the PKI entity will By sending a request to its preferred endpoint, the PKI entity will
recognize via the CoAP response status code whether a configured URI recognize, via the CoAP response status code, whether a configured
is supported by the PKI management entity. The CoAP-inherent URI is supported by the PKI management entity. The CoAP-inherent
discovery mechanisms MAY also be used. discovery mechanisms MAY also be used.
In case a PKI management entity receives an unexpected CoAP status In case a PKI management entity receives an unexpected CoAP status
code from upstream, it MUST respond downstream with an error message code from upstream, it MUST respond downstream with an error message,
as described in Section 3.6 using a failInfo bit corresponding to the as described in Section 3.6, using a failInfo bit corresponding to
status code, e.g., systemFailure. the 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]. If described in CMP over CoAP [RFC9482]. If DTLS is utilized, the same
DTLS is utilized, the same boundary conditions (peer authentication, boundary conditions (peer authentication, etc.) as those stated for
etc.) as stated for TLS to protect HTTP transfer in Section 6.1 apply TLS to protect HTTP transfer in Section 6.1 apply to DTLS likewise.
to DTLS likewise.
Note: The provisioning of client certificates and PSKs is out of Note: The provisioning of client certificates and PSKs is out of
scope of this document. scope of this document.
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 transferred on some other reliable protocol,
e.g., EAP or MQTT. Connection, delay, and error handling mechanisms e.g., Extensible Authentication Protocol (EAP) or Message Queuing
similar to those specified for HTTP in RFC 6712 [RFC6712]need to be Telemetry Transport (MQTT). Connection, delay, and error handling
implemented. mechanisms similar to those specified for HTTP in [RFC6712] 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
be used that is able to store and forward binary objects of that is able to store and forward binary objects of sufficient length
sufficient length and with sufficient reliability while preserving and with sufficient reliability while preserving the order of
the order of messages for each transaction. messages for each transaction can be used.
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 MUST report an error as specified in cases, the PKI entities MUST 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 EE is offline or a PKI management mechanisms, for instance, when an EE is offline 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 filename 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 upload/
up-/download, MAY transfer CMP messages between PKI entities. A MIME 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 is specified in RFC 8551 Section 3.1 [RFC8551]. MIME wrapping is specified in Section 3.1 of [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 Section 3.4 of CMP over HTTP transfer encoding, as specified in Section 3.4 of CMP over HTTP
[RFC6712]. A filename MUST be included either in a "content-type" or [RFC6712]. A filename MUST be included either in a "content-type" or
a "content-disposition" statement. The file name extension ".pki" a "content-disposition" statement. The filename extension ".pki"
MUST be used. 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 each type of PKI entity. specified in this profile is required for each 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 Sections 4 and 5 and states whether support operations specified in Sections 4 and 5 and states whether support
by conforming EE, RA, and CA implementations is mandatory, 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 The PKI management operation specifications in Section 4 assume that
either the RA or CA is the PKI management entity that terminates the either the RA or CA is the PKI management entity that terminates the
CMP protocol. If the RA terminates the CMP protocol it either Certificate Management Protocol. If the RA terminates CMP, it either
responds directly as described in Section 5.1 or forwards the responds directly as described in Section 5.1, or it forwards the
certificate management operation towards the CA not using CMP. certificate management operation towards the CA not using CMP.
Section 5.2 describes different options how an RA can forward a CMP Section 5.2 describes different options of how an RA can forward a
message using CMP. Section 5.3 offers the option that an RA operates CMP message using CMP. Section 5.3 offers the option that an RA
on behalf on an EE and therefore takes the role of the EE in operates on behalf on an EE and therefore takes the role of the EE in
Section 4. 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 | MUST | MUST |
| | Messages and PKI | | | | | | Messages and PKI | | | |
| | Management Operations, | | | | | | Management Operations, | | | |
| | Section 3 | | | | | | Section 3 | | | |
skipping to change at page 86, line 24 skipping to change at line 3918
| IR | Enrolling an End Entity to | MUST | MAY | MUST | | IR | Enrolling an End Entity to | MUST | MAY | MUST |
| | a New PKI, Section 4.1.1 | | | | | | a New PKI, Section 4.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CR | Enrolling an End Entity to | MAY | MAY | MAY | | CR | Enrolling an End Entity to | MAY | MAY | MAY |
| | a Known PKI, Section 4.1.2 | | | | | | a Known PKI, Section 4.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| KUR | Updating a Valid | MUST | MAY | MUST | | KUR | Updating a Valid | MUST | MAY | MUST |
| | Certificate, Section 4.1.3 | | | | | | Certificate, Section 4.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| P10CR | Enrolling an End Entity | MAY | MAY | MAY | | P10CR | Enrolling an End Entity | MAY | MAY | MAY |
| | Using a PKCS#10 Request, | | | | | | Using a PKCS #10 Request, | | | |
| | Section 4.1.4 | | | | | | Section 4.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| MAC | Using MAC-Based Protection | MAY | SHOULD | MAY | | MAC | Using MAC-Based Protection | MAY | SHOULD | MAY |
| | for Enrollment, with IR, | | 1) | | | | for Enrollment (IR, CR, | | 1) | |
| | CR, and P10CR if | | | | | | and P10CR if supported), | | | |
| | supported, Section 4.1.5 | | | | | | Section 4.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CKeyGen | Adding Central Key Pair | MAY | MAY | MAY | | CKeyGen | Adding Central Key Pair | MAY | MAY | MAY |
| | Generation to Enrollment, | | | | | | Generation to Enrollment | | | |
| | IR, CR, KUR, and P10CR if | | | | | | (IR, CR, KUR, and P10CR if | | | |
| | supported, Section 4.1.6 | | | | | | supported), Section 4.1.6 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| RR | Revoking a Certificate, | SHOULD | SHOULD | SHOULD | | RR | Revoking a Certificate, | SHOULD | SHOULD | SHOULD |
| | Section 4.2 | | 2) | 3) | | | Section 4.2 | | 2) | 3) |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| 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 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
skipping to change at page 87, line 40 skipping to change at line 3983
| FwdAddS | Forwarding Messages - | N/A | MUST | MUST | | FwdAddS | Forwarding Messages - | N/A | MUST | MUST |
| | Adding Protection to a | | | | | | Adding Protection to a | | | |
| | Request Message, | | | | | | Request Message, | | | |
| | Section 5.2.2.1 | | | | | | Section 5.2.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdAddB | Forwarding Messages - | N/A | MAY | MAY | | FwdAddB | Forwarding Messages - | N/A | MAY | MAY |
| | Batching Messages, | | | | | | Batching Messages, | | | |
| | Section 5.2.2.2 | | | | | | Section 5.2.2.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdReqKP | Forwarding Messages - Not | N/A | SHOULD | N/A | | FwdReqKP | Forwarding Messages - Not | N/A | SHOULD | N/A |
| | Changing | | 1) | | | | Changing Proof-of- | | 1) | |
| | Proof-of-Possession, | | | | | | Possession, | | | |
| | Section 5.2.3.1 | | | | | | Section 5.2.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| FwdReqBP | Forwarding Messages - | N/A | MAY | MAY | | FwdReqBP | Forwarding Messages - | N/A | MAY | MAY |
| | Using raVerified, | | | | | | Using raVerified, | | | |
| | Section 5.2.3.2 | | | | | | Section 5.2.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+ +----------+-----------------------------+--------+--------+--------+
| CertROnB | Acting on Behalf of other | N/A | MAY | N/A | | CertROnB | Acting on Behalf of Other | N/A | MAY | N/A |
| | PKI Entities - Requesting | | | | | | PKI Entities - Requesting | | | |
| | a Certificate, | | | | | | 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 | | 2) | 3) | | | PKI Entities - Revoking a | | 2) | 3) |
| | Certificate, Section 5.3.2 | | | | | | Certificate, 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
1) The RA should be able to change the CMP message protection from 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. MAC-based to signature-based protection; see Section 5.2.3.1.
2) The RA should be able to request certificate revocation on behalf 2) The RA should be able to request certificate revocation on behalf
of an EE, see Section 5.3.2, e.g., in order to handle incidents. of an EE (see Section 5.3.2), e.g., in order to handle incidents.
3) An alternative would be to perform revocation at the CA without 3) An alternative would be to perform revocation at the CA without
using CMP, for instance using a local administration interface. using CMP, for instance, using a local administration interface.
7.2. Message Transfer 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 a sequence of one that, for each request message sent, eventually a sequence of one
response message should be received. Therefore, virtually any response message should be received. Therefore, virtually any
reliable transfer mechanism can be used, such as HTTP, CoAP, and reliable transfer mechanism can be used, such as HTTP, CoAP, and
file-based offline transfer. Thus, this document does not require file-based offline transfer. Thus, this document does not require
any specific transfer protocol to be supported by conforming any specific transfer protocol to be supported by conforming
implementations. 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.
HTTP SHOULD be supported and CoAP MAY be supported at all PKI HTTP SHOULD be supported and CoAP MAY be supported at all PKI
entities for maximizing general interoperability at transfer level. entities for maximizing general interoperability at transfer level.
Yet full flexibility is retained to choose whatever transfer Yet full flexibility is retained to choose whatever transfer
mechanism is suitable, for instance for devices and system mechanism is suitable, for instance, for devices and system
architectures with specific constraints. architectures with 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 | | | |
skipping to change at page 89, line 26 skipping to change at line 4056
| | 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 defines new entries with the following content in the IANA has registered the following content in the "CMP Well-Known URI
"CMP Well-Known URI Path Segments" registry (see Path Segments" registry (see <https://www.iana.org/assignments/cmp>),
https://www.iana.org/assignments/cmp/) as defined in RFC 8615 as defined in [RFC8615].
[RFC8615].
+====================+===============================+===========+ +====================+==========================+===============+
| Path Segment | Description | Reference | | Path Segment | Description | Reference |
+====================+===============================+===========+ +====================+==========================+===============+
| initialization | Enrolling an End Entity to a | [thisRFC] | | initialization | Enrolling an End Entity | RFC 9483, |
| | New PKI over HTTP | | | | to a New PKI over HTTP | Section 4.1.1 |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| certification | Enrolling an End Entity to a | [thisRFC] | | certification | Enrolling an End Entity | RFC 9483, |
| | Known PKI over HTTP | | | | to a Known PKI over HTTP | Section 4.1.2 |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| keyupdate | Updating a Valid Certificate | [thisRFC] | | keyupdate | Updating a Valid | RFC 9483, |
| | over HTTP | | | | Certificate over HTTP | Section 4.1.3 |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| pkcs10 | Enrolling an End Entity Using | [thisRFC] | | pkcs10 | Enrolling an End Entity | RFC 9483, |
| | a PKCS#10 Request over HTTP | | | | Using a PKCS #10 Request | Section 4.1.4 |
+--------------------+-------------------------------+-----------+ | | over HTTP | |
| revocation | Revoking a Certificate over | [thisRFC] | +--------------------+--------------------------+---------------+
| | HTTP | | | revocation | Revoking a Certificate | RFC 9483, |
+--------------------+-------------------------------+-----------+ | | over HTTP | Section 4.2 |
| getcacerts | Get CA Certificates over HTTP | [thisRFC] | +--------------------+--------------------------+---------------+
+--------------------+-------------------------------+-----------+ | getcacerts | Get CA Certificates over | RFC 9483, |
| getrootupdate | Get Root CA Certificate | [thisRFC] | | | HTTP | Section 4.3.1 |
| | Update over HTTP | | +--------------------+--------------------------+---------------+
+--------------------+-------------------------------+-----------+ | getrootupdate | Get Root CA Certificate | RFC 9483, |
| getcertreqtemplate | Get Certificate Request | [thisRFC] | | | Update over HTTP | Section 4.3.2 |
| | Template over HTTP | | +--------------------+--------------------------+---------------+
+--------------------+-------------------------------+-----------+ | getcertreqtemplate | Get Certificate Request | RFC 9483, |
| getcrls | CRL Update Retrieval over | [thisRFC] | | | Template over HTTP | Section 4.3.3 |
| | HTTP | | +--------------------+--------------------------+---------------+
+--------------------+-------------------------------+-----------+ | getcrls | CRL Update Retrieval | RFC 9483, |
| nested | Batching Messages over HTTP | [thisRFC] | | | over HTTP | Section 4.3.4 |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| ir | Enrolling an End Entity to a | [thisRFC] | | nested | Batching Messages over | RFC 9483, |
| | New PKI over CoAP | | | | HTTP | Section |
+--------------------+-------------------------------+-----------+ | | | 5.2.2.2 |
| cr | Enrolling an End Entity to a | [thisRFC] | +--------------------+--------------------------+---------------+
| | Known PKI over CoAP | | | ir | Enrolling an End Entity | RFC 9483, |
+--------------------+-------------------------------+-----------+ | | to a New PKI over CoAP | Section 4.1.1 |
| kur | Updating a Valid Certificate | [thisRFC] | +--------------------+--------------------------+---------------+
| | over CoAP | | | cr | Enrolling an End Entity | RFC 9483, |
+--------------------+-------------------------------+-----------+ | | to a Known PKI over CoAP | Section 4.1.2 |
| p10 | Enrolling an End Entity Using | [thisRFC] | +--------------------+--------------------------+---------------+
| | a PKCS#10 Request over CoAP | | | kur | Updating a Valid | RFC 9483, |
+--------------------+-------------------------------+-----------+ | | Certificate over CoAP | Section 4.1.3 |
| rr | Revoking a Certificate over | [thisRFC] | +--------------------+--------------------------+---------------+
| | CoAP | | | p10 | Enrolling an End Entity | RFC 9483, |
+--------------------+-------------------------------+-----------+ | | Using a PKCS #10 Request | Section 4.1.4 |
| crts | Get CA Certificates over CoAP | [thisRFC] | | | over CoAP | |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| rcu | Get Root CA Certificate | [thisRFC] | | rr | Revoking a Certificate | RFC 9483, |
| | Update over CoAP | | | | over CoAP | Section 4.2 |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| att | Get Certificate Request | [thisRFC] | | crts | Get CA Certificates over | RFC 9483, |
| | Template over CoAP | | | | CoAP | Section 4.3.1 |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| crls | CRL Update Retrieval over | [thisRFC] | | rcu | Get Root CA Certificate | RFC 9483, |
| | CoAP | | | | Update over CoAP | Section 4.3.2 |
+--------------------+-------------------------------+-----------+ +--------------------+--------------------------+---------------+
| nest | Batching Messages over CoAP | [thisRFC] | | att | Get Certificate Request | RFC 9483, |
+--------------------+-------------------------------+-----------+ | | Template over CoAP | Section 4.3.3 |
+--------------------+--------------------------+---------------+
| crls | CRL Update Retrieval | RFC 9483, |
| | over CoAP | Section 4.3.4 |
+--------------------+--------------------------+---------------+
| nest | Batching Messages over | RFC 9483, |
| | CoAP | Section |
| | | 5.2.2.2 |
+--------------------+--------------------------+---------------+
Table 5: New "CMP Well-Known URI Path Segments" Registry Entries 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 laid out in CMP [RFC4210] and updated by
CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms CMP Updates [RFC9480], CMP Algorithms [RFC9481], CRMF [RFC4211],
[I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm Algorithm Requirements Update [RFC9045], CMP over HTTP [RFC6712], and
Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over CMP over CoAP [RFC9482] apply.
CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply.
Trust anchors for chain validations are often provided in the form of Trust anchors for chain validations are often provided in the form of
self-signed certificates. All trust anchors MUST be stored on the self-signed certificates. All trust anchors MUST be stored on the
device with integrity protection. In some cases, a PKI entity may device with integrity protection. In some cases, a PKI entity may
not have sufficient storage for the complete certificates. In such not have sufficient storage for the complete certificates. In such
cases it may only store, e.g., a hash of each self-signed certificate cases, it may only store, e.g., a hash of each self-signed
and require receiving the certificate in the extraCerts field as certificate and require receiving the certificate in the extraCerts
described in Section 3.3. If such self-signed certificates are field, as described in Section 3.3. If such self-signed certificates
provided in-band in the messages, they MUST be verified using are provided in-band in the messages, they MUST be verified using
information from the trust store of the PKI entity. information from the trust store of the PKI entity.
For TLS using shared secret information-based authentication, both For TLS using shared secret information-based authentication, both
PSK and PAKE provide the same amount of protection against a real- PSK and PAKE provide the same amount of protection against a real-
time authentication attack which is directly the amount of entropy in time authentication attack, which is directly the amount of entropy
the shared secret. The difference between a pre-shared key (PSK) and in the shared secret. The difference between a pre-shared key (PSK)
a password-authenticated key exchange (PAKE) protocol is in the level and a password-authenticated key exchange (PAKE) protocol is in the
of long-term confidentiality of the TLS messages against brute-force level of long-term confidentiality of the TLS messages against brute-
decryption, where a PSK-based cipher suite only provides security force decryption, where a PSK-based cipher suite only provides
according to the entropy of the shared secret, while a PAKE-based security according to the entropy of the shared secret, while a PAKE-
cipher suite provides full security independent of the entropy of the based cipher suite provides full security independent of the entropy
shared secret. of the shared secret.
10. Acknowledgements
We thank the various reviewers of this document.
11. References
11.1. Normative References
[I-D.ietf-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transfer for the
Certificate Management Protocol", Work in Progress,
Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-07, 27
January 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-ace-cmpv2-coap-transport-07>.
[I-D.ietf-lamps-cmp-algorithms] 10. References
Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms", Work
in Progress, Internet-Draft, draft-ietf-lamps-cmp-
algorithms-15, 2 June 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-15>.
[I-D.ietf-lamps-cmp-updates] 10.1. Normative References
Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", Work in Progress,
Internet-Draft, draft-ietf-lamps-cmp-updates-23, 29 June
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cmp-updates-23>.
[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 92, line 40 skipping to change at line 4187
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005, DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>. <https://www.rfc-editor.org/info/rfc4211>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010, DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>. <https://www.rfc-editor.org/info/rfc5958>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
skipping to change at page 93, line 41 skipping to change at line 4233
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
11.2. Informative References [RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", RFC 9480,
DOI 10.17487/RFC9480, October 2023,
<https://www.rfc-editor.org/info/rfc9480>.
[RFC9481] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms",
RFC 9481, DOI 10.17487/RFC9481, October 2023,
<https://www.rfc-editor.org/info/rfc9481>.
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
Application Protocol (CoAP) Transfer for the Certificate
Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
October 2023, <https://www.rfc-editor.org/info/rfc9482>.
10.2. Informative References
[BRSKI-AE] von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
Alternative Enrollment Protocols in BRSKI", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-ae-05, 28
June 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-anima-brski-ae-05>.
[BRSKI-PRM]
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-09,
10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-09>.
[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, December 2020,
<http://www.3gpp.org/ftp/Specs/html-info/33310.htm>. <http://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
[ETSI-EN.319411-1] [ETSI-EN.319411-1]
ETSI, "Electronic Signatures and Infrastructures (ESI); ETSI, "Electronic Signatures and Infrastructures (ESI);
Policy and security requirements for Trust Service Policy and security requirements for Trust Service
Providers issuing certificates; Part 1: General Providers issuing certificates; Part 1: General
requirements", ETSI EN 319 411-1 V1.3.1, May 2021, requirements", V1.3.1, ETSI EN 319 411-1, May 2021,
<https://www.etsi.org/deliver/ <https://www.etsi.org/deliver/
etsi_en/319400_319499/31941101/01.03.01_60/ etsi_en/319400_319499/31941101/01.03.01_60/
en_31941101v010301p.pdf>. en_31941101v010301p.pdf>.
[I-D.ietf-anima-brski-ae] [HTTP-CMP] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
Alternative Enrollment Protocols in BRSKI", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-ae-03, 24
October 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-ae-03>.
[I-D.ietf-anima-brski-prm]
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-06,
11 January 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-06>.
[I-D.ietf-lamps-rfc4210bis]
Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", Work in Progress, Internet-
Draft, draft-ietf-lamps-rfc4210bis-03, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
rfc4210bis-03>.
[I-D.ietf-lamps-rfc6712bis]
Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- HTTP Transfer "Internet X.509 Public Key Infrastructure -- HTTP Transfer
for the Certificate Management Protocol (CMP)", Work in for the Certificate Management Protocol (CMP)", Work in
Progress, Internet-Draft, draft-ietf-lamps-rfc6712bis-03, Progress, Internet-Draft, draft-ietf-lamps-rfc6712bis-03,
10 February 2023, <https://datatracker.ietf.org/doc/html/ 10 February 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-rfc6712bis-03>. draft-ietf-lamps-rfc6712bis-03>.
[I-D.ietf-netconf-sztp-csr]
Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14,
2 March 2022, <https://datatracker.ietf.org/doc/html/
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:2013, 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 Std 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://ieeexplore.ieee.org/document/8423794>. <https://ieeexplore.ieee.org/document/8423794>.
[NIST.CSWP.04162018] [NIST.CSWP.04162018]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Framework for Improving Critical Infrastructure "Framework for Improving Critical Infrastructure
Cybersecurity, Version 1.1", NIST NIST.CSWP.04162018, Cybersecurity", Version 1.1,
DOI 10.6028/NIST.CSWP.04162018, April 2018, DOI 10.6028/NIST.CSWP.04162018, April 2018,
<http://nvlpubs.nist.gov/nistpubs/CSWP/ <http://nvlpubs.nist.gov/nistpubs/CSWP/
NIST.CSWP.04162018.pdf>. NIST.CSWP.04162018.pdf>.
[NIST.SP.800-57p1r5] [NIST.SP.800-57p1r5]
Barker, E B., "Recommendation for key management, part 1 Barker, E., "Recommendation for Key Management: Part 1 -
:general", NIST NIST.SP.800-57pt1r5, General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
DOI 10.6028/NIST.SP.800-57pt1r5, 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>. <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[PKIX-CMP] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", Work in Progress, Internet-
Draft, draft-ietf-lamps-rfc4210bis-07, 19 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
rfc4210bis-07>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>. <https://www.rfc-editor.org/info/rfc3647>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <https://www.rfc-editor.org/info/rfc5753>. 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
skipping to change at page 96, line 12 skipping to change at line 4349
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RFC8649] Housley, R., "Hash Of Root Key Certificate Extension", [RFC8649] Housley, R., "Hash Of Root Key Certificate Extension",
RFC 8649, DOI 10.17487/RFC8649, August 2019, RFC 8649, DOI 10.17487/RFC8649, August 2019,
<https://www.rfc-editor.org/info/rfc8649>. <https://www.rfc-editor.org/info/rfc8649>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>. May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[SZTP-CSR] Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14,
2 March 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-14>.
[UNISIG.Subset-137] [UNISIG.Subset-137]
UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
FFFIS; V1.0.0", December 2015, 137, V1.0.0, December 2015,
<https://www.era.europa.eu/sites/default/files/filesystem/ <https://www.era.europa.eu/system/files/2023-01/
ertms/ccs_tsi_annex_a_-_mandatory_specifications/ sos3_index083_-_subset-137_v100.pdf>.
set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
_subset-137_v100.pdf>.
Appendix A. Example CertReqTemplate Appendix A. Example CertReqTemplate
Suppose the server requires that the certTemplate contains Suppose the server requires that the certTemplate contains:
* the issuer field with a value to be filled in by the EE, * the issuer field with a value to be filled in by the EE,
* the subject field with a common name to be filled in by the EE and * the subject field with a common name to be filled in by the EE and
two organizational unit fields with given values "myDept" and two organizational unit fields with given values "myDept" and
"myGroup", "myGroup",
* the publicKey field contains an ECC key on curve secp256r1 or an * the publicKey field contains an Elliptic Curve Cryptography (ECC)
RSA public key of length 2048, key on curve secp256r1 or an RSA public key of length 2048,
* the subjectAltName extension with DNS name "www.myServer.com" and * the subjectAltName extension with DNS name "www.myServer.com" and
an IP address to be filled in, an IP address to be filled in,
* the keyUsage extension marked critical with the value * the keyUsage extension marked critical with the value
digitalSignature and keyAgreement, and digitalSignature and keyAgreement, and
* the extKeyUsage extension with values to be filled in by the EE. * the extKeyUsage extension with values to be filled in by the EE.
Then the infoValue with certTemplate and keySpec fields returned to Then the infoValue with certTemplate and keySpec fields returned to
skipping to change at page 98, line 37 skipping to change at line 4475
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 Acknowledgements
Note: This appendix will be deleted in the final version of the
document.
From version 20 -> 21:
* Addressed comment from Murray checking each usage of key word
"SHOULD" and changing it to "MUST", "MAY", or "should" where
needed or adding an explanation how interoperability may be
affected (see thread "Murray Kucherawy's No Objection on draft-
ietf-lamps-lightweight-cmp-profile-18: (with COMMENT)")
* Some minor editorial changes
From version 19 -> 20:
* Addressed comment from John (see thread "[IANA #1261900] expert
review for draft-ietf-lamps-lightweight-cmp-profile (cmp)")
From version 18 -> 19:
* Addressed comment from Murray, moving section 'Convention and
Terminology' after Section 1.1 and adding a paragraph on the use
of key word "SHOULD", moving section 'Compatibility with Existing
CMP Profiles' right before section 'Use of CMP in SZTP and BRSKI
Environments', and adding a paragraph to section 'Scope of this
Document' also clarifying the use of key word "SHOULD" (see thread
"Murray Kucherawy's No Objection on draft-ietf-lamps-lightweight-
cmp-profile-18: (with COMMENT)")
* Updated Section 4.1.6 to reflect the changes to CMP Updates on
guidance which CMS key management technique to use with central
key management (see thread "CMS: selection of key management
technique to use for EnvelopedData") and removed normative
language regarding which key management technique to support
From version 17 -> 18:
* Addressed comment from Paul (see thread "Paul Wouters' Yes on
draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")
* Updated Section 4.3.4 with one minor correction and one
clarification (see thread "Minor change to draft-ietf-lamps-
lightweight-cmp-profile-17 on Section 4.3.4 CRL Update Retrieval")
From version 16 -> 17:
* Addressed comment from Paul (see thread "Paul Wouters' Yes on
draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)")
* Addressed comment from Robert (see thread "Robert Wilton's No
Objection on draft-ietf-lamps-lightweight-cmp-profile-16: (with
COMMENT)")
From version 15 -> 16:
* Addressed comment from Warren (see thread "Warren Kumari's No
Record on draft-ietf-lamps-lightweight-cmp-profile-15: (with
COMMENT)")
* Addressed comment from Sheng (see thread "Intdir telechat review
of draft-ietf-lamps-lightweight-cmp-profile-15")
* Addressed comment from Niklas (see thread "Iotdir telechat review
of draft-ietf-lamps-lightweight-cmp-profile-15")
* Addressed comment from Erik (see thread "Erik Kline's No Objection
on draft-ietf-lamps-lightweight-cmp-profile-15: (with COMMENT)")
* Streamlined wording in two ASN.1 comments
From version 14 -> 15:
* Added a reference to HashOfRootKey extension to note in
Section 3.3
* Addressed comment from Joel (see thread "Genart last call review
of draft-ietf-lamps-lightweight-cmp-profile-14")
* Addressed comment from Robert (see thread "Artart last call review
of draft-ietf-lamps-lightweight-cmp-profile-14")
From version 13 -> 14:
* Addressed comments from AD Evaluation (see thread "AD Review of
draft-ietf-lamps-lightweight-cmp-profile-13")
* Added a note to Section 1 informing about rfc4210bis and
rfc6712bis activity
* Added support for constrained PKI entities that can, e.g., only
store a hash of a self-signed certificate as trust anchor and
require the self-signed certificate to be provided in-line in
extraCerts, see Section 3.3 and Section 9
* Addressed idnits feedback, specifically changing the following RFC
reference: RFC3278 -> RFC5753
From version 12 -> 13:
* Some minor clarifications regarding 'exactly one element' ->
'sequence of one element'
* Adding authors contact details
From version 11 -> 12:
* Added a note to Section 4.1.6 to clarify the combination of
central key generation with certificate update
* Updated Section 4.3.4 for clarification that only one CRL per
round-trip is requested
* Updated Section 7.1 to fix a wrong change from the last update in
the first two rows of Table 3
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:
* Resolved some nits reported by I-D nit checker tool
* Resolve some wording issues
From version 08 -> 09:
* 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
draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-
cmp-profile-08")
* Updated Section 3.1 and 4.1.1 making implicitConfirm recommended
for ir/cr/p10cr/kur and providing further recommendations on its
use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp-
updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")
* Updated Section 4.1.6 adding some clarifications regarding
validating the authorization of centrally generated keys
* Updated Section 4.3.4 adding some clarifications on CRL update
retrieval (see thread "CRL update retrieval - WG Last Call for
draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-
cmp-profile-08")
* Updated references to CMP Updates pointing to concrete sections
(see thread "CRL update retrieval - WG Last Call for draft-ietf-
lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-
08"))
* Corrected a couple of nits elsewhere
From version 07 -> 08:
* Updates Section 4.1.6.1. regarding content of the originator and
keyEncryptionAlgorithm fields (see thread "AD review of draft-
ietf-lamps-cmp-algorithms-07")
* Rolled back part of the changes on root CA certificate updates in
Section 4.3.2 (see thread "Allocation of OIDs for CRL update
retrieval (draft-ietf-lamps-cmp-updates-13)")
From version 06 -> 07:
* Added references to [draft-ietf-netconf-sztp-csr] in new
Section 1.5 and Section 4.1.4
* Added reference to [I-D.ietf-anima-brski-ae] in new Section 1.5
and Section 4.1.1
* Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as
the PUSH use case is continued to be discussed in this draft after
the split of BRSKI-AE
* Improved note regarding UNISIG Subset-137 in Section 1.6
* Removed "rootCaCert" in Section 3.1 and updated the structure of
the genm request for root CA certificate updates in Section 4.3.2.
* Simplified handling of sender and recipient nonces in case of
delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2
* Changed the order of Sections 4.1.4 and 4.1.5
* Added reference on RFC 8933 regarding CMS signedAttrs to
Section 4.1.6
* Added Section 4.3.4 on CRL update retrieval
* Generalized delayed enrollment to delayed delivery in Section 4.4
and 5.1.2, updated the state machine in the introduction of
Section 4
* Updated Section 6 regarding delayed message transfer
* Changed file name extension from ".PKI" to ".pki", deleted
operational path for central key generation, and added an
operational path for CRL update retrieval in Sections 6.1 and 6.2
* Shifted many security considerations to CMP Updates
* Replaced the term "transport" by "transfer" where appropriate to
prevent confusion regarding TCP vs. HTTP and CoAP
* Various editorial changes and language corrections
From version 05 -> 06:
* Changed in Section 2.3 the normative requirement in of adding
protection to a single message to mandatory and replacing
protection to optional
* Added Section 3.4 specifying generic prerequisites to PKI
management operations
* Added Section 3.5 specifying generic message validation
* Added Section 3.6 on generic error reporting. This section
replaces the former error handling section from Section 4 and 5.
* Added reference to using hashAlg
* Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates
* Added Section 5.1 specifying the behavior of PKI management
entities when responding to requests
* Reworked Section 5.2.3. on usage of nested messages
* Updates Section 5.3 on performing PKI management operation on
behalf of another entity
* Updates Section 6.2 on HTTPS transport of CMP messages as
discusses at IETF 110 and email thread "I-D Action: draft-ietf-
lamps-lightweight-cmp-profile-05.txt"
* Added CoAP endpoints to Section 6.4
* Added security considerations on usage of shared secret
information
* Updated the example in Appendix A
* Added newly registered OIDs to the example in Appendix A
* Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs
* Multiple language corrections, clarifications, and changes in
wording
From version 04 -> 05:
* Changed to XML V3
* Added algorithm names introduced in CMP Algorithms Section 7.3 to
Section 4 of this document
* Updates Syntax in Section 4.4.3 due to changes made in CMP Updates
* Deleted the text on HTTP-based discovery as discussed in
Section 6.1
* Updates Appendix A due to change syntax in Section 4.4.3
* Many clarifications and changes in wording thanks to David's
extensive review
From version 03 -> 04:
* Deleted normative text sections on algorithms and refer to CMP
Algorithms and CRMF Algorithm Requirements Update instead
* Some clarifications and changes in wording
From version 02 -> 03:
* Updated the interoperability with [UNISIG.Subset-137] in
Section 1.4.
* Changed Section 2.3 to a tabular layout to enhanced readability
* Added a ToDo to section 3.1 on aligning with the CMP Algorithms
draft that will be set up as decided in IETF 108
* Updated section 4.1.6 to add the AsymmetricKey Package structure
to transport a newly generated private key as decided in IETF 108
* Added a ToDo to section 4.1.7 on required review of the nonce
handling in case an offline LRA responds and not forwards the
pollReq messages
* Updated Section 4 due to the definition of the new ITAV OIDs in
CMP Updates
* Updated Section 4.4.4 to utilize controls instead of rsaKeyLen
(see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen")
* Deleted the section on definition and discovery of HTTP URIs and
copied the text to the HTTP transport section and to CMP Updates
section 3.2
* Added some explanation to Section 5.1.2 and Section 5.1.3 on using
nested messages when a protection by the RA is required.
* Deleted the section on HTTP URI definition and discovery as some
content was moved to CMP Updates. The rest of the content was
moved back to the HTTP transport section
* Deleted the ASN.1 module after moving the new OIDs id-it-caCerts,
id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates
* Minor changes in wording and addition of some open ToDos
From version 01 -> 02:
* Extend Section 1.6 with regard to conflicts with UNISIG Subset-
137.
* Minor clarifications on extraCerts in Section 3.3 and
Section 4.1.1.
* Complete specification of requesting a certificate from a trusted
PKI with signature protection in Section 4.1.2.
* Changed from symmetric key-encryption to password-based key
management technique in Section 4.1.6.3 as discussed on the
mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.1.6.1")
* Changed delayed enrollment described in Section 4.4 from
recommended to optional as decided at IETF 107
* Introduced the new RootCAKeyUpdate structure for root CA
certificate update in Section 4.3.2 as decided at IETF 107 (also
see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
section 5.4.3")
* Extend the description of the CertReqTemplate PKI management
operation, including an example added in the Appendix. Keep
rsaKeyLen as a single integer value in Section 4.3.3 as discussed
on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.4.4")
* Deleted Sections "Get certificate management configuration" and
"Get enrollment voucher" as decided at IETF 107
* Complete specification of adding an additional protection by an
PKI management entity in Section 5.2.2.
* Added a section on HTTP URI definition and discovery and extended
Section 6.1 on definition and discovery of supported HTTP URIs and
content types, add a path for nested messages as specified in
Section 5.2.2 and delete the paths for /getCertMgtConfig and
/getVoucher
* Changed Section 6.4 to address offline transport and added more
detailed specification file-based transport of CMP
* Added a reference to the new I-D of Mohit Sahni on "CoAP Transport
for CMPV2" in Section 6.2; thanks to Mohit supporting the effort
to ease utilization of CMP
* Moved the change history to the Appendix
* Minor changes in wording
From version 00 -> 01:
* Harmonize terminology with CMP [RFC4210], e.g.,
- transaction, message sequence, exchange, use case -> PKI
management operation
- PKI component, (L)RA/CA -> PKI management entity
* Minor changes in wording
From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf-
lamps-lightweight-cmp-profile-00:
* Changes required to reflect WG adoption
* Minor changes in wording
From version 02 -> 03:
* Added a short summary of [RFC4210] Appendix D and E in
Section 1.5.
* Clarified some references to different sections and added some
clarification in response to feedback from Michael Richardson and
Tomas Gustavsson.
* Added an additional label to the operational path to address
multiple CAs or certificate profiles in Section 6.1.
From version 01 -> 02:
* Added some clarification on the key management techniques for
protection of centrally generated keys in Section 4.1.6.
* Added some clarifications on the certificates for root CA
certificate update in Section 4.3.2.
* Added a section to specify the usage of nested messages for RAs to
add an additional protection for further discussion, see
Section 5.2.2.
* Added a table containing endpoints for HTTP transport in
Section 6.1 to simplify addressing PKI management entities.
* Added some ToDos resulting from discussion with Tomas Gustavsson.
* Minor clarifications and changes in wording.
From version 00 -> 01:
* Added a section to specify the enrollment with an already trusted
PKI for further discussion, see Section 4.1.2.
* Complete specification of requesting a certificate from a legacy
PKI using a PKCS#10 [RFC2986] request in Section 4.1.4.
* Complete specification of adding central generation of a key pair
on behalf of an end entity in Section 4.1.6.
* Complete specification of handling delayed enrollment due to
asynchronous message delivery in Section 4.4.
* Complete specification of additional support messages, e.g., to
update a Root CA certificate or to request an RFC 8366 [RFC8366]
voucher, in Section 4.3.
* Minor changes in wording.
From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft-
brockhaus-lamps-lightweight-cmp-profile-00:
* Change focus from industrial to more multi-purpose use cases and We thank the various reviewers of this document.
lightweight CMP profile.
* Incorporate the omitted confirmation into the header specified in
Section 3.1 and described in the standard enrollment use case in
Section 4.1.1 due to discussion with Tomas Gustavsson.
* Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's
entities certificate' in Section 5.3.2, because it is regarded as
important functionality in many environments to enable the
management station to revoke EE certificates.
* Complete the specification of the revocation message flow in
Section 4.2 and Section 5.3.2.
* The CoAP based transport mechanism and piggybacking of CMP
messages on top of other reliable transport protocols is out of
scope of this document and would need to be specified in another
document.
* Further minor changes in wording.
Authors' Addresses Authors' Addresses
Hendrik Brockhaus Hendrik Brockhaus
Siemens Siemens
Werner-von-Siemens-Strasse 1 Werner-von-Siemens-Strasse 1
80333 Munich 80333 Munich
Germany Germany
Email: hendrik.brockhaus@siemens.com Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com URI: https://www.siemens.com
 End of changes. 484 change blocks. 
1632 lines changed or deleted 1265 lines changed or added

This html diff was produced by rfcdiff 1.48.