draft-ietf-lamps-lightweight-cmp-profile-02.txt   draft-ietf-lamps-lightweight-cmp-profile-03.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: January 12, 2021 Siemens Expires: April 5, 2021 Siemens
July 11, 2020 October 2, 2020
Lightweight CMP Profile Lightweight CMP Profile
draft-ietf-lamps-lightweight-cmp-profile-02 draft-ietf-lamps-lightweight-cmp-profile-03
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2021. This Internet-Draft will expire on April 5, 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4 1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4
1.2. Motivation for a lightweight profile for CMP . . . . . . 5 1.2. Motivation for a lightweight profile for CMP . . . . . . 5
1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 5 1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 5
1.4. Compatibility with existing CMP profiles . . . . . . . . 7 1.4. Compatibility with existing CMP profiles . . . . . . . . 7
1.5. Scope of this document . . . . . . . . . . . . . . . . . 9 1.5. Scope of this document . . . . . . . . . . . . . . . . . 9
1.6. Structure of this document . . . . . . . . . . . . . . . 9 1.6. Structure of this document . . . . . . . . . . . . . . . 9
1.7. Convention and Terminology . . . . . . . . . . . . . . . 10 1.7. Convention and Terminology . . . . . . . . . . . . . . . 10
2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11
2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11
2.2. Basic generic CMP message content . . . . . . . . . . . . 12 2.2. Basic generic CMP message content . . . . . . . . . . . . 12
2.3. Supported PKI management operations . . . . . . . . . . . 12 2.3. Supported PKI management operations . . . . . . . . . . . 13
2.3.1. Mandatory PKI management operations . . . . . . . . . 13 2.3.1. Mandatory PKI management operations . . . . . . . . . 13
2.3.2. Recommended PKI management operations . . . . . . . . 13 2.3.2. Recommended PKI management operations . . . . . . . . 14
2.3.3. Optional PKI management operations . . . . . . . . . 14 2.3.3. Optional PKI management operations . . . . . . . . . 14
2.4. CMP message transport . . . . . . . . . . . . . . . . . . 14 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 15
3. Generic parts of the PKI message . . . . . . . . . . . . . . 15 3. Generic parts of the PKI message . . . . . . . . . . . . . . 16
3.1. General description of the CMP message header . . . . . . 16 3.1. General description of the CMP message header . . . . . . 17
3.2. General description of the CMP message protection . . . . 17 3.2. General description of the CMP message protection . . . . 19
3.3. General description of CMP message extraCerts . . . . . . 18 3.3. General description of CMP message extraCerts . . . . . . 20
4. End Entity focused PKI management operations . . . . . . . . 19 4. End Entity focused PKI management operations . . . . . . . . 20
4.1. Requesting a new certificate from a PKI . . . . . . . . . 19 4.1. Requesting a new certificate from a PKI . . . . . . . . . 21
4.1.1. Request a certificate from a new PKI with signature 4.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 4.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 4.1.3. Update an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 28 protection . . . . . . . . . . . . . . . . . . . . . 29
4.1.4. Request a certificate from a PKI with MAC protection 29 4.1.4. Request a certificate from a PKI with MAC protection 30
4.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 . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.6. Generate the key pair centrally at the PKI management 4.1.6. Generate the key pair centrally at the PKI management
entity . . . . . . . . . . . . . . . . . . . . . . . 32 entity . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.6.1. Using key agreement key management technique . . 37 4.1.6.1. Using key agreement key management technique . . 40
4.1.6.2. Using key transport key management technique . . 38 4.1.6.2. Using key transport key management technique . . 41
4.1.6.3. Using password-based key management technique . . 39 4.1.6.3. Using password-based key management technique . . 42
4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 40 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 43
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 45 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48
4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 47 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50
4.4. Support messages . . . . . . . . . . . . . . . . . . . . 49 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52
4.4.1. General message and response . . . . . . . . . . . . 50 4.4.1. General message and response . . . . . . . . . . . . 53
4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 51 4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 54
4.4.3. Get root CA certificate update . . . . . . . . . . . 52 4.4.3. Get root CA certificate update . . . . . . . . . . . 55
4.4.4. Get certificate request template . . . . . . . . . . 53 4.4.4. Get certificate request template . . . . . . . . . . 56
5. LRA and RA focused PKI management operations . . . . . . . . 55 5. LRA and RA focused PKI management operations . . . . . . . . 58
5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 55 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59
5.1.1. Not changing protection . . . . . . . . . . . . . . . 57 5.1.1. Not changing protection . . . . . . . . . . . . . . . 61
5.1.2. Replacing protection . . . . . . . . . . . . . . . . 57 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61
5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 58 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62
5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 58 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 62
5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 59 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63
5.1.3.1. Handling a single PKI management message . . . . 60 5.1.3.1. Handling a single PKI management message . . . . 64
5.1.3.2. Handling a batch of PKI management messages . . . 60 5.1.3.2. Handling a batch of PKI management messages . . . 64
5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 61 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 65
5.2. Revoking certificates on behalf of another's entities . . 62 5.2. Revoking certificates on behalf of another's entities . . 66
5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 62 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 66
6. CMP message transport variants . . . . . . . . . . . . . . . 63 6. CMP message transport variants . . . . . . . . . . . . . . . 67
6.1. Definition and discovery of HTTP URIs . . . . . . . . . . 63 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 67
6.2. HTTP transport . . . . . . . . . . . . . . . . . . . . . 66 6.2. HTTPS transport using certificates . . . . . . . . . . . 69
6.3. HTTPS transport using certificates . . . . . . . . . . . 66 6.3. HTTPS transport using shared secrets . . . . . . . . . . 70
6.4. HTTPS transport using shared secrets . . . . . . . . . . 67 6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 71
6.5. Offline transport . . . . . . . . . . . . . . . . . . . . 67 6.4.1. File-based transport . . . . . . . . . . . . . . . . 71
6.5.1. File-based transport . . . . . . . . . . . . . . . . 68 6.4.2. Other asynchronous transport protocols . . . . . . . 71
6.5.2. Other asynchronous transport protocols . . . . . . . 68 6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71
6.6. CoAP transport . . . . . . . . . . . . . . . . . . . . . 68 6.6. Piggybacking on other reliable transport . . . . . . . . 71
6.7. Piggybacking on other reliable transport . . . . . . . . 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 72
8. Security Considerations . . . . . . . . . . . . . . . . . . . 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 72
10.1. Normative References . . . . . . . . . . . . . . . . . . 69 10.2. Informative References . . . . . . . . . . . . . . . . . 73
10.2. Informative References . . . . . . . . . . . . . . . . . 70 Appendix A. Example for CertReqTemplate . . . . . . . . . . . . 75
Appendix A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . 72 Appendix B. History of changes . . . . . . . . . . . . . . . . . 76
Appendix B. Example for CertReqTemplate . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
Appendix C. History of changes . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
!!! The change history was moved to Appendix C !!! !!! The change history was moved to Appendix B !!!
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.
1.1. Motivation for profiling CMP 1.1. Motivation for profiling CMP
skipping to change at page 4, line 38 skipping to change at page 4, line 37
implementation of all options is unrealistic because this would take implementation of all options is unrealistic because this would take
enormous effort. enormous effort.
Moreover, many details of the CMP protocol have been left open or Moreover, many details of the CMP protocol have been left open or
have not been specified in full preciseness. The profiles specified have not been specified in full preciseness. The profiles specified
in Appendix D and E of [RFC4210] offer some more detailed PKI in Appendix D and E of [RFC4210] offer some more detailed PKI
management operations. But the specific needs of highly automated management operations. But the specific needs of highly automated
scenarios for a machine-to-machine communication are not covered scenarios for a machine-to-machine communication are not covered
sufficiently. sufficiently.
As also 3GPP and UNISIG already put across, profiling is a way of As also ETSI and UNISIG already put across, profiling is a way of
coping with the challenges mentioned above. To profile means to take coping with the challenges mentioned above. To profile means to take
advantage of the strengths of the given protocol, while explicitly advantage of the strengths of the given protocol, while explicitly
narrowing down the options it provides to exactly those needed for narrowing down the options it provides to exactly those needed for
the purpose(s) at hand and eliminating all identified ambiguities. the purpose(s) at hand and eliminating all identified ambiguities.
In this way all the general and applicable aspects of the protocol In this way all the general and applicable aspects of the protocol
can be taken over and only the peculiarities of the target scenario can be taken over and only the peculiarities of the target scenario
need to be dealt with specifically. need to be dealt with specifically.
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
skipping to change at page 7, line 30 skipping to change at page 7, line 26
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 4.1.1 of this document. operation specified in Section 4.1.1 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 ETSI makes use of CMP [RFC4210] in its Technical Specification 133
310 [ETSI-3GPP] for automatic management of IPSec certificates in 310 [ETSI-TS133310] 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-Subset137] 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.
1.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
skipping to change at page 8, line 22 skipping to change at page 8, line 19
raVerified), raVerified),
o confirmation of newly enrolled certificates may be omitted, and o confirmation of newly enrolled certificates may be omitted, and
o all PKI management operations consist of request-response message o all PKI management operations consist of request-response message
pairs originating at the EE, i.e., announcement messages are pairs originating at the EE, i.e., announcement messages are
omitted. 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 UMTS, LTE, and 5G network domain security and profile for UMTS, LTE, and 5G network domain security and
authentication framework [ETSI-3GPP], except that: authentication framework [ETSI-TS133310], except that:
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 field 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-Subset137], except that:
o As stated in Section 4.1.1 a CMP message SHALL only consist of one o As stated in Section 4.1.1 a CMP message SHALL only consist of one
certificate request (CertReqMsg). Therefore, UNISIG is in certificate request (CertReqMsg). As UNISIG Subset-137 Table 6
conflict with this document as subset-137 allows to transport more [UNISIG-Subset137] allows to transport more than one certificate
than one certificate request. request message, this conflicts with this document.
o as of RFC 4210 [RFC4210] the messageTime is required to be o There is no automatic revocation specified in this document. As
Greenwich Mean Time coded as generalizedTime (Note: While UNISIG UNISIG Subset-137 Section 6.3.2.1.2 [UNISIG-Subset137] request an
explicitly states that the messageTime in required to be 'UTC automatic certificate revocation by the CA in case of TCP
time', it is not clear if this means a coding as UTCTime or disconnection during certificate distribution, this conflicts with
generalizedTime and if other time zones than Greenwich Mean Time this document.
shall be allowed. Therefore, UNISG may be in conflict with
RFC 4210 [RFC4210]. Both time formats are described in RFC 5280
[RFC5280] section 4.1.2.5.), and
o in case the request message is MAC protected, also the response, o As of RFC 4210 [RFC4210] the messageTime is required to be
certConf, and pkiConf messages have a MAC-based protection (Note: Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137
if changing to signature protection of the response the caPubs Table 5 [UNISIG-Subset137] explicitly states that the messageTime
field cannot be used securely anymore.). in required to be 'UTC time', it is not clear if this means a
coding as UTCTime or generalizedTime and if other time zones than
Greenwich Mean Time shall be allowed. Therefore, UNISIG
Subset-137 [UNISIG-Subset137] conflicts with RFC 4210 [RFC4210].
Both time formats are described in RFC 5280 Section 4.1.2.5
[RFC5280].
o This profile requires usage of the same type of protection for all
messages of one PKI management operation. This means, in case the
request message is MAC protected, also the response, certConf, and
pkiConf messages have a MAC-based protection. As UNISIG
Subset-137 Table 5 [UNISIG-Subset137] specifies for the first
certificate request MAC protection for all messages send by the
client and signature protection for all messages send by the
server, this conflicts with this document.
o The usage of caPubs is mainly allowed in combination with MAC
protected PKI management operations. UNISIG Subset-137 Table 12
[UNISIG-Subset137] requires to use caPubs. When changing to
signature protection of the response using a certificate issued
under the root CA that is to be transported in the caPubs field,
this is not a secure delivery of this root CA certificate.
1.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
skipping to change at page 13, line 11 skipping to change at page 13, line 21
Section 4 and Section 5 and points out whether an implementation by Section 4 and Section 5 and points out whether an implementation by
compliant EE or PKI management entities is mandatory, recommended or compliant EE or PKI management entities is mandatory, recommended or
optional. optional.
2.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 4 - End Entity focused PKI management operations +--------------------------------------------------------+----------+
| PKI management operations | Section |
o Request a certificate from a new PKI with signature protection; +--------------------------------------------------------+----------+
see Section 4.1.1. | Request a certificate from a new PKI with signature | Section |
| protection | 4.1.1 |
o Request to update an existing certificate with signature +--------------------------------------------------------+----------+
protection; see Section 4.1.3. | Request to update an existing certificate with | Section |
| signature protection | 4.1.3 |
o Error reporting; see Section 4.3. +--------------------------------------------------------+----------+
| Error reporting | Section |
Section 5 - LRA and RA focused PKI management operations | | 4.3 |
+--------------------------------------------------------+----------+
o Forward messages without changes; see Section 5.1.1.
o Forward messages with replaced protection and keeping the original Table 1: Mandatory End Entity focused PKI management operations
proof-of-possession; see Section 5.1.2.1.
o Forward messages with replaced protection and raVerified as proof- +--------------------------------------------------------+----------+
of-possession; see Section 5.1.2.2. | PKI management operations | Section |
+--------------------------------------------------------+----------+
| Forward messages without changes | Section |
| | 5.1.1 |
+--------------------------------------------------------+----------+
| Forward messages with replaced protection and keeping | Section |
| the original proof-of-possession | 5.1.2.1 |
+--------------------------------------------------------+----------+
| Forward messages with replaced protection and | Section |
| raVerified as proof-of-possession | 5.1.2.2 |
+--------------------------------------------------------+----------+
| Error reporting | Section |
| | 5.3 |
+--------------------------------------------------------+----------+
o Error reporting; see Section 5.3. Table 2: Mandatory LRA and RA focused PKI management operations
2.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 4 - End Entity focused PKI management operations +--------------------------------------------------------+----------+
| PKI management operations | Section |
o Request a certificate from a PKI with MAC protection; see +--------------------------------------------------------+----------+
Section 4.1.4. | Request a certificate from a PKI with MAC protection | Section |
| | 4.1.4 |
+--------------------------------------------------------+----------+
| Revoke an own certificate | Section |
| | 4.2 |
+--------------------------------------------------------+----------+
o Revoke an own certificate. Table 3: Recommended End Entity focused PKI management operations
Section 5 - LRA and RA focused PKI management operations +--------------------------------------------------------+----------+
| PKI management operations | Section |
+--------------------------------------------------------+----------+
| Revoke another's entities certificate | Section |
| | 5.2 |
+--------------------------------------------------------+----------+
o Revoke another's entities certificate. Table 4: Recommended LRA and RA focused PKI management operations
2.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 4 - End Entity focused PKI management operations +---------------------------------------------------------+---------+
| PKI management operations | Section |
o Request a certificate from a trusted PKI with signature +---------------------------------------------------------+---------+
protection; see Section 4.1.2. | Request a certificate from a trusted PKI with signature | Section |
| protection | 4.1.2 |
o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] +---------------------------------------------------------+---------+
request; see Section 4.1.5. | Request a certificate from a legacy PKI using a PKCS#10 | Section |
| [RFC2986] request | 4.1.5 |
o Add central generation of a key pair to a certificate request; see +---------------------------------------------------------+---------+
Section 4.1.6. If central key generation is supported, the key | Add central generation of a key pair to a certificate | Section |
agreement key management technique is REQUIRED to be supported, | request. (If central key generation is supported, the | 4.1.6 |
and the key transport and symmetric key-encryption key management | key agreement key management technique is REQUIRED to | |
techniques are OPTIONAL. | be supported, and the key transport and password-based | |
| key management techniques are OPTIONAL.) | |
o Handle delayed enrollment due to asynchronous message delivery; +---------------------------------------------------------+---------+
see Section 4.1.7. | Handle delayed enrollment due to asynchronous message | Section |
| delivery | 4.1.7 |
o Additional support messages, e.g., to update a root CA certificate +---------------------------------------------------------+---------+
or to request an RFC 8366 [RFC8366] voucher; see Section 4.4. | Additional support messages - distribution of CA | Section |
| certificates, update of a root CA certificate and | 4.4 |
| provisioning of certificate request template | |
+---------------------------------------------------------+---------+
Section 5 - LRA and RA focused PKI management operations Table 5: Optional End Entity focused PKI management operations
o Forward messages with additional protection; see Section 5.1.3 +--------------------------------------------------------+----------+
| PKI management operations | Section |
+--------------------------------------------------------+----------+
| Forward messages with additional protection | Section |
| | 5.1.3 |
+--------------------------------------------------------+----------+
| Initiate delayed enrollment due to asynchronous | Section |
| message delivery | 5.1.4 |
+--------------------------------------------------------+----------+
o Initiate delayed enrollment due to asynchronous message delivery; Table 6: Optional LRA and RA focused PKI management operations
see Section 5.1.4.
2.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 constraints to choose whatever transport is suitable. with special constraints to choose whatever transport is suitable.
Recommended transport +--------------------------------------------------------+----------+
o Transfer CMP messages using HTTP; see Section 6.2. | Transport | Section |
+--------------------------------------------------------+----------+
Optional transport | Transfer CMP messages using HTTP | Section |
| | 6.1 |
+--------------------------------------------------------+----------+
o Transfer CMP messages using HTTPS with certificate-based Table 7: Recommended transport operations
authentication; see Section 6.3.
o Transfer CMP messages using HTTPS with shared-secret based +--------------------------------------------------------+----------+
protection; see Section 6.4. | Transport | Section |
+--------------------------------------------------------+----------+
| Transfer CMP messages using HTTPS with certificate- | Section |
| based authentication | 6.2 |
+--------------------------------------------------------+----------+
| Transfer CMP messages using HTTPS with shared-secret | Section |
| based protection | 6.3 |
+--------------------------------------------------------+----------+
| Offline CMP message transport | Section |
| | 6.4 |
+--------------------------------------------------------+----------+
| Transfer CMP messages using CoAP | Section |
| | 6.5 |
+--------------------------------------------------------+----------+
o File-based CMP message transport. Table 8: Optional transport operations
3. Generic parts of the PKI message 3. 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 4 and messages used in the transactions specified in Section 4 and
Section 5 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.
skipping to change at page 16, line 30 skipping to change at page 18, line 9
sender, protectionAlg, and senderKID. sender, protectionAlg, and senderKID.
For requirements about proper random number generation please refer For requirements about proper random number generation please refer
to [RFC4086]. Any message-specific fields or variations are to [RFC4086]. Any message-specific fields or variations are
described in the respective sections of this chapter. described in the respective sections of this chapter.
header header
pvno REQUIRED pvno REQUIRED
-- MUST be set to 2 to indicate CMP V2 -- MUST be set to 2 to indicate CMP V2
sender REQUIRED sender REQUIRED
-- MUST be the subject of the protection certificate used for, -- MUST contain a name representing the originator of the message
-- SHOULD be the subject of the protection certificate,
-- the certificate for the private key used to sign the message -- the certificate for the private key used to sign the message
recipient REQUIRED recipient REQUIRED
-- SHOULD be the name of the intended recipient and -- SHOULD be the name of the intended recipient and
-- MAY be a NULL_DN if the sender does not know the DN of -- MAY be a NULL-DN, i.e., has a zero-length SEQUENCE OF
-- the recipient -- RelativeDistinguishedNames, if the sender does not know the
-- DN of the recipient
-- If this is the first message of a transaction: SHOULD be the -- If this is the first message of a transaction: SHOULD be the
-- subject of the issuing CA certificate -- subject of the issuing CA certificate
-- 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
skipping to change at page 17, line 17 skipping to change at page 18, line 47
-- 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:
-- MUST be 128 bits of random data for the start of a -- MUST be 128 bits of random data for the start of a
-- transaction to reduce the probability of having the -- transaction to reduce the probability of having the
-- transactionID already in use at the server -- transactionID already in use at the server
-- In all other messages: -- In all other messages:
-- MUST be the value from the previous message in the same -- MUST be the value from the previous message in the same
-- transaction -- transaction
senderNonce REQUIRED senderNonce REQUIRED
-- MUST be fresh 128 random bits -- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED recipNonce RECOMMENDED
-- If this is the first message of a transaction: SHOULD be -- If this is the first message of a transaction: SHOULD be
-- absent -- absent
-- In all other messages: MUST be present and contain the value -- In all other messages: MUST be present and contain the value
-- from senderNonce of the previous message in the same -- from senderNonce of the previous message in the same
-- transaction -- transaction
generalInfo OPTIONAL generalInfo OPTIONAL
implicitConfirm OPTIONAL implicitConfirm OPTIONAL
-- The field is optional though it only applies to -- The field is optional though it only applies to
-- ir/cr/kur/p10cr requests and ip/cp/kup response messages -- ir/cr/kur/p10cr requests and ip/cp/kup response messages
-- Add to request messages to request omit sending certConf -- Add to request messages to request omit sending certConf
-- message -- message
-- See [RFC4210] Section 5.1.1.1.
-- 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
< TBD: As discussed at IETF 108, the normative naming of specific
algorithms, e.g., like SHA-256 in the protectionAlg field should be
moved to a CMP Algorithms Draft. >
3.2. General description of the CMP message protection 3.2. General description of the CMP message protection
This section describes the generic protection field 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
skipping to change at page 19, line 34 skipping to change at page 21, line 15
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 4. extraCerts as specified in Section 4.
The behavior in case an error occurs is described in Section 4.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-TS133310], and [UNISIG-Subset137]
message sequences described here require agreement upon the do. Using the message sequences described here require agreement
algorithms to support and thus the algorithm identifiers for the upon the algorithms to support and thus the algorithm identifiers for
specific target environment. the specific target environment.
4.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:
skipping to change at page 20, line 52 skipping to change at page 22, line 35
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.
4.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 issued IDevID certificate
to the new PKI. The EE already has established trust in this new PKI [IEEE802.1AR], to prove its identity to the new PKI. The EE already
it is about to enroll to, e.g., by voucher exchange or configuration has established trust in this new PKI it is about to enroll to, e.g.,
means. The initialization request message is signature-protected by voucher exchange or configuration means. The certificate request
using the existing certificate. message is signature-protected using the existing certificate from
the external PKI.
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, the issuer field from a the CertReqTemplate response voucher, the issuer field from a CertReqTemplate response message,
message, or other configuration means. If the EE does not know or other configuration means. If the EE does not know the name of
the name of the CA, the PKI management entity MUST know where to the CA, the PKI management entity MUST know where to route this
route this request to. 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]
skipping to change at page 23, line 32 skipping to change at page 24, line 47
-- 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
certTemplate REQUIRED certTemplate REQUIRED
version OPTIONAL version OPTIONAL
-- MUST be 2 if supplied. -- MUST be 2 if supplied.
subject REQUIRED subject REQUIRED
-- MUST contain the suggested subject name of the EE -- The EE subject name MUST be carried in the subject field
-- certificate -- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN
publicKey REQUIRED publicKey REQUIRED
algorithm REQUIRED algorithm REQUIRED
-- MUST include the subject public key algorithm ID and value -- MUST include the subject public key algorithm ID and value
-- In case a central key generation is requested, this field -- In case a central key generation is requested, this field
-- contains the algorithm and parameter preferences of the -- contains the algorithm and parameter preferences of the
-- requesting entity regarding the to-be-generated key pair -- requesting entity regarding the to-be-generated key pair
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST contain the public key to be included into the requested -- MUST contain the public key to be included into the requested
-- certificate in case of local key-generation -- certificate in case of local key-generation
-- MUST contain a zero-length BIT STRING in case a central key -- MUST contain a zero-length BIT STRING in case a central key
-- generation is requested -- generation is requested
-- MUST include the subject public key algorithm ID and value
extensions OPTIONAL extensions OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the -- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name, -- requested certificate like subject alternative name,
-- key usage, and extended key usage -- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE
-- subject name includes a subject alternative name.
Popo REQUIRED Popo REQUIRED
POPOSigningKey OPTIONAL POPOSigningKey OPTIONAL
-- MUST be used in case subjectPublicKey contains a public key -- MUST be used in case subjectPublicKey contains a public key
-- MUST be absent in case subjectPublicKey contains a -- MUST be absent in case subjectPublicKey contains a
-- zero-length BIT STRING -- zero-length BIT STRING
poposkInput PROHIBITED poposkInput PROHIBITED
-- MUST NOT be used because subject and publicKey are both -- MUST NOT be used because subject and publicKey are both
-- 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
skipping to change at page 27, line 32 skipping to change at page 28, line 49
Preconditions: Preconditions:
1 The EE MUST have a certificate enrolled by the PKI it requests 1 The EE MUST have a certificate enrolled by the PKI it requests
another certificate from in advance to this PKI management another certificate from in advance to this PKI management
operation to authenticate itself to the PKI management entity operation to authenticate itself to the PKI management entity
using signature-based protection. using signature-based protection.
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, the issuer field from a the CertReqTemplate response voucher, the issuer field from a CertReqTemplate response message,
message, or other configuration means. If the EE does not know or other configuration means. If the EE does not know the name of
the name of the CA, the PKI management entity MUST know where to the CA, the PKI management entity MUST know where to route this
route this request to. 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 MUST be established using an enrollment voucher or other trust MUST be established using an enrollment voucher or other
configuration means. configuration means.
4 The PKI management entity MUST trust the current PKI; trust MAY be 4 The PKI management entity MUST trust the current PKI; trust MAY be
established using some configuration means. established using some configuration means.
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.5. given in [RFC4210] Appendix D.5.
skipping to change at page 28, line 12 skipping to change at page 29, line 30
1 The body of the first request and response MUST be cr and cp, 1 The body of the first request and response MUST be cr and cp,
respectively. respectively.
2 The caPubs field in the cp message SHOULD be absent. 2 The caPubs field in the cp message SHOULD be absent.
4.1.3. Update an existing certificate with signature protection 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. The certificate request message is signature-protected
updated to the PKI. Therefore, the key update request message is using this certificate.
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 4.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.
skipping to change at page 28, line 38 skipping to change at page 30, line 8
The message sequence for this PKI management operation is identical The message sequence for this PKI management operation is identical
to that given in Section 4.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
1 The body of the first request and response MUST be kur and kup, 1 The body of the first request and response MUST be kur and kup,
respectively. respectively.
2 Protection of the kur MUST be performed using the certificate to 2 Protection of the kur MUST be performed using the certificate to
be updated. be updated.
3 The subject field of the CertTemplate MUST contain the subject 3 The subject field and/or the subjectAltName extension of the
name of the existing certificate to be updated, without CertTemplate MUST contain the EE subject name of the existing
modifications. certificate to be updated, without modifications.
4 The CertTemplate MUST contain the subject, issuer and publicKey 4 The CertTemplate SHOULD contain the subject and publicKey of the
fields only. EE only.
5 The oldCertId control SHOULD be used to make clear, even in case 5 The oldCertId control SHOULD be used to make clear which
an (L)RA changes the message protection, which certificate is to 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
skipping to change at page 29, line 42 skipping to change at page 31, line 11
same as given in Section 4.1.1. same as given in Section 4.1.1.
Preconditions: Preconditions:
1 The EE and the PKI management entity 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, the issuer field from a the CertReqTemplate response voucher, the issuer field from a CertReqTemplate response message,
message, or other configuration means. If the EE does not know or other configuration means. If the EE does not know the name of
the name of the CA, the PKI management entity MUST know where to the CA, the PKI management entity MUST know where to route this
route this request to. 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 4.1.1, with the following changes: to that given in Section 4.1.1, with the following changes:
skipping to change at page 31, line 33 skipping to change at page 33, line 4
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, the issuer field from a the CertReqTemplate response voucher, the issuer field from a CertReqTemplate response message,
message, or other configuration means. If the EE does not know or other configuration means. If the EE does not know the name of
the name of the CA, the RA MUST know where to route this request the CA, the RA MUST know where to route this request to.
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
skipping to change at page 32, line 49 skipping to change at page 34, line 47
protection REQUIRED protection REQUIRED
-- As described in section 3.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 3.3 -- As described in section 3.3
4.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 4.1.1 and certificate enrollment as described in Section 4.1.1, Section 4.1.2,
Section 4.1.4. The functional extension can be used in case an EE is and Section 4.1.4. The functional extension can be used in case an
not able or is not willing to generate its new public-private key EE is not able or is not willing to generate its new public-private
pair itself. It is a matter of the local implementation which PKI key pair itself. It is a matter of the local implementation which
management entity will perform the key generation. This entity MUST PKI management entity will act as Key Generation Authority (KGA) and
have a certificate containing the additional extended key usage perform the key generation. This PKI management entity MUST have a
extension id-kp-cmcKGA to be identified by the EE as a legitimate certificate containing the additional extended key usage extension
key-generation authority. In case the PKI management entity id-kp-cmKGA to be identified by the EE as a legitimate key-generation
generated the new key pair for the EE, it can use Section 4.1.1 to authority. In case the KGA generated the new key pair on behalf of
Section 4.1.4 to request the certificate for this key pair as usual. the EE, it can use Section 4.1.1, Section 4.1.2, or 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 holt 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
following: following:
o Lack of sufficient initial entropy. o Lack of sufficient initial entropy.
Note: Good random numbers are not only needed for key generation, but Note: Good random numbers are not only needed for key generation, but
also for session keys and nonces in any security protocol. also for session keys and nonces in any security protocol.
Therefore, we believe that a decent security architecture should Therefore, a decent security architecture should anyways support good
anyways support good random number generation on the EE side or random number generation on the EE side or provide enough entropy for
provide enough entropy for the RNG seed during manufacturing to the RNG seed to guarantee good initial pseudo-random number
guarantee good initial pseudo-random number generation. generation. May be this is not the case at the time of requesting a
certificate during manufacturing.
o Due to lack of computational resources, e.g., in case of RSA keys. o Due to lack of computational resources, e.g., in case of RSA keys.
Note: As key generation can be performed in advance to the Note: As key generation could be performed in advance to the
certificate enrollment communication, it is typical not time certificate enrollment communication, it is often not time critical.
critical.
Note: Besides the initial enrollment right after the very first
bootup of the device, where entropy available on the device may be
insufficient, we do not see any good reason for central key
generation.
Note: As mentioned in Section 2.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.
Note: As the protection of centrally generated keys in the response Note: As the protection of centrally generated keys in the response
message is being extended from EncryptedValue to EncryptedKey by CMP message is being extended from EncryptedValue to EncryptedKey by CMP
Updates [I-D.ietf-lamps-cmp-updates] also the alternative Updates [I-D.ietf-lamps-cmp-updates], also the alternative
EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use
of EncryptedValue has been deprecated in favor of the EnvelopedData of EncryptedValue has been deprecated in favor of the EnvelopedData
structure. Therefore, this profile specifies using EnvelopedData as structure. Therefore, this profile specifies using EnvelopedData as
specified in CMS Section 6 [RFC5652] to offer more crypto agility. specified in CMS Section 6 [RFC5652].
+------------------------------+ +----------------------------------+
| EnvelopedData | | EnvelopedData |
| [RFC5652] section 6 | | [RFC5652] section 6 |
| +--------------------------+ | | +------------------------------+ |
| | SignedData | | | | SignedData | |
| | [RFC5652] section 5 | | | | [RFC5652] section 5 | |
| | +----------------------+ | | | | +--------------------------+ | |
| | | privateKey | | | | | | AsymmetricKeyPackage | | |
| | | OCTET STRING | | | | | | [RFC5958] | | |
| | +----------------------+ | | | | | +----------------------+ | | |
| +--------------------------+ | | | | | privateKey | | | |
+------------------------------+ | | | | OCTET STRING | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+
Figure 3: Encrypted private key container Figure 3: Encrypted private key container
The PKI management entity delivers the private key in the privateKey The PKI management entity delivers the private key in the privateKey
field in the certifiedKeyPair structure of the response message also field in the certifiedKeyPair structure of the response message also
containing the newly issued certificate. containing the newly issued certificate.
The private key MUST be wrapped in a SignedData structure, as The private key MUST be provided as an AsymmetricKeyPackage structure
specified in CMS Section 5 [RFC5652], signed by the KGA generating as defined in RFC 5958 [RFC5958].
the key pair. The signature MUST be performed using a CMP signer
certificate asserting the extended key usage kp-id-cmpKGA as This AsymmetricKeyPackage structure MUST be wrapped in a SignedData
structure, as specified in CMS Section 5 [RFC5652], signed by the KGA
generating the key pair. The signature MUST be performed using a CMP
signer certificate asserting the extended key usage kp-id-cmKGA as
described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the
authorization to generate key pairs on behalf of an EE. authorization to generate key pairs on behalf of an EE.
Note: In case of using password-based key management technique as
described in Section 4.1.6.3 it may not be possible or meaningful to
the EE to validate the KGA signature in the SignedData structure as
shares secrets are used for initial authentication. In this case the
EE MAY omit this signature validation.
This SignedData structure MUST be wrapped in an EnvelopedData This SignedData structure MUST be wrapped in an EnvelopedData
structure, as specified in CMS Section 6 [RFC5652], encrypting it structure, as specified in CMS Section 6 [RFC5652], encrypting it
using a newly generated symmetric content-encryption key. using a newly generated symmetric content-encryption key.
Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210]
this content-encryption key is not generated on the EE side. As we this content-encryption key is not generated on the EE side. As we
just mentioned, central key generation should only be used in this just mentioned, central key generation should only be used in this
profile in case of lack of randomness on the EE. profile in case of lack of randomness on the EE.
As part of the EnvelopedData structure this content-encryption key As part of the EnvelopedData structure this content-encryption key
skipping to change at page 35, line 4 skipping to change at page 37, line 12
Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210]
this content-encryption key is not generated on the EE side. As we this content-encryption key is not generated on the EE side. As we
just mentioned, central key generation should only be used in this just mentioned, central key generation should only be used in this
profile in case of lack of randomness on the EE. profile in case of lack of randomness on the EE.
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 Signature protected request message:
* Using a certificate that contains a key usage extension
asserting keyAgreement: The content-encryption key SHALL be
protected using the key agreement key management technique, see
Section 4.1.6.1, if the certificate used by the EE for signing
the respective request message contains the key usage
keyAgreement. If the certificate also contains the key usage
keyEncipherment, the key transport key management technique
SHALL NOT be used.
* Using a certificate that contains a key usage extension
asserting keyEncipherment: The content-encryption key SHALL be
protected using the key transport key management technique, see
Section 4.1.6.2, if the certificate used by the EE for signing
the respective request message contains the key usage
keyEncipherment and not keyAgreement.
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 password-based key management technique, see protected using the password-based key management technique, see
Section 4.1.6.3, only if the EE used MAC protection for the Section 4.1.6.3, only if the EE used MAC protection for the
respected request message. respected request message.
o Signature protected request message using a certificate that
contains a key usage extension asserting keyAgreement: The
content-encryption key SHALL be protected using the key agreement
key management technique, see Section 4.1.6.1, if the certificate
used by the EE for signing the respective request message contains
the key usage keyAgreement. If the certificate also contains the
key usage keyEncipherment, the key transport key management
technique SHALL NOT be used.
o Signature protected request message using a certificate that
contains a key usage extension asserting keyEncipherment: The
content-encryption key SHALL be protected using the key transport
key management technique, see Section 4.1.6.2, if the certificate
used by the EE for signing the respective request message contains
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
password-based key management technique shall only be used in password-based key management technique shall only be used 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 of the 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 password-based key management the support of key transport and password-based key management
techniques are OPTIONAL. techniques are OPTIONAL.
skipping to change at page 36, line 42 skipping to change at page 39, line 4
-- 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
encapContentInfo encapContentInfo
REQUIRED REQUIRED
-- MUST be the content that is to be signed -- MUST be the content that is to be signed
contentType REQUIRED contentType REQUIRED
-- MUST be id-data
-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
content REQUIRED content REQUIRED
-- MUST be the privateKey as OCTET STRING AsymmetricKeyPackage
REQUIRED
OneAsymmetricKey
REQUIRED
-- MUST be exactly one asymmetric key package
version REQUIRED
-- The version MUST be v2
privateKeyAlgorithm
REQUIRED
-- The privateKeyAlgorithm field MUST contain
-- the OID of the asymmetric key pair algorithm
privateKey
REQUIRED
-- The privateKey MUST be in the privateKey field
Attributes
OPTIONAL
-- The attributes field SHOULD not be used
publicKey
REQUIRED
-- The publicKey MUST be in the publicKey field
certificates REQUIRED certificates REQUIRED
-- SHOULD contain the certificate, for the private key used -- SHOULD contain the certificate, for the private key used
-- to sign the content, together with its chain -- to sign the content, together with its chain
-- If present, the first certificate in this field MUST -- If present, the first certificate in this field MUST
-- be the certificate used for signing this content -- be the certificate used for signing this content
-- Self-signed certificates SHOULD NOT be included -- Self-signed certificates SHOULD NOT be included
-- and MUST NOT be trusted based on the listing in any case -- and MUST NOT be trusted based on the listing in any case
crls OPTIONAL crls OPTIONAL
-- 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
skipping to change at page 38, line 12 skipping to change at page 41, line 12
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
-- MUST contain the originatorKey sequence -- MUST contain the originatorKey sequence
algorithm REQUIRED algorithm REQUIRED
-- MUST be the algorithm identifier of the -- MUST be the algorithm identifier of the
-- static-ephemeral Diffie-Hellmann algorithm -- static-ephemeral Diffie-Hellmann algorithm
publicKey REQUIRED publicKey REQUIRED
-- MUST be the ephemeral public key of the sending party -- MUST be the ephemeral public key of the sending party
ukm OPTIONAL ukm OPTIONAL
-- MUST be used when 1-pass ECMQV is used -- MUST be used when 1-pass ECMQV is used
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the same as in the contentEncryptionAlgorithm field -- MUST be the same as in the contentEncryptionAlgorithm field
recipientEncryptedKeys recipientEncryptedKeys
REQUIRED REQUIRED
-- MUST be exactly one recipientEncryptedKey sequence -- MUST be exactly one recipientEncryptedKey sequence
recipientEncryptedKey recipientEncryptedKey
REQUIRED REQUIRED
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
4.1.6.2. 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 4.1.1 to Section 4.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
skipping to change at page 39, line 11 skipping to change at page 42, line 11
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
rid REQUIRED rid REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
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
4.1.6.3. Using password-based key management technique 4.1.6.3. Using password-based 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 operation specified in Section 4.1.4 using MAC PKI management operation specified in Section 4.1.4 using MAC
protected CMP messages. The shared secret used for the MAC protected CMP messages. The shared secret used for the MAC
protection MUST also be used for the encryption of the content- protection MUST also be used for the encryption of the content-
encryption key but with a different salt. To use this key management encryption key but with a different salt. To use this key management
technique the PasswordRecipientInfo structure MUST be used in the technique the PasswordRecipientInfo structure MUST be used in the
contentInfo field. contentInfo field.
The PasswordRecipientInfo structure included into the EnvelopedData The PasswordRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.3 [RFC5652]. structure is specified in CMS Section 6.2.4 [RFC5652].
The detailed description of the PasswordRecipientInfo structure looks The detailed description of the PasswordRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be PasswordRecipientInfo as specified in -- MUST be PasswordRecipientInfo as specified in
-- CMS section 6.2.4 [RFC5652] -- CMS section 6.2.4 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be set to 0 -- MUST be set to 0
keyDerivationAlgorithm keyDerivationAlgorithm
skipping to change at page 42, line 5 skipping to change at page 44, line 32
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 5.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 recipNonce CA arrives at the LRA, the next response will contain the recipNonce
set to the value of the senderNonce in the original request message set to the value of the senderNonce in the original request message
(copied by the CA). The LRA needs to replace the recipNonce in this (copied by the CA). The LRA needs to replace the recipNonce in this
case with the senderNonce of the last pollReq because the EE will case with the senderNonce of the last pollReq because the EE will
validate it in this way. validate it in this way.
< TBD: I would appreciate any feedback specifically addressing the
nonce handling in case an offline LRA responding and not forwarding
the pollReq messages. >
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
in the respective section in the respective section
skipping to change at page 44, line 21 skipping to change at page 47, line 21
-- certConf message of the respective PKI management operation -- certConf message of the respective PKI management operation
Polling Response -- pollRep Polling Response -- pollRep
Field Value Field Value
header header
-- MUST contain a header as described for the pkiConf message -- MUST contain a header as described for the pkiConf message
-- of the respective PKI management operation -- of the respective PKI management operation
body pollRep body
-- The message indicated the time to after which the EE may -- The message indicated the time to after which the EE may
-- send another pollReq messaged for this transaction -- send another pollReq messaged for this transaction
pollRep REQUIRED pollRep REQUIRED
-- MUST be exactly one set of the following values -- MUST be exactly one set of the following values
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be set to 0
checkAfter REQUIRED checkAfter REQUIRED
-- time in seconds to elapse before a new pollReq may be sent by -- time in seconds to elapse before a new pollReq may be sent by
-- the EE -- the EE
skipping to change at page 51, line 31 skipping to change at page 54, line 31
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 3.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 3.3 -- As described in section 3.3
< TBD: May be we should not restrict the number of ITAV elements in
the response message to one. >
4.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-caCerts. The PKI management sending a general message with OID id-it-caCerts as specified in CMP
entity responds with a general response with the same OID that either Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity
responds with a general response with the same OID that either
contains a SEQUENCE of certificates populated with the available CA contains a SEQUENCE of certificates populated with the available CA
intermediate and issuing CA certificates or with no content in case intermediate and issuing CA certificates or with no content in case
no CA certificate is available. no CA certificate is available.
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 4.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-caCerts 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
skipping to change at page 52, line 19 skipping to change at page 55, line 21
-- MUST be present if CA certificates are available -- MUST be present if CA certificates are available
-- MUST be a sequence of CMPCertificate -- MUST be a sequence of CMPCertificate
4.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. update of an existing root CA Certificate by the EE.
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-rootCaKeyUpdate as entity by sending a general message with OID id-it-rootCaKeyUpdate as
infoType and no infoValue. The PKI management entity responds with a specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI
general response with the same OID that either contains the update of management entity responds with a general response with the same OID
the root CA certificate consisting of up to three certificates, or that either contains the update of the root CA certificate consisting
with no content in case no update is available. of up to three certificates, or with no content in case no update is
available.
These three certificates are described in more detail in section The newWithNew certificate is the new root CA certificates and is
4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew REQUIRED to be present in the response message. The newWithOld
certificate is the new root CA certificates and is REQUIRED to be certificate is RECOMMENDED to be present in the response message
present in the response message. The newWithOld certificate is though it is REQUIRED for those cases where the receiving entity
RECOMMENDED to be present in the response message though it is trusts the old root CA certificate and wishes to gain trust in the
REQUIRED for those cases where the receiving entity trusts the old new root CA certificate. The oldWithNew certificate is OPTIONAL
root CA certificate and wishes to gain trust in the new root CA though it is only needed in a scenario where the requesting entity
certificate. The oldWithNew certificate is OPTIONAL though it is already trusts the new root CA certificate and wants to gain trust in
only needed in a scenario where the requesting entity already trusts the old root certificate.
the new root CA certificate and wants to gain trust in the old root
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 4.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-rootCaKeyUpdate 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
RootCaKeyUpdate structure RootCaKeyUpdate structure
skipping to change at page 53, line 25 skipping to change at page 56, line 25
-- MUST contain the new root CA certificate -- MUST contain the new root CA certificate
newWithOld RECOMMENDED 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
oldWithNew OPTIONAL oldWithNew OPTIONAL
-- MAY be present if infoValue is present -- MAY be present if infoValue is present
-- MUST contain an X.509 certificate containing the old public -- MUST contain an X.509 certificate containing the old public
-- root CA key signed with the new private root CA key -- root CA key signed with the new private root CA key
< TBD: In case the PKI management entity serves for different Root
CAs. There are three different options to handle this: - The EE
specifies by means of an respective lable in the http endpoint for
which Root CA certificate the update is requested. - The EE transfers
the oldWithOld certificate in the InfoValue of the request. - The PKI
management entity provides RootCaKeyUpdate element all Root CAs an
update is available. >
4.4.4. Get certificate request template 4.4.4. Get certificate request template
This PKI management operation can be used by an EE to request a This PKI management operation can be used by an EE to request a
template with parameters for a future certificate request operation. template with parameters for a future certificate request operation.
An EE requests certificate request parameters from the PKI management An EE requests certificate request parameter from the PKI management
entity by sending a general message with OID id-it-certReqTemplate. entity by sending a general message with OID id-it-certReqTemplate as
The PKI management entity responds with a general response with the specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI
same OID that either contains a certificate template with the management entity responds with a general response with the same OID
required fields and optionally a rsaKeyLen field containing that either contains a certificate template containing requirements
requirements on, e.g., algorithm identifier for key pair generation on certificate fields and extensions and optionally a sequence of
or certificate fields and extensions, or with no content in case no control fields containing requirements on algorithm identifier or RSA
key lengths for key pair generation, or with no content in case no
specific requirements are made by the PKI. specific requirements are made by the PKI.
The EE SHOULD follow the requirements from the received CertTemplate The EE SHOULD follow the requirements from the received CertTemplate
and the optional rsaKeyLen fields, by filling in all the fields and the optional control fields, by filling in all the fields
requested and taking over all the field values provided. The EE requested and taking over all the field values provided. The EE
SHOULD NOT add further CertTemplate fields, Name components, and SHOULD NOT add further CertTemplate fields, Name components, and
extensions or their (sub-)components. extensions or their (sub-)components.
Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order
to allow more flexibility in case the rules given here are not to allow more flexibility in case the rules given here are not
sufficient for specific scenarios. The EE can populate the sufficient for specific scenarios. The EE can populate the
certificate request as wanted and ignore any of the requirements certificate request as wanted and ignore any of the requirements
contained in the CertReqTemplate response message. On the other contained in the CertReqTemplate response message. On the other
hand, a PKI management entity is free to ignore or replace the hand, a PKI management entity is free to ignore or replace the
content of the certificate request provided by the EE. The content of the certificate request provided by the EE. The
CertReqTemplate PKI management operation offers means to ease a joint CertReqTemplate PKI management operation offers means to ease a joint
understanding which fields should be used. understanding which fields should be used.
In case a field of type Name, e.g., issuer or subject name, is In case a field of type Name, e.g., issuer or subject, is present in
present but has the value NULL-DN (i.e., has an empty list of RDN the CertTemplate but has the value NULL-DN (i.e., has an empty list
components) the field SHOULD be included with content provided by the of RDN components) the field SHOULD be included with content provided
EE. Similarly, in case an X.509v3 extension is present but its by the EE. Similarly, in case an X.509v3 extension is present but
extnValue is empty this means that the extension SHOULD be included its extnValue is empty this means that the extension SHOULD be
with content provided by the EE. In case a Name component, for included with content provided by the EE. In case a Name component,
instance a common name or serial number, is given but has an empty for instance a common name or serial number, is given but has an
string value the EE SHOULD fill in a value. Similarly, in case an empty string value the EE SHOULD fill in a value. Similarly, in case
extension has sub-components (e.g., an IP address in a SubjectAltName an extension has sub-components (e.g., an IP address in a
field) with empty value, the EE SHOULD fill in a value. SubjectAltName field) with empty value, the EE SHOULD fill in a
value.
The EE MUST ignore (i.e., not include and fill in) empty fields, The EE MUST ignore (i.e., not include and fill in) empty fields,
extensions, and sub-components that it does not know. extensions, and sub-components that it does not know.
If the publicKey field of type SubjectPublicKeyInfo is present its The publicKey field of type SubjectPublicKeyInfo in the CertTemplate
algorithm field specifies the type of the public key to request a MUST no algorithm ID in the algorithm field and a zero-length BIT
certificate for. The algorithm field contains the key type OID of STRING in the subjectPublicKey field. In case the PKI management
the public key. For EC keys the full curve information MUST be entity whishes to make stipulation on supported algorithms the EE may
specified as described in the respective standard documents. For RSA use for key generation, this MUST be specified using the control
keys the key length MUST be specified in the rsaKeyLen field of the fields.
outer infoValue field. The algorithm field MUST be followed by a
zero-length BIT STRING for the subjectPublicKey. If the publicKey The control with the OID id-regCtrl-algId, as specified in CMP
field is not present the EE is free to choose the public key type and Updates [I-D.ietf-lamps-cmp-updates], specifies algorithms other that
parameters. RSA. The algorithm field in SubjectPublicKeyInfo 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. The algorithm field MUST be followed by a zero-
length BIT STRING for the subjectPublicKey.
The control with the OID id-regCtrl-rsaKeyLen, as specified in CMP
Updates [I-D.ietf-lamps-cmp-updates], specifies RSA keys of the
specified key length. In case several control fields are present the
EE is free to choose one of the specified algorithms for key pair
generation. In case no control field is not present the EE is free
to choose the public key type and parameters.
In the certTemplate structure the serialNumber, signingAlg, In the certTemplate structure the serialNumber, signingAlg,
issuerUID, and subjectUID fields MUST be omitted. 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 4.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-certReqTemplate 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 certTemplate
certTemplate structure and an rsaKeyLen field of type INTEGER structure and an optional SEQUENCE of AttributeTypeAndValue of
type id-regCtrl-algId or id-regCtrl-rsaKeyLen
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
certReqTemplate OID looks like this: certReqTemplate OID looks like this:
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 template -- requirements on the content of the certificates template
-- 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 elements -- MUST contain the prefilled certTemplate structure elements
rsaKeyLen OPTIONAL -- The SubjectPublicKeyInfo MUST contain no algorithm ID in the
-- This field is of type INTEGER. Any reasonable RSA key length -- algorithm field and a zero-length BIT STRING in the
-- MUST be specified if the algorithm in the -- subjectPublicKey field
-- subjectPublicKeyInfo field of the certTemplate has the OID controls OPTIONAL
-- rsaEncryption. -- MUST be absent if no requirements on algorithms are available
-- MUST be omitted in otherwise. -- MUST be present if the PKI management entity has any
-- requirements on the algorithms to be used for key generation
-- MUST contain one AttributeTypeAndValue per supported algorithm
-- MAY be of type id-regCtrl-algId or id-regCtrl-rsaKeyLen
5. LRA and RA focused PKI management operations 5. 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
skipping to change at page 58, line 7 skipping to change at page 61, line 29
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
the previous PKI component and approve its content including any own the previous PKI management entity and approve its content including
modifications. For certificate requests the PKI management entity any own modifications. For certificate requests the PKI management
MUST verify in particular the included proof-of-possession self- entity MUST verify in particular the included proof-of-possession
signature of the certTemplate using the public key of the requested self-signature of the certTemplate using the public key of the
certificate and MUST check that the EE, as authenticated by the requested certificate and MUST check that the EE, as authenticated by
message protection, is authorized to request a certificate with the the message protection, is authorized to request a certificate with
subject as specified in the certTemplate. the 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 incoming 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 4.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.
These message adaptations MUST NOT be applied to certificate request
messages as described in Section 4.1.6requesting key generation by a
Key Generation Authority since their original protection using the
key and certificate for signature protection or the shared secret for
MAC-protection needs to be preserved up to the Key Generation
Authority.
In both cases, kur and central key generation, an additional
signature of a PKI management entity to the original certificate
request message MUST be provided using nested messages as specified
in Section 5.1.3.
5.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.
skipping to change at page 59, line 27 skipping to change at page 63, line 18
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
5.1.3. Adding Protection 5.1.3. Adding Protection
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 add another protection to one or several PKI management messages. to add another protection to one or several PKI management messages.
Applying an additional protection is specifically important when
forwarding certificate request messages requesting a key update or a
central key generation to preserve the original protection of the EE.
The nested message is a PKI management message containing a The nested message is a PKI management message containing a
PKIMessages sequence as its body containing one or more CMP messages. PKIMessages sequence as its body containing one or more CMP messages.
As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see
Section 3.3 of CMP Updates [I-D.ietf-lamps-cmp-updates]) there are CMP Updates [I-D.ietf-lamps-cmp-updates]) there are different use
different use case for adding another protection by a PKI management case for adding another protection by a PKI management entity.
entity. Specific procedures are described in more detail in the Specific procedures are described in more detail in the following
following sections. sections.
The behavior in case an error occurs is described in Section 4.3. The behavior in case an error occurs is described in Section 4.3.
Message flow: Message flow:
Step# PKI management entity PKI management entity Step# PKI management entity PKI management entity
1 format nested 1 format nested
2 -> nested -> 2 -> nested ->
3 handle, re-protect or 3 handle, re-protect or
forward nested forward nested
skipping to change at page 60, line 14 skipping to change at page 64, line 14
Detailed message description: Detailed message description:
Nested Message - nested Nested Message - nested
Field Value Field Value
header header
-- As described in section 3.1 -- As described in section 3.1
body nested body
-- Container to provide additional protection to original -- Container to provide additional protection to original
-- messages and to bundle request or response messages -- messages and to bundle request or response messages
PKIMessages REQUIRED PKIMessages REQUIRED
-- MUST be a sequence of one or more CMP messages -- MUST be a sequence of one or more CMP messages
protection REQUIRED protection REQUIRED
-- As described in section 3.2 using the CMP signer key of -- As described in section 3.2 using the CMP signer key of
-- the PKI management entity -- the PKI management entity
extraCerts REQUIRED extraCerts REQUIRED
skipping to change at page 63, line 31 skipping to change at page 67, line 31
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.
When conveying a CMP messages in HTTP or MIME-based transport When conveying a CMP messages in HTTP or MIME-based transport
protocols the internet media type "application/pkixcmp" MUST be set protocols the internet media type "application/pkixcmp" MUST be set
for transport encoding as specified in RFC2510 in Section 5.3 for transport encoding as specified in RFC2510 in Section 5.3
[RFC2510] and RFC6712 in Section 3.4 [RFC7712]. [RFC2510] and RFC6712 in Section 3.4 [RFC7712].
6.1. Definition and discovery of HTTP URIs 6.1. HTTP transport
Each PKI management entity supporting HTTP or HTTPS transport MUST
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
multi-vendor environment.
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 URI, e.g., 'www.example.com:80', or the full operational path of
the PKI management entity. An additional arbitrary label, e.g.,
'arbitraryLabel', MAY be configured as a separate component or as
part of the full operational path to provide further information to
address multiple CAs or certificate profiles. A valid full
operational path can look like this:
1 http://www.example.com/.well-known/cmp
2 http://www.example.com/.well-known/cmp/keyupdate
3 http://www.example.com/.well-known/cmp/arbitraryLabel This transport mechanism can be used by a PKI entity to transfer CMP
4 http://www.example.com/.well-known/cmp/arbitraryLabel/keyupdate messages over HTTP. If HTTP transport is used the specifications as
described in [RFC6712] and updated by CMP Updates
[I-D.ietf-lamps-cmp-updates] MUST be followed.
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) | | 4.1.1 | | (REQUIRED) | | 4.1.1 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Enroll client to existing PKI | /certification | Section | | Enroll client to existing PKI | /certification | Section |
skipping to change at page 64, line 42 skipping to change at page 68, line 41
| Get root CA certificate update | /getrootupdate | Section | | Get root CA certificate update | /getrootupdate | Section |
| (OPTIONAL) | | 4.4.3 | | (OPTIONAL) | | 4.4.3 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Get certificate request template | /getcertreqtemplate | Section | | Get certificate request template | /getcertreqtemplate | Section |
| (OPTIONAL) | | 4.4.4 | | (OPTIONAL) | | 4.4.4 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Additional protection (OPTIONAL) | /nested | Section | | Additional protection (OPTIONAL) | /nested | Section |
| | | 5.1.3 | | | | 5.1.3 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
Table 1: HTTP endpoints Table 9: 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.
The discovery of supported endpoints as defined above will provide The discovery mechanism as described in CMP Updates
the information to the EE, how to contact the PKI management entity [I-D.ietf-lamps-cmp-updates] SHOULD be used to query information on
and, if available, how to request enrolment for a specific the supported PKI management operations, certificate profiles and
certificate profile or revoke a certificate at a specific CA. CAs.
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 As it is very likely, that a CA supports different certification
profiles or that the RA offers PKI management operations for profiles or that the RA offers PKI management operations for
different issuing CAs, the discovery can also be used to provide the different issuing CAs, the discovery can also be used to provide the
information about these options. The second example listing contains information about these options. The second example listing contains
the supported PKI management operations for three different the supported PKI management operations for three different
certificate profiles. The supported CA hierarchy consists of one certificate profiles. The supported CA hierarchy consists of one
root CA and two issuing CAs. root CA and two issuing CAs.
Detailed message description: Detailed message description:
skipping to change at page 66, line 35 skipping to change at page 69, line 40
</cmp/rootca1/getrootupdate>;ct=pkixcmp </cmp/rootca1/getrootupdate>;ct=pkixcmp
</cmp/certprofile1/getcertreqtemplate >;ct=pkixcmp </cmp/certprofile1/getcertreqtemplate >;ct=pkixcmp
</cmp/certprofile2/getcertreqtemplate >;ct=pkixcmp </cmp/certprofile2/getcertreqtemplate >;ct=pkixcmp
</cmp/certprofile3/getcertreqtemplate >;ct=pkixcmp </cmp/certprofile3/getcertreqtemplate >;ct=pkixcmp
There are different options in the handling of the naming. The PKI There are different options in the handling of the naming. The PKI
management entity either needs to offer the certprofile or CA labels management entity either needs to offer the certprofile or CA labels
the EE expects. Alternatively, a mechanism is required to configure the EE expects. Alternatively, a mechanism is required to configure
this information to the EE beforehand. this information to the EE beforehand.
6.2. HTTP transport 6.2. HTTPS transport using certificates
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 6.2 using TLS 1.2 protect the HTTP transport as described in Section 6.1 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
skipping to change at page 67, line 32 skipping to change at page 70, 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.
6.4. HTTPS transport using shared secrets 6.3. 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 6.2 using TLS 1.2 protect the HTTP transport as described in Section 6.1 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.
6.5. Offline transport < TBD: It needs to be clarified which cipher suite shall be
recommended as there seems to be no support for TLS-SRP un JavaSE. >
6.4. Offline transport
For transporting CMP messages between PKI entities any mechanism can For transporting CMP messages between PKI entities any mechanism can
be used that is able to store and forward binary objects of be used that is able to store and forward binary objects of
sufficient length and with sufficient reliability while preserving sufficient length and with sufficient reliability while preserving
the order of messages. the order of messages.
The transport mechanism SHOULD be able to indicate message loss, The transport mechanism SHOULD be able to indicate message loss,
excessive delay, and possibly other transmission errors. In such excessive delay, and possibly other transmission errors. In such
cases the PKI entities using this mechanism SHOULD report an error as cases the PKI entities using this mechanism SHOULD report an error as
specified in Section 4.3. specified in Section 4.3.
6.5.1. File-based transport 6.4.1. File-based transport
CMP messages MAY be transferred between PKI entities using file- CMP messages MAY be transferred between PKI entities using file-
system-based mechanisms, for instance when an off-line end entity or system-based mechanisms, for instance when an off-line end entity or
a PKI management entity performs delayed enrollment. Each file MUST a PKI management entity performs delayed enrollment. Each file MUST
contain the ASN.1 DER encoding of one CMP message only. There 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 be no extraneous header or trailer information in the file. The file
type extensions ".PKI" SHOULD be used. type extensions ".PKI" SHOULD be used.
6.5.2. Other asynchronous transport protocols 6.4.2. Other asynchronous transport protocols
Other asynchronous transport protocols, e.g., email or website Other asynchronous transport protocols, e.g., email or website
up-/download, MAY transfer CMP messages between PKI entities. A MIME up-/download, MAY transfer CMP messages between PKI entities. A MIME
wrapping is defined for those environments that are MIME native. The wrapping is defined for those environments that are MIME native. The
MIME wrapping in this section is specified in [RFC8551], section 3.1. MIME wrapping in this section is specified in [RFC8551], section 3.1.
The ASN.1 DER encoding of the CMP messages MUST be transferred using The ASN.1 DER encoding of the CMP messages MUST be transferred using
the "application/pkixcmp" content type and base64-encoded content- the "application/pkixcmp" content type and base64-encoded content-
transfer-encoding as specified in [RFC2510], section 5.3. A filename transfer-encoding as specified in [RFC2510], section 5.3. A filename
MUST be included either in a content-type or a content-disposition MUST be included either in a content-type or a content-disposition
statement. The extension for the file MUST be ".PKI". statement. The extension for the file MUST be ".PKI".
6.6. CoAP transport 6.5. CoAP transport
In constrained environments where no HTTP transport is desired or In constrained environments where no HTTP transport is desired or
possible, CoAP [RFC7252] as specified in possible, CoAP [RFC7252] as specified in
[I-D.msahni-tbd-cmpv2-coap-transport] MAY be used instead. [I-D.msahni-tbd-cmpv2-coap-transport] MAY be used instead.
6.7. Piggybacking on other reliable transport 6.6. 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.
7. IANA Considerations 7. 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. >
8. Security Considerations 8. Security Considerations
< TBD: Add any security considerations > < TBD: Add any security considerations >
9. 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.
10. References 10. References
10.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-02 (work in progress), July 2020. updates-05 (work in progress), September 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 15 skipping to change at page 73, line 15
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5958, August 2010,
DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5958>.
<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>.
10.2. Informative References 10.2. Informative References
[ETSI-3GPP] [ETSI-TS133310]
3GPP, "TS33.310; Network Domain Security (NDS); ETSI, "TS 133 310; Network Domain Security (NDS);
Authentication Framework (AF); Release 16; V16.1.0", Authentication Framework (AF); Release 16; V16.4.0",
December 2018, August 2020, <https://www.etsi.org/deliver/
<http://www.3gpp.org/ftp/Specs/archive/33_series/33.310/>. etsi_ts/133300_133399/133310/>.
[I-D.msahni-tbd-cmpv2-coap-transport] [I-D.msahni-tbd-cmpv2-coap-transport]
Sahni, M., "CoAP Transport for CMPV2", draft-msahni-tbd- Sahni, M., "CoAP Transport for CMPV2", draft-msahni-tbd-
cmpv2-coap-transport-00 (work in progress), June 2020. cmpv2-coap-transport-00 (work in progress), June 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>.
skipping to change at page 72, line 14 skipping to change at page 75, line 5
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management [UNISIG-Subset137]
UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management
FFFIS; V1.0.0", December 2015, FFFIS; V1.0.0", December 2015,
<https://www.era.europa.eu/filebrowser/download/542_en>. <https://www.era.europa.eu/filebrowser/download/542_en>.
Appendix A. ASN.1 Syntax Appendix A. Example for CertReqTemplate
id-it-caCerts OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx}
CaCerts ::= SEQUENCE OF CMPCertificate
}
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,
}
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 < TBD: This Appendix must be updated to reflect the change from using
rsaKeyLen to controles. >
This Section provides a concrete example for the content of an This Section provides a concrete example for the content of an
infoValue used of type id-it-certReqTemplate as described in infoValue used of type id-it-certReqTemplate as described in
Section 4.4.4. Section 4.4.4.
Suppose the server requires that the certTemplate contains the issuer 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 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 a common name to be filled in by the EE and two organizational unit
fields with given values "myDept" and "myGroup", the publicKey field fields with given values "myDept" and "myGroup", the publicKey field
with an RSA public key of length 2048, the subjectAltName extension with an RSA public key of length 2048, the subjectAltName extension
skipping to change at page 74, line 26 skipping to change at page 76, line 46
OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates { OCTET STRING, encapsulates {
SEQUENCE {} SEQUENCE {}
} }
} }
} }
} }
INTEGER 2048 INTEGER 2048
} }
Appendix C. History of changes Appendix B. History of changes
Note: This section will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
From version 02 -> 03:
o Updated the interoperability with [UNISIG-Subset137] in
Section 1.4.
o Changed Section 2.3 to a tabular layout to enhanced readability
o Added a ToDo to section 3.1 on aligning with the CMP Algorithms
draft that will be set up as decided in IETF 108
o Updated section 4.1.6 to add the AsymmetricKey Package structure
to transport a newly generated private key as decided in IETF 108
o Added a ToDo to section 4.1.7 on required review of the nonce
handling in case an offline LRA responds and not forwards the
pollReq messages
o Updated Section 4 due to the definition of the new ITAV OIDs in
CMP Updates
o Updated Section 4.4.4 to utilize controls instead of rsaKeyLen
(see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen")
o Deleted the section on definition and discovery of HTTP URIs and
copied the text to the HTTP transport section and to CMP Updates
section 3.2
o Added some explanation to Section 5.1.2 and Section 5.1.3 on using
nested messages when a protection by the RA is required.
o Deleted the section on HTTP URI definition and discovery as some
content was moved to CMP Updates. The rest of the content was
moved back to the HTTP transport section
o Deleted the ASN.1 module after moving the new OIDs id-it-caCerts,
id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates
o Minor changes in wording and addition of some open ToDos
From version 01 -> 02: From version 01 -> 02:
o Extend Section 1.4 with regard to conflicts with UNISIG Subset- o Extend Section 1.4 with regard to conflicts with UNISIG Subset-
137. 137.
o Minor clarifications on extraCerts in Section 3.3 and o Minor clarifications on extraCerts in Section 3.3 and
Section 4.1.1. Section 4.1.1.
o Complete specification of requesting a certificate from a trusted o Complete specification of requesting a certificate from a trusted
PKI with signature protection in Section 4.1.2. PKI with signature protection in Section 4.1.2.
skipping to change at page 75, line 19 skipping to change at page 78, line 30
rsaKeyLen as a single integer value in Section 4.4.4 as discussed rsaKeyLen as a single integer value in Section 4.4.4 as discussed
on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.4.4") profile-01, section 5.4.4")
o Deleted Sections "Get certificate management configuration" and o Deleted Sections "Get certificate management configuration" and
"Get enrollment voucher" as decided at IETF 107 "Get enrollment voucher" as decided at IETF 107
o Complete specification of adding an additional protection by an o Complete specification of adding an additional protection by an
PKI management entity in Section 5.1.3. PKI management entity in Section 5.1.3.
o Added Section 6.1 and extended Section 6.2 on definition and o Added a section on HTTP URI definition and discovery and extended
discovery of supported HTTP URIs and content types, add a path for Section 6.1 on definition and discovery of supported HTTP URIs and
nested messages as specified in Section 5.1.3 and delete the paths content types, add a path for nested messages as specified in
for /getCertMgtConfig and /getVoucher Section 5.1.3 and delete the paths for /getCertMgtConfig and
/getVoucher
o Changed Section 6.5 to address offline transport and added more o Changed Section 6.4 to address offline transport and added more
detailed specification file-based transport of CMP detailed specification file-based transport of CMP
o Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 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 for CMPV2" in Section 6.5; thanks to Mohit supporting the effort
to ease utilization of CMP to ease utilization of CMP
o Moved the change history to the Appendix o Moved the change history to the Appendix
o Minor changes in wording o Minor changes in wording
From version 00 -> 01: From version 00 -> 01:
o Harmonize terminology with CMP [RFC4210], e.g., o Harmonize terminology with CMP [RFC4210], e.g.,
skipping to change at page 76, line 14 skipping to change at page 79, line 26
From version 02 -> 03: From version 02 -> 03:
o Added a short summary of [RFC4210] Appendix D and E in o Added a short summary of [RFC4210] Appendix D and E in
Section 1.3. Section 1.3.
o Clarified some references to different sections and added some o Clarified some references to different sections and added some
clarification in response to feedback from Michael Richardson and clarification in response to feedback from Michael Richardson and
Tomas Gustavsson. Tomas Gustavsson.
o Added an additional label to the operational path to address o Added an additional label to the operational path to address
multiple CAs or certificate profiles in Section 6.2. multiple CAs or certificate profiles in Section 6.1.
From version 01 -> 02: From version 01 -> 02:
o Added some clarification on the key management techniques for o Added some clarification on the key management techniques for
protection of centrally generated keys in Section 4.1.6. protection of centrally generated keys in Section 4.1.6.
o Added some clarifications on the certificates for root CA o Added some clarifications on the certificates for root CA
certificate update in Section 4.4.3. certificate update in Section 4.4.3.
o Added a section to specify the usage of nested messages for RAs to o Added a section to specify the usage of nested messages for RAs to
add an additional protection for further discussion, see add an additional protection for further discussion, see
Section 5.1.3. Section 5.1.3.
o Added a table containing endpoints for HTTP transport in o Added a table containing endpoints for HTTP transport in
Section 6.2 to simplify addressing PKI management entities. Section 6.1 to simplify addressing PKI management entities.
o Added some ToDos resulting from discussion with Tomas Gustavsson. o Added some ToDos resulting from discussion with Tomas Gustavsson.
o Minor clarifications and changes in wording. o Minor clarifications and changes in wording.
From version 00 -> 01: From version 00 -> 01:
o Added a section to specify the enrollment with an already trusted o Added a section to specify the enrollment with an already trusted
PKI for further discussion, see Section 4.1.2. PKI for further discussion, see Section 4.1.2.
 End of changes. 134 change blocks. 
446 lines changed or deleted 563 lines changed or added

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