draft-ietf-lamps-lightweight-cmp-profile-01.txt   draft-ietf-lamps-lightweight-cmp-profile-02.txt 
LAMPS Working Group H. Brockhaus LAMPS Working Group H. Brockhaus
Internet-Draft S. Fries Internet-Draft S. Fries
Intended status: Standards Track D. von Oheimb Intended status: Standards Track D. von Oheimb
Expires: September 5, 2020 Siemens Expires: January 12, 2021 Siemens
March 4, 2020 July 11, 2020
Lightweight CMP Profile Lightweight CMP Profile
draft-ietf-lamps-lightweight-cmp-profile-01 draft-ietf-lamps-lightweight-cmp-profile-02
Abstract Abstract
The goal of this document is to facilitate interoperability and The goal of this document is to facilitate interoperability and
automation by profiling the Certificate Management Protocol (CMP) automation by profiling the Certificate Management Protocol (CMP)
version 2, the related Certificate Request Message Format (CRMF) version 2, the related Certificate Request Message Format (CRMF)
version 2, and the HTTP Transfer for the Certificate Management version 2, and the HTTP Transfer for the Certificate Management
Protocol. It specifies a subset of CMP and CRMF focusing on typical Protocol. It specifies a subset of CMP and CRMF focusing on typical
uses cases relevant for managing certificates of devices in many uses cases relevant for managing certificates of devices in many
industrial and IoT scenarios. To limit the overhead of certificate industrial and IoT scenarios. To limit the overhead of certificate
management for more constrained devices only the most crucial types management for more constrained devices only the most crucial types
of operations are specified as mandatory. To foster interoperability of operations are specified as mandatory. To foster interoperability
also in more complex scenarios, other types of operations are in more complex scenarios, other types of operations are specified as
specified as recommended or optional. recommended or optional.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2020. This Internet-Draft will expire on January 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. History of changes . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4
2.1. Motivation for profiling CMP . . . . . . . . . . . . . . 6 1.2. Motivation for a lightweight profile for CMP . . . . . . 5
2.2. Motivation for a lightweight profile for CMP . . . . . . 7 1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 5
2.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 1.4. Compatibility with existing CMP profiles . . . . . . . . 7
2.4. Compatibility with existing CMP profiles . . . . . . . . 9 1.5. Scope of this document . . . . . . . . . . . . . . . . . 9
2.5. Scope of this document . . . . . . . . . . . . . . . . . 11 1.6. Structure of this document . . . . . . . . . . . . . . . 9
2.6. Structure of this document . . . . . . . . . . . . . . . 11 1.7. Convention and Terminology . . . . . . . . . . . . . . . 10
2.7. Convention and Terminology . . . . . . . . . . . . . . . 12 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11
3. Architecture and use cases . . . . . . . . . . . . . . . . . 13 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11
3.1. Solution architecture . . . . . . . . . . . . . . . . . . 13 2.2. Basic generic CMP message content . . . . . . . . . . . . 12
3.2. Basic generic CMP message content . . . . . . . . . . . . 14 2.3. Supported PKI management operations . . . . . . . . . . . 12
3.3. Supported PKI management operations . . . . . . . . . . . 14 2.3.1. Mandatory PKI management operations . . . . . . . . . 13
3.3.1. Mandatory PKI management operations . . . . . . . . . 15 2.3.2. Recommended PKI management operations . . . . . . . . 13
3.3.2. Recommended PKI management operations . . . . . . . . 15 2.3.3. Optional PKI management operations . . . . . . . . . 14
3.3.3. Optional PKI management operations . . . . . . . . . 16 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 14
3.4. CMP message transport . . . . . . . . . . . . . . . . . . 16 3. Generic parts of the PKI message . . . . . . . . . . . . . . 15
4. Generic parts of the PKI message . . . . . . . . . . . . . . 17 3.1. General description of the CMP message header . . . . . . 16
4.1. General description of the CMP message header . . . . . . 18 3.2. General description of the CMP message protection . . . . 17
4.2. General description of the CMP message protection . . . . 19 3.3. General description of CMP message extraCerts . . . . . . 18
4.3. General description of CMP message extraCerts . . . . . . 20 4. End Entity focused PKI management operations . . . . . . . . 19
5. End Entity focused PKI management operations . . . . . . . . 20 4.1. Requesting a new certificate from a PKI . . . . . . . . . 19
5.1. Requesting a new certificate from a PKI . . . . . . . . . 21 4.1.1. Request a certificate from a new PKI with signature
5.1.1. Request a certificate from a new PKI with signature protection . . . . . . . . . . . . . . . . . . . . . 20
protection . . . . . . . . . . . . . . . . . . . . . 22 4.1.2. Request a certificate from a trusted PKI with
5.1.2. Request a certificate from a trusted PKI with signature protection . . . . . . . . . . . . . . . . 27
signature protection . . . . . . . . . . . . . . . . 28 4.1.3. Update an existing certificate with signature
5.1.3. Update an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 28 protection . . . . . . . . . . . . . . . . . . . . . 28
5.1.4. Request a certificate from a PKI with MAC protection 29 4.1.4. Request a certificate from a PKI with MAC protection 29
5.1.5. Request a certificate from a legacy PKI using PKCS#10 4.1.5. Request a certificate from a legacy PKI using PKCS#10
request . . . . . . . . . . . . . . . . . . . . . . . 31 request . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.6. Generate the key pair centrally at the PKI management 4.1.6. Generate the key pair centrally at the PKI management
entity . . . . . . . . . . . . . . . . . . . . . . . 33 entity . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.6.1. Using symmetric key-encryption key management 4.1.6.1. Using key agreement key management technique . . 37
technique . . . . . . . . . . . . . . . . . . . . 38 4.1.6.2. Using key transport key management technique . . 38
5.1.6.2. Using key agreement key management technique . . 39 4.1.6.3. Using password-based key management technique . . 39
5.1.6.3. Using key transport key management technique . . 40 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 40
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 45
5.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 41 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 47
5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 46 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 49
5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 48 4.4.1. General message and response . . . . . . . . . . . . 50
5.4. Support messages . . . . . . . . . . . . . . . . . . . . 50 4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 51
5.4.1. General message and response . . . . . . . . . . . . 51 4.4.3. Get root CA certificate update . . . . . . . . . . . 52
5.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 52 4.4.4. Get certificate request template . . . . . . . . . . 53
5.4.3. Get root CA certificate update . . . . . . . . . . . 53 5. LRA and RA focused PKI management operations . . . . . . . . 55
5.4.4. Get certificate request parameters . . . . . . . . . 54 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 55
5.4.5. Get certificate management configuration . . . . . . 55 5.1.1. Not changing protection . . . . . . . . . . . . . . . 57
5.4.6. Get enrollment voucher . . . . . . . . . . . . . . . 57 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 57
6. LRA and RA focused PKI management operations . . . . . . . . 59 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 58
6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 58
6.1.1. Not changing protection . . . . . . . . . . . . . . . 61 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 59
6.1.2. Replacing protection . . . . . . . . . . . . . . . . 62 5.1.3.1. Handling a single PKI management message . . . . 60
6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 5.1.3.2. Handling a batch of PKI management messages . . . 60
6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 63 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 61
6.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 5.2. Revoking certificates on behalf of another's entities . . 62
6.1.4. Initiating delayed enrollment . . . . . . . . . . . . 63 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 62
6.2. Revoking certificates on behalf of another's entities . . 63 6. CMP message transport variants . . . . . . . . . . . . . . . 63
6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 64 6.1. Definition and discovery of HTTP URIs . . . . . . . . . . 63
7. CMP message transport variants . . . . . . . . . . . . . . . 65 6.2. HTTP transport . . . . . . . . . . . . . . . . . . . . . 66
7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 65 6.3. HTTPS transport using certificates . . . . . . . . . . . 66
7.2. HTTPS transport using certificates . . . . . . . . . . . 67 6.4. HTTPS transport using shared secrets . . . . . . . . . . 67
7.3. HTTPS transport using shared secrets . . . . . . . . . . 67 6.5. Offline transport . . . . . . . . . . . . . . . . . . . . 67
7.4. File-based transport . . . . . . . . . . . . . . . . . . 68 6.5.1. File-based transport . . . . . . . . . . . . . . . . 68
7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 68 6.5.2. Other asynchronous transport protocols . . . . . . . 68
7.6. Piggybacking on other reliable transport . . . . . . . . 68 6.6. CoAP transport . . . . . . . . . . . . . . . . . . . . . 68
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 6.7. Piggybacking on other reliable transport . . . . . . . . 68
9. Security Considerations . . . . . . . . . . . . . . . . . . . 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 69
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Normative References . . . . . . . . . . . . . . . . . . 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 69
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 72 10.2. Informative References . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 Appendix A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . 72
Appendix B. Example for CertReqTemplate . . . . . . . . . . . . 72
1. History of changes Appendix C. History of changes . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
Note: This section will be deleted in the final version of the
document.
From version 00 -> 01:
o Harmonize terminology with CMP [RFC4210], e.g.,
* transaction, message sequence, exchange, use case -> PKI
management operqation
* PKI component, (L)RA/CA -> PKI management entity
o Minor changes in wording
From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf-
lamps-lightweight-cmp-profile-00:
o Changes required to reflect WG adoption
o Minor changes in wording
From version 02 -> 03:
o Added a short summary of [RFC4210] Appendix D and E in
Section 2.3.
o Clarified some references to different sections and added some
clarification in response to feedback from Michael Richardson and
Tomas Gustavsson.
o Added an additional label to the operational path to address
multiple CAs or certificate profiles in Section 7.1.
From version 01 -> 02:
o Added some clarification on the key management techniques for
protection of centrally generated keys in Section 5.1.6.
o Added some clarifications on the certificates for root CA
certificate update in Section 5.4.3.
o Added a section to specify the usage of nested messages for RAs to
add an additional protection for further discussion, see
Section 6.1.3.
o Added a table containing endpoints for HTTP transport in
Section 7.1 to simplify addressing PKI management entities.
o Added some ToDos resulting from discussion with Tomas Gustavsson.
o Minor clarifications and changes in wording.
From version 00 -> 01:
o Added a section to specify the enrollment with a already trusted
PKI for further discussion, see Section 5.1.2.
o Complete specification of requesting a certificate from a legacy
PKI using a PKCS#10 [RFC2986] request in Section 5.1.5.
o Complete specification of adding central generation of a key pair
on behalf of an end entity in Section 5.1.6.
o Complete specification of handling delayed enrollment due to
asynchronous message delivery in Section 5.1.7.
o Complete specification of additional support messages, e.g., to
update a Root CA certificate or to request an RFC 8366 [RFC8366]
voucher, in Section 5.4.
o Minor changes in wording.
From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft-
brockhaus-lamps-lightweight-cmp-profile-00:
o Change focus from industrial to more multi-purpose use cases and
lightweight CMP profile.
o Incorporate the omitted confirmation into the header specified in
Section 4.1 and described in the standard enrollment use case in
Section 5.1.1 due to discussion with Tomas Gustavsson.
o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's
entities certificate' in Section 6.2, because it is regarded as
important functionality in many environments to enable the
management station to revoke EE certificates.
o Complete the specification of the revocation message flow in
Section 5.2 and Section 6.2.
o The CoAP based transport mechanism and piggybacking of CMP
messages on top of other reliable transport protocols is out of
scope of this document and would need to be specified in another
document.
o Further minor changes in wording. 1. Introduction
2. Introduction !!! The change history was moved to Appendix C !!!
This document specifies PKI management operations supporting machine- This document specifies PKI management operations supporting machine-
to-machine and IoT use cases. The focus lies on maximum automation to-machine and IoT use cases. The focus lies on maximum automation
and interoperable implementation of all involved PKI entities from and interoperable implementation of all involved PKI entities from
end entities (EE) through an optional Local Registration Authority end entities (EE) through an optional Local Registration Authority
(LRA) and the RA up to the CA. The profile makes use of the concepts (LRA) and the RA up to the CA. The profile makes use of the concepts
and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer
for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates].
Especially CMP and CRMF are very feature-rich standards, while only a Especially CMP and CRMF are very feature-rich standards, while only a
limited subset of the specified functionality is needed in many limited subset of the specified functionality is needed in many
environments. Additionally, the standards are not always precise environments. Additionally, the standards are not always precise
enough on how to interpret and implement the described concepts. enough on how to interpret and implement the described concepts.
Therefore, this document aims at tailoring and specifying in more Therefore, this document aims at tailoring and specifying in more
detail how to use these concepts to implement lightweight automated detail how to use these concepts to implement lightweight automated
certificate management. certificate management.
2.1. Motivation for profiling CMP 1.1. Motivation for profiling CMP
CMP was standardized in 1999 and is implemented in several CA CMP was standardized in 1999 and is implemented in several CA
products. In 2005 a completely reworked and enhanced version 2 of products. In 2005 a completely reworked and enhanced version 2 of
CMP [RFC4210] and CRMF [RFC4211] has been published followed by a CMP [RFC4210] and CRMF [RFC4211] has been published followed by a
document specifying a transfer mechanism for CMP messages using http document specifying a transfer mechanism for CMP messages using http
[RFC6712] in 2012. [RFC6712] in 2012.
Though CMP is a very solid and capable protocol it could be used more Though CMP is a very solid and capable protocol it could be used more
widely. The most important reason for not more intense application widely. The most important reason for not more intense application
of CMP appears to be that the protocol is offering a large set of of CMP appears to be that the protocol is offering a large set of
skipping to change at page 7, line 8 skipping to change at page 5, line 9
Doing such a profiling for a new target environment can be a high Doing such a profiling for a new target environment can be a high
effort because the range of available options needs to be well effort because the range of available options needs to be well
understood and the selected options need to be consistent with each understood and the selected options need to be consistent with each
other and with the intended usage scenario. Since most industrial other and with the intended usage scenario. Since most industrial
PKI management use cases typically have much in common it is worth PKI management use cases typically have much in common it is worth
sharing this effort, which is the aim of this document. Other sharing this effort, which is the aim of this document. Other
standardization bodies can then reference the needed PKI management standardization bodies can then reference the needed PKI management
operations from this document and do not need to come up with operations from this document and do not need to come up with
individual profiles. individual profiles.
2.2. Motivation for a lightweight profile for CMP 1.2. Motivation for a lightweight profile for CMP
The profiles specified in Appendix D and E of CMP have been developed The profiles specified in Appendix D and E of CMP have been developed
in particular to manage certificates of human end entities. With the in particular to manage certificates of human end entities. With the
evolution of distributed systems and client-server architectures, evolution of distributed systems and client-server architectures,
certificates for machines and applications on them have become widely certificates for machines and applications on them have become widely
used. This trend has strengthened even more in emerging industrial used. This trend has strengthened even more in emerging industrial
and IoT scenarios. CMP is sufficiently flexible to support these and IoT scenarios. CMP is sufficiently flexible to support these
very well. very well.
Today's IT security architectures for industrial solutions typically Today's IT security architectures for industrial solutions typically
skipping to change at page 7, line 45 skipping to change at page 5, line 46
Further challenges in many industrial systems are network Further challenges in many industrial systems are network
segmentation and asynchronous communication, where PKI operation is segmentation and asynchronous communication, where PKI operation is
often not deployed on-site but in a more protected environment of a often not deployed on-site but in a more protected environment of a
data center or trust center. Certificate management must be able to data center or trust center. Certificate management must be able to
cope with such network architectures. CMP offers the required cope with such network architectures. CMP offers the required
flexibility and functionality, namely self-contained messages, flexibility and functionality, namely self-contained messages,
efficient polling, and support for asynchronous message transfer with efficient polling, and support for asynchronous message transfer with
end-to-end security. end-to-end security.
2.3. Existing CMP profiles 1.3. Existing CMP profiles
As already stated, CMP contains profiles with mandatory and optional As already stated, CMP contains profiles with mandatory and optional
transactions in the Appendixes D and E of [RFC4210]. Those profiles transactions in the Appendixes D and E of [RFC4210]. Those profiles
focus on management of human user certificates and do only partly focus on management of human user certificates and do only partly
address the specific needs for certificate management automation for address the specific needs for certificate management automation for
unattended machine or application-oriented end entities. unattended machine or application-oriented end entities.
[RFC4210] specifies in Appendix D the following mandatory PKI [RFC4210] specifies in Appendix D the following mandatory PKI
management operations (all require support of, in the meantime management operations (all require support of, in the meantime
outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may
enroll up to two certificates, one for a locally generated and enroll up to two certificates, one for a locally generated and
another optional one for a centrally generated key pair; all require another optional one for a centrally generated key pair; all require
use of certConf/PKIConf messages for confirmation): use of certConf/pkiConf messages for confirmation):
o Initial registration/certification; an (uninitialized) end entity o Initial registration/certification; an (uninitialized) end entity
requests a (first) certificate from a CA using shared secret based requests a (first) certificate from a CA using shared secret based
message authentication. The content is similar to the PKI message authentication. The content is similar to the PKI
management operation specified in Section 5.1.4 of this document. management operation specified in Section 4.1.4 of this document.
o Certificate request; an (initialized) end entity requests another o Certificate request; an (initialized) end entity requests another
certificate from a CA using signature or shared secret based certificate from a CA using signature or shared secret based
message authentication. The content is similar to the PKI message authentication. The content is similar to the PKI
management operation specified in Section 5.1.2 of this document. management operation specified in Section 4.1.2 of this document.
o Key update; an (initialized) end entity requests a certificate o Key update; an (initialized) end entity requests a certificate
from a CA (to update the key pair and/or corresponding certificate from a CA (to update the key pair and/or corresponding certificate
that it already possesses) using signature or shared secret based that it already possesses) using signature or shared secret based
message authentication. The content is similar to the PKI message authentication. The content is similar to the PKI
management operation specified in Section 5.1.3 of this document. management operation specified in Section 4.1.3 of this document.
Due to the two certificates that may be enrolled and the shared Due to the two certificates that may be enrolled and the shared
secret based authentication, these PKI management operations focus secret based authentication, these PKI management operations focus
more on the enrollment of human users at a PKI. more on the enrollment of human users at a PKI.
[RFC4210] specifies in Appendix E the following optional PKI [RFC4210] specifies in Appendix E the following optional PKI
management operations (all require support of, in the meantime management operations (all require support of, in the meantime
outdated, algorithms, e.g., SHA-1 and 3-DES): outdated, algorithms, e.g., SHA-1 and 3-DES):
o Root CA key update; a root CA updates its key pair and produces a o Root CA key update; a root CA updates its key pair and produces a
CA key update announcement message that can be made available (via CA key update announcement message that can be made available (via
some transport mechanism) to the relevant end entities. This some transport mechanism) to the relevant end entities. This
operation only supports a push and no pull model. The content is operation only supports a push and no pull model. The content is
similar to the PKI management operation specified in Section 5.4.3 similar to the PKI management operation specified in Section 4.4.3
of this document. of this document.
o Information request/response; an end entity sends a general o Information request/response; an end entity sends a general
message to the PKI requesting details that will be required for message to the PKI requesting details that will be required for
later PKI management operations. The content is similar to the later PKI management operations. The content is similar to the
PKI management operation specified in Section 5.4.4 and PKI management operation specified in Section 4.4.4 of this
Section 5.4.5 of this document. document.
o Cross-certification request/response (1-way); creation of a single o Cross-certification request/response (1-way); creation of a single
cross-certificate (i.e., not two at once). The requesting CA MAY cross-certificate (i.e., not two at once). The requesting CA MAY
choose who is responsible for publication of the cross-certificate choose who is responsible for publication of the cross-certificate
created by the responding CA through use of the PKIPublicationInfo created by the responding CA through use of the PKIPublicationInfo
control. control.
o In-band initialization using external identity certificate (this o In-band initialization using external identity certificate (this
PKI management operation may also enroll up to two certificates PKI management operation may also enroll up to two certificates
and requires use of certConf/PKIConf messages for confirmation as and requires use of certConf/pkiConf messages for confirmation as
specified in Appendix D of [RFC4210]). An (uninitialized) end specified in Appendix D of [RFC4210]). An (uninitialized) end
entity wishes to initialize into the PKI with a CA, CA-1. It entity wishes to initialize into the PKI with a CA, CA-1. It
uses, for authentication purposes, a pre-existing identity uses, for authentication purposes, a pre-existing identity
certificate issued by another (external) CA, CA-X. A trust certificate issued by another (external) CA, CA-X. A trust
relationship must already have been established between CA-1 and relationship must already have been established between CA-1 and
CA-X so that CA-1 can validate the EE identity certificate signed CA-X so that CA-1 can validate the EE identity certificate signed
by CA-X. Furthermore, some mechanism must already have been by CA-X. Furthermore, some mechanism must already have been
established within the Personal Security Environment (PSE) of the established within the Personal Security Environment (PSE) of the
EE that would allow it to authenticate and verify PKIMessages EE that would allow it to authenticate and verify PKIMessages
signed by CA-1. The content is similar to the PKI management signed by CA-1. The content is similar to the PKI management
operation specified in Section 5.1.1 of this document. The trust operation specified in Section 4.1.1 of this document.
establishment of the EE in CA-1 and of the CA/RA in CA-X can be
automated using, e.g., the exchange of a certificate management
configuration as specified in Section 5.4.5 or an enrollment
voucher as specified in Section 5.4.6 of this document.
Both Appendixes focus on EE to CA/RA PKI management operations and do Both Appendixes focus on EE to CA/RA PKI management operations and do
not address further profiling of RA to CA communication as typically not address further profiling of RA to CA communication as typically
used for full backend automation. used for full backend automation.
3GPP makes use of CMP [RFC4210] in its Technical Specification 133 3GPP makes use of CMP [RFC4210] in its Technical Specification 133
310 [ETSI-3GPP] for automatic management of IPSec certificates in 310 [ETSI-3GPP] for automatic management of IPSec certificates in
UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP
profile for initial certificate enrollment and update operations profile for initial certificate enrollment and update operations
between EE and RA/CA is specified in that document. between EE and RA/CA is specified in that document.
UNISIG has included a CMP profile for certificate enrollment in the UNISIG has included a CMP profile for certificate enrollment in the
subset 137 specifying the ETRAM/ECTS on-line key management for train subset 137 specifying the ETRAM/ECTS on-line key management for train
control systems [UNISIG] in 2015. control systems [UNISIG] in 2015.
Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and
HTTP transfer for CMP [RFC6712] to add tailored means for automated HTTP transfer for CMP [RFC6712] to add tailored means for automated
PKI management operations for unattended machine or application- PKI management operations for unattended machine or application-
oriented end entities. oriented end entities.
2.4. Compatibility with existing CMP profiles 1.4. Compatibility with existing CMP profiles
The profile specified in this document is compatible with CMP The profile specified in this document is compatible with CMP
[RFC4210] Appendixes D and E (PKI Management Message Profiles), with [RFC4210] Appendixes D and E (PKI Management Message Profiles), with
the following exceptions: the following exceptions:
o signature-based protection is the default protection; an initial o signature-based protection is the default protection; an initial
PKI management operation may also use HMAC, PKI management operation may also use HMAC,
o certification of a second key pair within the same PKI management o certification of a second key pair within the same PKI management
operation is not supported, operation is not supported,
skipping to change at page 10, line 37 skipping to change at page 8, line 34
o protection of initial PKI management operations may be HMAC-based, o protection of initial PKI management operations may be HMAC-based,
o the subject name is mandatory in certificate templates, and o the subject name is mandatory in certificate templates, and
o confirmation of newly enrolled certificates may be omitted. o confirmation of newly enrolled certificates may be omitted.
The profile specified in this document is compatible with the CMP The profile specified in this document is compatible with the CMP
profile for on-line key management in rail networks as specified in profile for on-line key management in rail networks as specified in
UNISIG subset-137 [UNISIG], except that: UNISIG subset-137 [UNISIG], except that:
o As stated in Section 4.1.1 a CMP message SHALL only consist of one
certificate request (CertReqMsg). Therefore, UNISIG is in
conflict with this document as subset-137 allows to transport more
than one certificate request.
o as of RFC 4210 [RFC4210] the messageTime is required to be o as of RFC 4210 [RFC4210] the messageTime is required to be
Greenwich Mean Time coded as generalizedTime (Note: While UNISIG Greenwich Mean Time coded as generalizedTime (Note: While UNISIG
explicitely states that the messageTime in required to be 'UTC explicitly states that the messageTime in required to be 'UTC
time', it is not clear if this means a coding as UTCTime or time', it is not clear if this means a coding as UTCTime or
generalizedTime and if other time zones than Greenwich Mean Time generalizedTime and if other time zones than Greenwich Mean Time
shall be allowed. Therefore UNISG may be in conflict with shall be allowed. Therefore, UNISG may be in conflict with
RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 RFC 4210 [RFC4210]. Both time formats are described in RFC 5280
[RFC5280] section 4.1.2.5.), and [RFC5280] section 4.1.2.5.), and
o in case the request message is MAC protected, also the response, o in case the request message is MAC protected, also the response,
certConf, and PKIconf messages have a MAC-based protection (Note: certConf, and pkiConf messages have a MAC-based protection (Note:
if changing to signature protection of the response the caPubs if changing to signature protection of the response the caPubs
field cannot be used securely anymore.). field cannot be used securely anymore.).
2.5. Scope of this document 1.5. Scope of this document
This document specifies requirements on generating PKI management This document specifies requirements on generating PKI management
messages on the sender side. It does not specify strictness of messages on the sender side. It does not specify strictness of
verification on the receiving side and how in detail to handle error verification on the receiving side and how in detail to handle error
cases. cases.
Especially on the EE side this profile aims at a lightweight protocol Especially on the EE side this profile aims at a lightweight protocol
that can be implemented on more constrained devices. On the side of that can be implemented on more constrained devices. On the side of
the central PKI management entities the profile accepts higher the central PKI management entities the profile accepts higher
resources needed. resources needed.
For the sake of robustness and preservation of security properties For the sake of robustness and preservation of security properties
implementations should, as far as security is not affected, adhere to implementations should, as far as security is not affected, adhere to
Postel's law: "Be conservative in what you do, be liberal in what you Postel's law: "Be conservative in what you do, be liberal in what you
accept from others" (often reworded as: "Be conservative in what you accept from others" (often reworded as: "Be conservative in what you
send, be liberal in what you accept"). send, be liberal in what you accept").
When in Section 4, Section 5, and Section 6 a field of the ASN.1 When in Section 3, Section 4, and Section 5 a field of the ASN.1
syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not
explicitly specified, it SHOULD not be used by the sending entity. explicitly specified, it SHOULD not be used by the sending entity.
The receiving entity MUST NOT require its absence and if present MUST The receiving entity MUST NOT require its absence and if present MUST
gracefully handle its presence. gracefully handle its presence.
2.6. Structure of this document 1.6. Structure of this document
Section 3 introduces the general PKI architecture and approach to Section 2 introduces the general PKI architecture and approach to
certificate management using CMP that is assumed in this document. certificate management using CMP that is assumed in this document.
Then it enlists the PKI management opertations specified in this Then it enlists the PKI management operations specified in this
document and describes them in general words. The list of supported document and describes them in general words. The list of supported
PKI management operations is divided into mandatory, recommended, and PKI management operations is divided into mandatory, recommended, and
optional ones. optional ones.
Section 4 profiles the CMP message header, protection, and extraCerts Section 3 profiles the CMP message header, protection, and extraCerts
section as they are general elements of CMP messages. section as they are general elements of CMP messages.
Section 5 profiles the exchange of CMP messages between an EE and the Section 4 profiles the exchange of CMP messages between an EE and the
first PKI management entities. There are various flavors of first PKI management entities. There are various flavors of
certificate enrollment requests optionally with polling, revocation, certificate enrollment requests optionally with polling, revocation,
error handling, and general support PKI management operations. error handling, and general support PKI management operations.
Section 6 profiles the exchange between PKI management entities. Section 5 profiles the exchange between PKI management entities.
These are in the first place the forwarding of messages coming from These are in the first place the forwarding of messages coming from
or going to an EE. This includes also initiating delayed delivery of or going to an EE. This includes also initiating delayed delivery of
messages, which involves polling. Additionally, it specifies PKI messages, which involves polling. Additionally, it specifies PKI
management operations where a PKI management entity manages management operations where a PKI management entity manages
certificates on behalf of an EE or for itself. certificates on behalf of an EE or for itself.
Section 7 outlines different mechanisms for CMP message transfer, Section 6 outlines different mechanisms for CMP message transfer,
namely http-based transfer as already specified in [RFC6712], using namely http-based transfer as already specified in [RFC6712], using
an additional TLS layer, or offline file-based transport. CoAP an additional TLS layer, or offline file-based transport. CoAP
[RFC7252] and piggybacking CMP messages on other protocols is out of [RFC7252] and piggybacking CMP messages on other protocols is out of
scope and left for further documents. scope and left for further documents.
2.7. Convention and Terminology 1.7. Convention and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case use of these words are not to be only when in ALL CAPS. Lower case use of these words are not to be
interpreted as carrying significance described in RFC 2119. interpreted as carrying significance described in RFC 2119.
Technical terminology is used in conformance with RFC 4210 [RFC4210], Technical terminology is used in conformance with RFC 4210 [RFC4210],
skipping to change at page 12, line 50 skipping to change at page 10, line 50
of its certificate. of its certificate.
The following terminology is reused from RFC 4210 [RFC4210] and used The following terminology is reused from RFC 4210 [RFC4210] and used
as follows: as follows:
PKI management operation: All CMP messages belonging to one PKI management operation: All CMP messages belonging to one
transaction context. The transaction is transaction context. The transaction is
identified in the transactionID field of identified in the transactionID field of
the message header. the message header.
PKI management entity: All central PKI entites like LRA, RA and PKI management entity: All central PKI entities like LRA, RA and
CA. CA.
PKI entity: EEs and PKI management entites PKI entity: EEs and PKI management entities
3. Architecture and use cases 2. Architecture and use cases
3.1. Solution architecture 2.1. Solution architecture
Typically, a machine EE will be equipped with a manufacturer issued Typically, a machine EE will be equipped with a manufacturer issued
certificate during production. Such a manufacturer issued certificate during production. Such a manufacturer issued
certificate is installed during production to identify the device certificate is installed during production to identify the device
throughout its lifetime. This manufacturer certificate can be used throughout its lifetime. This manufacturer certificate can be used
to protect the initial enrollment of operational certificates after to protect the initial enrollment of operational certificates after
installation of the EE in a plant or industrial network. An installation of the EE in a plant or industrial network. An
operational certificate is issued by the owner or operator of the operational certificate is issued by the owner or operator of the
device to identify the device during operation, e.g., within a device to identify the device during operation, e.g., within a
security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR
skipping to change at page 14, line 15 skipping to change at page 12, line 15
In operation environments a layered LRA-RA-CA architecture can be In operation environments a layered LRA-RA-CA architecture can be
deployed, e.g., with LRAs bundling requests from multiple EEs at deployed, e.g., with LRAs bundling requests from multiple EEs at
dedicated locations and one (or more than one) central RA aggregating dedicated locations and one (or more than one) central RA aggregating
the requests from multiple LRAs. Every (L)RA in this scenario will the requests from multiple LRAs. Every (L)RA in this scenario will
have its own dedicated certificate containing an extended key usage have its own dedicated certificate containing an extended key usage
as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] and private as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] and private
key allowing it to protect CMP messages it processes (CMP signing key allowing it to protect CMP messages it processes (CMP signing
key/certificate). The figure above shows an architecture using one key/certificate). The figure above shows an architecture using one
LRA and one RA. It is also possible to have only an RA or multiple LRA and one RA. It is also possible to have only an RA or multiple
LRAs and/or RAs. Depending on the network infrastructure, the LRAs and/or RAs. Depending on the network infrastructure, the
communication between different PKI management entites may be communication between different PKI management entities may be
synchronous online-communication, delayed asynchronous communication, synchronous online communication, delayed asynchronous communication,
or even offline file transfer. or even offline file transfer.
This profile focusses on specifying the pull model, where the EE This profile focusses on specifying the pull model, where the EE
always requests a specific PKI management operation. CMP response always requests a specific PKI management operation. CMP response
messages, especially in case of central key generation, as described messages, especially in case of central key generation, as described
in Section 5.1.6, could also be used proactively to implement the in Section 4.1.6, could also be used proactively to implement the
push model towards the EE. push model towards the EE.
Third-party CAs typically implement different variants of CMP or even Third-party CAs typically implement different variants of CMP or even
use proprietary interfaces for certificate management. Therefore, use proprietary interfaces for certificate management. Therefore,
the LRA or the RA may need to adapt the exchanged CMP messages to the the LRA or the RA may need to adapt the exchanged CMP messages to the
flavor of communication required by the CA. flavor of communication required by the CA.
3.2. Basic generic CMP message content 2.2. Basic generic CMP message content
Section 4 specifies the generic parts of the CMP messages as used Section 3 specifies the generic parts of the CMP messages as used
later in Section 5 and Section 6. later in Section 4 and Section 5.
o Header of a CMP message; see Section 4.1. o Header of a CMP message; see Section 3.1.
o Protection of a CMP message; see Section 4.2. o Protection of a CMP message; see Section 3.2.
o ExtraCerts field of a CMP message; see Section 4.3. o ExtraCerts field of a CMP message; see Section 3.3.
3.3. Supported PKI management operations 2.3. Supported PKI management operations
Following the outlined scope from Section 2.5, this section gives a Following the outlined scope from Section 1.5, this section gives a
brief overview of the PKI management operations specified in brief overview of the PKI management operations specified in
Section 5 and Section 6 and points out, whether an implementation by Section 4 and Section 5 and points out whether an implementation by
compliant EE or PKI management entites is mandatory, recommended or compliant EE or PKI management entities is mandatory, recommended or
optional. optional.
3.3.1. Mandatory PKI management operations 2.3.1. Mandatory PKI management operations
The mandatory PKI management operations in this document shall limit The mandatory PKI management operations in this document shall limit
the overhead of certificate management for more constrained devices the overhead of certificate management for more constrained devices
to the most crucial types of operations. to the most crucial types of operations.
Section 5 - End Entity focused PKI management operations Section 4 - End Entity focused PKI management operations
o Request a certificate from a new PKI with signature protection; o Request a certificate from a new PKI with signature protection;
see Section 5.1.1. see Section 4.1.1.
o Request to update an existing certificate with signature o Request to update an existing certificate with signature
protection; see Section 5.1.3. protection; see Section 4.1.3.
o Error reporting; see Section 5.3. o Error reporting; see Section 4.3.
Section 6 - LRA and RA focused PKI management operations Section 5 - LRA and RA focused PKI management operations
o Forward messages without changes; see Section 6.1.1. o Forward messages without changes; see Section 5.1.1.
o Forward messages with replaced protection and keeping the original
proof-of-possession; see Section 5.1.2.1.
o Forward messages with replaced protection and raVerified as proof- o Forward messages with replaced protection and raVerified as proof-
of-possession; see Section 6.1.2.2. of-possession; see Section 5.1.2.2.
o Error reporting; see Section 6.3. o Error reporting; see Section 5.3.
3.3.2. Recommended PKI management operations 2.3.2. Recommended PKI management operations
Additional recommended PKI management operations shall support some Additional recommended PKI management operations shall support some
more complex scenarios, that are considered as beneficial for more complex scenarios, that are considered as beneficial for
environments with more specific boundary conditions. environments with more specific boundary conditions.
Section 5 - End Entity focused PKI management operations Section 4 - End Entity focused PKI management operations
o Request a certificate from a PKI with MAC protection; see o Request a certificate from a PKI with MAC protection; see
Section 5.1.4. Section 4.1.4.
o Handle delayed enrollment due to asynchronous message delivery;
see Section 5.1.7.
< TBD: There still some discussion ongoing if this should be
recommended or optional. >
o Revoke an own certificate. o Revoke an own certificate.
Section 6 - LRA and RA focused PKI management operations Section 5 - LRA and RA focused PKI management operations
o Revoke another's entities certificate. o Revoke another's entities certificate.
3.3.3. Optional PKI management operations 2.3.3. Optional PKI management operations
The optional PKI management operations support specific requirements The optional PKI management operations support specific requirements
seen only in a subset of environments. seen only in a subset of environments.
Section 5 - End Entity focused PKI management operations Section 4 - End Entity focused PKI management operations
o Request a certificate from a trusted PKI with signature o Request a certificate from a trusted PKI with signature
protection; see Section 5.1.2. protection; see Section 4.1.2.
o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986]
request; see Section 5.1.5. request; see Section 4.1.5.
o Add central generation of a key pair to a certificate request; see o Add central generation of a key pair to a certificate request; see
Section 5.1.6. If central key generation is supported, the key Section 4.1.6. If central key generation is supported, the key
agreement key management technique is REQUIRED to be supported, agreement key management technique is REQUIRED to be supported,
and the key transport and symmetric key-encryption key management and the key transport and symmetric key-encryption key management
techniques are OPTIONAL. techniques are OPTIONAL.
o Handle delayed enrollment due to asynchronous message delivery;
see Section 4.1.7.
o Additional support messages, e.g., to update a root CA certificate o Additional support messages, e.g., to update a root CA certificate
or to request an RFC 8366 [RFC8366] voucher; see Section 5.4. or to request an RFC 8366 [RFC8366] voucher; see Section 4.4.
Section 6 - LRA and RA focused PKI management operations Section 5 - LRA and RA focused PKI management operations
o Forward messages with additional protection; see Section 5.1.3
o Initiate delayed enrollment due to asynchronous message delivery; o Initiate delayed enrollment due to asynchronous message delivery;
see Section 6.1.4. see Section 5.1.4.
3.4. CMP message transport 2.4. CMP message transport
On different links between PKI entities, e.g., EE<->RA and RA<->CA, On different links between PKI entities, e.g., EE<->RA and RA<->CA,
different transport MAY be used. As CMP has only very limited different transport MAY be used. As CMP has only very limited
requirement regarding the mechanisms used for message transport and requirement regarding the mechanisms used for message transport and
in different environments different transport mechanisms are in different environments different transport mechanisms are
supported, e.g. HTTP, CoAP, or even offline files based, this supported, e.g. HTTP, CoAP, or even offline files based, this
document requires no specific transport protocol to be supported by document requires no specific transport protocol to be supported by
all conforming implementations. all conforming implementations.
HTTP transfer is RECOMMENDED to use for all PKI entities, but there HTTP transfer is RECOMMENDED to use for all PKI entities, but there
is no transport specified as mandatory to be flexible for devices is no transport specified as mandatory to be flexible for devices
with special constraines to choose whatever transport is suitable. with special constraints to choose whatever transport is suitable.
Recommended transport Recommended transport
o Transfer CMP messages using HTTP; see Section 6.2.
o Transfer CMP messages using HTTP; see Section 7.1.
Optional transport Optional transport
o Transfer CMP messages using HTTPS with certificate-based o Transfer CMP messages using HTTPS with certificate-based
authentication; see Section 7.2. authentication; see Section 6.3.
o Transfer CMP messages using HTTPS with shared-secret based o Transfer CMP messages using HTTPS with shared-secret based
protection; see Section 7.3. protection; see Section 6.4.
o File-based CMP message transport. o File-based CMP message transport.
< TBD: Motivation see Section 7.4 > 3. Generic parts of the PKI message
< TBD: Michael Richardson proposed to also specify a CoAP based
message transport profile. If there is further support for this
profile and someone volunteering to provide the necessary input for
this section, I would like to add it to this document. >
4. Generic parts of the PKI message
To reduce redundancy in the text and to ease implementation, the To reduce redundancy in the text and to ease implementation, the
contents of the header, protection, and extraCerts fields of the CMP contents of the header, protection, and extraCerts fields of the CMP
messages used in the transactions specified in Section 5 and messages used in the transactions specified in Section 4 and
Section 6 are standardized to the maximum extent possible. Section 5 are standardized to the maximum extent possible.
Therefore, the generic parts of a CMP message are described centrally Therefore, the generic parts of a CMP message are described centrally
in this section. in this section.
As described in section 5.1 of [RFC4210], all CMP messages have the As described in section 5.1 of [RFC4210], all CMP messages have the
following general structure: following general structure:
+--------------------------------------------+ +--------------------------------------------+
| PKIMessage | | PKIMessage |
| +----------------------------------------+ | | +----------------------------------------+ |
| | header | | | | header | |
skipping to change at page 17, line 50 skipping to change at page 15, line 47
| | protection (OPTIONAL) | | | | protection (OPTIONAL) | |
| +----------------------------------------+ | | +----------------------------------------+ |
| +----------------------------------------+ | | +----------------------------------------+ |
| | extraCerts (OPTIONAL) | | | | extraCerts (OPTIONAL) | |
| +----------------------------------------+ | | +----------------------------------------+ |
+--------------------------------------------+ +--------------------------------------------+
Figure 2: CMP message structure Figure 2: CMP message structure
The general contents of the message header, protection, and The general contents of the message header, protection, and
extraCerts fields are specified in the Section 4.1 to Section 4.3. extraCerts fields are specified in the Section 3.1 to Section 3.3.
In case a specific CMP message needs different contents in the In case a specific CMP message needs different contents in the
header, protection, or extraCerts fields, the differences are header, protection, or extraCerts fields, the differences are
described in the respective message. described in the respective message.
The CMP message body contains the message-specific information. It The CMP message body contains the message-specific information. It
is described in the context of Section 5 and Section 6. is described in the context of Section 4 and Section 5.
The behavior in case an error occurs while handling a CMP message is The behavior in case an error occurs while handling a CMP message is
described in Section 6.3. described in Section 5.3.
4.1. General description of the CMP message header 3.1. General description of the CMP message header
This section describes the generic header field of all CMP messages This section describes the generic header field of all CMP messages
with signature-based protection. The only variations described here with signature-based protection. The only variations described here
are in the fields recipient, transactionID, and recipNonce of the are in the fields recipient, transactionID, and recipNonce of the
first message of a PKI management operation. first message of a PKI management operation.
In case a message has MAC-based protection the changes are described In case a message has MAC-based protection the changes are described
in the respective section. The variations will affect the fields in the respective section. The variations will affect the fields
sender, protectionAlg, and senderKID. sender, protectionAlg, and senderKID.
skipping to change at page 18, line 52 skipping to change at page 16, line 48
-- In all other messages: SHOULD be the same name as in the -- In all other messages: SHOULD be the same name as in the
-- sender field of the previous message in this transaction -- sender field of the previous message in this transaction
messageTime RECOMMENDED messageTime RECOMMENDED
-- MUST be the time at which the message was produced, if -- MUST be the time at which the message was produced, if
-- present -- present
protectionAlg REQUIRED protectionAlg REQUIRED
-- MUST be the algorithm identifier of the signature algorithm or -- MUST be the algorithm identifier of the signature algorithm or
-- id-PasswordBasedMac algorithm used for calculation of the -- id-PasswordBasedMac algorithm used for calculation of the
-- protection bits -- protection bits
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- SubjectPublicKeyInfo field of the signer's certificate -- subjectPublicKeyInfo field of the signer's certificate
-- The hash algorithm used SHOULD be SHA-256 -- The hash algorithm used SHOULD be SHA-256
algorithm REQUIRED algorithm REQUIRED
-- MUST be the OID of the signature algorithm, like -- MUST be the OID of the signature algorithm, like
-- sha256WithRSAEncryption or ecdsa-with-SHA256, or -- sha256WithRSAEncryption or ecdsa-with-SHA256, or
-- id-PasswordBasedMac -- id-PasswordBasedMac
senderKID RECOMMENDED senderKID RECOMMENDED
-- MUST be the SubjectKeyIdentifier, if available, of the -- MUST be the SubjectKeyIdentifier, if available, of the
-- protection certificate -- protection certificate
transactionID REQUIRED transactionID REQUIRED
-- If this is the first message of a transaction: -- If this is the first message of a transaction:
skipping to change at page 19, line 42 skipping to change at page 17, line 38
-- Add to request messages to request omit sending certConf -- Add to request messages to request omit sending certConf
-- message -- message
-- Add to response messages to confirm omit sending certConf -- Add to response messages to confirm omit sending certConf
-- message -- message
ImplicitConfirmValue REQUIRED ImplicitConfirmValue REQUIRED
-- ImplicitConfirmValue of the request message MUST be NULL if -- ImplicitConfirmValue of the request message MUST be NULL if
-- the EE wants to request not to send a confirmation message -- the EE wants to request not to send a confirmation message
-- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA
-- wants to grant not sending a confirmation message -- wants to grant not sending a confirmation message
4.2. General description of the CMP message protection 3.2. General description of the CMP message protection
This section describes the generic protection field of all CMP This section describes the generic protection field of all CMP
messages with signature-based protection. The certificate for the messages with signature-based protection. The certificate for the
private key used to sign a CMP message is called 'protection private key used to sign a CMP message is called 'protection
certificate'. certificate'.
protection RECOMMENDED protection RECOMMENDED
-- MUST contain the signature calculated using the signature -- MUST contain the signature calculated using the signature
-- algorithm specified in protectionAlg -- algorithm specified in protectionAlg
Generally CMP message protection is required for CMP messages, but Generally, CMP message protection is required for CMP messages, but
there are cases where protection of error messages as specified in there are cases where protection of error messages as specified in
Section 5.3 and Section 6.3 is not possible and therefore MAY be Section 4.3 and Section 5.3 is not possible and therefore MAY be
omitted. omitted.
For MAC-based protection as specified in Section 5.1.4 major For MAC-based protection as specified in Section 4.1.4 major
differences apply as described in the respective section. differences apply as described in the respective section.
The CMP message protection provides, if available, message origin The CMP message protection provides, if available, message origin
authentication and integrity protection for the CMP message header authentication and integrity protection for the CMP message header
and body. The CMP message extraCerts is not covered by this and body. The CMP message extraCerts is not covered by this
protection. protection.
NOTE: The extended key usages specified in CMP Updates NOTE: The extended key usages specified in CMP Updates
[I-D.ietf-lamps-cmp-updates] can be used for authorization of a [I-D.ietf-lamps-cmp-updates] can be used for authorization of a
sending PKI management entity. sending PKI management entity.
NOTE: The requirements for checking certificates given in [RFC5280] NOTE: The requirements for checking certificates given in [RFC5280]
MUST be followed for the CMP message protection. In case the CMP MUST be followed for the CMP message protection. In case the CMP
signer certificates is not the CA certificate that signed the newly signer certificate is not the CA certificate that signed the newly
issued certificate, certificate status checking SHOULD be used for issued certificate, certificate status checking SHOULD be used for
the CMP signer certificates of communication partners. the CMP signer certificates of communication partners.
4.3. General description of CMP message extraCerts 3.3. General description of CMP message extraCerts
This section describes the generic extraCerts field of all CMP This section describes the generic extraCerts field of all CMP
messages with signature-based protection. If extraCerts are messages with signature-based protection. If extraCerts are
required, recommended, or optional is specified in the respective PKI required, recommended, or optional is specified in the respective PKI
management operation. management operation.
extraCerts extraCerts
-- SHOULD contain the protection certificate together with its -- SHOULD contain the protection certificate together with its
-- chain, if needed -- chain, if needed and the self-signed root certificate SHOULD
-- be omitted
-- If present, the first certificate in this field MUST -- If present, the first certificate in this field MUST
-- be the protection certificate -- be the protection certificate and each following certificate
-- Self-signed certificates SHOULD NOT be included in -- SHOULD directly certify the one immediately preceding it.
-- extraCerts and MUST NOT be trusted based on the listing in -- Self-signed certificates SHOULD be omitted from extraCerts
-- extraCerts in any case -- and MUST NOT be trusted based on the listing in extraCerts
-- in any case
5. End Entity focused PKI management operations Note: For maximum compatibility, all implementations SHOULD be
prepared to handle potentially additional and arbitrary orderings of
the certificates, except that the protection certificate is the first
certificate in extraCerts.
4. End Entity focused PKI management operations
This chapter focuses on the communication of the EE and the first PKI This chapter focuses on the communication of the EE and the first PKI
management entities it talks to. Depending on the network and PKI management entities it talks to. Depending on the network and PKI
solution, this will either be the LRA, the RA or the CA. solution, this will either be the LRA, the RA or the CA.
Profiles of the Certificate Management Protocol (CMP) [RFC4210] Profiles of the Certificate Management Protocol (CMP) [RFC4210]
handled in this section cover the following PKI management handled in this section cover the following PKI management
operations: operations:
o Requesting a certificate from a PKI with variations like initial o Requesting a certificate from a PKI with variations like initial
requests and updating, central key generation and different requests and updating, central key generation and different
protection means protection means
o Revocation of a certificate o Revocation of a certificate
o General messages for further support functions o General messages for further support functions
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 5. extraCerts as specified in Section 4.
The behavior in case an error occurs is described in Section 5.3. The behavior in case an error occurs is described in Section 4.3.
This chapter is aligned to Appendix D and Appendix E of [RFC4210]. This chapter is aligned to Appendix D and Appendix E of [RFC4210].
The general rules for interpretation stated in Appendix D.1 in The general rules for interpretation stated in Appendix D.1 in
[RFC4210] need to be applied here, too. [RFC4210] need to be applied here, too.
This document does not mandate any specific supported algorithms like This document does not mandate any specific supported algorithms like
Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the
message sequences described here require agreement upon the message sequences described here require agreement upon the
algorithms to support and thus the algorithm identifiers for the algorithms to support and thus the algorithm identifiers for the
specific target environment. specific target environment.
5.1. Requesting a new certificate from a PKI 4.1. Requesting a new certificate from a PKI
There are different approaches to request a certificate from a PKI. There are different approaches to request a certificate from a PKI.
These approaches differ on the one hand in the way the EE can These approaches differ on the one hand in the way the EE can
authenticate itself to the PKI it wishes to get a new certificate authenticate itself to the PKI it wishes to get a new certificate
from and on the other hand in its capabilities to generate a proper from and on the other hand in its capabilities to generate a proper
new key pair. The authentication means may be as follows: new key pair. The authentication means may be as follows:
o Using a certificate from a trusted PKI and the corresponding o Using a certificate from a trusted PKI and the corresponding
private key, e.g., a manufacturer issued certificate private key, e.g., a manufacturer issued certificate
skipping to change at page 22, line 18 skipping to change at page 20, line 28
4.1 case 3. To this end it is assumed that the private key can 4.1 case 3. To this end it is assumed that the private key can
technically be used as signing key. The most commonly used technically be used as signing key. The most commonly used
algorithms are RSA and ECDSA, which can technically be used for algorithms are RSA and ECDSA, which can technically be used for
signature calculation regardless of potentially intended restrictions signature calculation regardless of potentially intended restrictions
of the key usage. of the key usage.
The requesting EE provides the binding of the proof-of-possession to The requesting EE provides the binding of the proof-of-possession to
its identity by signature-based or MAC-based protection of the CMP its identity by signature-based or MAC-based protection of the CMP
request message containing that POPO. The PKI management entity request message containing that POPO. The PKI management entity
needs to verify whether this EE is authorized to obtain a certificate needs to verify whether this EE is authorized to obtain a certificate
with the requested subject and other attributes and extensions. with the requested subject and other fields and extensions.
Especially when removing the protection provided by the EE and Especially when removing the protection provided by the EE and
applying a new protection the PKI management entity MUST verify in applying a new protection, the PKI management entity MUST verify in
particular the included proof-of-possession self-signature of the particular the included proof-of-possession self-signature of the
certTemplate using the public key of the requested certificate and certTemplate using the public key of the requested certificate and
MUST check that the EE, as authenticated by the message protection, MUST check that the EE, as authenticated by the message protection,
is authorized to request a certificate with the subject as specified is authorized to request a certificate with the subject as specified
in the certTemplate (see Section 6.1.2). in the certTemplate (see Section 5.1.2).
There are several ways to install the Root CA certificate of a new There are several ways to install the Root CA certificate of a new
PKI on an EE. The installation can be performed in an out-of-band PKI on an EE. The installation can be performed in an out-of-band
manner, using general messages, a voucher [RFC8366], or other formats manner, using general messages, a voucher [RFC8366], or other formats
for enrollment, or in-band of CMP by the caPubs field in the for enrollment, or in-band of CMP by the caPubs field in the
certificate response message. In case the installation of the new certificate response message. In case the installation of the new
root CA certificate is performed using the caPubs field, the root CA certificate is performed using the caPubs field, the
certificate response message MUST be properly authenticated, and the certificate response message MUST be properly authenticated, and the
sender of this message MUST be authorized to install new root CA sender of this message MUST be authorized to install new root CA
certificates on the EE. This authorization can be indicated by using certificates on the EE. This authorization can be indicated by using
pre-shared keys for the CMP message protection. pre-shared keys for the CMP message protection.
5.1.1. Request a certificate from a new PKI with signature protection 4.1.1. Request a certificate from a new PKI with signature protection
This PKI management operation should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate of a new PKI using an existing certificate from an certificate of a new PKI using an existing certificate from an
external PKI, e.g., a manufacturer certificate, to prove its identity external PKI, e.g., a manufacturer certificate, to prove its identity
to the new PKI. The EE already has established trust in this new PKI to the new PKI. The EE already has established trust in this new PKI
it is about to enroll to, e.g., by voucher exchgnge or configuration it is about to enroll to, e.g., by voucher exchange or configuration
means. The initialization request message is signature-protected means. The initialization request message is signature-protected
using the existing certificate. using the existing certificate.
Preconditions: Preconditions:
1 The EE MUST have a certificate enrolled by an external PKI in 1 The EE MUST have a certificate enrolled by an external PKI in
advance to this PKI management operation to authenticate itself to advance to this PKI management operation to authenticate itself to
the PKI management entity using signature-based protection, e.g., the PKI management entity using signature-based protection, e.g.,
using a manufacturer issued certificate. using a manufacturer issued certificate.
2 The EE SHOULD know the subject name of the new CA it requests a 2 The EE SHOULD know the subject name of the new CA it requests a
certificate from; this name MAY be established using an enrollment certificate from; this name MAY be established using an enrollment
voucher or other configuration means. If the EE does not know the voucher, the issuer field from a the CertReqTemplate response
name of the CA, the PKI management entity MUST know where to route message, or other configuration means. If the EE does not know
this request to. the name of the CA, the PKI management entity MUST know where to
route this request to.
3 The EE MUST authenticate responses from the PKI management entity; 3 The EE MUST authenticate responses from the PKI management entity;
trust MAY be established using an enrollment voucher or other trust MAY be established using an enrollment voucher or other
configuration means configuration means.
4 The PKI management entity MUST trust the external PKI the EE uses 4 The PKI management entity MUST trust the external PKI the EE uses
to authenticate itself; trust MAY be established using some to authenticate itself; trust MAY be established using some
configuration means configuration means.
This PKI management operation is like that given in [RFC4210] This PKI management operation is like that given in [RFC4210]
Appendix E.7. Appendix E.7.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format ir 1 format ir
2 -> ir -> 2 -> ir ->
3 handle, re-protect or 3 handle, re-protect or
skipping to change at page 23, line 44 skipping to change at page 22, line 25
6 <- ip <- 6 <- ip <-
7 handle ip 7 handle ip
8 In case of status 8 In case of status
"rejection" in the "rejection" in the
ip message, no certConf ip message, no certConf
and pkiConf are sent and pkiConf are sent
9 format certConf (optional) 9 format certConf (optional)
10 -> certConf -> 10 -> certConf ->
11 handle, re-protect or 11 handle, re-protect or
forward certConf forward certConf
12 format or receive PKIConf 12 format or receive pkiConf
13 <- pkiConf <- 13 <- pkiconf <-
14 handle pkiConf (optional) 14 handle pkiConf (optional)
For this PKI management operation the EE MUST include exactly one For this PKI management operation, the EE MUST include exactly one
single CertReqMsg in the ir. If more certificates are required, single CertReqMsg in the ir. If more certificates are required,
further requests MUST be sent using separate CMP messages. If the EE further requests MUST be sent using separate CMP messages. If the EE
wants to omit sending a certificate confirmation message after wants to omit sending a certificate confirmation message after
receiving the ip to reduce the number of protocol messages exchanged receiving the ip to reduce the number of protocol messages exchanged
in this PKI management operation, it MUST request this by setting the in this PKI management operation, it MUST request this by including
implicitControlValue in the ir to NULL. the implicitConfirm extension in the ir.
If the CA accepts the certificate request it MUST return the new If the CA accepts the certificate request it MUST return the new
certificate in the certifiedKeyPair field of the ip message. If the certificate in the certifiedKeyPair field of the ip message. If the
EE requested to omit sending a certConf message after receiving the EE requested to omit sending a certConf message after receiving the
ip, the PKI management entity MAY confirm it by also setting the ip, the PKI management entity MAY confirm it by also including the
implicitControlValue to NULL or MAY rejects it by omitting the implicitConfirm extension or MAY rejects it by omitting the
implicitConfirm field in the ip. implicitConfirm field in the ip.
If the EE did not request implicit confirmation or the request was If the EE did not request implicit confirmation or the request was
not granted by the PKI management entity the confirmation as follows not granted by the PKI management entity the confirmation as follows
MUST be performed. If the EE successfully receives the certificate MUST be performed. If the EE successfully receives the certificate
and accepts it, the EE MUST send a certConf message, which MUST be and accepts it, the EE MUST send a certConf message, which MUST be
answered by the PKI management entity with a pkiConf message. If the answered by the PKI management entity with a pkiConf message. If the
PKI management entity does not receive the expected certConf message PKI management entity does not receive the expected certConf message
in time it MUST handle this like a rejection by the EE. in time it MUST handle this like a rejection by the EE.
skipping to change at page 24, line 35 skipping to change at page 23, line 17
"rejection" and no certifiedKeyPair field. Such an ip message MUST "rejection" and no certifiedKeyPair field. Such an ip message MUST
NOT be followed by the certConf and pkiConf messages. NOT be followed by the certConf and pkiConf messages.
Detailed message description: Detailed message description:
Certification Request -- ir Certification Request -- ir
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The request of the EE for a new certificate -- The request of the EE for a new certificate
ir REQUIRED ir REQUIRED
-- MUST be exactly one CertReqMsg -- MUST be exactly one CertReqMsg
-- If more certificates are required, further requests MUST be -- If more certificates are required, further requests MUST be
-- packaged in separate PKI Messages -- packaged in separate PKI Messages
certReq REQUIRED certReq REQUIRED
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be set to 0
skipping to change at page 25, line 37 skipping to change at page 24, line 18
-- present in the certTemplate -- present in the certTemplate
algorithmIdentifier REQUIRED algorithmIdentifier REQUIRED
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- publicKey field of the certTemplate -- publicKey field of the certTemplate
-- The hash algorithm used SHOULD be SHA-256 -- The hash algorithm used SHOULD be SHA-256
signature REQUIRED signature REQUIRED
-- MUST be the signature computed over the DER-encoded -- MUST be the signature computed over the DER-encoded
-- certTemplate -- certTemplate
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 3.3
Certification Response -- ip Certification Response -- ip
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The response of the CA to the request as appropriate -- The response of the CA to the request as appropriate
ip REQUIRED ip REQUIRED
caPubs OPTIONAL caPubs OPTIONAL
-- MAY be used -- MAY be used
-- If used it MUST contain only the root certificate of the -- If used it MUST contain only the root certificate of the
-- certificate contained in certOrEncCert -- certificate contained in certOrEncCert
response REQUIRED response REQUIRED
-- MUST be exactly one CertResponse -- MUST be exactly one CertResponse
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be set to 0
status REQUIRED status REQUIRED
skipping to change at page 26, line 44 skipping to change at page 25, line 24
certificate REQUIRED certificate REQUIRED
-- MUST be present when certifiedKeyPair is present -- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate -- MUST contain the newly enrolled X.509 certificate
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be absent in case of local key-generation -- MUST be absent in case of local key-generation
-- MUST contain the encrypted private key in an EnvelopedData -- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in section 5.1.5 in case the private -- structure as specified in section 5.1.5 in case the private
-- key was generated centrally -- key was generated centrally
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 3.3
-- MUST contain the chain of the certificate present in -- MUST contain the chain of the certificate present in
-- certOrEncCert -- certOrEncCert, the self-signed root certificate SHOULD be
-- omitted
-- Duplicate certificates MAY be omitted -- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf Certificate Confirmation -- certConf
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The message of the EE sends confirmation to the PKI -- The message of the EE sends confirmation to the PKI
-- management entity to accept or reject the issued certificates -- management entity to accept or reject the issued certificates
certConf REQUIRED certConf REQUIRED
-- MUST be exactly one CertStatus -- MUST be exactly one CertStatus
CertStatus REQUIRED CertStatus REQUIRED
certHash REQUIRED certHash REQUIRED
-- MUST be the hash of the certificate, using the same hash -- MUST be the hash of the certificate, using the same hash
-- algorithm as used to create the certificate signature -- algorithm as used to create the certificate signature
skipping to change at page 27, line 37 skipping to change at page 26, line 18
-- positive values allowed: "accepted" -- positive values allowed: "accepted"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging, or to -- MAY be any human-readable text for debugging, logging, or to
-- display in a GUI -- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MUST be present if status is "rejection" -- MUST be present if status is "rejection"
-- MUST be absent if the status is "accepted" -- MUST be absent if the status is "accepted"
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
-- MUST use the same certificate as for protection of the ir -- MUST use the same certificate as for protection of the ir
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- SHOULD contain the protection certificate together with its -- SHOULD contain the protection certificate together with its
-- chain, but MAY be omitted if the message size is critical and -- chain, but MAY be omitted if the message size is critical and
-- the PKI management entity did cash the extraCerts from the ir -- the PKI management entity did cash the extraCerts from the ir
-- If present, the first certificate in this field MUST be the -- If present, the first certificate in this field MUST be the
-- certificate used for signing this message -- certificate used for signing this message
-- Self-signed certificates SHOULD NOT be included in -- Self-signed certificates SHOULD NOT be included in
-- extraCerts and -- extraCerts and
-- MUST NOT be trusted based on the listing in extraCerts in -- MUST NOT be trusted based on the listing in extraCerts in
-- any case -- any case
PKI Confirmation -- pkiConf PKI Confirmation -- pkiconf
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
pkiConf REQUIRED pkiconf REQUIRED
-- The content of this field MUST be NULL -- The content of this field MUST be NULL
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
-- SHOULD use the same certificate as for protection of the ip -- SHOULD use the same certificate as for protection of the ip
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- SHOULD contain the protection certificate together with its -- SHOULD contain the protection certificate together with its
-- chain, but MAY be omitted if the message size is critical and -- chain, but MAY be omitted if the message size is critical and
-- the PKI management entity did cash the extraCerts from the ip -- the PKI management entity did cash the extraCerts from the ip
-- If present, the first certificate in this field MUST be the -- If present, the first certificate in this field MUST be the
-- certificate used for signing this message -- certificate used for signing this message
-- Self-signed certificates SHOULD NOT be included in extraCerts -- Self-signed certificates SHOULD NOT be included in extraCerts
-- and -- and
-- MUST NOT be trusted based on the listing in extraCerts in -- MUST NOT be trusted based on the listing in extraCerts in
-- any case -- any case
5.1.2. Request a certificate from a trusted PKI with signature 4.1.2. Request a certificate from a trusted PKI with signature
protection protection
< TBD: In case the PKI is already trusted the cr/cp messages could be This PKI management operation should be used by an EE to request an
used instead of ir/ip. It needs to be decided, whether an additional additional certificate of the same PKI it already has certificates
section should be added here, or the previous section should be from. The EE uses one of these existing certificates to prove its
extended to also cover this use case. > identity. The certificate request message is signature-protected
using this certificate.
5.1.3. Update an existing certificate with signature protection The general message flow for this PKI management operation is the
same as given in Section 4.1.1.
Preconditions:
1 The EE MUST have a certificate enrolled by the PKI it requests
another certificate from in advance to this PKI management
operation to authenticate itself to the PKI management entity
using signature-based protection.
2 The EE SHOULD know the subject name of the CA it requests a
certificate from; this name MAY be established using an enrollment
voucher, the issuer field from a the CertReqTemplate response
message, or other configuration means. If the EE does not know
the name of the CA, the PKI management entity MUST know where to
route this request to.
3 The EE MUST authenticate responses from the PKI management entity;
trust MUST be established using an enrollment voucher or other
configuration means.
4 The PKI management entity MUST trust the current PKI; trust MAY be
established using some configuration means.
The message sequence for this PKI management operation is like that
given in [RFC4210] Appendix D.5.
The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes:
1 The body of the first request and response MUST be cr and cp,
respectively.
2 The caPubs field in the cp message SHOULD be absent.
4.1.3. Update an existing certificate with signature protection
This PKI management operation should be used by an EE to request an This PKI management operation should be used by an EE to request an
update of one of the certificates it already has and that is still update of one of the certificates it already has and that is still
valid. The EE uses the certificate it wishes to update to prove its valid. The EE uses the certificate it wishes to update to prove its
identity and possession of the private key for the certificate to be identity and possession of the private key for the certificate to be
updated to the PKI. Therefore, the key update request message is updated to the PKI. Therefore, the key update request message is
signed using the certificate that is to be updated. signed using the certificate that is to be updated.
The general message flow for this PKI management operation is the The general message flow for this PKI management operation is the
same as given in Section 5.1.1. same as given in Section 4.1.1.
Preconditions: Preconditions:
1 The certificate the EE wishes to update MUST NOT be expired or 1 The certificate the EE wishes to update MUST NOT be expired or
revoked. revoked.
2 A new public-private key pair SHOULD be used. 2 A new public-private key pair SHOULD be used.
The message sequence for this PKI management operation is like that The message sequence for this PKI management operation is like that
given in [RFC4210] Appendix D.6. given in [RFC4210] Appendix D.6.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 5.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
1 The body of the first request and response MUST be kur and kup, 1 The body of the first request and response MUST be kur and kup,
respectively. respectively.
2 Protection of the kur MUST be performed using the certificate to 2 Protection of the kur MUST be performed using the certificate to
be updated. be updated.
3 The subject field of the CertTemplate MUST contain the subject 3 The subject field of the CertTemplate MUST contain the subject
name of the existing certificate to be updated, without name of the existing certificate to be updated, without
modifications. modifications.
4 The CertTemplate MUST contain the subject, issuer and publicKey 4 The CertTemplate MUST contain the subject, issuer and publicKey
fields only. fields only.
5 The regCtrl OldCertId SHOULD be used to make clear, even in case 5 The oldCertId control SHOULD be used to make clear, even in case
an (L)RA changes the message protection, which certificate is to an (L)RA changes the message protection, which certificate is to
be updated. be updated.
6 The caPubs field in the kup message MUST be absent. 6 The caPubs field in the kup message MUST be absent.
As part of the certReq structure of the kur the control is added As part of the certReq structure of the kur the control is added
right after the certTemplate. right after the certTemplate.
controls controls
type RECOMMENDED type RECOMMENDED
-- MUST be the value id-regCtrl-oldCertID, if present -- MUST be the value id-regCtrl-oldCertID, if present
value value
issuer REQUIRED issuer REQUIRED
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the issuer and serialNumber of the certificate -- MUST contain the issuer and serialNumber of the certificate
-- to be updated -- to be updated
5.1.4. Request a certificate from a PKI with MAC protection 4.1.4. Request a certificate from a PKI with MAC protection
This PKI management operation should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate of a new PKI without having a certificate to prove its certificate of a new PKI without having a certificate to prove its
identity to the target PKI, but there is a shared secret established identity to the target PKI, but there is a shared secret established
between the EE and the PKI. Therefore, the initialization request is between the EE and the PKI. Therefore, the initialization request is
MAC-protected using this shared secret. The PKI management entity MAC-protected using this shared secret. The PKI management entity
checking the MAC-protection SHOULD replace this protection according checking the MAC-protection SHOULD replace this protection according
to Section 6.1.2 in case the next hop does not know the shared to Section 5.1.2 in case the next hop does not know the shared
secret. secret.
For requirements with regard to proper random number and key For requirements with regard to proper random number and key
generation please refer to [RFC4086]. generation please refer to [RFC4086].
The general message flow for this PKI management operation is the The general message flow for this PKI management operation is the
same as given in Section 5.1.1. same as given in Section 4.1.1.
Preconditions: Preconditions:
1 The EE and the PKI management ectitiy MUST share a symmetric key, 1 The EE and the PKI management entity MUST share a symmetric key,
this MAY be established by a service technician during initial this MAY be established by a service technician during initial
local configuration. local configuration.
2 The EE SHOULD know the subject name of the new CA it requests a 2 The EE SHOULD know the subject name of the new CA it requests a
certificate from; this name MAY be established using an enrollment certificate from; this name MAY be established using an enrollment
voucher or other configuration means. If the EE does not know the voucher, the issuer field from a the CertReqTemplate response
name of the CA, the (L)RA/CA MUST know where to route this request message, or other configuration means. If the EE does not know
to. the name of the CA, the PKI management entity MUST know where to
route this request to.
3 The EE MUST authenticate responses from the PKI management entity; 3 The EE MUST authenticate responses from the PKI management entity;
trust MAY be established using the shared symmetric key. trust MAY be established using the shared symmetric key.
The message sequence for this PKI management operation is like that The message sequence for this PKI management operation is like that
given in [RFC4210] Appendix D.4. given in [RFC4210] Appendix D.4.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 5.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
1 The protection of all messages MUST be calculated using Message 1 The protection of all messages MUST be calculated using Message
Authentication Code (MAC); the protectionAlg field MUST be id- Authentication Code (MAC); the protectionAlg field MUST be id-
PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. PasswordBasedMac as described in section 5.1.3.1 of [RFC4210].
2 The sender MUST contain a name representing the originator of the 2 The sender MUST contain a name representing the originator of the
message. The senderKID MUST contain a reference all participating message. The senderKID MUST contain a reference all participating
entities can use to identify the symmetric key used for the entities can use to identify the symmetric key used for the
protection. protection, e.g., the username of the EE.
3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 3 The extraCerts of the ir, certConf, and pkiConf messages MUST be
absent. absent.
4 The extraCerts of the ip message MUST contain the chain of the 4 The extraCerts of the ip message MUST contain the chain of the
issued certificate and root certificates SHOULD not be included issued certificate and root certificates SHOULD not be included
and MUST NOT be directly trusted in any case. and MUST NOT be directly trusted in any case.
Part of the protectionAlg structure, where the algorithm identifier Part of the protectionAlg structure, where the algorithm identifier
MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields
of PBMParameter SHOULD remain constant for message protection of PBMParameter SHOULD remain constant for message protection
throughout this PKI management operation to reduce the computational throughout this PKI management operation to reduce the computational
skipping to change at page 31, line 28 skipping to change at page 31, line 5
-- MUST be a limited number of times the one-way function is -- MUST be a limited number of times the one-way function is
-- applied -- applied
-- To prevent brute force and dictionary attacks a reasonable -- To prevent brute force and dictionary attacks a reasonable
-- high number SHOULD be used -- high number SHOULD be used
mac REQUIRED mac REQUIRED
-- MUST be the algorithm identifier of the MAC algorithm used -- MUST be the algorithm identifier of the MAC algorithm used
-- The MAC function HMAC-SHA1 MUST be supported due to -- The MAC function HMAC-SHA1 MUST be supported due to
-- [RFC4211] requirements, but SHOULD NOT be used any more -- [RFC4211] requirements, but SHOULD NOT be used any more
-- HMAC-SHA-256 SHOULD be used instead -- HMAC-SHA-256 SHOULD be used instead
5.1.5. Request a certificate from a legacy PKI using PKCS#10 request 4.1.5. Request a certificate from a legacy PKI using PKCS#10 request
This PKI management operation should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] certificate of a legacy PKI only capable to process PKCS#10 [RFC2986]
certification requests. The EE can prove its identity to the target certification requests. The EE can prove its identity to the target
PKI by using various protection means as described in Section 5.1.1 PKI by using various protection means as described in Section 4.1.1
or Section 5.1.4. or Section 4.1.4.
In contrast to the other PKI management operations described in In contrast to the other PKI management operations described in
Section 5.1, this transaction uses PKCS#10 [RFC2986] instead of CRMF Section 4.1, this transaction uses PKCS#10 [RFC2986] instead of CRMF
[RFC4211] for the certificate request for compatibility reasons with [RFC4211] for the certificate request for compatibility reasons with
legacy CA systems that require a PKCS#10 certificate request and legacy CA systems that require a PKCS#10 certificate request and
cannot process CRMF [RFC4211] requests. In such case the PKI cannot process CRMF [RFC4211] requests. In such case the PKI
management entity must extract the PKCS#10 certificate request from management entity MUST extract the PKCS#10 certificate request from
the p10cr and provides it separately to the CA. the p10cr and provides it separately to the CA.
The general message flow for this PKI management operation is the The general message flow for this PKI management operation is the
same as given in Section 5.1.1, but the public key is contained in same as given in Section 4.1.1, but the public key is contained in
the subjectPKInfo of the PKCS#10 certificate request. the subjectPKInfo of the PKCS#10 certificate request.
Preconditions: Preconditions:
1 The EE MUST either have a certificate enrolled from this or any 1 The EE MUST either have a certificate enrolled from this or any
other accepted PKI, or a shared secret known to the PKI and the EE other accepted PKI, or a shared secret known to the PKI and the EE
to authenticate itself to the RA. to authenticate itself to the RA.
2 The EE SHOULD know the subject name of the CA it requests a 2 The EE SHOULD know the subject name of the CA it requests a
certificate from; this name MAY be established using an enrollment certificate from; this name MAY be established using an enrollment
voucher or other configuration means. If the EE does not know the voucher, the issuer field from a the CertReqTemplate response
name of the CA, the RA MUST know where to route this request to. message, or other configuration means. If the EE does not know
the name of the CA, the RA MUST know where to route this request
to.
3 The EE MUST authenticate responses from the RA; trust MAY be 3 The EE MUST authenticate responses from the RA; trust MAY be
established by an available root certificate, using an enrollment established by an available root certificate, using an enrollment
voucher, or other configuration means. voucher, or other configuration means.
4 The RA MUST trust the current or the PKI the EE uses to 4 The RA MUST trust the current or the PKI the EE uses to
authenticate itself; trust MAY be established by a corresponding authenticate itself; trust MAY be established by a corresponding
available root certificate or using some configuration means. available root certificate or using some configuration means.
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 5.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
1 The body of the first request and response MUST be p10cr and cp, 1 The body of the first request and response MUST be p10cr and cp,
respectively. respectively.
2 The subject name of the CA MUST be in the recipient field of the 2 The certReqId in the cp message MUST be 0.
p10cr message header.
3 The certReqId in the cp message MUST be 0.
4 The caPubs field in the cp message SHOULD be absent. 3 The caPubs field in the cp message SHOULD be absent.
Detailed description of the p10cr message: Detailed description of the p10cr message:
Certification Request -- p10cr Certification Request -- p10cr
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The request of the EE for a new certificate using a PKCS#10 -- The request of the EE for a new certificate using a PKCS#10
-- certificate request -- certificate request
p10cr REQUIRED p10cr REQUIRED
CertificationRequestInfo REQUIRED certificationRequestInfo REQUIRED
version REQUIRED version REQUIRED
-- MUST be set to 0 to indicate PKCS#10 V1.7 -- MUST be set to 0 to indicate PKCS#10 V1.7
subject REQUIRED subject REQUIRED
-- MUST contain the suggested subject name of the EE -- MUST contain the suggested subject name of the EE
subjectPKInfo REQUIRED subjectPKInfo REQUIRED
algorithm REQUIRED algorithm REQUIRED
-- MUST include the subject public key algorithm ID -- MUST include the subject public key algorithm ID
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST include the subject public key algorithm value -- MUST include the subject public key algorithm value
attributes OPTIONAL attributes OPTIONAL
-- MAY contain a set of end-entity-specific attributes or X.509 -- MAY contain a set of end-entity-specific fields or X.509
-- extensions to be included in the requested certificate or used -- extensions to be included in the requested certificate or used
-- otherwise -- otherwise
signatureAlgorithm REQUIRED signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256
signature REQUIRED signature REQUIRED
-- MUST containing the self-signature for proof-of-possession -- MUST containing the self-signature for proof-of-possession
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 3.3
5.1.6. Generate the key pair centrally at the PKI management entity 4.1.6. Generate the key pair centrally at the PKI management entity
This functional extension can be applied in combination with This functional extension can be applied in combination with
certificate enrollment as described in Section 5.1.1 and certificate enrollment as described in Section 4.1.1 and
Section 5.1.4. The functional extension can be used in case an EE is Section 4.1.4. The functional extension can be used in case an EE is
not able or is not willing to generate its new public-private key not able or is not willing to generate its new public-private key
pair itself. It is a matter of the local implementation which PKI pair itself. It is a matter of the local implementation which PKI
management entity will perform the key generation. This entity MUST management entity will perform the key generation. This entity MUST
have a certificate containing the additional extended key usage have a certificate containing the additional extended key usage
extension id-kp-cmcKGA to be identified by the EE as a legitimate extension id-kp-cmcKGA to be identified by the EE as a legitimate
key-generation authority. In case the PKI management entity key-generation authority. In case the PKI management entity
generated the new key pair for the EE, it can use Section 5.1.1 to generated the new key pair for the EE, it can use Section 4.1.1 to
Section 5.1.4 to request the certificate for this key pair as usual. Section 4.1.4 to request the certificate for this key pair as usual.
Generally speaking, in a machine-to-machine scenario it is strongly Generally speaking, in a machine-to-machine scenario it is strongly
preferable to generate public-private key pairs locally at the EE. preferable to generate public-private key pairs locally at the EE.
Together with proof-of-possession of the private key in the Together with proof-of-possession of the private key in the
certification request, this is to make sure that only the entity certification request, this is to make sure that only the entity
identified in the newly issued certificate is the only entity who identified in the newly issued certificate is the only entity who
ever hold the private key. ever hold the private key.
There are some cases where an EE is not able or not willing to There are some cases where an EE is not able or not willing to
locally generate the new key pair. Reasons for this may be the locally generate the new key pair. Reasons for this may be the
skipping to change at page 34, line 40 skipping to change at page 33, line 42
Note: As key generation can be performed in advance to the Note: As key generation can be performed in advance to the
certificate enrollment communication, it is typical not time certificate enrollment communication, it is typical not time
critical. critical.
Note: Besides the initial enrollment right after the very first Note: Besides the initial enrollment right after the very first
bootup of the device, where entropy available on the device may be bootup of the device, where entropy available on the device may be
insufficient, we do not see any good reason for central key insufficient, we do not see any good reason for central key
generation. generation.
Note: As mentioned in Section 3.1 central key generation may be Note: As mentioned in Section 2.1 central key generation may be
required in a push model, where the certificate response message is required in a push model, where the certificate response message is
transferred by the PKI management entity to the EE without receiving transferred by the PKI management entity to the EE without receiving
a previous request message. a previous request message.
If the EE wishes to request central key generation, it MUST fill the If the EE wishes to request central key generation, it MUST fill the
subjectPublicKey field in the certTemplate structure of the request subjectPublicKey field in the certTemplate structure of the request
message with a zero-length BIT STRING. This indicates to the PKI message with a zero-length BIT STRING. This indicates to the PKI
management entity that a new key pair shall be generated centrally on management entity that a new key pair shall be generated centrally on
behalf of the EE. behalf of the EE.
skipping to change at page 36, line 9 skipping to change at page 35, line 9
As part of the EnvelopedData structure this content-encryption key As part of the EnvelopedData structure this content-encryption key
MUST be securely provided to the EE using one of three key management MUST be securely provided to the EE using one of three key management
techniques. The choice of the key management technique to be used by techniques. The choice of the key management technique to be used by
the PKI management entity depends on the authentication mechanism the the PKI management entity depends on the authentication mechanism the
EE choose to protect the request message, see CMP Updates section 3.4 EE choose to protect the request message, see CMP Updates section 3.4
[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.
o MAC protected request message: The content-encryption key SHALL be o MAC protected request message: The content-encryption key SHALL be
protected using the symmetric key-encryption key management protected using the password-based key management technique, see
technique, see Section 5.1.6.1, only if the EE used MAC protection Section 4.1.6.3, only if the EE used MAC protection for the
for the respected request message. respected request message.
o Signature protected request message using a certificate that o Signature protected request message using a certificate that
contains a key usage extension asserting keyAgreement: The contains a key usage extension asserting keyAgreement: The
content-encryption key SHALL be protected using the key agreement content-encryption key SHALL be protected using the key agreement
key management technique, see Section 5.1.6.2, if the certificate key management technique, see Section 4.1.6.1, if the certificate
used by the EE for signing the respective request message contains used by the EE for signing the respective request message contains
the key usage keyAgreement. If the certificate also contains the the key usage keyAgreement. If the certificate also contains the
key usage keyEncipherment, the key transport key management key usage keyEncipherment, the key transport key management
technique SHALL NOT be used. technique SHALL NOT be used.
o Signature protected request message using a certificate that o Signature protected request message using a certificate that
contains a key usage extension asserting keyEncipherment: The contains a key usage extension asserting keyEncipherment: The
content-encryption key SHALL be protected using the key transport content-encryption key SHALL be protected using the key transport
key management technique, see Section 5.1.6.3, if the certificate key management technique, see Section 4.1.6.2, if the certificate
used by the EE for signing the respective request message contains used by the EE for signing the respective request message contains
the key usage keyEncipherment and not keyAgreement. the key usage keyEncipherment and not keyAgreement.
The key agreement key management technique can be supported by most The key agreement key management technique can be supported by most
signature algorithms, as key transport key management technique can signature algorithms, as key transport key management technique can
only be supported by a very limited number of algorithms. The only be supported by a very limited number of algorithms. The
symmetric key-encryption key management technique shall only be used password-based key management technique shall only be used in
in combination with MAC protection, which is a side-line in this combination with MAC protection, which is a side-line in this
document. Therefore, if central key generation is supported, the document. Therefore, if central key generation is supported, the
support ofthe key agreement key management technique is REQUIRED and support of the key agreement key management technique is REQUIRED and
the support of key transport and symmetric key-encryption key the support of key transport and password-based key management
management techniques are OPTIONAL. techniques are OPTIONAL.
For encrypting the SignedData structure containing the private key a For encrypting the SignedData structure containing the private key a
fresh content-encryption key MUST be generated with enough entropy fresh content-encryption key MUST be generated with enough entropy
with regard to the used symmetric encryption algorithm. with regard to the used symmetric key-encryption algorithm.
Note: Depending on the lifetime of the certificate and the Note: Depending on the lifetime of the certificate and the
criticality of the generated private key, it is advisable to use the criticality of the generated private key, it is advisable to use the
strongest available symmetric encryption algorithm. Therefore, this strongest available symmetric encryption algorithm. Therefore, this
specification recommends using at least AES-256. specification recommends using at least AES-256.
The detailed description of the privateKey field looks like this: The detailed description of the privateKey field looks like this:
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be an envelopedData structure as specified in -- MUST be an EnvelopedData structure as specified in
-- CMS [RFC5652] section 6 -- CMS [RFC5652] section 6
version REQUIRED version REQUIRED
-- MUST be set to 2 -- MUST be set to 2
recipientInfos REQUIRED recipientInfos REQUIRED
-- MUST be exactly one RecipientInfo -- MUST be exactly one RecipientInfo
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be either KEKRecipientInfo (see section 5.1.5.1), -- MUST be either KeyAgreeRecipientInfo (see section 5.1.5.1),
-- KeyAgreeRecipientInfo (see section 5.1.5.2), or -- KeyTransRecipientInfo (see section 5.1.5.2), or
-- KeyTransRecipientInfo (see section 5.1.5.3) is used -- PasswordRecipientInfo (see section 5.1.5.3) is used
-- If central key generation is supported, support of -- If central key generation is supported, support of
-- KEKRecipientInfo is REQUIRED and support of -- KeyAgreeRecipientInfo is REQUIRED and support of
-- KeyAgreeRecipientInfo and KeyTransRecipientInfo is OPTIONAL -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL
encryptedContentInfo encryptedContentInfo
REQUIRED REQUIRED
contentType REQUIRED contentType REQUIRED
-- MUST be id-signedData -- MUST be id-signedData
contentEncryptionAlgorithm contentEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the symmetric -- MUST be the algorithm identifier of the symmetric
-- content-encryption algorithm used -- content-encryption algorithm used
-- As private keys need long-term protection, the use of AES-256 -- As private keys need long-term protection, the use of AES-256
-- or a stronger symmetric algorithm is RECOMMENDED -- or a stronger symmetric algorithm is RECOMMENDED
encryptedContent REQUIRED encryptedContent REQUIRED
-- MUST be the encrypted signedData structure as specified in -- MUST be the signedData structure as specified in
-- CMS [RFC5652] section 5 -- CMS [RFC5652] section 5 in encrypted form
version REQUIRED version REQUIRED
-- MUST be set to 3 -- MUST be set to 3
digestAlgorithms digestAlgorithms
REQUIRED REQUIRED
-- MUST be exactly one digestAlgorithm identifier -- MUST be exactly one digestAlgorithm identifier
digestAlgorithmIdentifier digestAlgorithmIdentifier
REQUIRED REQUIRED
-- MUST be the OID of the digest algorithm used for generating -- MUST be the OID of the digest algorithm used for generating
-- the signature -- the signature
-- The hash algorithm used SHOULD be SHA-256 -- The hash algorithm used SHOULD be SHA-256
skipping to change at page 38, line 15 skipping to change at page 37, line 15
-- MAY be present to provide status information on the signer or -- MAY be present to provide status information on the signer or
-- its CA certificates -- its CA certificates
signerInfos REQUIRED signerInfos REQUIRED
-- MUST be exactly one signerInfo -- MUST be exactly one signerInfo
version REQUIRED version REQUIRED
-- MUST be set to 3 -- MUST be set to 3
sid REQUIRED sid REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST be the subjectKeyIdentifier of the signer's certificate -- MUST be the subjectKeyIdentifier of the signer's certificate
digest algorithm digestAlgorithm
REQUIRED REQUIRED
-- MUST be the same OID as in digest algorithm -- MUST be the same OID as in digest algorithm
signatureAlgorithm signatureAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the signature algorithm -- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits, -- used for calculation of the signature bits,
-- like sha256WithRSAEncryption or ecdsa-with-SHA256 -- like sha256WithRSAEncryption or ecdsa-with-SHA256
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- SubjectPublicKeyInfo field of the signer's certificate -- subjectPublicKeyInfo field of the signer's certificate
signature REQUIRED signature REQUIRED
-- MUST be the result of the digital signature generation -- MUST be the result of the digital signature generation
5.1.6.1. Using symmetric key-encryption key management technique 4.1.6.1. Using key agreement key management technique
This key management technique can be applied in combination with the
PKI management operation specified in Section 5.1.4 using MAC
protected CMP messages. The shared secret used for the MAC
protection MUST also be used for the encryption of the content-
encryption key but with a different seed in the PBMParameter
sequence. To use this key management technique the KEKRecipientInfo
structure MUST be used in the contentInfo field.
The KEKRecipientInfo structure included into the envelopedData
structure is specified in CMS Section 6.2.3 [RFC5652].
The detailed description of the KEKRecipientInfo structure looks like
this:
recipientInfo REQUIRED
-- MUST be KEKRecipientInfo as specified in
-- CMS section 6.2.3 [RFC5652]
version REQUIRED
-- MUST be set to 4
kekid REQUIRED
keyIdentifier REQUIRED
-- MUST contain the same value as the senderKID in the respective
-- request messages
keyEncryptionAlgorithm
REQUIRED
-- MUST be id-PasswordBasedMac
PBMParameter REQUIRED
salt REQUIRED
-- MUST be the random value to salt the secret key
-- MUST be a different value than used in the PBMParameter
-- data structure of the CMP message protection in the
-- header of this message
owf REQUIRED
-- MUST be the same value than used in the PBMParameter
-- data structure in the header of this message
iterationCount
REQUIRED
-- MUST be a limited number of times the OWF is applied
-- To prevent brute force and dictionary attacks a reasonable
-- high number SHOULD be used
mac REQUIRED
-- MUST be the same as in the contentEncryptionAlgorithm field
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key
< TBD: To make use of a different symmetric keys for encrypting the
private key and for MAC-protection of the CMP message, we derive
another key using the same PBMParameter structure from CMP, even
though from the perspective of field names, it is not intended to be
used for deriving encryption keys. Does anyone sees a better
solution here? >
5.1.6.2. Using key agreement key management technique
This key management technique can be applied in combination with the This key management technique can be applied in combination with the
PKI management operations specified in Section 5.1.1 to Section 5.1.3 PKI management operations specified in Section 4.1.1 to Section 4.1.3
using signature-based protected CMP messages. The public key of the using signature-based protected CMP messages. The public key of the
EE certificate used for the signature-based protection of the request EE certificate used for the signature-based protection of the request
message MUST also be used for the Ephemeral-Static Diffie-Hellmann message MUST also be used for the Ephemeral-Static Diffie-Hellmann
key establishment of the content-encryption key. To use this key key establishment of the content-encryption key. To use this key
management technique the KeyAgreeRecipientInfo structure MUST be used management technique the KeyAgreeRecipientInfo structure MUST be used
in the contentInfo field. in the contentInfo field.
The KeyAgreeRecipientInfo structure included into the envelopedData The KeyAgreeRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.2 [RFC5652]. structure is specified in CMS Section 6.2.2 [RFC5652].
The detailed description of the KeyAgreeRecipientInfo structure looks The detailed description of the KeyAgreeRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be KeyAgreeRecipientInfo as specified in -- MUST be KeyAgreeRecipientInfo as specified in
version REQUIRED version REQUIRED
-- MUST be set to 3 -- MUST be set to 3
originator REQUIRED originator REQUIRED
skipping to change at page 40, line 45 skipping to change at page 38, line 39
rid REQUIRED rid REQUIRED
rKeyId REQUIRED rKeyId REQUIRED
subjectKeyID subjectKeyID
REQUIRED REQUIRED
-- MUST contain the same value as the senderKID in the -- MUST contain the same value as the senderKID in the
-- respective request messages -- respective request messages
encryptedKey encryptedKey
REQUIRED REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
5.1.6.3. Using key transport key management technique 4.1.6.2. Using key transport key management technique
This key management technique can be applied in combination with the This key management technique can be applied in combination with the
PKI management operations specified in Section 5.1.1 to Section 5.1.3 PKI management operations specified in Section 4.1.1 to Section 4.1.3
using signature-based protected CMP messages. The public key of the using signature-based protected CMP messages. The public key of the
EE certificate used for the signature-based protection of the request EE certificate used for the signature-based protection of the request
message MUST also be used for key encipherment of the content- message MUST also be used for key encipherment of the content-
encryption key. To use this key management technique the encryption key. To use this key management technique the
KeyTransRecipientInfo structure MUST be used in the contentInfo KeyTransRecipientInfo structure MUST be used in the contentInfo
field. field.
The KeyTransRecipientInfo structure included into the envelopedData The KeyTransRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.1 [RFC5652]. structure is specified in CMS Section 6.2.1 [RFC5652].
The detailed description of the KeyTransRecipientInfo structure looks The detailed description of the KeyTransRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be KeyTransRecipientInfo as specified in -- MUST be KeyTransRecipientInfo as specified in
-- CMS section 6.2.1 [RFC5652] -- CMS section 6.2.1 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be set to 2 -- MUST be set to 2
skipping to change at page 41, line 31 skipping to change at page 39, line 25
REQUIRED REQUIRED
-- MUST contain the same value as the senderKID in the respective -- MUST contain the same value as the senderKID in the respective
-- request messages -- request messages
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST contain the key encryption algorithm identifier used for -- MUST contain the key encryption algorithm identifier used for
-- public key encryption -- public key encryption
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
5.1.7. Delayed enrollment 4.1.6.3. Using password-based key management technique
This key management technique can be applied in combination with the
PKI management operation specified in Section 4.1.4 using MAC
protected CMP messages. The shared secret used for the MAC
protection MUST also be used for the encryption of the content-
encryption key but with a different salt. To use this key management
technique the PasswordRecipientInfo structure MUST be used in the
contentInfo field.
The PasswordRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.3 [RFC5652].
The detailed description of the PasswordRecipientInfo structure looks
like this:
recipientInfo REQUIRED
-- MUST be PasswordRecipientInfo as specified in
-- CMS section 6.2.4 [RFC5652]
version REQUIRED
-- MUST be set to 0
keyDerivationAlgorithm
REQUIRED
-- MUST be set to id-PBKDF2 as specified in [RFC8018]
-- The same shared secret MUST be used than used in
-- PBMParameter data structure for the MAC protection in the
-- header of this message
salt REQUIRED
-- MUST be the random value to salt the secret key
-- MUST be a different value than used in the PBMParameter
-- data structure of the CMP message protection in the
-- header of this message
iterationCount
REQUIRED
-- MUST be a limited number of times the OWF is applied
-- To prevent brute force and dictionary attacks a reasonable
-- high number SHOULD be used
keyLength REQUIRED
prf REQUIRED
-- MUST be the algorithm identifier of the underlying
-- pseudorandom function
-- The pseudorandom function HMAC-SHA1 MUST be supported
-- due to [RFC8018] requirements, but SHOULD NOT be used any
-- more HMAC-SHA-256 SHOULD be used instead
keyEncryptionAlgorithm
REQUIRED
-- MUST be the same as in the contentEncryptionAlgorithm field
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key
4.1.7. Delayed enrollment
This functional extension can be applied in combination with This functional extension can be applied in combination with
certificate enrollment as described in Section 5.1.1 to certificate enrollment as described in Section 4.1.1 to
Section 5.1.5. The functional extension can be used in case a PKI Section 4.1.5. The functional extension can be used in case a PKI
management entity cannot respond to the certificate request in a management entity cannot respond to the certificate request in a
timely manner, e.g., due to offline upstream communication or timely manner, e.g., due to offline upstream communication or
required registration officer interaction. Depending on the PKI required registration officer interaction. Depending on the PKI
architecture, it is not necessary that the PKI management entity architecture, it is not necessary that the PKI management entity
directly communicating with the EE initiates the delayed enrollment. directly communicating with the EE initiates the delayed enrollment.
The PKI management entity initiating the delayed enrollment MUST The PKI management entity initiating the delayed enrollment MUST
include the status "waiting" in the response and this response MUST include the status "waiting" in the response and this response MUST
NOT contain a newly issued certificate. When receiving a response NOT contain a newly issued certificate. When receiving a response
with status "waiting" the EE MUST send a poll request to the PKI with status "waiting" the EE MUST send a poll request to the PKI
skipping to change at page 42, line 12 skipping to change at page 41, line 23
as the PKI management entity can provide the final response message as the PKI management entity can provide the final response message
for the initial request of the EE, it MUST provide this in response for the initial request of the EE, it MUST provide this in response
to a poll request. After receiving this response, the EE can to a poll request. After receiving this response, the EE can
continue the original PKI management operation as described in the continue the original PKI management operation as described in the
respective section of this document, e.g., send a certConf message. respective section of this document, e.g., send a certConf message.
Typically, intermediate PKI management entities SHOULD NOT change the Typically, intermediate PKI management entities SHOULD NOT change the
sender and recipient nonce even in case an intermediate PKI sender and recipient nonce even in case an intermediate PKI
management entity modifies a request or a response message. In the management entity modifies a request or a response message. In the
special case of polling between EE and LRA with offline transport special case of polling between EE and LRA with offline transport
between an LRA and RA, see Section 6.1.4, an exception occurs. The between an LRA and RA, see Section 5.1.4, an exception occurs. The
EE and LRA exchange pollReq and pollRep messages handle the nonce EE and LRA exchange pollReq and pollRep messages handle the nonce
words as described. When, after pollRep, the final response from the words as described. When, after pollRep, the final response from the
CA arrives at the LRA, the next response will contain the CA arrives at the LRA, the next response will contain the recipNonce
recipientNonce set to the value of the senderNonce in the original set to the value of the senderNonce in the original request message
request message (copied by the CA). The LRA needs to replace the (copied by the CA). The LRA needs to replace the recipNonce in this
recipientNonce in this case with the senderNonce of the last pollReq case with the senderNonce of the last pollReq because the EE will
because the EE will validate it in this way. validate it in this way.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format ir/cr/p10cr/kur 1 format ir/cr/p10cr/kur
As described in the As described in the
respective section respective section
in this document in this document
2 ->ir/cr/p10cr/kur-> 2 ->ir/cr/p10cr/kur->
3 handle request as described 3 handle request as described
skipping to change at page 45, line 50 skipping to change at page 44, line 50
-- If present, it MUST contain certificates as described for the -- If present, it MUST contain certificates as described for the
-- pkiConf message of the respective PKI management operation. -- pkiConf message of the respective PKI management operation.
Final response -- ip/cp/kup Final response -- ip/cp/kup
Field Value Field Value
header header
-- MUST contain a header as described for the first -- MUST contain a header as described for the first
-- response message of the respective PKI management operation, -- response message of the respective PKI management operation,
-- but the recipientNonce MUST be the senderNonce of the last -- but the recipNonce MUST be the senderNonce of the last
-- pollReq message -- pollReq message
body body
-- The response of the PKI management entity to the initial -- The response of the PKI management entity to the initial
-- request as described in the respective PKI management -- request as described in the respective PKI management
-- operation -- operation
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the first response -- MUST contain protection as described for the first response
-- message of the respective PKI management operation, but -- message of the respective PKI management operation, but
-- MUST use the protection key of the PKI management entity that -- MUST use the protection key of the PKI management entity that
-- initiated the delayed enrollment and forwarding the response -- initiated the delayed enrollment and forwarding the response
-- message -- message
extraCerts REQUIRED extraCerts REQUIRED
-- MUST contain certificates as described for the first -- MUST contain certificates as described for the first
-- response message of the respective PKI management operation -- response message of the respective PKI management operation
5.2. Revoking a certificate 4.2. Revoking a certificate
This PKI management operation should be used by an entity to request This PKI management operation should be used by an entity to request
the revocation of a certificate. Here the revocation request is used the revocation of a certificate. Here the revocation request is used
by an EE to revoke one of its own certificates. A PKI management by an EE to revoke one of its own certificates. A PKI management
entity could also act as an EE to revoke one of its own certificates. entity could also act as an EE to revoke one of its own certificates.
The revocation request message MUST be signed using the certificate The revocation request message MUST be signed using the certificate
that is to be revoked to prove the authorization to revoke to the that is to be revoked to prove the authorization to revoke to the
PKI. The revocation request message is signature-protected using PKI. The revocation request message is signature-protected using
this certificate. this certificate.
skipping to change at page 47, line 18 skipping to change at page 46, line 18
1 format rr 1 format rr
2 -> rr -> 2 -> rr ->
3 handle, re-protect or 3 handle, re-protect or
forward rr forward rr
4 receive rp 4 receive rp
5 <- rp <- 5 <- rp <-
6 handle rp 6 handle rp
For this PKI management operation, the EE MUST include exactly one For this PKI management operation, the EE MUST include exactly one
RevDetails structure in the rr message body. In case no error RevDetails structure in the rr message body. In case no error
occurred the response to the rr MUST be an rp message. The PKI occurred the response to the rr MUST be a rp message. The PKI
management entity MUST produce a rp containing a status field with a management entity MUST produce a rp containing a status field with a
single set of values. single set of values.
Detailed message description: Detailed message description:
Revocation Request -- rr Revocation Request -- rr
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The request of the EE to revoke its certificate -- The request of the EE to revoke its certificate
rr REQUIRED rr REQUIRED
-- MUST contain exactly one element of type RevDetails -- MUST contain exactly one element of type RevDetails
-- If more revocations are desired, further requests MUST be -- If more revocations are desired, further requests MUST be
-- packaged in separate PKI Messages -- packaged in separate PKI Messages
certDetails REQUIRED certDetails REQUIRED
-- MUST be present and is of type CertTemplate -- MUST be present and is of type CertTemplate
serialNumber REQUIRED serialNumber REQUIRED
skipping to change at page 48, line 4 skipping to change at page 47, line 4
issuer REQUIRED issuer REQUIRED
-- MUST contain the issuer attribute of the X.509 certificate to -- MUST contain the issuer attribute of the X.509 certificate to
-- be revoked -- be revoked
crlEntryDetails REQUIRED crlEntryDetails REQUIRED
-- MUST contain exactly one reasonCode of type CRLReason (see -- MUST contain exactly one reasonCode of type CRLReason (see
-- [RFC5280] section 5.3.1) -- [RFC5280] section 5.3.1)
-- If the reason for this revocation is not known or shall not be -- If the reason for this revocation is not known or shall not be
-- published the reasonCode MUST be 0 = unspecified -- published the reasonCode MUST be 0 = unspecified
protection REQUIRED protection REQUIRED
-- As described in section 4.2 and the private key related to the -- As described in section 3.2 and the private key related to the
-- certificate to be revoked -- certificate to be revoked
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 3.3
Revocation Response -- rp Revocation Response -- rp
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The responds of the PKI management entity to the request as -- The responds of the PKI management entity to the request as
-- appropriate -- appropriate
rp REQUIRED rp REQUIRED
status REQUIRED status REQUIRED
-- MUST contain exactly one element of type PKIStatusInfo -- MUST contain exactly one element of type PKIStatusInfo
status REQUIRED status REQUIRED
-- positive value allowed: "accepted" -- positive value allowed: "accepted"
-- negative value allowed: "rejection" -- negative value allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, logging or to
-- display in a GUI -- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if and only if status is "rejection" -- MAY be present if and only if status is "rejection"
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 3.3
5.3. Error reporting 4.3. Error reporting
This functionality should be used by an EE to report any error This functionality should be used by an EE to report any error
conditions upstream to the PKI management entity. Error reporting by conditions upstream to the PKI management entity. Error reporting by
a PKI management entity downstream to the EE is described in a PKI management entity downstream to the EE is described in
Section 6.3. Section 5.3.
In case the error condition is related to specific details of an ip, In case the error condition is related to specific details of an ip,
cp, or kup response message and a confirmation is expected the error cp, or kup response message and a confirmation is expected the error
condition MUST be reported in the respective certConf message with condition MUST be reported in the respective certConf message with
negative contents. negative contents.
General error conditions, e.g., problems with the message header, General error conditions, e.g., problems with the message header,
protection, or extraCerts, and negative feedback on rp, pollRep, or protection, or extraCerts, and negative feedback on rp, pollRep, or
pkiConf messages MAY be reported in the form of an error message. pkiConf messages MAY be reported in the form of an error message.
skipping to change at page 50, line 12 skipping to change at page 49, line 12
error message SHOULD resend the request in a new transaction error message SHOULD resend the request in a new transaction
after some time. after some time.
Detailed error message description: Detailed error message description:
Error Message -- error Error Message -- error
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The message sent by the EE or the (L)RA/CA to indicate an -- The message sent by the EE or the (L)RA/CA to indicate an
-- error that occurred -- error that occurred
error REQUIRED error REQUIRED
pKIStatusInfo REQUIRED pKIStatusInfo REQUIRED
status REQUIRED status REQUIRED
-- MUST have the value "rejection" -- MUST have the value "rejection"
statusString RECOMMENDED statusString RECOMMENDED
-- SHOULD be any human-readable text for debugging, logging -- SHOULD be any human-readable text for debugging, logging
-- or to display in a GUI -- or to display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present -- MAY be present
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
extraCerts OPTIONAL extraCerts OPTIONAL
-- As described in section 4.3 -- As described in section 3.3
5.4. Support messages 4.4. Support messages
The following support messages offer on demand in-band transport of The following support messages offer on demand in-band transport of
content that may be provided by the PKI management entity and content that may be provided by the PKI management entity and
relevant to the EE. The general messages and general response are relevant to the EE. The general messages and general response are
used for this purpose. Depending on the environment, these requests used for this purpose. Depending on the environment, these requests
may be answered by the LRA, RA, or CA. may be answered by the LRA, RA, or CA.
The general message and general response transport InfoTypeAndValue The general message and general response transport InfoTypeAndValue
structures. In addition to those infoType values defined in CMP structures. In addition to those infoType values defined in CMP
[RFC4210] further OIDs MAY be defined to define new PKI management [RFC4210] further OIDs MAY be defined to define new PKI management
operations, or general-purpose messages as needed in a specific operations, or general-purpose support messages as needed in a
environment. specific environment.
Possible content described here address: Content specified in this document is describs the following:
o Request of CA certificates o Request of CA certificates
o Update of Root CA certificates o Update of Root CA certificates
o Parameters needed for a planned certificate request message o Parameters needed for a planned certificate request message
o Voucher request and enrollment voucher exchange 4.4.1. General message and response
5.4.1. General message and response
The PKI management operation is similar to that given in CMP The PKI management operation is similar to that given in CMP
Appendix E.5 [RFC4210]. In this section the general message (genm) Appendix E.5 [RFC4210]. In this section the general message (genm)
and general response (genp) are described. The specific and general response (genp) are described. The specific
InfoTypeAndValue structures are described in the following sections. InfoTypeAndValue structures are described in the following sections.
The behavior in case an error occurs is described in Section 5.3. The behavior in case an error occurs is described in Section 4.3.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format genm 1 format genm
2 -> genm -> 2 -> genm ->
3 handle, re-protect or 3 handle, re-protect or
forward genm forward genm
4 format or receive genp 4 format or receive genp
5 <- genp <- 5 <- genp <-
6 handle genp 6 handle genp
Detailed message description: Detailed message description:
General Message -- genm General Message -- genm
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The request of the EE to receive information -- The request of the EE to receive information
genm REQUIRED genm REQUIRED
-- MUST contain exactly one element of type -- MUST contain exactly one element of type
-- InfoTypeAndValue -- InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying the specific PKI -- MUST be the OID identifying the specific PKI
-- management operation described below -- management operation described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific PKI -- MUST be as described in the specific PKI
-- management operation described below -- management operation described below
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 3.3
General Response -- genp General Response -- genp
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 3.1
body body
-- The response of the PKI management entity to the -- The response of the PKI management entity to the
-- information request -- information request
genp REQUIRED genp REQUIRED
-- MUST contain exactly one element of type -- MUST contain exactly one element of type
-- InfoTypeAndValue -- InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying the specific PKI -- MUST be the OID identifying the specific PKI
-- management operationdescribed below -- management operation described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific PKI -- MUST be as described in the specific PKI
-- management operation described below -- management operation described below
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 3.3
5.4.2. Get CA certificates 4.4.2. Get CA certificates
This PKI management operation can be used by an EE to request CA This PKI management operation can be used by an EE to request CA
certificates from the PKI management entity. certificates from the PKI management entity.
An EE requests CA certificates from the PKI management entity by An EE requests CA certificates from the PKI management entity by
sending a general message with OID id-it-getCaCerts. The PKI sending a general message with OID id-it-caCerts. The PKI management
management entity responds with a general response with the same OID entity responds with a general response with the same OID that either
that either contains a SEQUENCE of certificates populated with the contains a SEQUENCE of certificates populated with the available CA
available CA intermediate and issuing CA certificates or with no intermediate and issuing CA certificates or with no content in case
content in case no CA certificate is available. no CA certificate is available.
< NOTE: The OID id-it-getCaCerts is not yet defined. It should be
registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType
OIDs, see CMP Appendix F [RFC4210] on page 92. >
The message sequence for this PKI management operation is as given in The message sequence for this PKI management operation is as given in
Section 5.4.1, with the following specific content: Section 4.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-getCaCerts 1 the body MUST contain as infoType the OID id-it-caCerts
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be caCerts field 3 if present, the infoValue of the response MUST be caCerts field
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
getCaCerts OID looks like this: caCerts OID looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CA certificate is available -- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available -- MUST be present if CA certificates are available
caCerts REQUIRED
-- MUST be present if infoValue is present
-- MUST be a sequence of CMPCertificate -- MUST be a sequence of CMPCertificate
5.4.3. Get root CA certificate update 4.4.3. 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
update of an existing root CA Certificate by the EE. It utilizes the update of an existing root CA Certificate by the EE.
CAKeyUpdAnnContent structure as described in CMP Appendix E.4
[RFC4210] as response to a respective general message.
An EE requests a root CA certificate update from the PKI management An EE requests a root CA certificate update from the PKI management
entity by sending a general message with OID id-it-caKeyUpdateInfo as entity by sending a general message with OID id-it-rootCaKeyUpdate as
infoType and no infoValue. The PKI management entity responds with a infoType and no infoValue. The PKI management entity responds with a
general response with the same OID that either contains the update of general response with the same OID that either contains the update of
the root CA certificate consisting of up to three certificates, or the root CA certificate consisting of up to three certificates, or
with no content in case no update is available. with no content in case no update is available.
These three certificates are described in more detail in section These three certificates are described in more detail in section
4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew
certificate is the new root CA certificates and is REQUIRED to be certificate is the new root CA certificates and is REQUIRED to be
present in the response message. The newWithOld certificate is present in the response message. The newWithOld certificate is
RECOMMENDED to be present in the response message though it is RECOMMENDED to be present in the response message though it is
REQUIRED for those cases where the receiving entity trusts the old REQUIRED for those cases where the receiving entity trusts the old
root CA certificate and whishes to gain trust in the new root CA root CA certificate and wishes to gain trust in the new root CA
certificate. The oldWithNew certificate is OPTIONAL though it is certificate. The oldWithNew certificate is OPTIONAL though it is
only needed in a scenario where the requesting entity already trusts only needed in a scenario where the requesting entity already trusts
the new root CA certificate and wants to gain trust in the old root the new root CA certificate and wants to gain trust in the old root
certificate. certificate.
The message sequence for this PKI management operation is as given in The message sequence for this PKI management operation is as given in
Section 5.4.1, with the following specific content: Section 4.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-caKeyUpdateInfo 1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be a 3 if present, the infoValue of the response MUST be a
CAKeyUpdAnnContent structure RootCaKeyUpdate structure
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
caKeyUpdateInfo extension looks like this: rootCaKeyUpdate extension looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no update of the root CA certificate is -- MUST be absent if no update of the root CA certificate is
available -- available
-- MUST be present if an update of the root CA certificate -- MUST be present if an update of the root CA certificate
-- is available -- is available and MUST be of type RootCaKeyUpdate
caKeyUpdateInfo REQUIRED newWithNew REQUIRED
-- MUST be present and be of type CAKeyUpdAnnContent -- MUST be present if infoValue is present
oldWithNew OPTIONAL -- MUST contain the new root CA certificate
-- MAY be present if infoValue is present newWithOld RECOMMENDED
-- MUST contain an X.509 certificate containing the old public
-- root CA key signed with the new private root CA key
newWithOld RECOMMENDED
-- SHOULD be present if infoValue is present -- SHOULD be present if infoValue is present
-- MUST contain an X.509 certificate containing the new public -- MUST contain an X.509 certificate containing the new public
-- root CA key signed with the old private root CA key -- root CA key signed with the old private root CA key
newWithNew REQUIRED oldWithNew OPTIONAL
-- MUST be present if infoValue is present -- MAY be present if infoValue is present
-- MUST contain the new root CA certificate -- MUST contain an X.509 certificate containing the old public
-- root CA key signed with the new private root CA key
< TBD: To reduce unnecessary overhead by including not needed 4.4.4. Get certificate request template
certificates, we intend to require only to incert the newWithNew
certificate in the caKeyUpdateInfo structure and optionally omit the
oldWithNew and newWithOld certificates. This is in conflict with
[RFC4210] where also oldWithNew and newWithOld are required fields in
caKeyUpdateInfo. Is there any possiblility to optionally leave these
filds empty and still reuse the caKeyUpdateInfo structure as
specified in [RFC4210]? >
5.4.4. Get certificate request parameters This PKI management operation can be used by an EE to request a
template with parameters for a future certificate request operation.
This PKI management operation can be used by an EE to request An EE requests certificate request parameters from the PKI management
configuration parameters for a planned certificate request operation. entity by sending a general message with OID id-it-certReqTemplate.
The PKI management entity responds with a general response with the
same OID that either contains a certificate template with the
required fields and optionally a rsaKeyLen field containing
requirements on, e.g., algorithm identifier for key pair generation
or certificate fields and extensions, or with no content in case no
specific requirements are made by the PKI.
An EE requests for a planned certificate request parameters from the The EE SHOULD follow the requirements from the received CertTemplate
PKI management entity by sending a general message with OID id-it- and the optional rsaKeyLen fields, by filling in all the fields
getCSRParam. The PKI management entity responds with a general requested and taking over all the field values provided. The EE
response with the same OID that either contains the required fields, SHOULD NOT add further CertTemplate fields, Name components, and
e.g., algorithm identifier for key pair generation or other extensions or their (sub-)components.
attributes and extensions or with no content in case no specific
requirements are made by the PKI.
< NOTE: The OID id-it-getCSRParam is not yet defined. It should be Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order
registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType to allow more flexibility in case the rules given here are not
OIDs, see CMP Appendix F [RFC4210] on page 92. > sufficient for specific scenarios. The EE can populate the
certificate request as wanted and ignore any of the requirements
contained in the CertReqTemplate response message. On the other
hand, a PKI management entity is free to ignore or replace the
content of the certificate request provided by the EE. The
CertReqTemplate PKI management operation offers means to ease a joint
understanding which fields should be used.
The EE SHOULD follow the requirements from the recieved CertTemplate In case a field of type Name, e.g., issuer or subject name, is
and the optional RSA key length. In case a field is present but the present but has the value NULL-DN (i.e., has an empty list of RDN
value is absent or NULL, it means that this field is required but its components) the field SHOULD be included with content provided by the
content has to be provided by the EE. EE. Similarly, in case an X.509v3 extension is present but its
extnValue is empty this means that the extension SHOULD be included
with content provided by the EE. In case a Name component, for
instance a common name or serial number, is given but has an empty
string value the EE SHOULD fill in a value. Similarly, in case an
extension has sub-components (e.g., an IP address in a SubjectAltName
field) with empty value, the EE SHOULD fill in a value.
< TBD: There is some more explanation needed to explain how to The EE MUST ignore (i.e., not include and fill in) empty fields,
prefill the certTemplate structure. Possibly an example will help to extensions, and sub-components that it does not know.
clarify this. >
If the publicKey field of type SubjectPublicKeyInfo is present its
algorithm field specifies the type of the public key to request a
certificate for. The algorithm field contains the key type OID of
the public key. For EC keys the full curve information MUST be
specified as described in the respective standard documents. For RSA
keys the key length MUST be specified in the rsaKeyLen field of the
outer infoValue field. The algorithm field MUST be followed by a
zero-length BIT STRING for the subjectPublicKey. If the publicKey
field is not present the EE is free to choose the public key type and
parameters.
In the certTemplate structure the serialNumber, signingAlg,
issuerUID, and subjectUID fields MUST be omitted.
The message sequence for this PKI management operation is as given in The message sequence for this PKI management operation is as given in
Section 5.4.1, with the following specific content: Section 4.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-getCSRParam 1 the body MUST contain as infoType the OID id-it-certReqTemplate
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be a SEQUENCE of a 3 if present, the infoValue of the response MUST be a SEQUENCE of a
certTemplate structure and an rsaKeyLen field of type INTEGER certTemplate structure and an rsaKeyLen field of type INTEGER
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
getCSRParam OID looks like this: certReqTemplate OID looks like this:
infoValue OPTIONAL InfoValue OPTIONAL
-- MUST be absent if no requirements are available -- MUST be absent if no requirements are available
-- MUST be present if the PKI management entity has any -- MUST be present if the PKI management entity has any
-- requirements on the content of the certificates to be -- requirements on the content of the certificates template
-- requested -- is available and MUST be of type CertReqTemplateValue
certTemplate REQUIRED certTemplate REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the prefilled certTemplate structure -- MUST contain the prefilled certTemplate structure elements
rsaKeyLen OPTIONAL rsaKeyLen OPTIONAL
-- This field is of type INTEGER. Any reasonable RSA key length -- This field is of type INTEGER. Any reasonable RSA key length
-- SHOULD be specified if the algorithm in the -- MUST be specified if the algorithm in the
-- subjectPublicKeyInfo field of the certTemplate is of type -- subjectPublicKeyInfo field of the certTemplate has the OID
-- rsaEncryption. -- rsaEncryption.
-- MUST be omitted in otherwise.
< TBD: To offer a set of allowed key lenths, the rsaKeyLen field 5. LRA and RA focused PKI management operations
could also be specified as a SEQUENCE OF INTEGER. >
5.4.5. Get certificate management configuration
This PKI management operation can be used by an EE to request the
current certificate management configuration information by the EE in
advance to a planned PKI management operation, e.g., in case no out-
of-band transport is available. Such certificate management
configuration can consist of all information the EE needs to know to
generate and deliver a proper certificate request, such as
o algorithm, curve, and key length for key generation
o various certificate attributes and extensions to be used for the
certificate request
o specific host name, port and path on the RA/LRA to send this CMP
request to
o Infrastructure Root CA Certificate, e.g., the root of the (L)RA
TLS and CMP signer certificates.
There is an overlap with Section 5.4.2 regarding transport of CA
certificates and with Section 5.4.4 regarding key generation
parameter and certificate request attributes and extensions. This
profile offers to request a proprietary configuration file containing
all information needed in one exchange.
< TBD: Especially with section 5.4.4 there is some overlap regarding
algorithms, attributes and, extensions of the certificate that will
be requested. It needs to be decided if both variants have a right
to exist next to each other or if one option should be removed from
this document. >
An EE requests certificate management configuration from the PKI
management entity by sending a general message with the OID id-it-
getCertMgtConfig. The PKI management entity responds with a general
response with the same OID that either contains a certMgtConfig field
containing the configuration file encoded as OCTET STRING or with no
content in case no certificate management configuration is available.
< NOTE: The OID id-it-getCertMgtConfig is not yet defined. It should
be registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType
OIDs, see CMP Appendix F [RFC4210] on page 92. >
The EE SHOULD use the contents of this certMgtConfig to format and
deliver the certificate request. The certificate management
configuration may contain contact details, e.g., like an URI and
issuing CA distinguished name, where to address the request messages
to and may also contain certificate request parameters as described
in Section 5.4.4.
The certMgtConfig field may be of any format suitable for the EE,
e.g., JWT [RFC7519] or XML [W3C_XML]. The certMgtConfig contents MAY
be signed, e.g., like CMS SignedData [RFC5652], JWS [RFC7515] or,
XML-DSig [W3C_XML-Dsig]. For interoperability the format of the
certMgtConfig field should be specified in detail if needed.
The message sequence for this PKI management operation is as given in
Section 5.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-getCertMgtConfig
2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be a certMgtConfig
structure
The infoValue field of the general response containing the id-it-
getCertMgtConfig extension looks like this:
infoValue OPTIONAL
-- MUST be absent if no certificate management configuration
-- is available
-- MUST be present if the PKI management entity provides any
-- certificate management configuration
certMgtConfig REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the certificate management configuration as OCTET
-- OCTET STRING
5.4.6. Get enrollment voucher
This PKI management operation can be used by an EE to request an
enrollment voucher containing the root certificate of a new,
additional, or alternative PKI to establish trust in this PKI, e.g.,
in case no out-of-band transport is available. Such an enrollment
voucher can be used in advance to an enrollment to this new
environment.
An EE requests an enrollment voucher from the PKI management entity
by sending a general message. The PKI management entity responds
with a general response with the same OID that either contains the
voucher or with no content in case no voucher is available.
The PKI management entity MAY use the content of the voucherRequest
to get an enrollment voucher from other backend components, e.g., as
described in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The EE
SHOULD use the contents of the received enrollmentVoucher to
authenticate the PKI management entity it is about to enroll to. The
enrollment voucher may for example contain the Root CA certificate of
the new PKI or the CMP signer certificate of the PKI management
entity. The general response message MUST be properly authenticated
and the EE MUST verify the authorization of the sender to install new
root certificates. One example for an enrollment voucher is
specified in RFC8366 [RFC8366].
The voucherRequest and enrollmentVoucher fields may be of any format
suitable for the EE, e.g., JWT [RFC7519] or XML [W3C_XML]. The
voucherRequest and enrollmentVoucher contents MAY contain a
signature, e.g., CMS SignedData [RFC5652], JWS [RFC7515] or, XML-DSig
[W3C_XML-Dsig]. For interoperability the format of the
voucherRequest and enrollmentVoucher field schould be specified in
detail if needed, e.g., as defined in BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366].
< TBD: The vontent of the voucherRequest and enrollmentVoucher fields
can also be linited to the specifications in BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. >
The message sequence for this PKI management operation is as given in
Section 5.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-
getEnrollmentVoucher
2 if present, the infoValue of the request MUST be a voucherRequest
structure
3 if present, the infoValue of the response MUST be an
enrollmentVoucher structure
The infoValue field of the general message containing the id-it-
getEnrollmentVoucher extension looks like this:
infoValue OPTIONAL
-- MUST be absent if no voucher request is available
-- MUST be present if the EE provides the voucher request
voucherRequest REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the voucher request as OCTET STRING
The infoValue field of the general response containing the id-it-
getEnrollmentVoucher extension looks like this:
infoValue OPTIONAL
-- MUST be absent if no enrollment voucher is available
-- MUST be present if the PKI management entity provides
-- the enrollment voucher
enrollmentVoucher REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the enrollment voucher as OCTET STRING
6. LRA and RA focused PKI management operations
This chapter focuses on the communication among different PKI This chapter focuses on the communication among different PKI
management entities. Depending on the network and PKI solution management entities. Depending on the network and PKI solution
design, these will either be an LRA, RA or CA. design, these will either be an LRA, RA or CA.
Typically, a PKI management entity forwards messages from downstream, Typically, a PKI management entity forwards messages from downstream,
but it may also reply to them itself. Besides forwarding of received but it may also reply to them itself. Besides forwarding of received
messages a PKI management entity could also need to revoke messages a PKI management entity could also need to revoke
certificates of EEs, report errors, or may need to manage its own certificates of EEs, report errors, or may need to manage its own
certificates. certificates.
< TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] additional 5.1. Forwarding of messages
extended key usages like id-kp-cmpRA will be defined to indicate that
a key pair is entitled to be used for signature-based protection of a
CMP message by a PKI management entity. >
6.1. Forwarding of messages
Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or
certConf) or error message coming from an EE or the previous certConf) or error message coming from an EE or the previous
(downstream) PKI management entity MUST be sent to the next (downstream) PKI management entity MUST be sent to the next
(upstream) PKI management entity. This PKI management entity MUST (upstream) PKI management entity. This PKI management entity MUST
forward response messages to the next (downstream) PKI management forward response messages to the next (downstream) PKI management
entity or EE. entity or EE.
The PKI management entity SHOULD verify the protection, the syntax, The PKI management entity SHOULD verify the protection, the syntax,
the required message fields, the message type, and if applicable the the required message fields, the message type, and if applicable the
authorization and the proof-of-possession of the message. Additional authorization and the proof-of-possession of the message. Additional
checks or actions MAY be applied depending on the PKI solution checks or actions MAY be applied depending on the PKI solution
requirements and concept. If one of these verification procedures requirements and concept. If one of these verification procedures
fails, the (L)RA SHOULD respond with a negative response message and fails, the (L)RA SHOULD respond with a negative response message and
SHOULD not forward the message further upstream. General error SHOULD not forward the message further upstream. General error
conditions should be handled as described in Section 5.3 and conditions should be handled as described in Section 4.3 and
Section 6.3. Section 5.3.
A PKI management entity SHOULD not change the received message if not A PKI management entity SHOULD not change the received message if not
necessary. The PKI management entity SHOULD only update the message necessary. The PKI management entity SHOULD only update the message
protection if it is technically necessary. Concrete PKI system protection if it is technically necessary. Concrete PKI system
specifications may define in more detail if and when to do so. specifications may define in more detail if and when to do so.
This is particularly relevant in the upstream communication of a This is particularly relevant in the upstream communication of a
request message. request message.
Each hop in a chain of PKI management entity has one or more Each hop in a chain of PKI management entity has one or more
skipping to change at page 61, line 5 skipping to change at page 57, line 5
o unchanged with the original protection, o unchanged with the original protection,
o unchanged with a new protection, or o unchanged with a new protection, or
o changed with a new protection o changed with a new protection
depends on the PKI solution design and the associated security policy depends on the PKI solution design and the associated security policy
(CP/CPS [RFC3647]). (CP/CPS [RFC3647]).
< TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] different
circumstances that require adding of an additional protection by a
PKI management entity or batching CMP messages at a PKI management
entity by using the nested messages is described. It needs to be
decided which of these variants should be specified here. Finally, I
guess they will all be OPTIONAL. >
This section specifies the different options a PKI management entity This section specifies the different options a PKI management entity
may implement and use. may implement and use.
A PKI management entity MAY update the protection of a message A PKI management entity MAY update the protection of a message
o if it performs changes to the header or the body of the message, o if it performs changes to the header or the body of the message,
o if it needs to prove checks or validations performed on the o if it needs to prove checks or validations performed on the
message to one of the next (upstream) PKI components, message to one of the next (upstream) PKI components,
skipping to change at page 61, line 38 skipping to change at page 57, line 31
certificate request messages. certificate request messages.
The message protection covers only the header and the body and not The message protection covers only the header and the body and not
the extraCerts. The PKI management entity MAY change the extraCerts the extraCerts. The PKI management entity MAY change the extraCerts
in any of the following message adaptations, e.g., to sort or add in any of the following message adaptations, e.g., to sort or add
needed or to delete needless certificates to support the next hop. needed or to delete needless certificates to support the next hop.
This may be particularly helpful to extend upstream messages with This may be particularly helpful to extend upstream messages with
additional certificates or to reduce the number of certificates in additional certificates or to reduce the number of certificates in
downstream messages when forwarding to constrained devices. downstream messages when forwarding to constrained devices.
6.1.1. Not changing protection 5.1.1. Not changing protection
This alternative to forward a message can be used by any PKI This alternative to forward a message can be used by any PKI
management entity to forward an original CMP message without changing management entity to forward an original CMP message without changing
the header, body or protection. In any of these cases the PKI the header, body or protection. In any of these cases the PKI
management entity acts more like a proxy, e.g., on a network management entity acts more like a proxy, e.g., on a network
boundary, implementing no specific RA-like security functionality to boundary, implementing no specific RA-like security functionality to
the PKI. the PKI.
This alternative to forward a message MUST be used for forwarding kur This alternative to forward a message MUST be used for forwarding kur
messages that must not be approved by the respective PKI management messages that must not be approved by the respective PKI management
entity. entity.
6.1.2. Replacing protection 5.1.2. Replacing protection
The following two alternatives to forward a message can be used by The following two alternatives to forward a message can be used by
any PKI management entity to forward a CMP message with or without any PKI management entity to forward a CMP message with or without
changes, but providing its own protection using its CMP signer key to changes, but providing its own protection using its CMP signer key to
assert approval of this message. In this case the PKI management assert approval of this message. In this case the PKI management
entity acts as an actual Registration Authority (RA), which entity acts as an actual Registration Authority (RA), which
implements important security functionality of the PKI. implements important security functionality of the PKI.
Before replacing the existing protection by a new protection, the PKI Before replacing the existing protection by a new protection, the PKI
management entity MUST verify the protection provided by the EE or by management entity MUST verify the protection provided by the EE or by
skipping to change at page 62, line 29 skipping to change at page 58, line 20
signature of the certTemplate using the public key of the requested signature of the certTemplate using the public key of the requested
certificate and MUST check that the EE, as authenticated by the certificate and MUST check that the EE, as authenticated by the
message protection, is authorized to request a certificate with the message protection, is authorized to request a certificate with the
subject as specified in the certTemplate. subject as specified in the certTemplate.
In case the received message has been protected by a CA or another In case the received message has been protected by a CA or another
PKI management entity, the current PKI management entity MUST verify PKI management entity, the current PKI management entity MUST verify
its protection and approve its content including any own its protection and approve its content including any own
modifications. For certificate requests the PKI management entity modifications. For certificate requests the PKI management entity
MUST check that the other PKI management entity, as authenticated by MUST check that the other PKI management entity, as authenticated by
the protection of the incomming message, was authorized to issue or the protection of the incoming message, was authorized to issue or
forward the request. forward the request.
These message adaptations MUST NOT be applied to kur request messages These message adaptations MUST NOT be applied to kur request messages
as described in Section 5.1.3 since their original protection using as described in Section 4.1.3 since their original protection using
the key and certificate to be updated needs to be preserved, unless the key and certificate to be updated needs to be preserved, unless
the regCtrl OldCertId is used to clearly identify the certificate to the regCtrl OldCertId is used to clearly identify the certificate to
be updated. be updated.
6.1.2.1. Keeping proof-of-possession 5.1.2.1. Keeping proof-of-possession
This alternative to forward a message can be used by any PKI This alternative to forward a message can be used by any PKI
management entity to forward a CMP message with or without modifying management entity to forward a CMP message with or without modifying
the message header or body while preserving any included proof-of- the message header or body while preserving any included proof-of-
possession. possession.
By replacing the existing protection using its own CMP signer key the By replacing the existing protection using its own CMP signer key the
PKI management entity provides a proof of verifying and approving of PKI management entity provides a proof of verifying and approving of
the message as described above. the message as described above.
In case the PKI management entity modifies the certTemplate of an ir In case the PKI management entity modifies the certTemplate of an ir
or cr message, the message adaptation in Section 6.1.2.2 needs to be or cr message, the message adaptation in Section 5.1.2.2 needs to be
applied instead. applied instead.
6.1.2.2. Breaking proof-of-possession 5.1.2.2. Breaking proof-of-possession
This alternativeto forward a message can be used by any PKI This alternative to forward a message can be used by any PKI
management entity to forward an ir or cr message with modifications management entity to forward an ir or cr message with modifications
of the certTemplate i.e., modification, addition, or removal of of the certTemplate i.e., modification, addition, or removal of
fields. Such changes will break the proof-of-possession provided by fields. Such changes will break the proof-of-possession provided by
the EE in the original message. the EE in the original message.
By replacing the existing using its own CMP signer key the PKI By replacing the existing using its own CMP signer key the PKI
management entity provides a proof of verifying and approving the new management entity provides a proof of verifying and approving the new
message as described above. message as described above.
In addition to the above the PKI management entity MUST verify in In addition to the above the PKI management entity MUST verify in
skipping to change at page 63, line 31 skipping to change at page 59, line 23
The popo field MUST contain the raVerified choice in the certReq The popo field MUST contain the raVerified choice in the certReq
structure of the modified message as follows: structure of the modified message as follows:
popo popo
raVerified REQUIRED raVerified REQUIRED
-- MUST have the value NULL and indicates that the PKI -- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original -- management entity verified the popo of the original
-- message -- message
6.1.3. Adding Protection 5.1.3. Adding Protection
< TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] different This PKI management operation can be used by a PKI management entity
circumstances that require adding of an additional protection by a to add another protection to one or several PKI management messages.
PKI management entity or batching CMP messages at a PKI management
entity by using the nested messages is described. It needs to be
decided which of these variants should be specified here. Finally, I
guess they will all be OPTIONAL. >
6.1.4. Initiating delayed enrollment The nested message is a PKI management message containing a
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
Section 3.3 of CMP Updates [I-D.ietf-lamps-cmp-updates]) there are
different use case for adding another protection by a PKI management
entity. Specific procedures are described in more detail in the
following sections.
The behavior in case an error occurs is described in Section 4.3.
Message flow:
Step# PKI management entity PKI management entity
1 format nested
2 -> nested ->
3 handle, re-protect or
forward nested
4 format or receive nested
5 <- nested <-
6 handle nested
Detailed message description:
Nested Message - nested
Field Value
header
-- As described in section 3.1
body nested
-- Container to provide additional protection to original
-- messages and to bundle request or response messages
PKIMessages REQUIRED
-- MUST be a sequence of one or more CMP messages
protection REQUIRED
-- As described in section 3.2 using the CMP signer key of
-- the PKI management entity
extraCerts REQUIRED
-- As described in section 3.3
5.1.3.1. Handling a single PKI management message
A PKI management entity may prove successful validation and
authorization of a PKI management message by adding an additional
signature to the original PKI management message.
A PKI management entity SHALL wrap the original PKI management
messages in a nested message structure. The additional signature as
prove of verification and authorization by the PKI management entity
MUST be applies as signature-based message protection of the nested
message.
5.1.3.2. Handling a batch of PKI management messages
A PKI management entity MAY bundle any number of PKI management
messages for batch processing or to transfer a bulk of PKI management
messages via an offline interface using the nested message structure.
The nested message can be either used on the upstream interface
towards the next PKI management entity as well as on the downstream
interface from the PKI management entity towards the EE.
This PKI management operation is typically used on the interface
between LRA and RA to bundle several PKI management messages for
offline transport. In this case the EE needs to make use of delayed
enrollment as described in Section 4.1.7. If the RA may need
different routing information per nested PKI management message a
suitable mechanism may need to be implemented. This mechanism
strongly depends on the requirements of the target architecture;
therefore, it is out of scope of this document.
An initial nested message is generated locally at the PKI management
entity. For the initial nested message, the PKI management entity
acts as a protocol end point and therefore a fresh transactionId and
a fresh senderNonce MUST be used in the header of the nested message.
The recipient field MUST identify the PKI management entity that is
expected to unpack the nested message. An initial nested message
should contain only request messages, e.g., ir, cr, p10cr, kur,
certConf, rr, or genm. While building the initial nested message the
PKI management entity SHOULD store the transactionIds and the
senderNonces of all bundled messages together with the transactionId
of the initial nested message.
Such an initial nested message is sent to the next PKI management
entity and SHOULD be answered with a responding nested message. This
responding message SHOULD use the transactionId of the initial nested
message and return the senderNonce of the initial nested message as
recipNonce of the responding nested message. The responding nested
message SHOULD bundle one response message (e.g. ip, cp, kup,
pkiconf, rp, genp, error) for each request message (i.e., for each
transactionId) in the initial nested message. While unbundling the
responding nested message it is possible to determine lost and
unexpected responses based on the previously stored transactionIds
and senderNonces. While forwarding the unbundled responses, odd
messages SHOULD be dropped, and lost messages should be replaced by
an error message to inform the EE about the failed certificate
management operation.
The PKI management entity building the nested message applies a
signature-based protection using its CMP-signer key as transport
protection. This protection SHALL NOT be regarded as prove of
verification or authorization of the bundled PKI management messages.
5.1.4. Initiating delayed enrollment
This functional extension can be used by a PKI management entity to This functional extension can be used by a PKI management entity to
initiate delayed enrollment. In this case a PKI management entity initiate delayed enrollment. In this case a PKI management entity
MUST add the status waiting in the response message. The PKI MUST add the status waiting in the response message. The PKI
management entity MUST then reply to the pollReq messages as management entity MUST then reply to the pollReq messages as
described in Section 5.1.7. described in Section 4.1.7.
6.2. Revoking certificates on behalf of another's entities 5.2. Revoking certificates on behalf of another's entities
This PKI management operation can be used by a PKI management entity This PKI management operation can be used by a PKI management entity
to revoke a certificate of any other entity. This revocation request to revoke a certificate of any other entity. This revocation request
message MUST be signed by the PKI management entity using its own CMP message MUST be signed by the PKI management entity using its own CMP
signer key to prove to the PKI authorization to revoke the signer key to prove to the PKI authorization to revoke the
certificate on behalf of the EE. certificate on behalf of the EE.
Preconditions: Preconditions:
1 the certificate to be revoked MUST be known to the PKI management 1 the certificate to be revoked MUST be known to the PKI management
entity entity
2 the PKI management entity MUST have the authorization to revoke 2 the PKI management entity MUST have the authorization to revoke
the certificates of other entities issued by the corresponding CA the certificates of other entities issued by the corresponding CA
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in section Section 5.2, with the following changes: to that given in Section 4.2, with the following changes:
1 it is not required that the certificate to be revoked is not yet 1 it is not required that the certificate to be revoked is not yet
expired or revoked expired or revoked
2 the PKI management entity acts as EE for this message exchange 2 the PKI management entity acts as EE for this message exchange
3 the rr messages MUST be signed using the CMP signer key of the PKI 3 the rr messages MUST be signed using the CMP signer key of the PKI
management entity. management entity.
6.3. Error reporting 5.3. Error reporting
This functionality should be used by the PKI management entity to This functionality should be used by the PKI management entity to
report any error conditions downstream to the EE. Potential error report any error conditions downstream to the EE. Potential error
reporting by the EE upstream to the PKI management entity is reporting by the EE upstream to the PKI management entity is
described in Section 5.3. described in Section 4.3.
In case the error condition is related to specific details of an ir, In case the error condition is related to specific details of an ir,
cr, p10cr, or kur request message it MUST be reported in the specific cr, p10cr, or kur request message it MUST be reported in the specific
response message, i.e., an ip, cp, or kup with negative contents. response message, i.e., an ip, cp, or kup with negative contents.
General error conditions, e.g., problems with the message header, General error conditions, e.g., problems with the message header,
protection, or extraCerts, and negative feedback on rr, pollReq, protection, or extraCerts, and negative feedback on rr, pollReq,
certConf, or error messages MUST be reported in the form of an error certConf, or error messages MUST be reported in the form of an error
message. message.
In both situations the PKI management entity reports the errors in In both situations the PKI management entity reports the errors in
the PKIStatusInfo structure of the respective message as described in the PKIStatusInfo structure of the respective message as described in
Section 5.3. Section 4.3.
An EE receiving any such negative feedback SHOULD log the error An EE receiving any such negative feedback SHOULD log the error
appropriately and MUST terminate the current transaction. appropriately and MUST terminate the current transaction.
7. CMP message transport variants 6. CMP message transport variants
The CMP messages are designed to be self-contained, such that in The CMP messages are designed to be self-contained, such that in
principle any transport can be used. HTTP SHOULD be used for online principle any transport can be used. HTTP SHOULD be used for online
transport while file-based transport MAY be used in case offline transport while file-based transport MAY be used in case offline
transport is required. In case HTTP transport is not desired or transport is required. In case HTTP transport is not desired or
possible, CMP messages MAY also be piggybacked on any other reliable possible, CMP messages MAY also be piggybacked on any other reliable
transport protocol, e.g., CoAP [RFC7252]. transport protocol, e.g., CoAP [RFC7252].
Independently of the means of transport it could happen that messages Independently of the means of transport it could happen that messages
are lost, or a communication partner does not respond. In order to are lost, or a communication partner does not respond. In order to
prevent waiting indefinitely, each CMP client component SHOULD use a prevent waiting indefinitely, each CMP client component SHOULD use a
configurable per-request timeout, and each CMP server component configurable per-request timeout, and each CMP server component
SHOULD use a configurable per-response timeout in case a further SHOULD use a configurable per-response timeout in case a further
message is to be expected from the client side. In this way a message is to be expected from the client side. In this way a
hanging transaction can be closed cleanly with an error and related hanging transaction can be closed cleanly with an error and related
resources (for instance, any cached extraCerts) can be freed. resources (for instance, any cached extraCerts) can be freed.
7.1. HTTP transport When conveying a CMP messages in HTTP or MIME-based transport
protocols the internet media type "application/pkixcmp" MUST be set
for transport encoding as specified in RFC2510 in Section 5.3
[RFC2510] and RFC6712 in Section 3.4 [RFC7712].
This transport mechanism can be used by a PKI entity to transfer CMP 6.1. Definition and discovery of HTTP URIs
messages over HTTP. If HTTP transport is used the specifications as
described in [RFC6712] MUST be followed.
Each PKI management entity supporting HTTP or HTTPS transport MUST Each PKI management entity supporting HTTP or HTTPS transport MUST
support the use of the path-prefix of '/.well-known/' as defined in support the use of the path-prefix of '/.well-known/' as defined in
[RFC5785] and the registered name of 'cmp' to ease interworking in a [RFC5785] and the registered name of 'cmp' to ease interworking in a
multi-vendor environment. multi-vendor environment.
The CMP client MUST be configured with sufficient information to form The CMP client MUST be configured with sufficient information to form
the CMP server URI. This MUST be at least the authority portion of the CMP server URI. This MUST be at least the authority portion of
the URI, e.g., 'www.example.com:80', or the full operational path of the URI, e.g., 'www.example.com:80', or the full operational path of
the PKI management entity. An additional arbitrary label, e.g., the PKI management entity. An additional arbitrary label, e.g.,
'arbitraryLabel1', MAY be configured as a separate component or as 'arbitraryLabel', MAY be configured as a separate component or as
part of the full operational path to provide further information to part of the full operational path to provide further information to
address multiple CAs or certificate profiles. A valid full address multiple CAs or certificate profiles. A valid full
operational path can look like this: operational path can look like this:
1 http://www.example.com/.well-known/cmp 1 http://www.example.com/.well-known/cmp
2 http://www.example.com/.well-known/cmp/keyupdate 2 http://www.example.com/.well-known/cmp/keyupdate
3 http://www.example.com/.well-known/cmp/arbitraryLabel1 3 http://www.example.com/.well-known/cmp/arbitraryLabel
4 http://www.example.com/.well-known/cmp/arbitraryLabel/keyupdate
4 http://www.example.com/.well-known/cmp/arbitraryLabel1/keyupdate
PKI management operations SHOULD use the following URI path: PKI management operations SHOULD use the following URI path:
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| PKI management operation | Path | Details | | PKI management operation | Path | Details |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Enroll client to new PKI | /initialization | Section | | Enroll client to new PKI | /initialization | Section |
| (REQUIRED) | | 5.1.1 | | (REQUIRED) | | 4.1.1 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Enroll client to existing PKI | /certification | Section | | Enroll client to existing PKI | /certification | Section |
| (OPTIONAL) | | 5.1.2 | | (OPTIONAL) | | 4.1.2 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Update client certificate | /keyupdate | Section | | Update client certificate | /keyupdate | Section |
| (REQUIRED) | | 5.1.3 | | (REQUIRED) | | 4.1.3 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Enroll client using PKCS#10 | /p10 | Section | | Enroll client using PKCS#10 | /p10 | Section |
| (OPTIONAL) | | 5.1.5 | | (OPTIONAL) | | 4.1.5 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Enroll client using central key | /serverkeygen | Section | | Enroll client using central key | /serverkeygen | Section |
| generation (OPTIONAL) | | 5.1.6 | | generation (OPTIONAL) | | 4.1.6 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Revoke client certificate | /revocation | Section | | Revoke client certificate | /revocation | Section |
| (RECOMMENDED) | | 5.2 | | (RECOMMENDED) | | 4.2 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Get CA certificates (OPTIONAL) | /getCAcert | Section | | Get CA certificates (OPTIONAL) | /getcacert | Section |
| | | 5.4.2 | | | | 4.4.2 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Get root CA certificate update | /getRootCAcertUpdate | Section | | Get root CA certificate update | /getrootupdate | Section |
| (OPTIONAL) | | 5.4.3 | | (OPTIONAL) | | 4.4.3 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Get certificate request | /getCSRparam | Section | | Get certificate request template | /getcertreqtemplate | Section |
| parameters (OPTIONAL) | | 5.4.4 | | (OPTIONAL) | | 4.4.4 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Get certificate management | /getCertMgtConfig | Section | | Additional protection (OPTIONAL) | /nested | Section |
| configuration (OPTIONAL) | | 5.4.5 | | | | 5.1.3 |
+---------------------------------+----------------------+----------+ +----------------------------------+---------------------+----------+
| Get enrollment voucher | /getVoucher | Section |
| (OPTIONAL) | | 5.4.6 |
+---------------------------------+----------------------+----------+
Table 1: HTTP endpoints Table 1: HTTP endpoints
Subsequent certConf, error, and pollReq messages are sent to the URI Subsequent certConf, error, and pollReq messages are sent to the URI
of the respective PKI management operation. of the respective PKI management operation.
< TBD: It needs to be defined if specific path values for The discovery of supported endpoints as defined above will provide
communication between PKI management entities as specified in section the information to the EE, how to contact the PKI management entity
6 are needed, e.g., 'forward' or 'nested'.> and, if available, how to request enrolment for a specific
certificate profile or revoke a certificate at a specific CA.
7.2. HTTPS transport using certificates Querying the PKI management entity, the EE will get a list of
potential endpoints supported by the PKI management entity.
Performing a GET on "/.well-known/cmp" to the default port returns a
set of links to endpoints available from the server or RA. In
addition to the link also the expected format of the data object is
provided as content type (ct).
The following provides an illustrative example for a PKI management
entity supporting different PKI management operations for a single
certificate profile or a single CA.
Detailed message description:
REQ: GET /.well-known/cmp
RES: Content
</cmp/initialization>;ct=pkixcmp
</cmp/certification >;ct=pkixcmp
</cmp/keyupdate >;ct=pkixcmp
</cmp/p10>;ct=pkixcmp
</cmp/revocation>;ct=pkixcmp
</cmp/ca2/revocation>;ct=pkixcmp
</cmp/getcacerts>;ct=pkixcmp
</cmp/getrootupdate>;ct=pkixcmp
</cmp/getcertreqtemplate >;ct=pkixcmp
As it is very likely, that a CA supports different certification
profiles or that the RA offers PKI management operations for
different issuing CAs, the discovery can also be used to provide the
information about these options. The second example listing contains
the supported PKI management operations for three different
certificate profiles. The supported CA hierarchy consists of one
root CA and two issuing CAs.
Detailed message description:
REQ: GET /.well-known/cmp
RES: Content
</cmp/certprofile1/initialization>;ct=pkixcmp
</cmp/certprofile2/initialization>;ct=pkixcmp
</cmp/certprofile3/initialization>;ct=pkixcmp
</cmp/certprofile1/certification >;ct=pkixcmp
</cmp/certprofile2/certification >;ct=pkixcmp
</cmp/certprofile3/certification >;ct=pkixcmp
</cmp/certprofile1/keyupdate >;ct=pkixcmp
</cmp/certprofile2/keyupdate >;ct=pkixcmp
</cmp/certprofile3/keyupdate >;ct=pkixcmp
</cmp/certprofile1/p10>;ct=pkixcmp
</cmp/certprofile2/p10>;ct=pkixcmp
</cmp/certprofile3/p10>;ct=pkixcmp
</cmp/ca1/revocation>;ct=pkixcmp
</cmp/ca2/revocation>;ct=pkixcmp
</cmp/getcacerts>;ct=pkixcmp
</cmp/rootca1/getrootupdate>;ct=pkixcmp
</cmp/certprofile1/getcertreqtemplate >;ct=pkixcmp
</cmp/certprofile2/getcertreqtemplate >;ct=pkixcmp
</cmp/certprofile3/getcertreqtemplate >;ct=pkixcmp
There are different options in the handling of the naming. The PKI
management entity either needs to offer the certprofile or CA labels
the EE expects. Alternatively, a mechanism is required to configure
this information to the EE beforehand.
6.2. HTTP transport
This transport mechanism can be used by a PKI entity to transfer CMP
messages over HTTP. If HTTP transport is used the specifications as
described in [RFC6712] MUST be followed.
6.3. HTTPS transport using certificates
This transport mechanism can be used by a PKI entity to further This transport mechanism can be used by a PKI entity to further
protect the HTTP transport as described in Section 7.1 using TLS 1.2 protect the HTTP transport as described in Section 6.2 using TLS 1.2
[RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with
certificate-based authentication. Using this transport mechanism, certificate-based authentication. Using this transport mechanism,
the CMP transport via HTTPS MUST use TLS server authentication and the CMP transport via HTTPS MUST use TLS server authentication and
SHOULD use TLS client authentication. SHOULD use TLS client authentication.
EE: EE:
o The EE SHOULD use a TLS client certificate as far as available. o The EE SHOULD use a TLS client certificate as far as available.
If no dedicated TLS certificate is available the EE SHOULD use an If no dedicated TLS certificate is available, the EE SHOULD use an
already existing certificate identifying the EE (e.g., a already existing certificate identifying the EE (e.g., a
manufacturer certificate). manufacturer certificate).
o If no TLS certificate is available at the EE, server-only o If no TLS certificate is available at the EE, server-only
authenticated TLS SHOULD be used. authenticated TLS SHOULD be used.
o The EE MUST validate the TLS server certificate of its o The EE MUST validate the TLS server certificate of its
communication partner. communication partner.
PKI management entity: PKI management entity:
skipping to change at page 67, line 43 skipping to change at page 67, line 32
its downstream (server) interface. its downstream (server) interface.
o Each PKI management entity MUST validate the TLS certificate of o Each PKI management entity MUST validate the TLS certificate of
its communication partners. its communication partners.
NOTE: The requirements for checking certificates given in [RFC5280], NOTE: The requirements for checking certificates given in [RFC5280],
[RFC5246] and [RFC8446] MUST be followed for the TLS layer. [RFC5246] and [RFC8446] MUST be followed for the TLS layer.
Certificate status checking SHOULD be used for the TLS certificates Certificate status checking SHOULD be used for the TLS certificates
of communication partners. of communication partners.
7.3. HTTPS transport using shared secrets 6.4. HTTPS transport using shared secrets
This transport mechanism can be used by a PKI entity to further This transport mechanism can be used by a PKI entity to further
protect the HTTP transport as described in Section 7.1 using TLS 1.2 protect the HTTP transport as described in Section 6.2 using TLS 1.2
[RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual
authentication based on shared secrets as described in [RFC5054]. authentication based on shared secrets as described in [RFC5054].
EE: EE:
o The EE MUST use the shared symmetric key for authentication. o The EE MUST use the shared symmetric key for authentication.
PKI management entity: PKI management entity:
o The PKI management entity MUST use the shared symmetric key for o The PKI management entity MUST use the shared symmetric key for
authentication. authentication.
7.4. File-based transport 6.5. Offline transport
For offline transfer file-based transport MAY be used. Offline For transporting CMP messages between PKI entities any mechanism can
transport is typically used between LRA and RA nodes. be used that is able to store and forward binary objects of
sufficient length and with sufficient reliability while preserving
the order of messages.
Connection and error handling mechanisms like those specified for The transport mechanism SHOULD be able to indicate message loss,
HTTP in [RFC6712] need to be implemented. excessive delay, and possibly other transmission errors. In such
cases the PKI entities using this mechanism SHOULD report an error as
specified in Section 4.3.
< TBD: Details need to be defined later > 6.5.1. File-based transport
7.5. CoAP transport CMP messages MAY be transferred between PKI entities using file-
system-based mechanisms, for instance when an off-line end entity or
a PKI management entity performs delayed enrollment. Each file MUST
contain the ASN.1 DER encoding of one CMP message only. There MUST
be no extraneous header or trailer information in the file. The file
type extensions ".PKI" SHOULD be used.
In constrained environments where no HTTP transport is desired or 6.5.2. Other asynchronous transport protocols
possible, CoAP [RFC7252] MAY be used instead. Connection and error
handling mechanisms like those specified for HTTP in [RFC6712] may
need to be implemented.
Such specification is out of scope of this document and would need to Other asynchronous transport protocols, e.g., email or website
be specifies in a separate document. up-/download, MAY transfer CMP messages between PKI entities. A MIME
wrapping is defined for those environments that are MIME native. The
MIME wrapping in this section is specified in [RFC8551], section 3.1.
7.6. Piggybacking on other reliable transport The ASN.1 DER encoding of the CMP messages MUST be transferred using
the "application/pkixcmp" content type and base64-encoded content-
transfer-encoding as specified in [RFC2510], section 5.3. A filename
MUST be included either in a content-type or a content-disposition
statement. The extension for the file MUST be ".PKI".
6.6. CoAP transport
In constrained environments where no HTTP transport is desired or
possible, CoAP [RFC7252] as specified in
[I-D.msahni-tbd-cmpv2-coap-transport] MAY be used instead.
6.7. Piggybacking on other reliable transport
For online transfer where no HTTP transport is desired or possible For online transfer where no HTTP transport is desired or possible
CMP messages MAY also be transported on some other reliable protocol. CMP messages MAY also be transported on some other reliable protocol.
Connection and error handling mechanisms like those specified for Connection and error handling mechanisms like those specified for
HTTP in [RFC6712] need to be implemented. HTTP in [RFC6712] need to be implemented.
Such specification is out of scope of this document and would need to Such specification is out of scope of this document and would need to
be specifies in a separate document, e.g., in the scope of the be specifies in a separate document, e.g., in the scope of the
respective transport protocol used. respective transport protocol used.
8. IANA Considerations 7. IANA Considerations
<Add any IANA considerations> < TBD: The OID id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-
certReqTemplate are not yet defined and should be registered in the
tree 1.3.6.1.5.5.7.4 (id-it) like other infoType OIDs, see CMP
Appendix F [RFC4210] on page 92. >
9. Security Considerations 8. Security Considerations
<Add any security considerations> < TBD: Add any security considerations >
10. Acknowledgements 9. Acknowledgements
We would like to thank the various reviewers of this document. We would like to thank the various reviewers of this document.
11. References 10. References
11.1. Normative References 10.1. Normative References
[I-D.ietf-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp- Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp-
updates-00 (work in progress), February 2020. updates-02 (work in progress), July 2020.
[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 70, line 16 skipping to change at page 70, line 26
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712, Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012, DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>. <https://www.rfc-editor.org/info/rfc6712>.
11.2. Informative References 10.2. Informative References
[ETSI-3GPP] [ETSI-3GPP]
3GPP, "TS33.310; Network Domain Security (NDS); 3GPP, "TS33.310; Network Domain Security (NDS);
Authentication Framework (AF); Release 16; V16.1.0", Authentication Framework (AF); Release 16; V16.1.0",
December 2018, December 2018,
<http://www.3gpp.org/ftp/Specs/archive/33_series/33.310/>. <http://www.3gpp.org/ftp/Specs/archive/33_series/33.310/>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.msahni-tbd-cmpv2-coap-transport]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Sahni, M., "CoAP Transport for CMPV2", draft-msahni-tbd-
and K. Watsen, "Bootstrapping Remote Secure Key cmpv2-coap-transport-00 (work in progress), June 2020.
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-35 (work in progress), February 2020.
[IEC62443-3-3] [IEC62443-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>.
[IEEE802.1AR] [IEEE802.1AR]
IEEE, "802.1AR Secure Device Identifier", June 2018, IEEE, "802.1AR Secure Device Identifier", June 2018,
<http://standards.ieee.org/findstds/standard/802.1AR- <http://standards.ieee.org/findstds/standard/802.1AR-
2009.html>. 2009.html>.
[NIST-CSFW] [NIST-CSFW]
NIST, "Framework for Improving Critical Infrastructure NIST, "Framework for Improving Critical Infrastructure
Cybersecurity Version 1.1", April 2018, Cybersecurity Version 1.1", April 2018,
<https://www.nist.gov/publications/framework-improving- <https://www.nist.gov/publications/framework-improving-
critical-infrastructure-cybersecurity-version-11>. critical-infrastructure-cybersecurity-version-11>.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure Certificate Management Protocols",
RFC 2510, DOI 10.17487/RFC2510, March 1999,
<https://www.rfc-editor.org/info/rfc2510>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>. <https://www.rfc-editor.org/info/rfc3647>.
skipping to change at page 71, line 26 skipping to change at page 71, line 41
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7712] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Associations (DNA) in the Extensible Messaging and
2015, <https://www.rfc-editor.org/info/rfc7515>. Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712,
November 2015, <https://www.rfc-editor.org/info/rfc7712>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management [UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management
FFFIS; V1.0.0", December 2015, FFFIS; V1.0.0", December 2015,
<https://www.era.europa.eu/filebrowser/download/542_en>. <https://www.era.europa.eu/filebrowser/download/542_en>.
[W3C_XML] W3C, "Extensible Markup Language (XML) 1.0", W3C XML, Appendix A. ASN.1 Syntax
November 2008, <https://www.w3.org/TR/xml/>.
[W3C_XML-Dsig] id-it-caCerts OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx}
W3C, "XML Signature Syntax and Processing Version 2.0", CaCerts ::= SEQUENCE OF CMPCertificate
W3C XML-DSIG, July 2015, }
<https://www.w3.org/TR/xmldsig-core2/>.
Appendix A. Additional Stuff id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx}
RootCaKeyUpdate ::= SEQUENCE {
newWithNew CMPCertificate
newWithOld [0] CMPCertificate OPTIONAL,
oldWithNew [1] CMPCertificate OPTIONAL,
}
This becomes an Appendix. id-it-certReqTemplate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx}
CertReqTemplateValue ::= SEQUENCE {
certTemplate CertTemplate,
rsaKeyLen INTEGER OPTIONAL,
}
< TBD: The OID id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-
certReqTemplate must be defined by IANA >
Appendix B. Example for CertReqTemplate
This Section provides a concrete example for the content of an
infoValue used of type id-it-certReqTemplate as described in
Section 4.4.4.
Suppose the server requires that the certTemplate contains the issuer
field with a value to be filled in by the EE, the subject field with
a common name to be filled in by the EE and two organizational unit
fields with given values "myDept" and "myGroup", the publicKey field
with an RSA public key of length 2048, the subjectAltName extension
with DNS name "www.myServer.com" and an IP address to be filled in,
the keyUsage extension marked critical with the value
digitalSignature and keyAgreement, and the extKeyUsage extension with
values to be filled in by the EE. Then the infoValue with
certTemplate and rsaKeyLen returned to the EE must be encoded as
follows:
SEQUENCE {
SEQUENCE {
[3] {
SEQUENCE {}
}
[5] {
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
UTF8String ''
}
}
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String 'myDept'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String 'myGroup'
}
}
}
}
[6] {
SEQUENCE {
OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING, encapsulates {
SEQUENCE {}
}
}
[9] {
SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17)
OCTET STRING, encapsulates {
SEQUENCE {
[2] 'www.myServer.com'
[7] ''
}
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
BOOLEAN TRUE
OCTET STRING, encapsulates {
BIT STRING 3 unused bits
'10001'B
}
}
SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
}
}
INTEGER 2048
}
Appendix C. History of changes
Note: This section will be deleted in the final version of the
document.
From version 01 -> 02:
o Extend Section 1.4 with regard to conflicts with UNISIG Subset-
137.
o Minor clarifications on extraCerts in Section 3.3 and
Section 4.1.1.
o Complete specification of requesting a certificate from a trusted
PKI with signature protection in Section 4.1.2.
o Changed from symmetric key-encryption to password-based key
management technique in section Section 4.1.6.3 as discussed on
the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.1.6.1")
o Changed delayed enrollment described in Section 4.1.7 from
recommended to optional as decided at IETF 107
o Introduced the new RootCAKeyUpdate structure for root CA
certificate update in Section 4.4.3 as decided at IETF 107 (also
see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
section 5.4.3")
o Extend the description of the CertReqTemplate PKI management
operation, including an example added in the Appendix. Keep
rsaKeyLen as a single integer value in Section 4.4.4 as discussed
on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.4.4")
o Deleted Sections "Get certificate management configuration" and
"Get enrollment voucher" as decided at IETF 107
o Complete specification of adding an additional protection by an
PKI management entity in Section 5.1.3.
o Added Section 6.1 and extended Section 6.2 on definition and
discovery of supported HTTP URIs and content types, add a path for
nested messages as specified in Section 5.1.3 and delete the paths
for /getCertMgtConfig and /getVoucher
o Changed Section 6.5 to address offline transport and added more
detailed specification file-based transport of CMP
o Added a reference to the new I-D of Mohit Sahni on "CoAP Transport
for CMPV2" in Section 6.6; thanks to Mohit supporting the effort
to ease utilization of CMP
o Moved the change history to the Appendix
o Minor changes in wording
From version 00 -> 01:
o Harmonize terminology with CMP [RFC4210], e.g.,
* transaction, message sequence, exchange, use case -> PKI
management operation
* PKI component, (L)RA/CA -> PKI management entity
o Minor changes in wording
From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf-
lamps-lightweight-cmp-profile-00:
o Changes required to reflect WG adoption
o Minor changes in wording
From version 02 -> 03:
o Added a short summary of [RFC4210] Appendix D and E in
Section 1.3.
o Clarified some references to different sections and added some
clarification in response to feedback from Michael Richardson and
Tomas Gustavsson.
o Added an additional label to the operational path to address
multiple CAs or certificate profiles in Section 6.2.
From version 01 -> 02:
o Added some clarification on the key management techniques for
protection of centrally generated keys in Section 4.1.6.
o Added some clarifications on the certificates for root CA
certificate update in Section 4.4.3.
o Added a section to specify the usage of nested messages for RAs to
add an additional protection for further discussion, see
Section 5.1.3.
o Added a table containing endpoints for HTTP transport in
Section 6.2 to simplify addressing PKI management entities.
o Added some ToDos resulting from discussion with Tomas Gustavsson.
o Minor clarifications and changes in wording.
From version 00 -> 01:
o Added a section to specify the enrollment with an already trusted
PKI for further discussion, see Section 4.1.2.
o Complete specification of requesting a certificate from a legacy
PKI using a PKCS#10 [RFC2986] request in Section 4.1.5.
o Complete specification of adding central generation of a key pair
on behalf of an end entity in Section 4.1.6.
o Complete specification of handling delayed enrollment due to
asynchronous message delivery in Section 4.1.7.
o Complete specification of additional support messages, e.g., to
update a Root CA certificate or to request an RFC 8366 [RFC8366]
voucher, in Section 4.4.
o Minor changes in wording.
From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft-
brockhaus-lamps-lightweight-cmp-profile-00:
o Change focus from industrial to more multi-purpose use cases and
lightweight CMP profile.
o Incorporate the omitted confirmation into the header specified in
Section 3.1 and described in the standard enrollment use case in
Section 4.1.1 due to discussion with Tomas Gustavsson.
o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's
entities certificate' in Section 5.2, because it is regarded as
important functionality in many environments to enable the
management station to revoke EE certificates.
o Complete the specification of the revocation message flow in
Section 4.2 and Section 5.2.
o The CoAP based transport mechanism and piggybacking of CMP
messages on top of other reliable transport protocols is out of
scope of this document and would need to be specified in another
document.
o Further minor changes in wording.
Authors' Addresses Authors' Addresses
Hendrik Brockhaus Hendrik Brockhaus
Siemens AG Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
Email: hendrik.brockhaus@siemens.com Email: hendrik.brockhaus@siemens.com
URI: http://www.siemens.com/
Steffen Fries Steffen Fries
Siemens AG Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
Email: steffen.fries@siemens.com Email: steffen.fries@siemens.com
URI: http://www.siemens.com/
David von Oheimb David von Oheimb
Siemens AG Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
Email: david.von.oheimb@siemens.com Email: david.von.oheimb@siemens.com
URI: http://www.siemens.com/
 End of changes. 301 change blocks. 
854 lines changed or deleted 1074 lines changed or added

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