draft-ietf-lamps-lightweight-cmp-profile-03.txt   draft-ietf-lamps-lightweight-cmp-profile-04.txt 
LAMPS Working Group H. Brockhaus LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft S. Fries Internet-Draft S. Fries
Intended status: Standards Track D. von Oheimb Intended status: Standards Track D. von Oheimb
Expires: April 5, 2021 Siemens Expires: May 6, 2021 Siemens
October 2, 2020 November 2, 2020
Lightweight CMP Profile Lightweight CMP Profile
draft-ietf-lamps-lightweight-cmp-profile-03 draft-ietf-lamps-lightweight-cmp-profile-04
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 use cases relevant for managing certificates of devices in many
industrial and IoT scenarios. To limit the overhead of certificate industrial and IoT scenarios. To limit the overhead of certificate
management for more constrained devices only the most crucial types management for more constrained devices only the most crucial types
of operations are specified as mandatory. To foster interoperability of operations are specified as mandatory. To foster interoperability
in more complex scenarios, other types of operations are specified as in more complex scenarios, other types of operations are specified as
recommended or optional. recommended or optional.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 5, 2021. This Internet-Draft will expire on May 6, 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 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . 6
1.4. Compatibility with existing CMP profiles . . . . . . . . 7 1.4. Compatibility with existing CMP profiles . . . . . . . . 8
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 . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . 13
2.3. Supported PKI management operations . . . . . . . . . . . 13 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 . . . . . . . . 14 2.3.2. Recommended PKI management operations . . . . . . . . 14
2.3.3. Optional PKI management operations . . . . . . . . . 14 2.3.3. Optional PKI management operations . . . . . . . . . 15
2.4. CMP message transport . . . . . . . . . . . . . . . . . . 15 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 16
3. Generic parts of the PKI message . . . . . . . . . . . . . . 16 3. Generic parts of the PKI message . . . . . . . . . . . . . . 17
3.1. General description of the CMP message header . . . . . . 17 3.1. General description of the CMP message header . . . . . . 18
3.2. General description of the CMP message protection . . . . 19 3.2. General description of the CMP message protection . . . . 20
3.3. General description of CMP message extraCerts . . . . . . 20 3.3. General description of CMP message extraCerts . . . . . . 21
4. End Entity focused PKI management operations . . . . . . . . 20 4. End Entity focused PKI management operations . . . . . . . . 21
4.1. Requesting a new certificate from a PKI . . . . . . . . . 21 4.1. Requesting a new certificate from a PKI . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . 22 protection . . . . . . . . . . . . . . . . . . . . . 23
4.1.2. Request a certificate from a trusted PKI with 4.1.2. Request a certificate from a trusted PKI with
signature protection . . . . . . . . . . . . . . . . 28 signature protection . . . . . . . . . . . . . . . . 29
4.1.3. Update an existing certificate with signature 4.1.3. Update an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 29 protection . . . . . . . . . . . . . . . . . . . . . 30
4.1.4. Request a certificate from a PKI with MAC protection 30 4.1.4. Request a certificate from a PKI with MAC protection 31
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 . . . . . . . . . . . . . . . . . . . . . . . 32 request . . . . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . . . . . . . . . . 34 entity . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.6.1. Using key agreement key management technique . . 40 4.1.6.1. Using key agreement key management technique . . 41
4.1.6.2. Using key transport key management technique . . 41 4.1.6.2. Using key transport key management technique . . 42
4.1.6.3. Using password-based key management technique . . 42 4.1.6.3. Using password-based key management technique . . 43
4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 43 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 44
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48
4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50
4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52
4.4.1. General message and response . . . . . . . . . . . . 53 4.4.1. Get CA certificates . . . . . . . . . . . . . . . . . 54
4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 54 4.4.2. Get root CA certificate update . . . . . . . . . . . 55
4.4.3. Get root CA certificate update . . . . . . . . . . . 55 4.4.3. Get certificate request template . . . . . . . . . . 56
4.4.4. Get certificate request template . . . . . . . . . . 56
5. LRA and RA focused PKI management operations . . . . . . . . 58 5. LRA and RA focused PKI management operations . . . . . . . . 58
5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59
5.1.1. Not changing protection . . . . . . . . . . . . . . . 61 5.1.1. Not changing protection . . . . . . . . . . . . . . . 61
5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61
5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62
5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 62 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 62
5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63
5.1.3.1. Handling a single PKI management message . . . . 64 5.1.3.1. Handling a single PKI management message . . . . 64
5.1.3.2. Handling a batch of PKI management messages . . . 64 5.1.3.2. Handling a batch of PKI management messages . . . 64
5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 65 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 65
skipping to change at page 3, line 38 skipping to change at page 3, line 37
6.4.2. Other asynchronous transport protocols . . . . . . . 71 6.4.2. Other asynchronous transport protocols . . . . . . . 71
6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71 6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71
6.6. Piggybacking on other reliable transport . . . . . . . . 71 6.6. Piggybacking on other reliable transport . . . . . . . . 71
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
8. Security Considerations . . . . . . . . . . . . . . . . . . . 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 72
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
10.1. Normative References . . . . . . . . . . . . . . . . . . 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 72
10.2. Informative References . . . . . . . . . . . . . . . . . 73 10.2. Informative References . . . . . . . . . . . . . . . . . 73
Appendix A. Example for CertReqTemplate . . . . . . . . . . . . 75 Appendix A. Example for CertReqTemplate . . . . . . . . . . . . 75
Appendix B. History of changes . . . . . . . . . . . . . . . . . 76 Appendix B. History of changes . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
1. Introduction 1. Introduction
!!! The change history was moved to Appendix B !!! [RFC Editor: please delete]:!!! The change history was moved to
Appendix B !!!
[RFC Editor: please delete]: The labels 'RFC-CMP-Alg' and 'RFC-CRMF-
Alg' in ASN.1 Syntax needs to be replaced with the RFC numbers of CMP
Algorithms [I-D.ietf-lamps-cmp-algorithms] and CRMF Algorithm
Requirements Update [I-D.housley-lamps-crmf-update-algs], when
available.
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 5, line 33 skipping to change at page 5, line 41
Due to increasing security in operational networks as well as Due to increasing security in operational networks as well as
availability requirements, especially on critical infrastructures and availability requirements, especially on critical infrastructures and
systems with a high volume of certificates, a state-of-the-art systems with a high volume of certificates, a state-of-the-art
certificate management must be constantly available and cost- certificate management must be constantly available and cost-
efficient, which calls for high automation and reliability. The NIST efficient, which calls for high automation and reliability. The NIST
Cyber Security Framework [NIST-CSFW] also refers to proper processes Cyber Security Framework [NIST-CSFW] also refers to proper processes
for issuance, management, verification, revocation, and audit for for issuance, management, verification, revocation, and audit for
authorized devices, users and processes involving identity and authorized devices, users and processes involving identity and
credential management. Such PKI operation according to commonly credential management. Such PKI operation according to commonly
accepted best practices is also required in IEC 62443-3-3 accepted best practices is also required in IEC 62443-3-3
[IEC62443-3-3] for security level 2 up to security level 4. [IEC62443-3-3] for security level 2 and higher.
Further challenges in many industrial systems are network Further challenges in many industrial systems are network
segmentation and asynchronous communication, where PKI operation is segmentation and asynchronous communication, where PKI operation is
often not deployed on-site but in a more protected environment of a often not deployed on-site but in a more protected environment of a
data center or trust center. Certificate management must be able to data center or trust center. Certificate management must be able to
cope with such network architectures. CMP offers the required cope with such network architectures. CMP offers the required
flexibility and functionality, namely self-contained messages, flexibility and functionality, namely self-contained messages,
efficient polling, and support for asynchronous message transfer with efficient polling, and support for asynchronous message transfer with
end-to-end security. end-to-end security.
1.3. Existing CMP profiles 1.3. Existing CMP profiles
As already stated, CMP contains profiles with mandatory and optional As already stated, CMP contains profiles with mandatory and optional
transactions in the Appendixes D and E of [RFC4210]. Those profiles transactions in the Appendixes D and E of [RFC4210]. Those profiles
focus on management of human user certificates and do only partly focus on management of human user certificates and do only partly
address the specific needs for certificate management automation for address the specific needs for certificate management automation for
unattended machine or application-oriented end entities. unattended machine or application-oriented end entities.
[RFC4210] specifies in Appendix D the following mandatory PKI [RFC4210] specifies in Appendix D the following mandatory PKI
management operations (all require support of, in the meantime management operations (all require support of algorithms was updated
outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may by CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]; all operations may
enroll up to two certificates, one for a locally generated and enroll up to two certificates, one for a locally generated and
another optional one for a centrally generated key pair; all require another optional one for a centrally generated key pair; all require
use of certConf/pkiConf messages for confirmation): use of certConf/pkiConf messages for confirmation):
o Initial registration/certification; an (uninitialized) end entity o Initial registration/certification; an (uninitialized) end entity
requests a (first) certificate from a CA using shared secret based requests a (first) certificate from a CA using shared secret based
message authentication. The content is similar to the PKI message authentication. The content is similar to the PKI
management operation specified in Section 4.1.4 of this document. management operation specified in Section 4.1.4 of this document.
o Certificate request; an (initialized) end entity requests another o Certificate request; an (initialized) end entity requests another
skipping to change at page 6, line 33 skipping to change at page 6, line 42
from a CA (to update the key pair and/or corresponding certificate from a CA (to update the key pair and/or corresponding certificate
that it already possesses) using signature or shared secret based that it already possesses) using signature or shared secret based
message authentication. The content is similar to the PKI message authentication. The content is similar to the PKI
management operation specified in Section 4.1.3 of this document. management operation specified in Section 4.1.3 of this document.
Due to the two certificates that may be enrolled and the shared Due to the two certificates that may be enrolled and the shared
secret based authentication, these PKI management operations focus secret based authentication, these PKI management operations focus
more on the enrollment of human users at a PKI. more on the enrollment of human users at a PKI.
[RFC4210] specifies in Appendix E the following optional PKI [RFC4210] specifies in Appendix E the following optional PKI
management operations (all require support of, in the meantime management operations (all require support of algorithms was updated
outdated, algorithms, e.g., SHA-1 and 3-DES): by CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]):
o Root CA key update; a root CA updates its key pair and produces a o Root CA key update; a root CA updates its key pair and produces a
CA key update announcement message that can be made available (via CA key update announcement message that can be made available (via
some transport mechanism) to the relevant end entities. This some transport mechanism) to the relevant end entities. This
operation only supports a push and no pull model. The content is operation only supports a push and no pull model. The content is
similar to the PKI management operation specified in Section 4.4.3 similar to the PKI management operation specified in Section 4.4.2
of this document. of this document.
o Information request/response; an end entity sends a general o Information request/response; an end entity sends a general
message to the PKI requesting details that will be required for message to the PKI requesting details that will be required for
later PKI management operations. The content is similar to the later PKI management operations. The content is similar to the
PKI management operation specified in Section 4.4.4 of this PKI management operation specified in Section 4.4.3 of this
document. document.
o Cross-certification request/response (1-way); creation of a single o Cross-certification request/response (1-way); creation of a single
cross-certificate (i.e., not two at once). The requesting CA MAY cross-certificate (i.e., not two at once). The requesting CA MAY
choose who is responsible for publication of the cross-certificate choose who is responsible for publication of the cross-certificate
created by the responding CA through use of the PKIPublicationInfo created by the responding CA through use of the PKIPublicationInfo
control. control.
o In-band initialization using external identity certificate (this o In-band initialization using external identity certificate (this
PKI management operation may also enroll up to two certificates PKI management operation may also enroll up to two certificates
skipping to change at page 8, line 48 skipping to change at page 9, line 11
automatic certificate revocation by the CA in case of TCP automatic certificate revocation by the CA in case of TCP
disconnection during certificate distribution, this conflicts with disconnection during certificate distribution, this conflicts with
this document. this document.
o As of RFC 4210 [RFC4210] the messageTime is required to be o As of RFC 4210 [RFC4210] the messageTime is required to be
Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137 Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137
Table 5 [UNISIG-Subset137] explicitly states that the messageTime Table 5 [UNISIG-Subset137] explicitly states that the messageTime
in required to be 'UTC time', it is not clear if this means a 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 coding as UTCTime or generalizedTime and if other time zones than
Greenwich Mean Time shall be allowed. Therefore, UNISIG Greenwich Mean Time shall be allowed. Therefore, UNISIG
Subset-137 [UNISIG-Subset137] conflicts with RFC 4210 [RFC4210]. Subset-137 [UNISIG-Subset137] may conflict with RFC 4210
Both time formats are described in RFC 5280 Section 4.1.2.5 [RFC4210]. Both time formats are described in RFC 5280
[RFC5280]. Section 4.1.2.5 [RFC5280].
o This profile requires usage of the same type of protection for all o This profile requires usage of the same type of protection for all
messages of one PKI management operation. This means, in case the messages of one PKI management operation. This means, in case the
request message is MAC protected, also the response, certConf, and request message is MAC protected, also the response, certConf, and
pkiConf messages have a MAC-based protection. As UNISIG pkiConf messages have a MAC-based protection. As UNISIG
Subset-137 Table 5 [UNISIG-Subset137] specifies for the first Subset-137 Table 5 [UNISIG-Subset137] specifies for the first
certificate request MAC protection for all messages send by the certificate request MAC protection for all messages send by the
client and signature protection for all messages send by the client and signature protection for all messages send by the
server, this conflicts with this document. server, this conflicts with this document.
skipping to change at page 9, line 28 skipping to change at page 9, line 38
under the root CA that is to be transported in the caPubs field, under the root CA that is to be transported in the caPubs field,
this is not a secure delivery of this root CA certificate. 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
that can be implemented on more constrained devices. On the side of implementation. This means that the number of PKI management
the central PKI management entities the profile accepts higher operations implementations must support are reduced to a reasonable
resources needed. minimum to support most typical certificate management use cases in
industrial machine-to-machine environments. On the side EE side only
limited resources are expected, as on the of the PKI management
entities the profile accepts higher resources needed.
For the sake of robustness and preservation of security properties For the sake of robustness and preservation of security properties
implementations should, as far as security is not affected, adhere to implementations should, as far as security is not affected, adhere to
Postel's law: "Be conservative in what you do, be liberal in what you Postel's law: "Be conservative in what you do, be liberal in what you
accept from others" (often reworded as: "Be conservative in what you accept from others" (often reworded as: "Be conservative in what you
send, be liberal in what you accept"). send, be liberal in what you accept").
When in Section 3, Section 4, and Section 5 a field of the ASN.1 When in Section 3, Section 4, and Section 5 a field of the ASN.1
syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not
explicitly specified, it SHOULD not be used by the sending entity. explicitly specified, it SHOULD not be used by the sending entity.
skipping to change at page 10, line 30 skipping to change at page 10, line 45
Section 6 outlines different mechanisms for CMP message transfer, Section 6 outlines different mechanisms for CMP message transfer,
namely http-based transfer as already specified in [RFC6712], using namely http-based transfer as already specified in [RFC6712], using
an additional TLS layer, or offline file-based transport. CoAP an additional TLS layer, or offline file-based transport. CoAP
[RFC7252] and piggybacking CMP messages on other protocols is out of [RFC7252] and piggybacking CMP messages on other protocols is out of
scope and left for further documents. scope and left for further documents.
1.7. Convention and Terminology 1.7. Convention and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
In this document, these words will appear with that interpretation here.
only when in ALL CAPS. Lower case use of these words are not to be
interpreted as carrying significance described in RFC 2119.
Technical terminology is used in conformance with RFC 4210 [RFC4210], Technical terminology is used in conformance with RFC 4210 [RFC4210],
RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR
[IEEE802.1AR]. The following key words are used: [IEEE802.1AR]. The following key words are used:
CA: Certification authority, which issues certificates. CA: Certification authority, which issues certificates.
RA: Registration authority, an optional system component to which a RA: Registration authority, an optional system component to which a
CA delegates certificate management functions such as CA delegates certificate management functions such as
authorization checks. authorization checks.
skipping to change at page 11, line 26 skipping to change at page 11, line 39
PKI management entity: All central PKI entities like LRA, RA and PKI management entity: All central PKI entities like LRA, RA and
CA. CA.
PKI entity: EEs and PKI management entities PKI entity: EEs and PKI management entities
2. Architecture and use cases 2. Architecture and use cases
2.1. Solution architecture 2.1. Solution architecture
Typically, a machine EE will be equipped with a manufacturer issued In order to facilitate secure automatic certificate enrollment if the
device hosting an EE is equipped with a manufacturer issued
certificate during production. Such a manufacturer issued certificate during production. Such a manufacturer issued
certificate is installed during production to identify the device certificate is installed during production to identify the device
throughout its lifetime. This manufacturer certificate can be used throughout its lifetime. This manufacturer certificate can be used
to protect the initial enrollment of operational certificates after to protect the initial enrollment of operational certificates after
installation of the EE in a plant or industrial network. An installation of the EE on site in its operational environment. An
operational certificate is issued by the owner or operator of the operational certificate is issued by the owner or operator of the
device to identify the device during operation, e.g., within a device to identify the device during operation, e.g., within a
security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR
[IEEE802.1AR] a manufacturer certificate is called IDevID certificate [IEEE802.1AR] a manufacturer certificate is called IDevID certificate
and an operational certificate is called LDevID certificate. and an operational certificate is called LDevID certificate.
All certificate management transactions specified in this document All certificate management transactions specified in this document
are initiated by the EE. The EE creates a CMP request message, are initiated by the EE. The EE creates a CMP request message,
protects it using its manufacturer or operational certificate, if protects it using some asymmetric or symmetric credential, as far as
available, and sends it to its locally reachable PKI component. This available, and sends it to its locally reachable PKI component. This
PKI component may be an LRA, RA, or the CA, which checks the request, PKI component may be an LRA, RA, or the CA, which checks the request,
responds to it itself, or forwards the request upstream to the next responds to it itself, or forwards the request upstream to the next
PKI component. In case an (L)RA changes the CMP request message PKI component. In case an (L)RA changes the CMP request message
header or body or wants to prove a successful verification or header or body or wants to prove a successful verification or
authorization, it can apply a protection of its own. Especially the authorization, it can apply a protection of its own. Especially the
communication between an LRA and RA can be performed synchronously or communication between an LRA and RA can be performed synchronously or
asynchronously. Synchronous communication describes a timely asynchronously. Synchronous communication describes a timely
uninterrupted communication between two communication partners, while uninterrupted communication between two communication partners, while
asynchronous communication is not performed in a timely consistent asynchronous communication is not performed in a timely consistent
skipping to change at page 12, line 22 skipping to change at page 12, line 37
+----connection----+------connection------+----connection----+ +----connection----+------connection------+----connection----+
on site at operators service partner on site at operators service partner
+----------plant---------+-----backend services-----+-trust center-+ +----------plant---------+-----backend services-----+-trust center-+
Figure 1: Certificate management on site Figure 1: Certificate management on site
In operation environments a layered LRA-RA-CA architecture can be In operation environments a layered LRA-RA-CA architecture can be
deployed, e.g., with LRAs bundling requests from multiple EEs at deployed, e.g., with LRAs bundling requests from multiple EEs at
dedicated locations and one (or more than one) central RA aggregating dedicated locations and one (or more than one) central RA aggregating
the requests from multiple LRAs. Every (L)RA in this scenario will the requests from multiple LRAs. Every (L)RA in this scenario
have its own dedicated certificate containing an extended key usage typically has a shared key for password-based protection or a CMP
as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] and private signer key and certificate containing an extended key usage as
key allowing it to protect CMP messages it processes (CMP signing specified in CMP Updates [I-D.ietf-lamps-cmp-updates] allowing it to
key/certificate). The figure above shows an architecture using one protect CMP messages it processes. The figure above shows an
LRA and one RA. It is also possible to have only an RA or multiple architecture using one LRA and one RA. It is also possible to have
LRAs and/or RAs. Depending on the network infrastructure, the only an RA or multiple LRAs and/or RAs. Depending on the network
communication between different PKI management entities may be infrastructure, the communication between different PKI management
synchronous online communication, delayed asynchronous communication, entities may be synchronous online communication, delayed
or even offline file transfer. asynchronous communication, or even offline file transfer.
This profile focusses on specifying the pull model, where the EE This profile focusses on specifying the pull model, where the EE
always requests a specific PKI management operation. CMP response always requests a specific PKI management operation.
messages, especially in case of central key generation, as described
in Section 4.1.6, could also be used proactively to implement the Note: CMP response messages, especially in case of central key
push model towards the EE. generation, as described in Section 4.1.6, could also be used
proactively to implement the push model towards the EE.
Third-party CAs typically implement different variants of CMP or even Third-party CAs typically implement different variants of CMP or even
use proprietary interfaces for certificate management. Therefore, use proprietary interfaces for certificate management. Therefore,
the LRA or the RA may need to adapt the exchanged CMP messages to the the LRA or the RA may need to adapt the exchanged CMP messages to the
flavor of communication required by the CA. flavor of communication required by the CA.
2.2. Basic generic CMP message content 2.2. Basic generic CMP message content
Section 3 specifies the generic parts of the CMP messages as used Section 3 specifies the generic parts of the CMP messages as used
later in Section 4 and Section 5. later in Section 4 and Section 5.
skipping to change at page 13, line 18 skipping to change at page 13, line 36
Following the outlined scope from Section 1.5, this section gives a Following the outlined scope from Section 1.5, this section gives a
brief overview of the PKI management operations specified in brief overview of the PKI management operations specified in
Section 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. This minimal set of
to the most crucial types of operations. operations may be helpful for keeping development effort low and for
use in memory-constrained devices.
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
| PKI management operations | Section | | PKI management operations | Section |
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
| Request a certificate from a new PKI with signature | Section | | Request a certificate from a new PKI with signature | Section |
| protection | 4.1.1 | | protection | 4.1.1 |
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
| Request to update an existing certificate with | Section | | Request to update an existing certificate with | Section |
| signature protection | 4.1.3 | | signature protection | 4.1.3 |
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
skipping to change at page 14, line 8 skipping to change at page 14, line 41
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
| Error reporting | Section | | Error reporting | Section |
| | 5.3 | | | 5.3 |
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
Table 2: Mandatory LRA and RA focused PKI management operations 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 beneficial for
environments with more specific boundary conditions. environments with more specific boundary conditions.
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
| PKI management operations | Section | | PKI management operations | Section |
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
| Request a certificate from a PKI with MAC protection | Section | | Request a certificate from a PKI with MAC protection | Section |
| | 4.1.4 | | | 4.1.4 |
+--------------------------------------------------------+----------+ +--------------------------------------------------------+----------+
| Revoke an own certificate | Section | | Revoke an own certificate | Section |
| | 4.2 | | | 4.2 |
skipping to change at page 18, line 30 skipping to change at page 19, line 30
-- sender field of the previous message in this transaction -- sender field of the previous message in this transaction
messageTime RECOMMENDED messageTime RECOMMENDED
-- MUST be the time at which the message was produced, if -- MUST be the time at which the message was produced, if
-- present -- present
protectionAlg REQUIRED protectionAlg REQUIRED
-- MUST be the algorithm identifier of the signature algorithm or -- MUST be the algorithm identifier of the signature algorithm or
-- id-PasswordBasedMac algorithm used for calculation of the -- id-PasswordBasedMac algorithm used for calculation of the
-- protection bits -- protection bits
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPublicKeyInfo field of the signer's certificate -- subjectPublicKeyInfo field of the signer's certificate
-- The hash algorithm used SHOULD be SHA-256 -- For more details on cryptographic algorithms to use,
-- see RFC-CMP-Alg
algorithm REQUIRED algorithm REQUIRED
-- MUST be the OID of the signature algorithm, like -- MUST be the OID of the signature algorithm, like
-- sha256WithRSAEncryption or ecdsa-with-SHA256, or -- sha256WithRSAEncryption or ecdsa-with-SHA256, or
-- id-PasswordBasedMac -- id-PasswordBasedMac
senderKID RECOMMENDED senderKID RECOMMENDED
-- MUST be the SubjectKeyIdentifier, if available, of the -- MUST be the SubjectKeyIdentifier, if available, of the
-- protection certificate -- protection certificate
transactionID REQUIRED transactionID REQUIRED
-- If this is the first message of a transaction: -- If this is the first message of a transaction:
-- MUST be 128 bits of random data for the start of a -- MUST be 128 bits of random data for the start of a
skipping to change at page 19, line 20 skipping to change at page 20, line 21
-- message -- message
-- See [RFC4210] Section 5.1.1.1. -- 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 20, line 40 skipping to change at page 21, line 36
prepared to handle potentially additional and arbitrary orderings of prepared to handle potentially additional and arbitrary orderings of
the certificates, except that the protection certificate is the first the certificates, except that the protection certificate is the first
certificate in extraCerts. certificate in extraCerts.
4. End Entity focused PKI management operations 4. End Entity focused PKI management operations
This chapter focuses on the communication of the EE and the first PKI This chapter focuses on the communication of the EE and the first PKI
management entities it talks to. Depending on the network and PKI management entities it talks to. Depending on the network and PKI
solution, this will either be the LRA, the RA or the CA. solution, this will either be the LRA, the RA or the CA.
Profiles of the Certificate Management Protocol (CMP) [RFC4210] The PKI management operations specified in this section cover the
handled in this section cover the following PKI management following:
operations:
o Requesting a certificate from a PKI with variations like initial o Requesting a certificate from a PKI with variations like initial
requests and updating, central key generation and different requests and updating, central key generation and different
protection means protection means
o Revocation of a certificate o Revocation of a certificate
o General messages for further support functions o General messages for further support functions
These operations mainly specify the message body of the CMP messages These operations mainly specify the message body of the CMP messages
and utilize the specification of the message header, protection and and utilize the specification of the message header, protection and
extraCerts as specified in Section 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.
skipping to change at page 21, line 14 skipping to change at page 22, line 9
These operations mainly specify the message body of the CMP messages These operations mainly specify the message body of the CMP messages
and utilize the specification of the message header, protection and and utilize the specification of the message header, protection and
extraCerts as specified in Section 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 algorithms
Appendix D.2 of [RFC4210], [ETSI-TS133310], and [UNISIG-Subset137] implementations must or should support like [ETSI-TS133310] and
do. Using the message sequences described here require agreement [UNISIG-Subset137] do. Using the message sequences described here
upon the algorithms to support and thus the algorithm identifiers for require agreement upon the algorithms to support. A set of
the specific target environment. algorithms and the respective identifier to use with CMP is available
in CMP Algorithms [draft-ietf-lamps-cmp-algorithms].
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 21, line 50 skipping to change at page 22, line 46
entity then MUST send confirmation back, closing the transaction. entity then MUST send confirmation back, closing the transaction.
The message sequences in this section allow the EE to request The message sequences in this section allow the EE to request
certification of a locally generated public-private key pair. For certification of a locally generated public-private key pair. For
requirements about proper random number and key generation please requirements about proper random number and key generation please
refer to [RFC4086]. The EE MUST provide a signature-based proof-of- refer to [RFC4086]. The EE MUST provide a signature-based proof-of-
possession of the private key associated with the public key possession of the private key associated with the public key
contained in the certificate request as defined by [RFC4211] section contained in the certificate request as defined by [RFC4211] section
4.1 case 3. To this end it is assumed that the private key can 4.1 case 3. To this end it is assumed that the private key can
technically be used as signing key. The most commonly used technically be used as signing key. The most commonly used
algorithms are RSA and ECDSA, which can technically be used for algorithms currentlyare RSA and ECDSA, which can technically be used
signature calculation regardless of potentially intended restrictions for signature calculation regardless of potentially intended
of the key usage. restrictions of the key usage.
The requesting EE provides the binding of the proof-of-possession to The requesting EE provides the binding of the proof-of-possession to
its identity by signature-based or MAC-based protection of the CMP its identity by signature-based or MAC-based protection of the CMP
request message containing that POPO. The PKI management entity request message containing that POPO. The PKI management entity
needs to verify whether this EE is authorized to obtain a certificate needs to verify whether this EE is authorized to obtain a certificate
with the requested subject and other fields and extensions. with the requested subject and other fields and extensions.
Especially when removing the protection provided by the EE and Especially when removing the protection provided by the EE and
applying a new protection, the PKI management entity MUST verify in applying a new protection, the PKI management entity MUST verify in
particular the included proof-of-possession self-signature of the particular the included proof-of-possession self-signature of the
certTemplate using the public key of the requested certificate and certTemplate using the public key of the requested certificate and
skipping to change at page 23, line 5 skipping to change at page 23, line 47
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 CertReqTemplate response message, voucher, the issuer field from a CertReqTemplate response message,
or other configuration means. If the EE does not know the name of or other configuration means. If the EE does not know the name of
the CA, the PKI management entity MUST know where to route this the CA, the PKI management entity MUST know where to route these
request to. requests 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] The general message flow for this PKI management operation is like
Appendix E.7. that given in [RFC4210] Appendix E.7.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
1 format ir 1 format ir
2 -> ir -> 2 -> ir ->
3 handle, re-protect or 3 handle, re-protect or
forward ir forward ir
4 format or receive ip 4 format or receive ip
5 possibly grant implicit 5 possibly grant implicit
skipping to change at page 24, line 20 skipping to change at page 25, line 15
implicitConfirm field in the ip. implicitConfirm field in the ip.
If the EE did not request implicit confirmation or the request was If the EE did not request implicit confirmation or the request was
not granted by the PKI management entity the confirmation as follows not granted by the PKI management entity the confirmation as follows
MUST be performed. If the EE successfully receives the certificate MUST be performed. If the EE successfully receives the certificate
and accepts it, the EE MUST send a certConf message, which MUST be and accepts it, the EE MUST send a certConf message, which MUST be
answered by the PKI management entity with a pkiConf message. If the answered by the PKI management entity with a pkiConf message. If the
PKI management entity does not receive the expected certConf message PKI management entity does not receive the expected certConf message
in time it MUST handle this like a rejection by the EE. in time it MUST handle this like a rejection by the EE.
If the certificate request was refused by the CA, the PKI management If the certificate request was rejected by the CA, the PKI management
entity must return an ip message containing the status code entity must return an ip message containing the status code
"rejection" and no certifiedKeyPair field. Such an ip message MUST "rejection" and no certifiedKeyPair field. Such an ip message MUST
NOT be followed by the certConf and pkiConf messages. NOT be followed by the certConf and pkiConf messages and the
transaction MUST be terminated.
Detailed message description: Detailed message description:
Certification Request -- ir Certification Request -- ir
Field Value Field Value
header header
-- As described in section 3.1 -- As described in section 3.1
skipping to change at page 25, line 31 skipping to change at page 26, line 27
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
-- publicKey field of the certTemplate -- publicKey field of the certTemplate
-- The hash algorithm used SHOULD be SHA-256
signature REQUIRED signature REQUIRED
-- MUST be the signature computed over the DER-encoded -- MUST be the signature computed over the DER-encoded
-- certTemplate -- certTemplate
protection REQUIRED protection REQUIRED
-- As described in section 3.2 -- As described in section 3.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 3.3 -- As described in section 3.3
skipping to change at page 26, line 17 skipping to change at page 27, line 13
-- certificate contained in certOrEncCert -- certificate contained in certOrEncCert
response REQUIRED response REQUIRED
-- MUST be exactly one CertResponse -- MUST be exactly one CertResponse
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be set to 0
status REQUIRED status REQUIRED
-- PKIStatusInfo structure MUST be present -- PKIStatusInfo structure MUST be present
status REQUIRED status REQUIRED
-- positive values allowed: "accepted", "grantedWithMods" -- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
-- In case of rejection certConf and pkiConf messages MUST NOT
-- be sent
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, logging or to
-- display in a GUI -- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MUST be present if status is "rejection" and in this case -- MUST be present if status is "rejection"
-- the transaction MUST be terminated
-- MUST be absent if the status is "accepted" or -- MUST be absent if the status is "accepted" or
-- "grantedWithMods" -- "grantedWithMods"
certifiedKeyPair OPTIONAL certifiedKeyPair OPTIONAL
-- MUST be present if status is "accepted" or "grantedWithMods" -- MUST be present if status is "accepted" or "grantedWithMods"
-- MUST be absent if status is "rejection" -- MUST be absent if status is "rejection"
certOrEncCert REQUIRED certOrEncCert REQUIRED
-- MUST be present when certifiedKeyPair is present -- MUST be present when certifiedKeyPair is present
certificate REQUIRED certificate REQUIRED
-- MUST be present when certifiedKeyPair is present -- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate -- MUST contain the newly enrolled X.509 certificate
skipping to change at page 32, line 11 skipping to change at page 33, line 11
of PBMParameter SHOULD remain constant for message protection of PBMParameter SHOULD remain constant for message protection
throughout this PKI management operation to reduce the computational throughout this PKI management operation to reduce the computational
overhead. overhead.
PBMParameter REQUIRED PBMParameter REQUIRED
salt REQUIRED salt REQUIRED
-- MUST be the random value to salt the secret key -- MUST be the random value to salt the secret key
owf REQUIRED owf REQUIRED
-- MUST be the algorithm identifier for the one-way function -- MUST be the algorithm identifier for the one-way function
-- used -- used
-- The one-way function SHA-1 MUST be supported due to -- For more details on cryptographic algorithms to use, see
-- [RFC4211] requirements, but SHOULD NOT be used any more -- RFC-CMP-Alg and RFC-CRMF-Alg
-- SHA-256 SHOULD be used instead
iterationCount REQUIRED iterationCount REQUIRED
-- MUST be a limited number of times the one-way function is -- MUST be a limited number of times the one-way function is
-- applied -- applied
-- To prevent brute force and dictionary attacks a reasonable -- To prevent brute force and dictionary attacks a reasonable
-- high number SHOULD be used -- high number SHOULD be used
mac REQUIRED mac REQUIRED
-- MUST be the algorithm identifier of the MAC algorithm used -- MUST be the algorithm identifier of the MAC algorithm used
-- The MAC function HMAC-SHA1 MUST be supported due to -- For more details on cryptographic algorithms to use, see
-- [RFC4211] requirements, but SHOULD NOT be used any more -- RFC-CMP-Alg and RFC-CRMF-Alg
-- HMAC-SHA-256 SHOULD be used instead
4.1.5. Request a certificate from a legacy PKI using PKCS#10 request 4.1.5. Request a certificate from a legacy PKI using PKCS#10 request
This PKI management operation should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] certificate of a legacy PKI only capable to process PKCS#10 [RFC2986]
certification requests. The EE can prove its identity to the target certification requests. The EE can prove its identity to the target
PKI by using various protection means as described in Section 4.1.1 PKI by using various protection means as described in Section 4.1.1
or Section 4.1.4. or Section 4.1.4.
In contrast to the other PKI management operations described in In contrast to the other PKI management operations described in
skipping to change at page 34, line 22 skipping to change at page 35, line 22
-- As described in section 3.1 -- As described in section 3.1
body body
-- The request of the EE for a new certificate using a PKCS#10 -- The request of the EE for a new certificate using a PKCS#10
-- certificate request -- certificate request
p10cr REQUIRED p10cr REQUIRED
certificationRequestInfo REQUIRED certificationRequestInfo REQUIRED
version REQUIRED version REQUIRED
-- MUST be set to 0 to indicate PKCS#10 V1.7 -- MUST be set to 0 to indicate PKCS#10 V1.7
subject REQUIRED subject REQUIRED
-- MUST contain the suggested subject name of the EE -- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be a NULL-DN
subjectPKInfo REQUIRED subjectPKInfo REQUIRED
algorithm REQUIRED algorithm REQUIRED
-- MUST include the subject public key algorithm ID -- MUST include the subject public key algorithm ID
subjectPublicKey REQUIRED subjectPublicKey REQUIRED
-- MUST include the subject public key algorithm value -- MUST include the subject public key algorithm value
attributes OPTIONAL attributes OPTIONAL
-- MAY contain a set of end-entity-specific fields or X.509 -- MAY include end-entity-specific X.509 extensions of the
-- extensions to be included in the requested certificate or used -- requested certificate like subject alternative name,
-- otherwise -- key usage, and extended key usage.
-- The subjectAltName extension MUST be present if the EE
-- subject name includes a subject alternative name.
signatureAlgorithm REQUIRED signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 -- subjectPKInfo field.
signature REQUIRED signature REQUIRED
-- MUST containing the self-signature for proof-of-possession -- MUST containing the self-signature for proof-of-possession
protection REQUIRED protection REQUIRED
-- As described in section 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
skipping to change at page 37, line 48 skipping to change at page 39, line 9
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.
For details on algorithms to be used, please see CMP Algorithms
Section 4 and 5 [I-D.ietf-lamps-cmp-algorithms].
For encrypting the SignedData structure containing the private key a For encrypting the SignedData structure containing the private key a
fresh content-encryption key MUST be generated with enough entropy fresh content-encryption key MUST be generated with enough entropy
with regard to the used symmetric key-encryption algorithm. with regard to the used symmetric key-encryption algorithm.
Note: Depending on the lifetime of the certificate and the Note: Depending on the lifetime of the certificate and the
criticality of the generated private key, it is advisable to use the criticality of the generated private key, it is advisable to use the
strongest available symmetric encryption algorithm. Therefore, this strongest available symmetric encryption algorithm.
specification recommends using at least AES-256.
The detailed description of the privateKey field looks like this: The detailed description of the privateKey field looks like this:
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be an EnvelopedData structure as specified in -- MUST be an EnvelopedData structure as specified in
-- CMS [RFC5652] section 6 -- CMS [RFC5652] section 6
version REQUIRED version REQUIRED
-- MUST be set to 2 -- MUST be set to 2
recipientInfos REQUIRED recipientInfos REQUIRED
-- MUST be exactly one RecipientInfo -- MUST be exactly one RecipientInfo
skipping to change at page 38, line 34 skipping to change at page 39, line 44
-- KeyAgreeRecipientInfo is REQUIRED and support of -- KeyAgreeRecipientInfo is REQUIRED and support of
-- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL
encryptedContentInfo encryptedContentInfo
REQUIRED REQUIRED
contentType REQUIRED contentType REQUIRED
-- MUST be id-signedData -- MUST be id-signedData
contentEncryptionAlgorithm contentEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the symmetric -- MUST be the algorithm identifier of the symmetric
-- content-encryption algorithm used -- content-encryption algorithm used
-- As private keys need long-term protection, the use of AES-256
-- or a stronger symmetric algorithm is RECOMMENDED
encryptedContent REQUIRED encryptedContent REQUIRED
-- MUST be the signedData structure as specified in -- MUST be the signedData structure as specified in
-- CMS [RFC5652] section 5 in encrypted form -- CMS [RFC5652] section 5 in encrypted form
version REQUIRED version REQUIRED
-- MUST be set to 3 -- MUST be set to 3
digestAlgorithms digestAlgorithms
REQUIRED REQUIRED
-- MUST be exactly one digestAlgorithm identifier -- MUST be exactly one digestAlgorithm identifier
digestAlgorithmIdentifier digestAlgorithmIdentifier
REQUIRED REQUIRED
-- MUST be the OID of the digest algorithm used for generating -- MUST be the OID of the digest algorithm used for generating
-- the signature -- the signature
-- The hash algorithm used SHOULD be SHA-256
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-ct-KP-aKeyPackage as specified in [RFC5958] -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
content REQUIRED content REQUIRED
AsymmetricKeyPackage AsymmetricKeyPackage
REQUIRED REQUIRED
OneAsymmetricKey OneAsymmetricKey
REQUIRED REQUIRED
-- MUST be exactly one asymmetric key package -- MUST be exactly one asymmetric key package
version REQUIRED version REQUIRED
-- The version MUST be v2 -- The version MUST be v2
privateKeyAlgorithm privateKeyAlgorithm
skipping to change at page 39, line 47 skipping to change at page 41, line 6
signerInfos REQUIRED signerInfos REQUIRED
-- MUST be exactly one signerInfo -- MUST be exactly one signerInfo
version REQUIRED version REQUIRED
-- MUST be set to 3 -- MUST be set to 3
sid REQUIRED sid REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
-- MUST be the subjectKeyIdentifier of the signer's certificate -- MUST be the subjectKeyIdentifier of the signer's certificate
digestAlgorithm digestAlgorithm
REQUIRED REQUIRED
-- MUST be the same OID as in digest algorithm -- MUST be the same OID as in digest AlgorithmIdentifier
signatureAlgorithm signatureAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the signature algorithm -- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits, -- used for calculation of the signature bits,
-- like sha256WithRSAEncryption or ecdsa-with-SHA256 -- like sha256WithRSAEncryption or ecdsa-with-SHA256
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPublicKeyInfo field of the signer's certificate -- subjectPublicKeyInfo field of the signer's certificate
signature REQUIRED signature REQUIRED
-- MUST be the result of the digital signature generation -- MUST be the result of the digital signature generation
skipping to change at page 41, line 26 skipping to change at page 42, line 26
-- 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 element
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
skipping to change at page 42, line 31 skipping to change at page 43, line 31
-- 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 key derivation algorithm. To use
technique the PasswordRecipientInfo structure MUST be used in the this key management technique the PasswordRecipientInfo structure
contentInfo field. MUST be used in the contentInfo field.
The PasswordRecipientInfo structure included into the EnvelopedData The PasswordRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.4 [RFC5652]. structure is specified in CMS Section 6.2.4 [RFC5652].
The detailed description of the PasswordRecipientInfo structure looks The detailed description of the PasswordRecipientInfo structure looks
like this: like this:
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
REQUIRED REQUIRED
-- MUST be set to id-PBKDF2 as specified in [RFC8018] -- A key derivation algorithm as specified in RFC-CMP-Alg
-- The same shared secret MUST be used than used in -- SHOULD be used
-- PBMParameter data structure for the MAC protection in the
-- header of this message
salt REQUIRED
-- MUST be the random value to salt the secret key
-- MUST be a different value than used in the PBMParameter
-- data structure of the CMP message protection in the
-- header of this message
iterationCount
REQUIRED
-- MUST be a limited number of times the OWF is applied
-- To prevent brute force and dictionary attacks a reasonable
-- high number SHOULD be used
keyLength REQUIRED
prf REQUIRED
-- MUST be the algorithm identifier of the underlying
-- pseudorandom function
-- The pseudorandom function HMAC-SHA1 MUST be supported
-- due to [RFC8018] requirements, but SHOULD NOT be used any
-- more HMAC-SHA-256 SHOULD be used instead
keyEncryptionAlgorithm
REQUIRED
-- MUST be the same as in the contentEncryptionAlgorithm field
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key
4.1.7. Delayed enrollment 4.1.7. Delayed enrollment
This functional extension can be applied in combination with This functional extension can be applied in combination with
certificate enrollment as described in Section 4.1.1 to certificate enrollment as described in Section 4.1.1 to
Section 4.1.5. The functional extension can be used in case a PKI Section 4.1.5. The functional extension can be used in case a PKI
management entity cannot respond to the certificate request in a management entity cannot respond to the certificate request in a
timely manner, e.g., due to offline upstream communication or timely manner, e.g., due to offline upstream communication or
required registration officer interaction. Depending on the PKI required registration officer interaction. Depending on the PKI
architecture, it is not necessary that the PKI management entity architecture, it is not necessary that the PKI management entity
skipping to change at page 53, line 6 skipping to change at page 53, line 6
operations, or general-purpose support messages as needed in a operations, or general-purpose support messages as needed in a
specific environment. specific environment.
Content specified in this document is describs the following: Content specified in this document is describs the following:
o Request of CA certificates o Request of CA certificates
o Update of Root CA certificates o Update of Root CA certificates
o Parameters needed for a planned certificate request message o Parameters needed for a planned certificate request message
4.4.1. General message and response
The PKI management operation is similar to that given in CMP The PKI management operation is similar to that given in CMP
Appendix E.5 [RFC4210]. In this section the general message (genm) Appendix E.5 [RFC4210]. In this section the general message (genm)
and general response (genp) are described. The specific and general response (genp) are described. The specific
InfoTypeAndValue structures are described in the following sections. InfoTypeAndValue structures are described in the following sections.
The behavior in case an error occurs is described in Section 4.3. The behavior in case an error occurs is described in Section 4.3.
Message flow: Message flow:
Step# EE PKI management entity Step# EE PKI management entity
skipping to change at page 54, line 34 skipping to change at page 54, line 34
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 < TBD: May be we should not restrict the number of ITAV elements in
the response message to one. > the response message to one. >
4.4.2. Get CA certificates 4.4.1. Get CA certificates
This PKI management operation can be used by an EE to request CA This PKI management operation can be used by an EE to request CA
certificates from the PKI management entity. certificates from the PKI management entity.
An EE requests CA certificates 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 as specified in CMP sending a general message with OID id-it-caCerts as specified in CMP
Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity
responds with a general response with the same OID that either 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, 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
3 if present, the infoValue of the response MUST be caCerts field 3 if present, the infoValue of the response MUST be caCerts field
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
caCerts OID looks like this: caCerts OID looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CA certificate is available -- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available -- MUST be present if CA certificates are available
-- MUST be a sequence of CMPCertificate -- MUST be a sequence of CMPCertificate
4.4.3. Get root CA certificate update 4.4.2. Get root CA certificate update
This PKI management operation can be used by an EE to request an This PKI management operation can be used by an EE to request an
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
specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI
management entity responds with a general response with the same OID management entity responds with a general response with the same OID
that either contains the update of the root CA certificate consisting that either contains the update of the root CA certificate consisting
of up to three certificates, or with no content in case no update is of up to three certificates, or with no content in case no update is
available. available.
The newWithNew certificate is the new root CA certificates and is The newWithNew certificate is the new root CA certificates and is
REQUIRED to be present in the response message. The newWithOld REQUIRED to be present in the response message. The newWithOld
certificate is RECOMMENDED to be present in the response message certificate is RECOMMENDED to be present in the response message
though it is REQUIRED for those cases where the receiving entity though it is needed for those cases where the receiving entity trusts
trusts the old root CA certificate and wishes to gain trust in the the old root CA certificate and wishes to gain trust in the new root
new root CA certificate. The oldWithNew certificate is OPTIONAL CA certificate. The oldWithNew certificate is OPTIONAL though it is
though it is only needed in a scenario where the requesting entity only needed in a scenario where the requesting entity already trusts
already trusts the new root CA certificate and wants to gain trust in the new root CA certificate and wants to gain trust in the old root
the old root certificate. certificate.
The message sequence for this PKI management operation is as given in The message sequence for this PKI management operation is as given in
Section 4.4.1, with the following specific content: Section 4.4, 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
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
rootCaKeyUpdate extension looks like this: rootCaKeyUpdate extension looks like this:
skipping to change at page 56, line 27 skipping to change at page 56, line 27
-- 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 < TBD: In case the PKI management entity serves for different Root
CAs. There are three different options to handle this: - The EE CAs. There are three different options to handle this: - The EE
specifies by means of an respective lable in the http endpoint for specifies by means of a respective lable in the http endpoint for
which Root CA certificate the update is requested. - The EE transfers which Root CA certificate the update is requested. - The EE transfers
the oldWithOld certificate in the InfoValue of the request. - The PKI the oldWithOld certificate in the InfoValue of the request. - The PKI
management entity provides RootCaKeyUpdate element all Root CAs an management entity provides RootCaKeyUpdate element all Root CAs an
update is available. > update is available. >
4.4.4. Get certificate request template 4.4.3. Get certificate request template
This PKI management operation can be used by an EE to request a This PKI management operation can be used by an EE to request a
template with parameters for a future certificate request operation. template with parameters for a future certificate request operation.
An EE requests certificate request parameter 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 as entity by sending a general message with OID id-it-certReqTemplate as
specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI
management entity responds with a general response with the same OID management entity responds with a general response with the same OID
that either contains a certificate template containing requirements that either contains a certificate template containing requirements
on certificate fields and extensions and optionally a sequence of on certificate fields and extensions and optionally a sequence of
skipping to change at page 57, line 28 skipping to change at page 57, line 28
by the EE. Similarly, in case an X.509v3 extension is present but by the EE. Similarly, in case an X.509v3 extension is present but
its extnValue is empty this means that the extension SHOULD be its extnValue is empty this means that the extension SHOULD be
included with content provided by the EE. In case a Name component, included with content provided by the EE. In case a Name component,
for instance a common name or serial number, is given but has an for instance a common name or serial number, is given but has an
empty string value the EE SHOULD fill in a value. Similarly, in case empty string value the EE SHOULD fill in a value. Similarly, in case
an extension has sub-components (e.g., an IP address in a an extension has sub-components (e.g., an IP address in a
SubjectAltName field) with empty value, the EE SHOULD fill in a SubjectAltName field) with empty value, the EE SHOULD fill in a
value. 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 understand or does
not know suitable values to be filled in.
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate The publicKey field of type SubjectPublicKeyInfo in the CertTemplate
MUST no algorithm ID in the algorithm field and a zero-length BIT MUST NOT be used and MUST contain no algorithm ID in the algorithm
STRING in the subjectPublicKey field. In case the PKI management field and a zero-length BIT STRING in the subjectPublicKey field. In
entity whishes to make stipulation on supported algorithms the EE may case the PKI management entity wishes to make stipulation on
use for key generation, this MUST be specified using the control supported algorithms the EE may use for key generation, this MUST be
fields. specified using the control fields.
The control with the OID id-regCtrl-algId, as specified in CMP The control with the OID id-regCtrl-algId, as specified in CMP
Updates [I-D.ietf-lamps-cmp-updates], specifies algorithms other that Updates [I-D.ietf-lamps-cmp-updates], specifies algorithms other that
RSA. The algorithm field in SubjectPublicKeyInfo specifies the type RSA. The algorithm field in SubjectPublicKeyInfo specifies the type
of the public key to request a certificate for. The algorithm field 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 contains the key type OID of the public key. For EC keys the full
curve information MUST be specified as described in the respective curve information MUST be specified as described in the respective
standard documents. The algorithm field MUST be followed by a zero- standard documents. The algorithm field MUST be followed by a zero-
length BIT STRING for the subjectPublicKey. length BIT STRING for the subjectPublicKey.
The control with the OID id-regCtrl-rsaKeyLen, as specified in CMP The control with the OID id-regCtrl-rsaKeyLen, as specified in CMP
Updates [I-D.ietf-lamps-cmp-updates], specifies RSA keys of the Updates [I-D.ietf-lamps-cmp-updates], specifies RSA keys of the
specified key length. In case several control fields are present 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 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 generation. In case no control field is not present the EE is free
to choose the public key type and parameters. 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. publicKey, 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, 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 certTemplate 3 if present, the infoValue of the response MUST be a certTemplate
structure and an optional SEQUENCE of AttributeTypeAndValue of structure and an optional SEQUENCE of AttributeTypeAndValue of
type id-regCtrl-algId or id-regCtrl-rsaKeyLen 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-
skipping to change at page 58, line 37 skipping to change at page 58, line 37
-- 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
-- The SubjectPublicKeyInfo MUST contain no algorithm ID in the -- The SubjectPublicKeyInfo MUST contain no algorithm ID in the
-- algorithm field and a zero-length BIT STRING in the -- algorithm field and a zero-length BIT STRING in the
-- subjectPublicKey field -- subjectPublicKey field
controls OPTIONAL controls OPTIONAL
-- MUST be absent if no requirements on algorithms are available -- MUST be absent if no requirements on algorithms 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 algorithms to be used for key generation -- requirements on the algorithms to be used for key generation
-- MUST contain one AttributeTypeAndValue per supported algorithm -- MUST contain one AttributeTypeAndValue per supported algorithm
-- MAY be of type id-regCtrl-algId or id-regCtrl-rsaKeyLen -- with attribute 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 60, line 37 skipping to change at page 60, line 37
A PKI management entity MAY update the protection of a message A PKI management entity MAY update the protection of a message
o if it performs changes to the header or the body of the message, o if it performs changes to the header or the body of the message,
o if it needs to prove checks or validations performed on the o if it needs to prove checks or validations performed on the
message to one of the next (upstream) PKI components, message to one of the next (upstream) PKI components,
o if it needs to protect the message using a key and certificate o if it needs to protect the message using a key and certificate
from a different PKI, or from a different PKI, or
o if it needs to replace a MAC based-protection. o if it needs to replace or produce a MAC based-protection.
This is particularly relevant in the upstream communication of This is particularly relevant in the upstream communication of
certificate request messages. certificate request messages.
The message protection covers only the header and the body and not The message protection covers only the header and the body and not
the extraCerts. The PKI management entity MAY change the extraCerts the extraCerts. The PKI management entity MAY change the extraCerts
in any of the following message adaptations, e.g., to sort or add in any of the following message adaptations, e.g., to sort or add
needed or to delete needless certificates to support the next hop. needed or to delete needless certificates to support the next hop.
This may be particularly helpful to extend upstream messages with This may be particularly helpful to extend upstream messages with
additional certificates or to reduce the number of certificates in additional certificates or to reduce the number of certificates in
skipping to change at page 61, line 31 skipping to change at page 61, line 31
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 management entity and approve its content including the previous PKI management entity and approve its content including
any own modifications. For certificate requests the PKI management any own modifications. For certificate requests the PKI management
entity MUST verify in particular the included proof-of-possession entity MUST verify (except in case of central key generation) the
self-signature of the certTemplate using the public key of the presence and contents of the proof-of-possession self-signature of
requested certificate and MUST check that the EE, as authenticated by the certTemplate using the public key of the requested certificate
the message protection, is authorized to request a certificate with and MUST check that the EE, as authenticated by the message
the subject as specified in the certTemplate. protection, is authorized to request a certificate with 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 request messages the PKI management entity MUST
MUST check that the other PKI management entity, as authenticated by check that the other PKI management entity, as authenticated by the
the protection of the incoming message, was authorized to issue or 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 These message adaptations MUST NOT be applied to certificate request
messages as described in Section 4.1.6requesting key generation by a messages as described in Section 4.1.6requesting key generation by a
skipping to change at page 64, line 29 skipping to change at page 64, line 29
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
-- As described in section 3.3 -- As described in section 3.3
5.1.3.1. Handling a single PKI management message 5.1.3.1. Handling a single PKI management message
A PKI management entity may prove successful validation and A PKI management entity may indicate successful validation and
authorization of a PKI management message by adding an additional authorization of a PKI management message by adding an additional
signature to the original PKI management message. signature to the original PKI management message.
A PKI management entity SHALL wrap the original PKI management A PKI management entity SHALL wrap the original PKI management
messages in a nested message structure. The additional signature as messages in a nested message structure. The additional signature as
prove of verification and authorization by the PKI management entity prove of verification and authorization by the PKI management entity
MUST be applies as signature-based message protection of the nested MUST be applies as signature-based message protection of the nested
message. message.
5.1.3.2. Handling a batch of PKI management messages 5.1.3.2. Handling a batch of PKI management messages
A PKI management entity MAY bundle any number of PKI management A PKI management entity MAY bundle any number of PKI management
messages for batch processing or to transfer a bulk of PKI management messages for batch processing or to transfer a bulk of PKI management
messages via an offline interface using the nested message structure. messages via an offline interface using the nested message structure.
The nested message can be either used on the upstream interface Nested messages can be used on the upstream interface towards the
towards the next PKI management entity as well as on the downstream next PKI management entity and/or on the downstream interface from
interface from the PKI management entity towards the EE. the PKI management entity towards the EE.
This PKI management operation is typically used on the interface This PKI management operation is typically used on the interface
between LRA and RA to bundle several PKI management messages for between LRA and RA to bundle several PKI management messages for
offline transport. In this case the EE needs to make use of delayed offline transport. In this case the LRA needs to initiate delayed
enrollment as described in Section 4.1.7. If the RA may need enrollment as described in Section 5.1.4. If the RA may need
different routing information per nested PKI management message a different routing information per nested PKI management message a
suitable mechanism may need to be implemented. This mechanism suitable mechanism may need to be implemented. This mechanism
strongly depends on the requirements of the target architecture; strongly depends on the requirements of the target architecture;
therefore, it is out of scope of this document. therefore, it is out of scope of this document.
An initial nested message is generated locally at the PKI management An initial nested message is generated locally at the PKI management
entity. For the initial nested message, the PKI management entity entity. For the initial nested message, the PKI management entity
acts as a protocol end point and therefore a fresh transactionId and acts as a protocol end point and therefore a fresh transactionId and
a fresh senderNonce MUST be used in the header of the nested message. a fresh senderNonce MUST be used in the header of the nested message.
The recipient field MUST identify the PKI management entity that is The recipient field MUST identify the PKI management entity that is
skipping to change at page 68, line 29 skipping to change at page 68, line 29
| Enroll client using PKCS#10 | /p10 | Section | | Enroll client using PKCS#10 | /p10 | Section |
| (OPTIONAL) | | 4.1.5 | | (OPTIONAL) | | 4.1.5 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Enroll client using central key | /serverkeygen | Section | | Enroll client using central key | /serverkeygen | Section |
| generation (OPTIONAL) | | 4.1.6 | | generation (OPTIONAL) | | 4.1.6 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Revoke client certificate | /revocation | Section | | Revoke client certificate | /revocation | Section |
| (RECOMMENDED) | | 4.2 | | (RECOMMENDED) | | 4.2 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Get CA certificates (OPTIONAL) | /getcacert | Section | | Get CA certificates (OPTIONAL) | /getcacert | Section |
| | | 4.4.2 | | | | 4.4.1 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Get root CA certificate update | /getrootupdate | Section | | Get root CA certificate update | /getrootupdate | Section |
| (OPTIONAL) | | 4.4.3 | | (OPTIONAL) | | 4.4.2 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Get certificate request template | /getcertreqtemplate | Section | | Get certificate request template | /getcertreqtemplate | Section |
| (OPTIONAL) | | 4.4.4 | | (OPTIONAL) | | 4.4.3 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
| Additional protection (OPTIONAL) | /nested | Section | | Additional protection (OPTIONAL) | /nested | Section |
| | | 5.1.3 | | | | 5.1.3 |
+----------------------------------+---------------------+----------+ +----------------------------------+---------------------+----------+
Table 9: 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.
skipping to change at page 72, line 23 skipping to change at page 72, line 23
< 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.housley-lamps-crmf-update-algs]
Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", draft-housley-lamps-crmf-
update-algs-01 (work in progress), October 2020.
[I-D.ietf-lamps-cmp-algorithms]
Brockhaus, H., "CMP Algorithms", draft-ietf-lamps-cmp-
algorithms-00 (work in progress), October 2020.
[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-05 (work in progress), September 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
skipping to change at page 73, line 25 skipping to change at page 73, line 36
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010, DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>. <https://www.rfc-editor.org/info/rfc5958>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712, Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012, DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>. <https://www.rfc-editor.org/info/rfc6712>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[ETSI-TS133310] [ETSI-TS133310]
ETSI, "TS 133 310; Network Domain Security (NDS); ETSI, "TS 133 310; Network Domain Security (NDS);
Authentication Framework (AF); Release 16; V16.4.0", Authentication Framework (AF); Release 16; V16.4.0",
August 2020, <https://www.etsi.org/deliver/ August 2020, <https://www.etsi.org/deliver/
etsi_ts/133300_133399/133310/>. 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-
skipping to change at page 75, line 17 skipping to change at page 75, line 36
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. Example for CertReqTemplate Appendix A. Example for CertReqTemplate
< TBD: This Appendix must be updated to reflect the change from using < TBD: This Appendix must be updated to reflect the change from using
rsaKeyLen to controles. > 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.3.
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
with DNS name "www.myServer.com" and an IP address to be filled in, with DNS name "www.myServer.com" and an IP address to be filled in,
the keyUsage extension marked critical with the value the keyUsage extension marked critical with the value
digitalSignature and keyAgreement, and the extKeyUsage extension with digitalSignature and keyAgreement, and the extKeyUsage extension with
values to be filled in by the EE. Then the infoValue with values to be filled in by the EE. Then the infoValue with
skipping to change at page 76, line 51 skipping to change at page 77, line 23
} }
} }
INTEGER 2048 INTEGER 2048
} }
Appendix B. History of changes Appendix B. History of changes
Note: This appendix will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
From version 03 -> 04:
o Deleted normative text sections on algorithms and refer to CMP
Algorithms and CRMF Algorithm Requirements Update instead
o Some clarifications and changes in wording
From version 02 -> 03: From version 02 -> 03:
o Updated the interoperability with [UNISIG-Subset137] in o Updated the interoperability with [UNISIG-Subset137] in
Section 1.4. Section 1.4.
o Changed Section 2.3 to a tabular layout to enhanced readability 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 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 draft that will be set up as decided in IETF 108
skipping to change at page 78, line 14 skipping to change at page 78, line 41
o Changed from symmetric key-encryption to password-based key o Changed from symmetric key-encryption to password-based key
management technique in section Section 4.1.6.3 as discussed on management technique in section Section 4.1.6.3 as discussed on
the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
profile-01, section 5.1.6.1") profile-01, section 5.1.6.1")
o Changed delayed enrollment described in Section 4.1.7 from o Changed delayed enrollment described in Section 4.1.7 from
recommended to optional as decided at IETF 107 recommended to optional as decided at IETF 107
o Introduced the new RootCAKeyUpdate structure for root CA o Introduced the new RootCAKeyUpdate structure for root CA
certificate update in Section 4.4.3 as decided at IETF 107 (also certificate update in Section 4.4.2 as decided at IETF 107 (also
see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
section 5.4.3") section 5.4.3")
o Extend the description of the CertReqTemplate PKI management o Extend the description of the CertReqTemplate PKI management
operation, including an example added in the Appendix. Keep operation, including an example added in the Appendix. Keep
rsaKeyLen as a single integer value in Section 4.4.4 as discussed rsaKeyLen as a single integer value in Section 4.4.3 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 a section on HTTP URI definition and discovery and extended o Added a section on HTTP URI definition and discovery and extended
skipping to change at page 79, line 34 skipping to change at page 80, line 14
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.1. 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.2.
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.1 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.
skipping to change at page 80, line 47 skipping to change at page 81, line 26
o The CoAP based transport mechanism and piggybacking of CMP o The CoAP based transport mechanism and piggybacking of CMP
messages on top of other reliable transport protocols is out of messages on top of other reliable transport protocols is out of
scope of this document and would need to be specified in another scope of this document and would need to be specified in another
document. document.
o Further minor changes in wording. o Further minor changes in wording.
Authors' Addresses Authors' Addresses
Hendrik Brockhaus Hendrik Brockhaus (editor)
Siemens AG Siemens AG
Email: hendrik.brockhaus@siemens.com Email: hendrik.brockhaus@siemens.com
Steffen Fries Steffen Fries
Siemens AG Siemens AG
Email: steffen.fries@siemens.com Email: steffen.fries@siemens.com
David von Oheimb David von Oheimb
Siemens AG Siemens AG
Email: david.von.oheimb@siemens.com Email: david.von.oheimb@siemens.com
 End of changes. 91 change blocks. 
196 lines changed or deleted 201 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/