draft-ietf-lamps-lightweight-cmp-profile-08.txt   draft-ietf-lamps-lightweight-cmp-profile-09.txt 
LAMPS Working Group H. Brockhaus, Ed. LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft D. von Oheimb Internet-Draft D. von Oheimb
Intended status: Standards Track S. Fries Intended status: Standards Track S. Fries
Expires: 23 May 2022 Siemens Expires: 20 June 2022 Siemens
19 November 2021 17 December 2021
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-08 draft-ietf-lamps-lightweight-cmp-profile-09
Abstract Abstract
This document aims at simple, interoperable, and automated PKI This document aims at simple, interoperable, and automated PKI
management operations covering typical use cases of industrial and management operations covering typical use cases of industrial and
IoT scenarios. This is achieved by profiling the Certificate IoT scenarios. This is achieved by profiling the Certificate
Management Protocol (CMP), the related Certificate Request Message Management Protocol (CMP), the related Certificate Request Message
Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
but sufficiently detailed and self-contained way. To make secure but sufficiently detailed and self-contained way. To make secure
certificate management for simple scenarios and constrained devices certificate management for simple scenarios and constrained devices
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 May 2022. This Internet-Draft will expire on 20 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4
1.2. Motivation for a lightweight profile of CMP . . . . . . . 4 1.2. Motivation for a lightweight profile of CMP . . . . . . . 5
1.3. Special requirements of industrial and IoT scenarios . . 5 1.3. Special requirements of industrial and IoT scenarios . . 6
1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7
1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7
1.6. Compatibility with existing CMP profiles . . . . . . . . 7 1.6. Compatibility with existing CMP profiles . . . . . . . . 8
1.7. Scope of this document . . . . . . . . . . . . . . . . . 9 1.7. Scope of this document . . . . . . . . . . . . . . . . . 9
1.8. Structure of this document . . . . . . . . . . . . . . . 9 1.8. Structure of this document . . . . . . . . . . . . . . . 10
1.9. Convention and Terminology . . . . . . . . . . . . . . . 10 1.9. Convention and Terminology . . . . . . . . . . . . . . . 11
2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12
2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 3. Generic aspects of the PKI message . . . . . . . . . . . . . 13
2.2. Supported PKI management operations . . . . . . . . . . . 13 3.1. General description of the CMP message header . . . . . . 14
2.2.1. Mandatory PKI management operations . . . . . . . . . 13 3.2. General description of the CMP message protection . . . . 16
2.2.2. Recommended PKI management operations . . . . . . . . 14 3.3. General description of CMP message extraCerts . . . . . . 17
2.2.3. Optional PKI management operations . . . . . . . . . 15 3.4. Generic PKI management operation prerequisites . . . . . 17
2.3. CMP message transfer . . . . . . . . . . . . . . . . . . 16 3.5. Generic validation of a PKI message . . . . . . . . . . . 19
3. Generic aspects of the PKI message . . . . . . . . . . . . . 17 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21
3.1. General description of the CMP message header . . . . . . 18 3.6.1. Reporting error conditions upstream . . . . . . . . . 21
3.2. General description of the CMP message protection . . . . 20 3.6.2. Reporting error conditions downstream . . . . . . . . 22
3.3. General description of CMP message extraCerts . . . . . . 20
3.4. Generic PKI management operation prerequisites . . . . . 21
3.5. Generic validation of a PKI message . . . . . . . . . . . 22
3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 24
3.6.1. Reporting error conditions upstream . . . . . . . . . 24
3.6.2. Reporting error conditions downstream . . . . . . . . 25
3.6.3. Handling error conditions on nested messages used for 3.6.3. Handling error conditions on nested messages used for
batching . . . . . . . . . . . . . . . . . . . . . . 25 batching . . . . . . . . . . . . . . . . . . . . . . 22
3.6.4. Reporting error conditions . . . . . . . . . . . . . 26 3.6.4. Reporting error conditions . . . . . . . . . . . . . 22
4. End Entity PKI management operations . . . . . . . . . . . . 28 4. End Entity PKI management operations . . . . . . . . . . . . 24
4.1. Requesting a new certificate from a PKI . . . . . . . . . 31 4.1. Requesting a new certificate from a PKI . . . . . . . . . 27
4.1.1. Requesting a certificate from a new PKI with 4.1.1. Requesting a certificate from a new PKI with
signature-based protection . . . . . . . . . . . . . 32 signature-based protection . . . . . . . . . . . . . 28
4.1.2. Requesting an additional certificate with 4.1.2. Requesting an additional certificate with
signature-based protection . . . . . . . . . . . . . 38 signature-based protection . . . . . . . . . . . . . 34
4.1.3. Updating an existing certificate with signature 4.1.3. Updating an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 39 protection . . . . . . . . . . . . . . . . . . . . . 35
4.1.4. Requesting a certificate from a legacy PKI using a 4.1.4. Requesting a certificate from a legacy PKI using a
PKCS#10 request . . . . . . . . . . . . . . . . . . . 40 PKCS#10 request . . . . . . . . . . . . . . . . . . . 36
4.1.5. Requesting a certificate from a PKI with MAC-based 4.1.5. Requesting a certificate from a PKI with MAC-based
protection . . . . . . . . . . . . . . . . . . . . . 42 protection . . . . . . . . . . . . . . . . . . . . . 38
4.1.6. Adding central key pair generation to a certificate 4.1.6. Adding central key pair generation to a certificate
request . . . . . . . . . . . . . . . . . . . . . . . 43 request . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.6.1. Using key agreement key management technique . . 48
4.1.6.2. Using key transport key management technique . . 50 4.1.6.1. Using key agreement key management technique . . 45
4.1.6.3. Using password-based key management technique . . 50 4.1.6.2. Using key transport key management technique . . 46
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 51 4.1.6.3. Using password-based key management technique . . 47
4.3. Support messages . . . . . . . . . . . . . . . . . . . . 54 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48
4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 56 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 50
4.3.2. Get root CA certificate update . . . . . . . . . . . 56 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 53
4.3.3. Get certificate request template . . . . . . . . . . 58 4.3.2. Get root CA certificate update . . . . . . . . . . . 53
4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 60 4.3.3. Get certificate request template . . . . . . . . . . 55
4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 62 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 57
5. PKI management entity operations . . . . . . . . . . . . . . 66 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 59
5.1. Responding to requests . . . . . . . . . . . . . . . . . 66 5. PKI management entity operations . . . . . . . . . . . . . . 64
5.1.1. Responding to a certificate request . . . . . . . . . 67 5.1. Responding to requests . . . . . . . . . . . . . . . . . 64
5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 67 5.1.1. Responding to a certificate request . . . . . . . . . 65
5.1.3. Responding to a confirmation message . . . . . . . . 68 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 65
5.1.4. Responding to a revocation request . . . . . . . . . 68 5.1.3. Responding to a confirmation message . . . . . . . . 66
5.1.5. Responding to a support message . . . . . . . . . . . 69 5.1.4. Responding to a revocation request . . . . . . . . . 66
5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 69 5.1.5. Responding to a support message . . . . . . . . . . . 67
5.2.1. Not changing protection . . . . . . . . . . . . . . . 71 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 67
5.2.2. Adding protection and batching of messages . . . . . 71 5.2.1. Not changing protection . . . . . . . . . . . . . . . 69
5.2.2.1. Adding protection to a request message . . . . . 72 5.2.2. Adding protection and batching of messages . . . . . 69
5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 73 5.2.2.1. Adding protection to a request message . . . . . 70
5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 71
5.2.3.1. Not changing any included proof-of-possession . . 75 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 73
5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76 5.2.3.1. Not changing any included proof-of-possession . . 73
5.3. Acting on behalf of other PKI entities . . . . . . . . . 76 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 74
5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77 5.3. Acting on behalf of other PKI entities . . . . . . . . . 74
5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 77 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 75
6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 78 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 75
6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 79 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 76
6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 81 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 77
6.3. Piggybacking on other reliable transfer . . . . . . . . . 83 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 79
6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 83 6.3. Piggybacking on other reliable transfer . . . . . . . . . 81
6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 83 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 81
6.4.2. Other asynchronous transfer protocols . . . . . . . . 84 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 82
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 6.4.2. Other asynchronous transfer protocols . . . . . . . . 82
8. Security Considerations . . . . . . . . . . . . . . . . . . . 84 7. Conformance requirements . . . . . . . . . . . . . . . . . . 82
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 7.1. PKI management operations . . . . . . . . . . . . . . . . 82
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.2. Message transfer . . . . . . . . . . . . . . . . . . . . 85
10.1. Normative References . . . . . . . . . . . . . . . . . . 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
10.2. Informative References . . . . . . . . . . . . . . . . . 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 86
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 86
Appendix B. History of changes . . . . . . . . . . . . . . . . . 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 87
11.2. Informative References . . . . . . . . . . . . . . . . . 88
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 91
Appendix B. History of changes . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98
1. Introduction 1. Introduction
[RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC-
CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of
CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms], when available. [I-D.ietf-lamps-cmp-algorithms], when available.
This document specifies PKI management operations supporting machine- This document specifies PKI management operations supporting machine-
to-machine and IoT use cases. Its focus is to maximize automation to-machine and IoT use cases. Its focus is to maximize automation
skipping to change at page 4, line 39 skipping to change at page 4, line 37
document aims at tailoring the available options and specifying at an document aims at tailoring the available options and specifying at an
adequate detail how to use them to make the implementation of adequate detail how to use them to make the implementation of
interoperable automated certificate management as straightforward and interoperable automated certificate management as straightforward and
lightweight as possible. lightweight as possible.
1.1. How to Read This Document 1.1. How to Read This Document
This document has become longer than the authors would have liked it This document has become longer than the authors would have liked it
to be. Yet apart from studying Section 3, which contains general to be. Yet apart from studying Section 3, which contains general
requirements, the reader does not have to work through the whole requirements, the reader does not have to work through the whole
document but can use the guidance in Section 1.8, Section 2.2, and document. The guidance in Section 1.8 and Section 7 should be used
Section 2.3 to figure out which parts of Section 4 to Section 6 are to figure out which parts of Section 4 to Section 6 are relevant for
relevant, depending on the PKI management operations and options of the target certificate management solution depending on the PKI
interest. management operations, their variants, and types of message transfer
needed.
Since conformity to this document can be achieved by implementing
only the functionality declared mandatory in Section 7, the profile
can still be called lightweight because in particular for end
entities the mandatory-to-implement set of features is rather
limited.
1.2. Motivation for a lightweight profile of CMP 1.2. Motivation for a lightweight profile of CMP
CMP was standardized in 1999 and is implemented in several PKI CMP was standardized in 1999 and is implemented in several PKI
products. In 2005, a completely reworked and enhanced version 2 of products. In 2005, a completely reworked and enhanced version 2 of
CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a
document specifying a transfer mechanism for CMP messages using HTTP document specifying a transfer mechanism for CMP messages using HTTP
[RFC6712] in 2012. [RFC6712] in 2012.
Though CMP is a solid and very capable protocol it is so far not used Though CMP is a solid and very capable protocol it is so far not used
very widely. The most important reason appears to be that the very widely. The most important reason appears to be that the
protocol offers a too large set of features and options. On the one protocol offers a too large set of features and options. On the one
hand, this makes CMP applicable to a very wide range of scenarios, hand, this makes CMP applicable to a very wide range of scenarios,
but on the other hand, a full implementation supporting all options but on the other hand, a full implementation supporting all options
is not realistic because this would take undue effort. is not realistic because this would take undue effort.
In order to reduce complexity, the set of mandatory PKI management
operations and variants required by this specification has been kept
lean. This limits development effort and minimizes resource needs,
which is particularly important for memory-constrained devices. To
this end, when there was a choice to have necessary complexity more
on the EE or PKI management entity side, it has been pushed towards
PKI management entities, where typically more computational resources
are available and the development can be consolidated better.
Additional recommended PKI management operations and variants support
some more complex scenarios that are considered beneficial for
environments with more specific demands or boundary conditions. The
optional PKI management operations support less common scenarios and
requirements.
Moreover, many details of the CMP protocol have been left open or Moreover, many details of the CMP protocol have been left open or
have not been specified in full preciseness. The profiles specified have not been specified in full preciseness. The profiles specified
in Appendix D and E of [RFC4210] define some more detailed PKI in Appendix D and E of [RFC4210] define some more detailed PKI
management operations. Yet, the specific needs of highly automated management operations. Yet, the specific needs of highly automated
scenarios for a machine-to-machine communication are not covered scenarios for a machine-to-machine communication are not covered
sufficiently. sufficiently.
As also 3GPP and UNISIG already put across, profiling is a way of As also 3GPP and UNISIG already put across, profiling is a way of
coping with the challenges mentioned above. To profile means to take coping with the challenges mentioned above. To profile means to take
advantage of the strengths of the given protocol, while explicitly advantage of the strengths of the given protocol, while explicitly
skipping to change at page 5, line 49 skipping to change at page 6, line 22
The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have
been developed particularly for managing certificates of human end been developed particularly for managing certificates of human end
entities. With the evolution of distributed systems and client- entities. With the evolution of distributed systems and client-
server architectures, certificates for machines and applications on server architectures, certificates for machines and applications on
them have become widely used. This trend has strengthened even more them have become widely used. This trend has strengthened even more
in emerging industrial and IoT scenarios. CMP is sufficiently in emerging industrial and IoT scenarios. CMP is sufficiently
flexible to support them well. flexible to support them well.
Today's IT security architectures for industrial solutions typically Today's IT security architectures for industrial solutions typically
use certificates for endpoint authentication within protocols like use certificates for endpoint authentication within protocols like
IPSec, TLS, or SSH. Therefore, the security of these architectures IPsec, TLS, or SSH. Therefore, the security of these architectures
highly relies upon the security and availability of the implemented highly relies upon the security and availability of the implemented
certificate management operations. certificate management operations.
Due to increasing security needs in operational networks as well as Due to increasing security needs in operational networks as well as
availability requirements, especially on critical infrastructures and availability requirements, especially on critical infrastructures and
systems with a high 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, the NIST Framework for Improving Critical
Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper
skipping to change at page 6, line 45 skipping to change at page 7, line 22
scenarios. scenarios.
Both Appendixes D and E focus on EE-to-RA/CA PKI management Both Appendixes D and E focus on EE-to-RA/CA PKI management
operations and do not address further profiling of RA-to-CA operations and do not address further profiling of RA-to-CA
communication as typically needed for full backend automation. All communication as typically needed for full backend automation. All
requirements regarding algorithm support for RFC 4210 Appendix D and requirements regarding algorithm support for RFC 4210 Appendix D and
E [RFC4210] have been updated by CMP Algorithms Section 7.1 E [RFC4210] have been updated by CMP Algorithms Section 7.1
[I-D.ietf-lamps-cmp-algorithms]. [I-D.ietf-lamps-cmp-algorithms].
3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310
[ETSI-3GPP.33.310] for automatic management of IPSec certificates in [ETSI-3GPP.33.310] for automatic management of IPsec certificates in
3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP
profile for initial certificate enrollment and certificate update profile for initial certificate enrollment and certificate update
operations between EE and RA/CA is specified in that document. operations between EE and RA/CA is specified in that document.
UNISIG has included a CMP profile for enrollment of TLS certificates UNISIG has included a CMP profile for enrollment of TLS certificates
in the Subset-137 specifying the ETRAM/ETCS on-line key management in the Subset-137 specifying the ETRAM/ETCS on-line key management
for train control systems [UNISIG.Subset-137] in 2015. for train control systems [UNISIG.Subset-137] in 2015.
Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and
HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI
skipping to change at page 10, line 26 skipping to change at page 10, line 49
Section 5 profiles responding to requests, exchange between PKI Section 5 profiles responding to requests, exchange between PKI
management entities, and operations on behalf of other PKI entities. management entities, and operations on behalf of other PKI entities.
This may include delayed delivery of messages, which involves polling This may include delayed delivery of messages, which involves polling
for 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 [RFC6712] transfer optionally using TLS, and including HTTP-based [RFC6712] transfer optionally using TLS, and
[I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS, [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS,
and offline file-based transport. and offline file-based transport.
Section 7 defines which parts of the profile are mandatory,
recommended, optional, or not relevant to implement for which type of
entity.
1.9. Convention and Terminology 1.9. Convention and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Technical terminology is used in conformance with RFC 4210 [RFC4210], Technical terminology is used in conformance with RFC 4210 [RFC4210],
RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR
skipping to change at page 11, line 26 skipping to change at page 12, line 5
PKI management operation: All CMP messages belonging to a single PKI management operation: All CMP messages belonging to a single
transaction. The transaction is transaction. The transaction is
identified by the transactionID field of identified by the transactionID field of
the message headers. the message headers.
PKI management entity: A non-EE PKI entity, i.e., RA or CA. PKI management entity: A non-EE PKI entity, i.e., RA or CA.
PKI entity: An EE or PKI management entity. PKI entity: An EE or PKI management entity.
2. Architecture and use cases 2. Solution architecture
2.1. 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 IDevID certificate
and an operational certificate is called LDevID certificate. and an operational certificate is called LDevID certificate.
Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises
the triple of the certificate, the corresponding private key, and the the triple of the certificate, the corresponding private key, and the
certificate chain. 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., 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
skipping to change at page 13, line 21 skipping to change at page 13, line 36
the messages specified in this profile offer all required the messages specified in this profile offer all required
capabilities, but the message flow and state machine as described in capabilities, but the message flow and state machine as described in
Section 4 must be adapted to implement a push model. Section 4 must be adapted to implement a push model.
Third-party CAs may implement other variants of CMP, different Third-party CAs may implement other variants of CMP, different
standardized protocols, or even proprietary interfaces for standardized protocols, or even proprietary interfaces for
certificate management. Therefore, the RA may need to adapt the certificate management. Therefore, the RA may need to adapt the
exchanged CMP messages to the flavor of certificate management exchanged CMP messages to the flavor of certificate management
interaction required by the CA. interaction required by the CA.
2.2. Supported PKI management operations
Following the scope outlined in Section 1.7, this section gives a
brief overview of the base PKI management operations and their
variants specified in Section 4 and Section 5 and states whether
implementation by compliant EEs or PKI management entities is
mandatory, recommended, or optional. Variants amend or change
behavior of base PKI management operations and are therefore also
listed here.
2.2.1. Mandatory PKI management operations
The set of mandatory PKI management operations in this document is
intentionally lean to help for keeping development effort low and to
enable use in memory-constrained devices.
+=====================================+=========+
| PKI management operations | Section |
+=====================================+=========+
| Requesting a certificate from a new | Section |
| PKI with signature-based protection | 4.1.1 |
+-------------------------------------+---------+
| Updating an existing certificate | Section |
| with signature-based protection | 4.1.3 |
+-------------------------------------+---------+
Table 1: Mandatory End Entity PKI management
operations
+===============================================+=================+
| PKI management operations | Section |
+===============================================+=================+
| Responding to a certificate request | Section 5.1 |
+-----------------------------------------------+-----------------+
| Responding to a confirmation message | Section 5.1.3 |
+-----------------------------------------------+-----------------+
| Forwarding messages - not changing protection | Section 5.2.1 |
+-----------------------------------------------+-----------------+
| Adding protection to a request message | Section 5.2.2.1 |
+-----------------------------------------------+-----------------+
Table 2: Mandatory PKI management entity operations
2.2.2. Recommended PKI management operations
Additional recommended PKI management operations support some more
complex scenarios, that are considered beneficial for environments
with more specific demand or boundary conditions.
+=================================+=========+
| PKI management operations | Section |
+=================================+=========+
| Requesting a certificate from a | Section |
| PKI with MAC-based protection | 4.1.5 |
+---------------------------------+---------+
| Revoking a certificate | Section |
| | 4.2 |
+---------------------------------+---------+
Table 3: Recommended End Entity PKI
management operations
+====================================+===============+
| PKI management operations | Section |
+====================================+===============+
| Responding to a revocation request | Section 5.1.4 |
+------------------------------------+---------------+
| Acting on behalf of other PKI | Section 5.3.2 |
| entities - revoking a certificate | |
+------------------------------------+---------------+
Table 4: Recommended PKI management entity operations
2.2.3. Optional PKI management operations
The optional PKI management operations support specific scenarios
seen only in some environments with specific requirements.
+========================================================+=========+
| PKI management operations and variants | Section |
+========================================================+=========+
| Requesting an additional certificate with signature- | Section |
| based protection | 4.1.2 |
+--------------------------------------------------------+---------+
| Requesting a certificate from a legacy PKI using a | Section |
| PKCS#10 request | 4.1.4 |
+--------------------------------------------------------+---------+
| Adding central key generation to a certificate | Section |
| request. (If central key generation is supported, the | 4.1.6 |
| key agreement key management technique is REQUIRED to | |
| be supported, and the key transport and password-based | |
| key management techniques are OPTIONAL.) | |
+--------------------------------------------------------+---------+
| Support messages | Section |
| | 4.3 |
+--------------------------------------------------------+---------+
| Handling delayed delivery | Section |
| | 4.4 |
+--------------------------------------------------------+---------+
| Acting on behalf of other PKI entities - requesting | Section |
| certificates | 5.3.1 |
+--------------------------------------------------------+---------+
Table 5: Optional End Entity PKI management operations
+===============================================+===============+
| PKI management operations and variants | Section |
+===============================================+===============+
| Initiating delayed delivery | Section 5.1.2 |
+-----------------------------------------------+---------------+
| Forwarding messages - replacing protection, | Section |
| not changing any included proof-of-possession | 5.2.3.1 |
+-----------------------------------------------+---------------+
| Forwarding messages - replacing protection, | Section |
| breaking proof-of-possession | 5.2.3.2 |
+-----------------------------------------------+---------------+
| Batching messages | Section |
| | 5.2.2.2 |
+-----------------------------------------------+---------------+
Table 6: Optional PKI management entity operations
2.3. CMP message transfer
On different links between PKI entities, e.g., EE-RA and RA-CA,
different transfer mechanisms MAY be used. CMP does not have
specific needs regarding message transfer, except that for each
request message sent, eventually exactly one response message should
be received. Thus, virtually any reliable transfer mechanism can be
used, e.g., HTTP, CoAP, and offline file-based transfer. Therefore,
this document does not require any specific transfer protocol to be
supported by conforming implementations.
HTTP transfer is RECOMMENDED to use for all PKI entities, yet full
flexibility is retained to choose whatever transfer mechanism is
suitable, for instance for devices and system architectures with
specific constraints.
+===============+=============+
| Transfer | Section |
+===============+=============+
| HTTP transfer | Section 6.1 |
+---------------+-------------+
Table 7: Recommended
transfer mechanisms
+=========================================+=============+
| Transfer | Section |
+=========================================+=============+
| Offline transfer | Section 6.4 |
+-----------------------------------------+-------------+
| CoAP transfer | Section 6.2 |
+-----------------------------------------+-------------+
| Piggybacking on other reliable transfer | Section 6.3 |
+-----------------------------------------+-------------+
Table 8: Optional transfer mechanisms
3. Generic aspects of the PKI message 3. Generic aspects of the PKI message
This section covers the generic aspects of the PKI management This section covers the generic aspects of the PKI management
operations specified in Section 4 and Section 5 as upfront general operations specified in Section 4 and Section 5 as upfront general
requirements to minimize redundancy in the description and to ease requirements to minimize redundancy in the description and to ease
implementation. implementation.
As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages
have the following general structure: have the following general structure:
skipping to change at page 19, line 24 skipping to change at page 15, line 51
-- 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 a
-- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and
-- MUST be consistent with the subjectPublicKeyInfo field of -- MUST be consistent with the subjectPublicKeyInfo field of
-- the protection certificate -- the 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 a MSG_MAC_ALG as
-- specified in [RFC-CMP-Alg] Section 6.1 -- specified in [RFC-CMP-Alg] Section 6.1
senderKID RECOMMENDED senderKID RECOMMENDED
-- MUST be the SubjectKeyIdentifier of the CMP protection -- MUST be the SubjectKeyIdentifier of the CMP protection
-- certificate -- certificate in case of signature-based protection
transactionID REQUIRED transactionID REQUIRED
-- In the first message of a PKI management operation: -- In the first message of a PKI management operation:
-- MUST be 128 bits of random data, to minimize the probability -- MUST be 128 bits of random data, to minimize the probability
-- of having the transactionID already in use at the server -- of having the transactionID already in use at the server
-- In all other messages: -- In all other messages:
-- MUST be the value from the previous message in the same -- MUST be the value from the previous message in the same
-- PKI management operation -- PKI management operation
senderNonce REQUIRED senderNonce REQUIRED
-- MUST be cryptographically secure and fresh 128 random bits -- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED recipNonce RECOMMENDED
-- If this is the first message of a transaction: SHOULD be -- If this is the first message of a transaction: SHOULD be
-- absent -- absent
-- If this is a delayed response message: MUST be present and -- If this is a delayed response message: MUST be present and
-- contain the value of the senderNonce of the respective request -- contain the value of the senderNonce of the respective request
-- message in the same transaction -- message in the same transaction
-- In all other messages: MUST be present and contain the value -- In all other messages: MUST be present and contain the value
-- of the senderNonce of the previous message in the same -- of the senderNonce of the previous message in the same
-- transaction -- transaction
generalInfo OPTIONAL generalInfo OPTIONAL
implicitConfirm OPTIONAL implicitConfirm OPTIONAL
-- The extension is optional in ir/cr/kur/p10cr requests and -- RECOMENDED in ir/cr/kur/p10cr messages,
-- ip/cp/kup response messages and PROHIBTED in other types of -- OPTIONAL in ip/cp/kup response messages, and
-- 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
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
skipping to change at page 20, line 40 skipping to change at page 17, line 21
there are cases where protection of error messages specified in there are cases where protection of error messages specified in
Section 3.6 is not possible and therefore MAY be omitted. Section 3.6 is not possible and therefore MAY be omitted.
For MAC-based protection as specified in Section 4.1.5 major For MAC-based protection as specified in Section 4.1.5 major
differences apply as described there. differences apply as described there.
The CMP message protection provides, if available, message origin The CMP message protection provides, if available, message origin
authentication and integrity protection for the header and body. The authentication and integrity protection for the header and body. The
CMP message extraCerts field is not covered by this protection. CMP message extraCerts field is not covered by this protection.
Note: The extended key usages described in CMP Updates Note: The extended key usages described in CMP Updates Section 2.2
[I-D.ietf-lamps-cmp-updates] can be used for authorization of a [I-D.ietf-lamps-cmp-updates] can be used for authorization of a
sending PKI management entity. sending PKI management entity.
3.3. General description of CMP message extraCerts 3.3. General description of CMP message extraCerts
This section describes the generic extraCerts field of all CMP This section describes the generic extraCerts field of all CMP
messages with signature-based protection. Any specific requirements messages with signature-based protection. Any specific requirements
on the extraCerts are specified in the respective PKI management on the extraCerts are specified in the respective PKI management
operation. operation.
skipping to change at page 28, line 47 skipping to change at page 25, line 4
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
These operations mainly specify the message body of the CMP messages These operations mainly specify the message body of the CMP messages
and utilize the specification of the message header, protection and and utilize the specification of the message header, protection and
extraCerts as specified in Section 3. extraCerts as specified in Section 3. The messages are named by the
respective field names in PKIBody like ir, ip, cr, cp, etc., see
RFC 4210 Section 5.1.2 [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, as well as
ip/cp/kup/error messages with status "waiting", pollReq, and pollRep ip/cp/kup/error messages with status "waiting", pollReq, and pollRep
messages described in Section 4.4. messages described in Section 4.4.
On receiving messages from upstream, the EE MUST perform the general On receiving messages from upstream, the EE MUST perform the general
validation checks described in Section 3.5. The behavior in case an validation checks described in Section 3.5. The behavior in case an
error occurs is described in Section 3.6. error occurs is described in Section 3.6.
skipping to change at page 30, line 31 skipping to change at page 26, line 31
| | pollRep | pollReq | | | pollRep | pollReq |
| | v | | | v |
| | waiting for response | | | waiting for response |
| | | | | | | |
| +------------+--------+ | | +------------+--------+ |
| | | | | | | |
| received ip/cp/kup | | received | | received ip/cp/kup | | received |
| with status "accepted" | | rp/genp or | | with status "accepted" | | rp/genp or |
| or "grantedWithMods" | | ip/cp/kup/error | | or "grantedWithMods" | | ip/cp/kup/error |
| | | with status | | | | with status |
+-----------+--------------+ | "rejection" | +---------->+<-------------+ | "rejection" |
| | | | | |
+-----------+-----+ | | +-----------+-----+ | |
| | | | | | | |
| implicitConfirm | implicitConfirm | | | implicitConfirm | implicitConfirm | |
| granted | not granted | | | granted | not granted | |
| | | | | | | |
| | send certConf | | | | send certConf | |
| v | | | v | |
| waiting for pkiConf*) | | | waiting for pkiConf*) | |
| | | | | | | |
| | received | | | | received | |
| | pkiConf | | | | pkiConf | |
+-----------------+-----------------+-----------------+ +-----------------+------->+<-------+-----------------+
| |
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
skipping to change at page 34, line 7 skipping to change at page 29, line 48
8 format certConf 8 format certConf
9 -> certConf -> 9 -> certConf ->
10 handle or 10 handle or
forward certConf forward certConf
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 exactly one For this PKI management operation, the EE MUST include exactly one
CertReqMsg in the ir. If more certificates are required, further CertReqMsg in the ir. If more certificates are required, further
requests MUST be sent using separate PKI management operation. If requests MUST be sent using separate PKI management operation.
the EE wants to omit sending a certificate confirmation message after
receiving the ip, e.g., to reduce the number of protocol messages The EE SHOULD include the implicitConfirm extension in the header of
exchanged in this PKI management operation, it MUST request this by the ir message as described in Section 3.1, unless it knows that
including the implicitConfirm extension in the header of the ir certificate confirmation is needed. This leaves the choice to the
message, see Section 3.1. PKI management entities whether the EE must send a certConf message
on receiving a new certificate. Depending on the PKI policy and
requirements for managing EE certificates, it can be important for
PKI management entities to learn if the EE accepted the new
certificate. In such cases, when responding with an ip message, the
PKI management entity MUST NOT include the implicitConfirm extension.
In case the PKI management entity does not need any explicit
confirmation from the EE, it MUST include the extension as described
in Section 3.1. This prevents explicit certificate confirmation and
saves the overhead of a further message round-trip.
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 the PKI management entity SHALL terminate the PKI rejection, depending on its policy the PKI management entity MAY
management operation, and the PKI MAY revoke the newly issued revoke the newly issued certificate, notify a monitoring system, or
certificate. log the event internally.
Note: Depending on PKI policy, a new certificate may be published by
a PKI management entity, and explicit confirmation may be required.
In this case it is advisable not to do the publication until a
positive certificate confirmation has been received. This way the
need to revoke the certificate on negative confirmation is avoided.
If the certificate request was rejected by the CA, the PKI management If the certificate request was rejected by the CA, the PKI management
entity must return an ip message containing the status code entity must return an ip message containing the status code
"rejection" as described in Section 3.6 and no certifiedKeyPair "rejection" as described in Section 3.6 and no certifiedKeyPair
field. The EE MUST NOT react to such an ip message with a certConf field. The EE MUST NOT react to such an ip message with a certConf
message and the PKI management operation MUST be terminated. message and the PKI management operation MUST be terminated.
Detailed message description: Detailed message description:
Initialization Request -- ir Initialization Request -- ir
skipping to change at page 44, line 9 skipping to change at page 40, line 9
number generation. Yet maybe this is not the case at the time of number generation. Yet maybe this is not the case at the time of
requesting an initial certificate during manufacturing. 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.1, 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 it in the algorithm sub-field and key type to be generated, provide it in the algorithm sub-field and
fill the subjectPublicKey sub-field with a zero-length BIT STRING. fill the subjectPublicKey sub-field with a zero-length BIT STRING.
Both variants indicate to the PKI management entity that a new key Both variants indicate to the PKI management entity that a new key
pair shall be generated centrally on behalf of the EE. 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 message has been extended to EncryptedKey by CMP Updates Section 2.7
[I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred
alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the
use of EncryptedValue has been deprecated in favor of the use of EncryptedValue has been deprecated in favor of the
EnvelopedData structure. Therefore, this profile requires using EnvelopedData structure. Therefore, this profile requires using
EnvelopedData as specified in CMS Section 6 [RFC5652]. When EnvelopedData as specified in CMS Section 6 [RFC5652]. When
EnvelopedData is to be used in a PKI management operation, CMP v3 EnvelopedData is to be used in a PKI management operation, CMP v3
MUST be indicated in the message header already for the initial MUST be indicated in the message header already for the initial
request message, see Section 7 of CMP Updates request message, see CMP Updates Section 2.19 and Section 2.20
[I-D.ietf-lamps-cmp-updates]. [I-D.ietf-lamps-cmp-updates].
+----------------------------------+ +----------------------------------+
| EnvelopedData | | EnvelopedData |
| [RFC5652] section 6 | | [RFC5652] section 6 |
| +------------------------------+ | | +------------------------------+ |
| | SignedData | | | | SignedData | |
| | [RFC5652] section 5 | | | | [RFC5652] section 5 | |
| | +--------------------------+ | | | | +--------------------------+ | |
| | | AsymmetricKeyPackage | | | | | | AsymmetricKeyPackage | | |
skipping to change at page 45, line 17 skipping to change at page 41, line 17
containing the newly issued certificate. containing the newly issued certificate.
The private key MUST be provided as an AsymmetricKeyPackage structure The private key MUST be provided as an AsymmetricKeyPackage structure
as defined in RFC 5958 [RFC5958]. as defined in RFC 5958 [RFC5958].
This AsymmetricKeyPackage structure MUST be wrapped in a SignedData This AsymmetricKeyPackage structure MUST be wrapped in a SignedData
structure, as specified in CMS Section 5 [RFC5652] and [RFC8933], structure, as specified in CMS Section 5 [RFC5652] and [RFC8933],
signed by the KGA generating the key pair. The signature MUST be 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 CMP Updates
[I-D.ietf-lamps-cmp-updates] to demonstrate authorization to generate Section 2.2 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization
key pairs on behalf of an EE. The EE SHOULD verify the presence of to generate key pairs on behalf of an EE. The EE SHOULD validate the
this extended key usage in the SignedData structure. signer certificate contained in the SignedData structure and verify
the presence of this extended key usage in the signer certificate.
Note: When using password-based key management technique as described Note: When using password-based key management technique as described
in Section 4.1.6.3 it may not be possible or meaningful to the EE to in Section 4.1.6.3 it may not be possible or meaningful to the EE to
validate the KGA signature in the SignedData structure since shared validate the KGA signature and the related certificate in the
secret information is used for initial authentication. In this case SignedData structure since shared secret information is used for
the EE MAY omit this signature validation. initial authentication. In this case the EE MAY omit this
validation.
The SignedData structure MUST be wrapped in an EnvelopedData The SignedData structure MUST be wrapped in an EnvelopedData
structure, as specified in CMS Section 6 [RFC5652], encrypting it structure, as specified in CMS Section 6 [RFC5652], encrypting it
using a newly generated symmetric content-encryption key. using a newly generated symmetric content-encryption key.
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.8 EE chose to protect the request message. See CMP Updates Section 2.7
[I-D.ietf-lamps-cmp-updates] for more details on which key management [I-D.ietf-lamps-cmp-updates] for more details on which key management
technique to use. technique to use.
* Signature-based protection of the request message: * Signature-based protection of the request message:
- The content-encryption key SHALL be protected using the key - The content-encryption key SHALL be protected using the key
agreement key management technique, see Section 4.1.6.1, if the agreement key management technique, see Section 4.1.6.1, if the
certificate used by the EE for protecting the request message certificate used by the EE for protecting the request message
allows the key usage keyAgreement. If the certificate also allows the key usage keyAgreement. If the certificate also
allows the key usage keyEncipherment, the key transport key allows the key usage keyEncipherment, the key transport key
skipping to change at page 51, line 10 skipping to change at page 47, line 48
encryption key but with a different salt value applied in the key encryption key but with a different salt value applied in the key
derivation algorithm. For this key management technique, the derivation algorithm. For this key management technique, the
PasswordRecipientInfo structure MUST be used in the contentInfo PasswordRecipientInfo structure MUST be used in the contentInfo
field. field.
Note: The entropy of the shared secret information is crucial for the Note: The entropy of the shared secret information is crucial for the
level of protection when using a password-based key management level of protection when using a password-based key management
technique. For centrally generated key pairs, the entropy of the technique. For centrally generated key pairs, the entropy of the
shared secret information SHALL NOT be less than the security shared secret information SHALL NOT be less than the security
strength of the centrally generated key pair. Further guidance is strength of the centrally generated key pair. Further guidance is
available in Section 8. available in Section 9.
The PasswordRecipientInfo structure included into the EnvelopedData The PasswordRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.4 [RFC5652]. structure is specified in CMS Section 6.2.4 [RFC5652].
The detailed description of the PasswordRecipientInfo structure looks The detailed description of the PasswordRecipientInfo structure looks
like this: like this:
pwri REQUIRED pwri REQUIRED
-- MUST be a PasswordRecipientInfo as specified in CMS -- MUST be a PasswordRecipientInfo as specified in CMS
-- Section 6.2.4 [RFC5652] -- Section 6.2.4 [RFC5652]
skipping to change at page 56, line 12 skipping to change at page 53, line 12
extraCerts REQUIRED extraCerts REQUIRED
-- As described in Section 3.3 -- As described in Section 3.3
4.3.1. Get CA certificates 4.3.1. Get CA certificates
This PKI management operation can be used by an EE to request CA This PKI management operation can be used by an EE to request CA
certificates from the PKI management entity. certificates from the PKI management entity.
An EE requests CA certificates, e.g., for chain construction, from an An EE requests CA certificates, e.g., for chain construction, from an
PKI management entity by sending a general message with OID id-it- PKI management entity by sending a general message with OID id-it-
caCerts as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. caCerts as specified in CMP Updates Section 2.13
The PKI management entity responds with a general response with the [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds
same OID that either contains a SEQUENCE of certificates populated with a general response with the same OID that either contains a
with the available intermediate and issuing CA certificates or with SEQUENCE of certificates populated with the available intermediate
no content in case no CA certificate is available. and issuing CA certificates or with no content in case no CA
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
skipping to change at page 57, line 8 skipping to change at page 54, line 8
4.3.2. Get root CA certificate update 4.3.2. Get root CA certificate update
This PKI management operation can be used by an EE to request an This PKI management operation can be used by an EE to request an
updated root CA Certificate as described in Section 4.4 of RFC 4210 updated root CA Certificate as described in Section 4.4 of RFC 4210
[RFC4210]. [RFC4210].
An EE requests an update of a root CA certificate from the PKI An EE requests an update of a root CA certificate from the PKI
management entity by sending a general message with OID id-it- management entity by sending a general message with OID id-it-
rootCaCert, which SHOULD include the old root CA certificate in the rootCaCert, which SHOULD include the old root CA certificate in the
message body, as specified in CMP Updates message body, as specified in CMP Updates Section 2.14
[I-D.ietf-lamps-cmp-updates]. The PKI management entity responds [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds
with a general response with OID id-it-rootCaKeyUpdate that either with a general response with OID id-it-rootCaKeyUpdate that either
contains the update of the root CA certificate consisting of up to contains the update of the root CA certificate consisting of up to
three certificates, or with no content in case no update is three certificates, or with no 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., trusted intermediate CA or issuing CA certificates, i.e., trusted intermediate CA or issuing CA
certificates. certificates.
skipping to change at page 58, line 29 skipping to change at page 55, line 29
-- 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 [I-D.ietf-lamps-cmp-updates]. The EE MAY specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates].
indicate the certificate profile to use in the id-it-certProfile The EE MAY indicate the certificate profile to use in the id-it-
extension of the generalInfo field in the PKIHeader of the general certProfile extension of the generalInfo field in the PKIHeader of
message as described in Section 3.1. The PKI management entity the general message as described in Section 3.1. The PKI management
responds with a general response with the same OID that either entity 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 with 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 field
containing requirements on algorithms acceptable for key pair containing requirements on algorithms acceptable for key pair
generation. generation.
The EE SHOULD follow the requirements from the received CertTemplate, The EE SHOULD follow the requirements from the received CertTemplate,
by including in the certificate requests all the fields requested, by including in the certificate requests all the fields requested,
taking over all the field values provided and filling in any taking over all the field values provided and filling in any
skipping to change at page 59, line 29 skipping to change at page 56, line 29
value, the EE SHOULD fill in a value. value, the EE SHOULD fill in a value.
The EE MUST ignore (i.e., not include and fill in) empty fields, The EE MUST ignore (i.e., not include and fill in) empty fields,
extensions, and sub-components that it does not understand or does extensions, and sub-components that it does not understand or does
not know suitable values to be filled in. not know suitable values to be filled in.
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate The publicKey field of type SubjectPublicKeyInfo in the CertTemplate
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 stipulation on algorithms the EE may
use for key generation, this MUST be specified using the keySpec use for key generation, this MUST be specified using the keySpec
field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. field as specified in CMP Updates Section 2.15
[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 [I-D.ietf-lamps-cmp-updates], MUST be of specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates],
type AlgorithmIdentifier and give an algorithm other than RSA. For MUST be of type AlgorithmIdentifier and give an algorithm other than
EC keys the curve information MUST be specified as described in the RSA. For EC keys the curve information MUST be specified as
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 [I-D.ietf-lamps-cmp-updates], MUST be a specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates],
positive integer value and give an RSA key length. MUST be a positive integer value and give an RSA key length.
In the CertTemplate of the CertReqTemplateValue the serialNumber, In the CertTemplate of the CertReqTemplateValue the serialNumber,
signingAlg, issuerUID, and subjectUID fields MUST be omitted. signingAlg, issuerUID, and subjectUID fields MUST be omitted.
Specific prerequisites augmenting the prerequisites in Section 3.4: Specific prerequisites augmenting the prerequisites in Section 3.4:
* When using the generalInfo field certProfile, the EE MUST know the * When using the generalInfo field certProfile, the EE MUST know the
identifier needed to indicate the requested certificate profile. identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
skipping to change at page 60, line 43 skipping to change at page 57, line 46
-- available -- available
-- MUST be present if the PKI management entity has any -- MUST be present if the PKI management entity has any
-- requirements on the keys generated -- requirements on the keys generated
-- MUST contain one AttributeTypeAndValue per supported -- MUST contain one AttributeTypeAndValue per supported
-- algorithm with attribute id-regCtrl-algId or -- algorithm with attribute id-regCtrl-algId or
-- id-regCtrl-rsaKeyLen -- id-regCtrl-rsaKeyLen
4.3.4. CRL update retrieval 4.3.4. CRL update retrieval
This PKI management operation can be used by an EE to request a new This PKI management operation can be used by an EE to request a new
CRL. If a CA offers methods to access a CRL they are often provided CRL. If a CA offers methods to access a CRL, it may include CRL
by the CA through the CRLDP or AuthorityInfoAccess as specified in distribution points or authority information access extensions as
[RFC5280] components in the issued certificates. In addition, CMP specified in RFC 5280 [RFC5280] into the issued certificates. In
offers this functionality as part of the PKI management operation. addition, CMP offers CRL provisioning functionality as part of the
PKI management operation.
An EE requests a CRL update from the PKI management entity by sending An EE requests a CRL update from the PKI management entity by sending
a general message with OID id-it-crlStatusList. This MUST include a general message with OID id-it-crlStatusList. The EE MUST include
the CRL source and, if available, the thisUpdate time of the most the CRL source identifying the requested CRL and, if available, the
current CRL instance it already has, as specified in CMP Updates thisUpdate time of the most current CRL instance it already has, as
[I-D.ietf-lamps-cmp-updates]. The PKI management entity MUST respond specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates].
with a general response with OID id-it-crls. If no thisUpdate value The PKI management entity MUST respond with a general response with
was given by the EE, it MUST return the latest CRL available. If a OID id-it-crls. If no thisUpdate value was given by the EE, the PKI
thisUpdate value was given, it MUST return the latest available CRL management entity MUST return the latest CRL available. If a
in case this CRL is more recent, otherwise the infoValue in the thisUpdate value was given, the PKI management entity MUST return the
response message MUST be absent. latest available CRL in case this CRL is more recent, otherwise the
infoValue in the response message MUST be absent.
The EE MUST identify the requested CRL either by its CRL distribution
point name or issuer name. The CRL distribution point name can
either be provided form the CRL distribution points extension of the
certificate to be validated or from the issuing distribution point
extension from the CRL to be updated. If no CRL distribution name is
available to identify the CRL, the EE can use the issuer name either
from the certificate to be validated or from the CRL to be updated.
The PKI management entity SHOULD treat a CRL distribution point name
as an internal pointer to identify a CRL for which is available at
the PKI management entity directly. It is not intended as a way to
fetch an arbitrary CRL from an external location.
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 for the requested CRL either its CRL distribution point MUST know which CRL to request.
name or the name of the CRL issuer.
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 use
instead a general message with OID id-it-currentCrl as specified in instead a general message with OID id-it-currentCrl as specified in
RFC 4210 Section 5.3.19.6 [I-D.ietf-lamps-cmp-updates]. RFC 4210 Section 5.3.19.6 [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
CRLStatus structure CRLStatus structure
3 if present, the infoValue of the response MUST contain a CRL 3 if present, the infoValue of the response MUST contain a CRL
The infoValue field of the general request containing the id-it- The infoValue field of the general request containing the id-it-
crlStatusList OID looks like this: crlStatusList OID looks like this:
CRLSourceListValue REQUIRED CRLSource REQUIRED
-- MUST contain a CRLSource structure -- MUST contain exactly one CRLSource structure
-- MUST contain the dpn choice if the CRL distribution point name -- MUST contain the dpn choice of type DistributionPointName if
-- is available -- the CRL distribution point name is available
-- MUST contain the issuer choice otherwise, naming the CA that -- Otherwise, MUST contain the issuer choice identifying the CA
-- issues the CRL. -- that issues the CRL. It MUST contain the issuer DN in the
-- directoryName field of a GeneralName element.
thisUpdate OPTIONAL thisUpdate OPTIONAL
-- SHOULD contain the thisUpdate field of the latest CRL form -- SHOULD contain the thisUpdate field of the latest CRL form
-- the given dpn or issuer, in case such a CRL is already known -- the issuer specified in the given dpn or issuer field,
-- by the EE -- in case such a CRL is already known by the EE
The infoValue field of the general response containing the id-it-crls The infoValue field of the general response containing the id-it-crls
OID looks like this: OID looks like this:
infoValue REQUIRED infoValue OPTIONAL
-- MUST contain a CRL update from the referenced source, if a -- MUST be absent if no CRL to be returned is available
-- MUST contain one CRL update from the referenced source, if a
-- thisUpdate value was not given or a more recent CRL is -- thisUpdate value was not given or a more recent CRL is
-- available -- available
4.4. Handling delayed delivery 4.4. Handling delayed delivery
This is a variant of all PKI management operations described in This is a variant of all PKI management operations described in this
described in this document. It is initiated in case a PKI management document. It is initiated in case a PKI management entity cannot
entity cannot respond to a request message in a timely manner, respond to a request message in a timely manner, typically due to
typically due to offline or asynchronous upstream communication, or offline or asynchronous upstream communication, or due to delays in
due to delays in handling the request. The polling mechanism has handling the request. The polling mechanism has been specified in
been specified in RFC 4210 Section 5.3.22 [RFC4210] and updated by RFC 4210 Section 5.3.22 [RFC4210] and updated by
[I-D.ietf-lamps-cmp-updates]. [I-D.ietf-lamps-cmp-updates].
Depending on the PKI architecture, the entity initiating delayed Depending on the PKI architecture, the entity initiating delayed
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 an ip/cp/kup/error the PKI management entity MUST respond with an ip/cp/kup/error
message including the status "waiting". On receiving this response, message including the status "waiting". On receiving this response,
the EE MUST store in its transaction context the senderNonce of the the EE MUST store in its transaction context the senderNonce of the
skipping to change at page 66, line 42 skipping to change at page 64, line 42
The PKI management entity terminating the PKI management operation at The PKI management entity terminating the PKI management operation at
CMP level MUST respond to all received requests by returning a CMP level MUST respond to all received requests by returning a
related CMP response message or an error. Any intermediate PKI related CMP response message or an error. Any intermediate PKI
management entity MAY respond depending on the PKI configuration and management entity MAY respond depending on the PKI configuration and
policy. policy.
In addition to the checks described in Section 3.5, the responding In addition to the checks described in Section 3.5, the responding
PKI management entity SHOULD check that a request that initiates a PKI management entity SHOULD check that a request that initiates a
new PKI management operation does not use a transactionID that is new PKI management operation does not use a transactionID that is
currently in useThe failInfo bit value to use on reporting failure as currently in use. The failInfo bit value to use on reporting failure
described in Section 3.6.4 is transactionIdInUse. If any of these as described in Section 3.6.4 is transactionIdInUse. If any of these
verification steps or any of the essential checks described in the verification steps or any of the essential checks described in the
following subsections fails, the PKI management entity MUST proceed following subsections fails, the PKI management entity MUST proceed
as described in Section 3.6. as described in Section 3.6.
The responding PKI management entity SHOULD copy the sender field of The responding PKI management entity SHOULD copy the sender field of
the request to the recipient field of the response, MUST copy the the request to the recipient field of the response, MUST copy the
senderNonce of the request to the recipNonce of the response, and senderNonce of the request to the recipNonce of the response, and
MUST use the same transactionID for the response. MUST use the same transactionID for the response.
5.1.1. Responding to a certificate request 5.1.1. Responding to a certificate request
skipping to change at page 71, line 43 skipping to change at page 69, line 43
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 RFC4210 [RFC4210] (see As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210]
CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases (see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there
for adding another protection by a PKI management entity. Specific are various use cases for adding another protection by a PKI
procedures are described in more detail in the following sections. management entity. Specific procedures are described in more detail
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
skipping to change at page 77, line 20 skipping to change at page 75, line 20
inserts the new public key in the subjectPublicKey field of the inserts the new public key in the subjectPublicKey field of the
request certTemplate, or it uses a certificate request received from request certTemplate, or it uses a certificate request received from
downstream, e.g., by means of a different protocol. In the latter downstream, e.g., by means of a different protocol. In the latter
case it SHOULD verify the received proof-of-possession. case it SHOULD verify the received proof-of-possession.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
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. Section 5.2.3 because in both cases the message is protected by the
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
skipping to change at page 80, line 5 skipping to change at page 78, line 5
This transfer mechanism can be used by a PKI entity to transfer CMP This transfer mechanism can be used by a PKI entity to transfer CMP
messages over HTTP. If HTTP transfer is used the specifications as messages over HTTP. If HTTP transfer is used the specifications as
described in [RFC6712] and updated by CMP Updates described in [RFC6712] and updated by CMP Updates
[I-D.ietf-lamps-cmp-updates] MUST be followed. [I-D.ietf-lamps-cmp-updates] MUST be followed.
PKI management operations SHOULD use URI paths consisting of '/.well- PKI management operations SHOULD use URI paths consisting of '/.well-
known/cmp/' followed by an operation label depending on the type of known/cmp/' followed by an operation label depending on the type of
PKI management operation. PKI management operation.
+=======================================+=================+=========+ +============================+=====================+=========+
| PKI management operation | operationLabel | Details | | PKI management operation | operation label | Details |
+=======================================+=================+=========+ +============================+=====================+=========+
| Enroll client to new PKI | /initialization | Section | | Enroll client to new PKI | /initialization | Section |
| | | 4.1.1 | | | | 4.1.1 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Enroll client to existing | /certification | Section | | Enroll client to existing | /certification | Section |
| PKI | | 4.1.2 | | PKI | | 4.1.2 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Update client certificate | /keyupdate | Section | | Update client certificate | /keyupdate | Section |
| | | 4.1.3 | | | | 4.1.3 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Enroll client using | /p10 | Section | | Enroll client using | /p10 | Section |
| PKCS#10 | | 4.1.4 | | PKCS#10 | | 4.1.4 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Revoke client certificate | /revocation | Section | | Revoke client certificate | /revocation | Section |
| | | 4.2 | | | | 4.2 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Get CA certificates | /getcacerts | Section | | Get CA certificates | /getcacerts | Section |
| | | 4.3.1 | | | | 4.3.1 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Get root CA certificate | /getrootupdate | Section | | Get root CA certificate | /getrootupdate | Section |
| update | | 4.3.2 | | update | | 4.3.2 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Get certificate request | /getcacerts | Section | | Get certificate request | /getcertreqtemplate | Section |
| template | | 4.3.1 | | template | | 4.3.1 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Get CRL updates | /getcrls | Section | | Get CRL updates | /getcrls | Section |
| | | 4.3.4 | | | | 4.3.4 |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
| Batching messages | /nested | Section | | Batching messages | /nested | Section |
| | | 5.2.2.2 | | | | 5.2.2.2 |
| Note: This path element is | | | | Note: This path element is | | |
| applicable only between | | | | applicable only between | | |
| PKI management entities. | | | | PKI management entities. | | |
+---------------------------------------+-----------------+---------+ +----------------------------+---------------------+---------+
Table 9: HTTP endpoints Table 1: HTTP endpoints
Independently of any variants used (see Section 4.1.5, Section 4.1.6, Independently of any variants used (see Section 4.1.5, Section 4.1.6,
and Section 4.4) the operation label corresponding to the PKI and Section 4.4) the operation label corresponding to the PKI
management operation SHALL be used. management operation SHALL be used.
Any certConf or pollReq messages are sent to the same endpoint as Any certConf or pollReq messages are sent to the same endpoint as
determined by the PKI management operation. determined by the PKI management operation.
When a single request message is nested as described in When a single request message is nested as described in
Section 5.2.2.1, the label to use is the same as for the underlying Section 5.2.2.1, the label to use is the same as for the underlying
skipping to change at page 82, line 9 skipping to change at page 80, line 9
This transfer mechanism can be used by a PKI entity to transfer CMP This transfer mechanism can be used by a PKI entity to transfer CMP
messages over CoAP [RFC7252], e.g., in constrained environments. If messages over CoAP [RFC7252], e.g., in constrained environments. If
CoAP transfer is used the specifications as described in CMP over CoAP transfer is used the specifications as described in CMP over
CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed.
PKI management operations SHOULD use URI paths consisting of '/.well- PKI management operations SHOULD use URI paths consisting of '/.well-
known/cmp/' followed by an operation label depending on the type of known/cmp/' followed by an operation label depending on the type of
PKI management operation. PKI management operation.
+=======================================+================+=========+ +=======================================+===========+=========+
| PKI management operation | operationLabel | Details | | PKI management operation | operation | Details |
+=======================================+================+=========+ | | label | |
| Enroll client to new PKI | /ir | Section | +=======================================+===========+=========+
| | | 4.1.1 | | Enroll client to new PKI | /ir | Section |
+---------------------------------------+----------------+---------+ | | | 4.1.1 |
| Enroll client to existing PKI | /cr | Section | +---------------------------------------+-----------+---------+
| | | 4.1.2 | | Enroll client to existing PKI | /cr | Section |
+---------------------------------------+----------------+---------+ | | | 4.1.2 |
| Update client certificate | /kur | Section | +---------------------------------------+-----------+---------+
| | | 4.1.3 | | Update client certificate | /kur | Section |
+---------------------------------------+----------------+---------+ | | | 4.1.3 |
| Enroll client using PKCS#10 | /p10 | Section | +---------------------------------------+-----------+---------+
| | | 4.1.4 | | Enroll client using PKCS#10 | /p10 | Section |
+---------------------------------------+----------------+---------+ | | | 4.1.4 |
| Revoke client certificate | /rr | Section | +---------------------------------------+-----------+---------+
| | | 4.2 | | Revoke client certificate | /rr | Section |
+---------------------------------------+----------------+---------+ | | | 4.2 |
| Get CA certificates | /crts | Section | +---------------------------------------+-----------+---------+
| | | 4.3.1 | | Get CA certificates | /crts | Section |
+---------------------------------------+----------------+---------+ | | | 4.3.1 |
| Get root CA certificate update | /rcu | Section | +---------------------------------------+-----------+---------+
| | | 4.3.2 | | Get root CA certificate update | /rcu | Section |
+---------------------------------------+----------------+---------+ | | | 4.3.2 |
| Get certificate request template | /att | Section | +---------------------------------------+-----------+---------+
| | | 4.3.3 | | Get certificate request template | /att | Section |
+---------------------------------------+----------------+---------+ | | | 4.3.3 |
| Get CRL updates | /crls | Section | +---------------------------------------+-----------+---------+
| | | 4.3.4 | | Get CRL updates | /crls | Section |
+---------------------------------------+----------------+---------+ | | | 4.3.4 |
| Batching messages | /nest | Section | +---------------------------------------+-----------+---------+
| | | 5.2.2.2 | | Batching messages | /nest | Section |
| Note: This path element is applicable | | | | | | 5.2.2.2 |
| only between PKI management entities. | | | | Note: This path element is applicable | | |
+---------------------------------------+----------------+---------+ | only between PKI management entities. | | |
+---------------------------------------+-----------+---------+
Table 10: CoAP endpoints Table 2: CoAP endpoints
Independently of any variants used (see Section 4.1.5, Section 4.1.6, Independently of any variants used (see Section 4.1.5, Section 4.1.6,
and Section 4.4) the operation label corresponding to the PKI and Section 4.4) the operation label corresponding to the PKI
management operation SHALL be used. management operation SHALL be used.
Any certConf or pollReq messages are sent to the same endpoint as Any certConf or pollReq messages are sent to the same endpoint as
determined by the PKI management operation. determined by the PKI management operation.
When a single request message is nested as described in When a single request message is nested as described in
Section 5.2.2.1, the label to use is the same as for the underlying Section 5.2.2.1, the label to use is the same as for the underlying
skipping to change at page 84, line 19 skipping to change at page 82, line 28
wrapping is defined for those environments that are MIME-native. The wrapping is defined for those environments that are MIME-native. The
MIME wrapping in this section is specified in RFC 8551 Section 3.1 MIME wrapping in this section is specified in RFC 8551 Section 3.1
[RFC8551]. [RFC8551].
The ASN.1 DER encoding of the CMP messages MUST be transferred using The ASN.1 DER encoding of the CMP messages MUST be transferred using
the "application/pkixcmp" content type and base64-encoded content the "application/pkixcmp" content type and base64-encoded content
transfer encoding as specified in [RFC2510], section 5.3. A filename transfer encoding as specified in [RFC2510], section 5.3. A filename
MUST be included either in a "content-type" or a "content- MUST be included either in a "content-type" or a "content-
disposition" statement. The file name extension ".pki" MUST be used. disposition" statement. The file name extension ".pki" MUST be used.
7. IANA Considerations 7. Conformance requirements
8. Security Considerations This section defines which level of support for the various features
specified in this profile is required for which type of PKI entity.
7.1. PKI management operations
The following table provides an overview of the PKI management
operations specified in Section 4 and Section 5 and states whether
support by conforming EE, RA, and CA implementations is mandatory,
recommended, optional, or not applicable. Variants amend or change
behavior of base PKI management operations and are therefore also
included.
+==========+=============================+========+========+========+
| ID | PKI management operations | EE | RA | CA |
| | and variants | | | |
+==========+=============================+========+========+========+
| Generic | generic aspects of PKI | MUST | MUST | MUST |
| | management operations, | | | |
| | Section 3 | | | |
+----------+-----------------------------+--------+--------+--------+
| IR | Requesting a certificate | MUST | MUST | MUST |
| | from a new PKI with | | | |
| | signature-based | | | |
| | protection, Section 4.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| CR | Requesting an additional | MAY | MAY | MAY |
| | certificate with | | | |
| | signature-based | | | |
| | protection, Section 4.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| KUR | Updating an existing | MUST | MUST | MUST |
| | certificate with | | | |
| | signature-based | | | |
| | protection, Section 4.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| P10CR | Requesting a certificate | MAY | MAY | MAY |
| | from a legacy PKI using a | | | |
| | PKCS#10 request, | | | |
| | Section 4.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| MAC | Requesting a certificate | SHOULD | SHOULD | SHOULD |
| | from a PKI with MAC-based | | | |
| | protection (IR, CR, KUR, | | | |
| | and P10CR if supported), | | | |
| | Section 4.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+
| CKeyGen | Adding central key | MAY | MAY | MAY |
| | generation to a | | | |
| | certificate request (IR, | | | |
| | CR, KUR, and P10CR if | | | |
| | supported). (If | | | |
| | supported, key agreement | | | |
| | key management technique | | | |
| | is REQUIRED, and key | | | |
| | transport and password- | | | |
| | based key management | | | |
| | techniques are | | | |
| | OPTIONAL.), Section 4.1.6 | | | |
+----------+-----------------------------+--------+--------+--------+
| RR | Revoking a certificate, | SHOULD | SHOULD | SHOULD |
| | Section 4.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| CACerts | Get CA certificates, | MAY | MAY | MAY |
| | Section 4.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| RootUpd | Get root CA certificate | MAY | MAY | MAY |
| | update, Section 4.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| ReqTempl | Get certificate request | MAY | MAY | MAY |
| | template, Section 4.3.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| CRLUpd | CRL update retrieval, | MAY | MAY | MAY |
| | Section 4.3.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| Polling | Handling delayed | MAY | MAY | MAY |
| | delivery, Section 4.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertResp | Responding to a | N/A | MAY | MUST |
| | certificate request (IR, | | | |
| | CR, KUR, and P10CR if | | | |
| | supported), Section 5.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| InitPoll | Initiating delayed | N/A | MAY | MAY |
| | delivery, Section 5.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertConf | Responding to a | MUST | MAY | MUST |
| | confirmation message, | | | |
| | Section 5.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| RevResp | Responding to a | N/A | MAY | SHOULD |
| | revocation request, | | | |
| | Section 5.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| GenResp | Responding to a support | N/A | MAY | MAY |
| | message (CACerts, | | | |
| | RootUpd, ReqTempl, CRLUpd | | | |
| | if supported), | | | |
| | Section 5.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdKeep | Forwarding messages - not | N/A | MUST | N/A |
| | changing protection, | | | |
| | Section 5.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdAddS | Adding protection to a | N/A | MUST | MUST |
| | request message, | | | |
| | Section 5.2.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdAddB | Batching messages, | N/A | MAY | MAY |
| | Section 5.2.2.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdRepKP | Forwarding messages - | N/A | MAY | N/A |
| | replacing protection, not | | | |
| | changing any included | | | |
| | proof-of-possession, | | | |
| | Section 5.2.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdRepBP | Forwarding messages - | N/A | MAY | MAY |
| | replacing protection, | | | |
| | breaking proof-of- | | | |
| | possession, | | | |
| | Section 5.2.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertOnB | Acting on behalf of other | N/A | MAY | N/A |
| | PKI entities - requesting | | | |
| | certificates, | | | |
| | Section 5.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| RevROnB | Acting on behalf of other | N/A | SHOULD | SHOULD |
| | PKI entities - revoking a | | | |
| | certificate, | | | |
| | Section 5.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
Table 3: Level of support for PKI management operations and variants
7.2. Message transfer
CMP does not have specific needs regarding message transfer, except
that for each request message sent, eventually exactly one response
message should be received. Therefore, virtually any reliable
transfer mechanism can be used, such as HTTP, CoAP, and file-based
offline transfer. Thus, this document does not require any specific
transfer protocol to be supported by conforming implementations.
On different links between PKI entities, e.g., EE-RA and RA-CA,
different transfer mechanisms as specified in Section 6 may be used.
HTTP transfer is RECOMMENDED to use for all PKI entities for
maximizing general interoperability at transfer level, yet full
flexibility is retained to choose whatever transfer mechanism is
suitable, for instance for devices and system architectures with
specific constraints.
The following table lists the name and level of support specified for
each transfer mechanism.
+=========+=======================+========+========+========+
| ID | Message transfer type | EE | RA | CA |
+=========+=======================+========+========+========+
| HTTP | HTTP transfer, | SHOULD | SHOULD | SHOULD |
| | Section 6.1 | | | |
+---------+-----------------------+--------+--------+--------+
| CoAP | CoAP transfer, | MAY | MAY | MAY |
| | Section 6.2 | | | |
+---------+-----------------------+--------+--------+--------+
| Piggyb | Piggybacking on other | MAY | MAY | MAY |
| | reliable transfer, | | | |
| | Section 6.3 | | | |
+---------+-----------------------+--------+--------+--------+
| Offline | Offline transfer, | MAY | MAY | MAY |
| | Section 6.4 | | | |
+---------+-----------------------+--------+--------+--------+
Table 4: Level of support for message transfer types
8. IANA Considerations
This document does not request changes to the IANA registry.
9. Security Considerations
The security considerations as laid out in CMP [RFC4210] updated by The security considerations as laid out in CMP [RFC4210] updated by
CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm
Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over
CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply. CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply.
For TLS using shared secret information-based authentication, both For TLS using shared secret information-based authentication, both
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 in
the shared secret. The difference between a pre-shared key (PSK) and the shared secret. The difference between a pre-shared key (PSK) and
a password-authenticated key exchange (PAKE) protocols is in the a password-authenticated key exchange (PAKE) protocol is in the level
level of long-term confidentiality of the TLS messages against brute- of long-term confidentiality of the TLS messages against brute-force
force decryption, where a PSK-based cipher suite only provides decryption, where a PSK-based cipher suite only provides security
security according to the entropy of the shared secret, while a PAKE- according to the entropy of the shared secret, while a PAKE-based
based cipher suite provides full security independent of the entropy cipher suite provides full security independent of the entropy of the
of the shared secret. shared secret.
9. Acknowledgements 10. Acknowledgements
We thank the various reviewers of this document. We thank the various reviewers of this document.
10. References 11. References
11.1. Normative References
10.1. Normative References
[I-D.ietf-ace-cmpv2-coap-transport] [I-D.ietf-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transfer for the Sahni, M. and S. Tripathi, "CoAP Transfer for the
Certificate Management Protocol", Work in Progress, Certificate Management Protocol", Work in Progress,
Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8
November 2021, <https://datatracker.ietf.org/doc/html/ November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-ace-cmpv2-coap-transport-04>. draft-ietf-ace-cmpv2-coap-transport-04>.
[I-D.ietf-lamps-cmp-algorithms] [I-D.ietf-lamps-cmp-algorithms]
Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms", Work "Certificate Management Protocol (CMP) Algorithms", Work
in Progress, Internet-Draft, draft-ietf-lamps-cmp- in Progress, Internet-Draft, draft-ietf-lamps-cmp-
algorithms-08, 17 November 2021, algorithms-08, 17 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-08>. cmp-algorithms-08>.
[I-D.ietf-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
Management Protocol (CMP) Updates", Work in Progress, Management Protocol (CMP) Updates", Work in Progress,
Internet-Draft, draft-ietf-lamps-cmp-updates-13, 25 Internet-Draft, draft-ietf-lamps-cmp-updates-15, 17
October 2021, <https://datatracker.ietf.org/doc/html/ December 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-cmp-updates-13>. draft-ietf-lamps-cmp-updates-15>.
[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 86, line 34 skipping to change at page 88, line 40
(CMS) for Algorithm Identifier Protection", RFC 8933, (CMS) for Algorithm Identifier Protection", RFC 8933,
DOI 10.17487/RFC8933, October 2020, DOI 10.17487/RFC8933, October 2020,
<https://www.rfc-editor.org/info/rfc8933>. <https://www.rfc-editor.org/info/rfc8933>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the [RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045, Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021, DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>. <https://www.rfc-editor.org/info/rfc9045>.
10.2. Informative References 11.2. Informative References
[ETSI-3GPP.33.310] [ETSI-3GPP.33.310]
3GPP, "Network Domain Security (NDS); Authentication 3GPP, "Network Domain Security (NDS); Authentication
Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020.
[I-D.ietf-anima-brski-async-enroll] [I-D.ietf-anima-brski-async-enroll]
Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear, Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear,
"Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)", "Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)",
Work in Progress, Internet-Draft, draft-ietf-anima-brski- Work in Progress, Internet-Draft, draft-ietf-anima-brski-
async-enroll-04, 25 October 2021, async-enroll-04, 25 October 2021,
skipping to change at page 87, line 16 skipping to change at page 89, line 16
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, Progress, Internet-Draft, draft-ietf-anima-brski-prm-00,
25 October 2021, <https://datatracker.ietf.org/doc/html/ 25 October 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-00>. draft-ietf-anima-brski-prm-00>.
[I-D.ietf-netconf-sztp-csr] [I-D.ietf-netconf-sztp-csr]
Watsen, K., Housley, R., and S. Turner, "Conveying a Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-11, Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-12,
8 November 2021, <https://datatracker.ietf.org/doc/html/ 3 December 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-11>. draft-ietf-netconf-sztp-csr-12>.
[IEC.62443-3-3] [IEC.62443-3-3]
IEC, "Industrial communication networks - Network and IEC, "Industrial communication networks - Network and
system security - Part 3-3: System security requirements system security - Part 3-3: System security requirements
and security levels", IEC 62443-3-3, August 2013, and security levels", IEC 62443-3-3, August 2013,
<https://webstore.iec.ch/publication/7033>. <https://webstore.iec.ch/publication/7033>.
[IEEE.802.1AR_2018] [IEEE.802.1AR_2018]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", IEEE 802.1AR-2018, networks - Secure Device Identity", IEEE 802.1AR-2018,
skipping to change at page 90, line 42 skipping to change at page 92, line 42
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates { OCTET STRING, encapsulates {
SEQUENCE {} SEQUENCE {}
} }
} }
} }
} }
SEQUENCE { SEQUENCE {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 11) OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11)
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
} }
} }
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)
INTEGER 2048 INTEGER 2048
} }
} }
} }
Appendix B. History of changes Appendix B. History of changes
Note: This appendix will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
From version 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: From version 07 -> 08:
* Updates Section 4.1.6.1. regarding content of the originator and * Updates Section 4.1.6.1. regarding content of the originator and
keyEncryptionAlgorithm fields (see thread "AD review of draft- keyEncryptionAlgorithm fields (see thread "AD review of draft-
ietf-lamps-cmp-algorithms-07") ietf-lamps-cmp-algorithms-07")
* Rolled back part of the changes on root CA certificate updates in * Rolled back part of the changes on root CA certificate updates in
Section 4.3.2 (see thread "Allocation of OIDs for CRL update Section 4.3.2 (see thread "Allocation of OIDs for CRL update
retrieval (draft-ietf-lamps-cmp-updates-13)") retrieval (draft-ietf-lamps-cmp-updates-13)")
From version 06 -> 07: From version 06 -> 07:
 End of changes. 68 change blocks. 
429 lines changed or deleted 529 lines changed or added

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