draft-ietf-lamps-lightweight-cmp-profile-00.txt   draft-ietf-lamps-lightweight-cmp-profile-01.txt 
LAMPS Working Group H. Brockhaus LAMPS Working Group H. Brockhaus
Internet-Draft S. Fries Internet-Draft S. Fries
Intended status: Standards Track D. von Oheimb Intended status: Standards Track D. von Oheimb
Expires: August 17, 2020 Siemens Expires: September 5, 2020 Siemens
February 14, 2020 March 4, 2020
Lightweight CMP Profile Lightweight CMP Profile
draft-ietf-lamps-lightweight-cmp-profile-00 draft-ietf-lamps-lightweight-cmp-profile-01
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 and the related Certificate Request Message Format (CRMF) version 2, the related Certificate Request Message Format (CRMF)
version 2 and the HTTP Transfer for the Certificate Management version 2, and the HTTP Transfer for the Certificate Management
Protocol. It specifies a subset of CMP and CRMF focusing on typical Protocol. It specifies a subset of CMP and CRMF focusing on typical
uses cases relevant for managing certificates of devices in many uses cases relevant for managing certificates of devices in many
industrial and IoT scenarios. To limit the overhead of certificate industrial and IoT scenarios. To limit the overhead of certificate
management for more constrained devices only the most crucial types management for more constrained devices only the most crucial types
of transactions are specified as mandatory. To foster of operations are specified as mandatory. To foster interoperability
interoperability also in more complex scenarios, other types of also in more complex scenarios, other types of operations are
transactions are specified as recommended or optional. specified as recommended or optional.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2020. This Internet-Draft will expire on September 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. History of changes . . . . . . . . . . . . . . . . . . . . . 3 1. History of changes . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Motivation for profiling CMP . . . . . . . . . . . . . . 5 2.1. Motivation for profiling CMP . . . . . . . . . . . . . . 6
2.2. Motivation for a lightweight profile for CMP . . . . . . 6 2.2. Motivation for a lightweight profile for CMP . . . . . . 7
2.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 2.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7
2.4. Compatibility with existing CMP profiles . . . . . . . . 9 2.4. Compatibility with existing CMP profiles . . . . . . . . 9
2.5. Scope of this document . . . . . . . . . . . . . . . . . 10 2.5. Scope of this document . . . . . . . . . . . . . . . . . 11
2.6. Structure of this document . . . . . . . . . . . . . . . 11 2.6. Structure of this document . . . . . . . . . . . . . . . 11
2.7. Convention and Terminology . . . . . . . . . . . . . . . 11 2.7. Convention and Terminology . . . . . . . . . . . . . . . 12
3. Architecture and use cases . . . . . . . . . . . . . . . . . 12 3. Architecture and use cases . . . . . . . . . . . . . . . . . 13
3.1. Solution architecture . . . . . . . . . . . . . . . . . . 12 3.1. Solution architecture . . . . . . . . . . . . . . . . . . 13
3.2. Basic generic CMP message content . . . . . . . . . . . . 13 3.2. Basic generic CMP message content . . . . . . . . . . . . 14
3.3. Supported use cases . . . . . . . . . . . . . . . . . . . 14 3.3. Supported PKI management operations . . . . . . . . . . . 14
3.3.1. Mandatory use cases . . . . . . . . . . . . . . . . . 14 3.3.1. Mandatory PKI management operations . . . . . . . . . 15
3.3.2. Recommended Use Cases . . . . . . . . . . . . . . . . 14 3.3.2. Recommended PKI management operations . . . . . . . . 15
3.3.3. Optional use cases . . . . . . . . . . . . . . . . . 15 3.3.3. Optional PKI management operations . . . . . . . . . 16
3.4. CMP message transport . . . . . . . . . . . . . . . . . . 15 3.4. CMP message transport . . . . . . . . . . . . . . . . . . 16
4. Generic parts of the PKI message . . . . . . . . . . . . . . 16 4. Generic parts of the PKI message . . . . . . . . . . . . . . 17
4.1. General description of the CMP message header . . . . . . 17 4.1. General description of the CMP message header . . . . . . 18
4.2. General description of the CMP message protection . . . . 18 4.2. General description of the CMP message protection . . . . 19
4.3. General description of CMP message extraCerts . . . . . . 19 4.3. General description of CMP message extraCerts . . . . . . 20
5. End Entity focused certificate management use cases . . . . . 19 5. End Entity focused PKI management operations . . . . . . . . 20
5.1. Requesting a new certificate from a PKI . . . . . . . . . 20 5.1. Requesting a new certificate from a PKI . . . . . . . . . 21
5.1.1. A certificate from a new PKI with signature 5.1.1. Request a certificate from a new PKI with signature
protection . . . . . . . . . . . . . . . . . . . . . 21 protection . . . . . . . . . . . . . . . . . . . . . 22
5.1.2. A certificate from a trusted PKI with signature 5.1.2. Request a certificate from a trusted PKI with
protection . . . . . . . . . . . . . . . . . . . . . 27 signature protection . . . . . . . . . . . . . . . . 28
5.1.3. Update an existing certificate with signature 5.1.3. Update an existing certificate with signature
protection . . . . . . . . . . . . . . . . . . . . . 27 protection . . . . . . . . . . . . . . . . . . . . . 28
5.1.4. A certificate from a PKI with MAC protection . . . . 28 5.1.4. Request a certificate from a PKI with MAC protection 29
5.1.5. A certificate from a legacy PKI using PKCS#10 request 30 5.1.5. Request a certificate from a legacy PKI using PKCS#10
5.1.6. Generate the key pair centrally at the (L)RA/CA . . . 32 request . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.6. Generate the key pair centrally at the PKI management
entity . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.6.1. Using symmetric key-encryption key management 5.1.6.1. Using symmetric key-encryption key management
technique . . . . . . . . . . . . . . . . . . . . 37 technique . . . . . . . . . . . . . . . . . . . . 38
5.1.6.2. Using key agreement key management technique . . 38 5.1.6.2. Using key agreement key management technique . . 39
5.1.6.3. Using key transport key management technique . . 39 5.1.6.3. Using key transport key management technique . . 40
5.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 40
5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 45 5.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 41
5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 47 5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 46
5.4. Support messages . . . . . . . . . . . . . . . . . . . . 49 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 48
5.4.1. General message and response . . . . . . . . . . . . 49 5.4. Support messages . . . . . . . . . . . . . . . . . . . . 50
5.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 51 5.4.1. General message and response . . . . . . . . . . . . 51
5.4.3. Get root CA certificate update . . . . . . . . . . . 51 5.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 52
5.4.4. Get certificate request parameters . . . . . . . . . 53 5.4.3. Get root CA certificate update . . . . . . . . . . . 53
5.4.5. Get certificate management configuration . . . . . . 54 5.4.4. Get certificate request parameters . . . . . . . . . 54
5.4.6. Get enrollment voucher . . . . . . . . . . . . . . . 56 5.4.5. Get certificate management configuration . . . . . . 55
6. LRA and RA focused certificate management use cases . . . . . 57 5.4.6. Get enrollment voucher . . . . . . . . . . . . . . . 57
6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 57 6. LRA and RA focused PKI management operations . . . . . . . . 59
6.1.1. Not changing protection . . . . . . . . . . . . . . . 59 6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59
6.1.2. Replacing protection . . . . . . . . . . . . . . . . 60 6.1.1. Not changing protection . . . . . . . . . . . . . . . 61
6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 60 6.1.2. Replacing protection . . . . . . . . . . . . . . . . 62
6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 61 6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62
6.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 61 6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 63
6.1.4. Initiating delayed enrollment . . . . . . . . . . . . 61 6.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63
6.2. Revoking certificates on behalf of another's entities . . 61 6.1.4. Initiating delayed enrollment . . . . . . . . . . . . 63
6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 62 6.2. Revoking certificates on behalf of another's entities . . 63
7. CMP message transport variants . . . . . . . . . . . . . . . 63 6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 64
7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 63 7. CMP message transport variants . . . . . . . . . . . . . . . 65
7.2. HTTPS transport using certificates . . . . . . . . . . . 65 7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 65
7.3. HTTPS transport using shared secrets . . . . . . . . . . 65 7.2. HTTPS transport using certificates . . . . . . . . . . . 67
7.4. File-based transport . . . . . . . . . . . . . . . . . . 66 7.3. HTTPS transport using shared secrets . . . . . . . . . . 67
7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 66 7.4. File-based transport . . . . . . . . . . . . . . . . . . 68
7.6. Piggybacking on other reliable transport . . . . . . . . 66 7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 68
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 7.6. Piggybacking on other reliable transport . . . . . . . . 68
9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 68
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Normative References . . . . . . . . . . . . . . . . . . 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 69
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 70 11.2. Informative References . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72
1. History of changes 1. History of changes
Note: This section will be deleted in the final version of the Note: This section will be deleted in the final version of the
document. document.
From version 00 -> 01:
o Harmonize terminology with CMP [RFC4210], e.g.,
* transaction, message sequence, exchange, use case -> PKI
management operqation
* PKI component, (L)RA/CA -> PKI management entity
o Minor changes in wording
From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf-
lamps-lightweight-cmp-profile-00: lamps-lightweight-cmp-profile-00:
o Changes required to reflect WG adoption o Changes required to reflect WG adoption
o Minor changes in wording o Minor changes in wording
From version 02 -> 03: From version 02 -> 03:
o Added a short summary of [RFC4210] Appendix D and E in o Added a short summary of [RFC4210] Appendix D and E in
skipping to change at page 5, line 38 skipping to change at page 6, line 4
o Further minor changes in wording. o Further minor changes in wording.
2. Introduction 2. Introduction
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.brockhaus-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, we aim at tailoring and specifying in more detail how to Therefore, this document aims at tailoring and specifying in more
use these concepts to implement lightweight automated certificate detail how to use these concepts to implement lightweight automated
management. certificate management.
2.1. Motivation for profiling CMP 2.1. Motivation for profiling CMP
CMP was standardized in 1999 and is implemented in several CA CMP was standardized in 1999 and is implemented in several CA
products. In 2005 a completely reworked and enhanced version 2 of products. In 2005 a completely reworked and enhanced version 2 of
CMP [RFC4210] and CRMF [RFC4211] has been published followed by a CMP [RFC4210] and CRMF [RFC4211] has been published followed by a
document specifying a transfer mechanism for CMP messages using http document specifying a transfer mechanism for CMP messages using http
[RFC6712] in 2012. [RFC6712] in 2012.
Though CMP is a very solid and capable protocol it could be used more Though CMP is a very solid and capable protocol it could be used more
widely. The most important reason for not more intense application widely. The most important reason for not more intense application
of CMP appears to be that the protocol is offering a large set of of CMP appears to be that the protocol is offering a large set of
features and options but being not always precise enough and leaving features and options but being not always precise enough and leaving
room for interpretation. On the one hand, this makes CMP applicable room for interpretation. On the one hand, this makes CMP applicable
to a very wide range of scenarios, but on the other hand a full to a very wide range of scenarios, but on the other hand a full
implementation of all options is unrealistic because this would take implementation of all options is unrealistic because this would take
enormous effort. enormous effort.
Moreover, many details of the CMP protocol have been left open or Moreover, many details of the CMP protocol have been left open or
have not been specified in full preciseness. The profiles specified have not been specified in full preciseness. The profiles specified
in Appendix D and E of [RFC4210] offer some more detailed certificate in Appendix D and E of [RFC4210] offer some more detailed PKI
use cases. But the specific needs of highly automated scenarios for management operations. But the specific needs of highly automated
a machine-to-machine communication are not covered sufficiently. scenarios for a machine-to-machine communication are not covered
sufficiently.
As also 3GPP and UNISIG already put across, profiling is a way of As also 3GPP and UNISIG already put across, profiling is a way of
coping with the challenges mentioned above. To profile means to take coping with the challenges mentioned above. To profile means to take
advantage of the strengths of the given protocol, while explicitly advantage of the strengths of the given protocol, while explicitly
narrowing down the options it provides to exactly those needed for narrowing down the options it provides to exactly those needed for
the purpose(s) at hand and eliminating all identified ambiguities. the purpose(s) at hand and eliminating all identified ambiguities.
In this way all the general and applicable aspects of the protocol In this way all the general and applicable aspects of the protocol
can be taken over and only the peculiarities of the target scenario can be taken over and only the peculiarities of the target scenario
need to be dealt with specifically. need to be dealt with specifically.
Doing such a profiling for a new target environment can be a high Doing such a profiling for a new target environment can be a high
effort because the range of available options needs to be well effort because the range of available options needs to be well
understood and the selected options need to be consistent with each understood and the selected options need to be consistent with each
other and with the intended usage scenario. Since most industrial other and with the intended usage scenario. Since most industrial
use cases typically have much in common it is worth sharing this PKI management use cases typically have much in common it is worth
effort, which is the aim of this document. Other standardization sharing this effort, which is the aim of this document. Other
bodies can then reference the profile from this document and do not standardization bodies can then reference the needed PKI management
need to come up with individual profiles. operations from this document and do not need to come up with
individual profiles.
2.2. Motivation for a lightweight profile for CMP 2.2. Motivation for a lightweight profile for CMP
The profiles specified in Appendix D and E of CMP have been developed The profiles specified in Appendix D and E of CMP have been developed
in particular to manage certificates of human end entities. With the in particular to manage certificates of human end entities. With the
evolution of distributed systems and client-server architectures, evolution of distributed systems and client-server architectures,
certificates for machines and applications on them have become widely certificates for machines and applications on them have become widely
used. This trend has strengthened even more in emerging industrial used. This trend has strengthened even more in emerging industrial
and IoT scenarios. CMP is sufficiently flexible to support these and IoT scenarios. CMP is sufficiently flexible to support these
very well. very well.
skipping to change at page 7, line 46 skipping to change at page 8, line 14
[RFC4210] specifies in Appendix D the following mandatory PKI [RFC4210] specifies in Appendix D the following mandatory PKI
management operations (all require support of, in the meantime management operations (all require support of, in the meantime
outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may
enroll up to two certificates, one for a locally generated and enroll up to two certificates, one for a locally generated and
another optional one for a centrally generated key pair; all require another optional one for a centrally generated key pair; all require
use of certConf/PKIConf messages for confirmation): use of certConf/PKIConf messages for confirmation):
o Initial registration/certification; an (uninitialized) end entity o Initial registration/certification; an (uninitialized) end entity
requests a (first) certificate from a CA using shared secret based requests a (first) certificate from a CA using shared secret based
message authentication. The content is similar to PKI management message authentication. The content is similar to the PKI
operation specified in Section 5.1.4 of this document. management operation specified in Section 5.1.4 of this document.
o Certificate request; an (initialized) end entity requests a o Certificate request; an (initialized) end entity requests another
certificate from a CA (for any reason) using signature or shared certificate from a CA using signature or shared secret based
secret based message authentication. The content is similar to message authentication. The content is similar to the PKI
PKI management operation specified in Section 5.1.2 of this management operation specified in Section 5.1.2 of this document.
document.
o Key update; an (initialized) end entity requests a certificate o Key update; an (initialized) end entity requests a certificate
from a CA (to update the key pair and/or corresponding certificate from a CA (to update the key pair and/or corresponding certificate
that it already possesses) using signature or shared secret based that it already possesses) using signature or shared secret based
message authentication. The content is similar to PKI management message authentication. The content is similar to the PKI
operation specified in Section 5.1.3 of this document. management operation specified in Section 5.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 transactions [RFC4210] specifies in Appendix E the following optional PKI
(all require support of, in the meantime outdated, algorithms, e.g., management operations (all require support of, in the meantime
SHA-1 and 3-DES): outdated, algorithms, e.g., SHA-1 and 3-DES):
o Root CA key update; a root CA updates its key pair and produces a o Root CA key update; a root CA updates its key pair and produces a
CA key update announcement message that can be made available (via CA key update announcement message that can be made available (via
some transport mechanism) to the relevant end entities. This some transport mechanism) to the relevant end entities. This
operation only supports a push and no pull model. The content is operation only supports a push and no pull model. The content is
similar to PKI management operation specified in Section 5.4.3 of similar to the PKI management operation specified in Section 5.4.3
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 PKI later PKI management operations. The content is similar to the
management operation specified in Section 5.4.4 and Section 5.4.5 PKI management operation specified in Section 5.4.4 and
of this document. Section 5.4.5 of this document.
o Cross-certification request/response (1-way); creation of a single o Cross-certification request/response (1-way); creation of a single
cross-certificate (i.e., not two at once). The requesting CA MAY cross-certificate (i.e., not two at once). The requesting CA MAY
choose who is responsible for publication of the cross-certificate choose who is responsible for publication of the cross-certificate
created by the responding CA through use of the PKIPublicationInfo created by the responding CA through use of the PKIPublicationInfo
control. control.
o In-band initialization using external identity certificate (this o In-band initialization using external identity certificate (this
PKI management operation may also enroll up to two certificates PKI management operation may also enroll up to two certificates
and requires use of certConf/PKIConf messages for confirmation as and requires use of certConf/PKIConf messages for confirmation as
specified in Appendix D of [RFC4210]). An (uninitialized) end specified in Appendix D of [RFC4210]). An (uninitialized) end
entity wishes to initialize into the PKI with a CA, CA-1. It entity wishes to initialize into the PKI with a CA, CA-1. It
uses, for authentication purposes, a pre-existing identity uses, for authentication purposes, a pre-existing identity
certificate issued by another (external) CA, CA-X. A trust certificate issued by another (external) CA, CA-X. A trust
relationship must already have been established between CA-1 and relationship must already have been established between CA-1 and
CA-X so that CA-1 can validate the EE identity certificate signed CA-X so that CA-1 can validate the EE identity certificate signed
by CA-X. Furthermore, some mechanism must already have been by CA-X. Furthermore, some mechanism must already have been
established within the Personal Security Environment (PSE) of the established within the Personal Security Environment (PSE) of the
EE that would allow it to authenticate and verify PKIMessages EE that would allow it to authenticate and verify PKIMessages
signed by CA-1. The content is similar to PKI management signed by CA-1. The content is similar to the PKI management
operation specified in Section 5.1.1 of this document. The trust operation specified in Section 5.1.1 of this document. The trust
establishment of the EE in CA-1 and of the CA/RA in CA-X can be establishment of the EE in CA-1 and of the CA/RA in CA-X can be
automated using, e.g., the exchange of a certificate management automated using, e.g., the exchange of a certificate management
configuration as specified in Section 5.4.5 or an enrollment configuration as specified in Section 5.4.5 or an enrollment
voucher as specified in Section 5.4.6 of this document. voucher as specified in Section 5.4.6 of this document.
Both Appendixes focus on EE to CA/RA PKI management operations and do Both Appendixes focus on EE to CA/RA PKI management operations and do
not address further profiling of RA to CA communication as typically not address further profiling of RA to CA communication as typically
used for full backend automation. used for full backend automation.
3GPP makes use of CMP [RFC4210] in its Technical Specification 133 3GPP makes use of CMP [RFC4210] in its Technical Specification 133
310 [ETSI-3GPP] for automatic management of IPSec certificates in 310 [ETSI-3GPP] for automatic management of IPSec certificates in
UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP
profile for initial certificate enrollment and update transactions profile for initial certificate enrollment and update operations
between end entities and the RA/CA is specified in the document. between EE and RA/CA is specified in that document.
UNISIG has included a CMP profile for certificate enrollment in the UNISIG has included a CMP profile for certificate enrollment in the
subset 137 specifying the ETRAM/ECTS on-line key management for train subset 137 specifying the ETRAM/ECTS on-line key management for train
control systems [UNISIG] in 2015. control systems [UNISIG] in 2015.
Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and
HTTP transfer for CMP [RFC6712] to add tailored means for automated HTTP transfer for CMP [RFC6712] to add tailored means for automated
certificate management for unattended machine or application-oriented PKI management operations for unattended machine or application-
end entities. oriented end entities.
2.4. Compatibility with existing CMP profiles 2.4. Compatibility with existing CMP profiles
The profile specified in this document is compatible with CMP The profile specified in this document is compatible with CMP
[RFC4210] Appendixes D and E (PKI Management Message Profiles), with [RFC4210] Appendixes D and E (PKI Management Message Profiles), with
the following exceptions: the following exceptions:
o signature-based protection is the default protection; initial o signature-based protection is the default protection; an initial
transactions may also use HMAC, PKI management operation may also use HMAC,
o certification of a second key pair within the same transaction is o certification of a second key pair within the same PKI management
not supported, operation is not supported,
o proof-of-possession (POPO) with self-signature of the certTemplate o proof-of-possession (POPO) with self-signature of the certTemplate
according to [RFC4211] section 4.1 clause 3 is the recommended according to [RFC4211] section 4.1 clause 3 is the recommended
default POPO method (deviations are possible by EEs when default POPO method (deviations are possible by EEs when
requesting central key generation and by (L)RAs when using requesting central key generation and by (L)RAs when using
raVerified), raVerified),
o confirmation of newly enrolled certificates may be omitted, and o confirmation of newly enrolled certificates may be omitted, and
o all transactions consist of request-response message pairs o all PKI management operations consist of request-response message
originating at the EE, i.e., announcement messages are omitted. pairs originating at the EE, i.e., announcement messages are
omitted.
The profile specified in this document is compatible with the CMP The profile specified in this document is compatible with the CMP
profile for UMTS, LTE, and 5G network domain security and profile for UMTS, LTE, and 5G network domain security and
authentication framework [ETSI-3GPP], except that: authentication framework [ETSI-3GPP], except that:
o protection of initial transactions may be HMAC-based, o protection of initial PKI management operations may be HMAC-based,
o the subject name is mandatory in certificate templates, and o the subject name is mandatory in certificate templates, and
o confirmation of newly enrolled certificates may be omitted. o confirmation of newly enrolled certificates may be omitted.
The profile specified in this document is compatible with the CMP The profile specified in this document is compatible with the CMP
profile for on-line key management in rail networks as specified in profile for on-line key management in rail networks as specified in
UNISIG subset-137 [UNISIG], except that: UNISIG subset-137 [UNISIG], except that:
o as of RFC 4210 [RFC4210] the messageTime is required to be o as of RFC 4210 [RFC4210] the messageTime is required to be
skipping to change at page 10, line 35 skipping to change at page 11, line 7
RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 RFC 4210 [RFC4210]. Both time formats are described in RFC 5280
[RFC5280] section 4.1.2.5.), and [RFC5280] section 4.1.2.5.), and
o in case the request message is MAC protected, also the response, o in case the request message is MAC protected, also the response,
certConf, and PKIconf messages have a MAC-based protection (Note: certConf, and PKIconf messages have a MAC-based protection (Note:
if changing to signature protection of the response the caPubs if changing to signature protection of the response the caPubs
field cannot be used securely anymore.). field cannot be used securely anymore.).
2.5. Scope of this document 2.5. Scope of this document
This document specifies requirements on generating messages on the This document specifies requirements on generating PKI management
sender side. It does not specify strictness of verification on the messages on the sender side. It does not specify strictness of
receiving side and how in detail to handle error cases. verification on the receiving side and how in detail to handle error
cases.
Especially on the EE side this profile aims at a lightweight protocol Especially on the EE side this profile aims at a lightweight protocol
that can be implemented on more constrained devices. On the side of that can be implemented on more constrained devices. On the side of
the central PKI management entities the profile accepts higher the central PKI management entities the profile accepts higher
resource needed. resources needed.
For the sake of robustness and preservation of security properties For the sake of robustness and preservation of security properties
implementations should, as far as security is not affected, adhere to implementations should, as far as security is not affected, adhere to
Postel's law: "Be conservative in what you do, be liberal in what you Postel's law: "Be conservative in what you do, be liberal in what you
accept from others" (often reworded as: "Be conservative in what you accept from others" (often reworded as: "Be conservative in what you
send, be liberal in what you accept"). send, be liberal in what you accept").
When in Section 4, Section 5, and Section 6 a field of the ASN.1 When in Section 4, Section 5, and Section 6 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 11, line 4 skipping to change at page 11, line 26
For the sake of robustness and preservation of security properties For the sake of robustness and preservation of security properties
implementations should, as far as security is not affected, adhere to implementations should, as far as security is not affected, adhere to
Postel's law: "Be conservative in what you do, be liberal in what you Postel's law: "Be conservative in what you do, be liberal in what you
accept from others" (often reworded as: "Be conservative in what you accept from others" (often reworded as: "Be conservative in what you
send, be liberal in what you accept"). send, be liberal in what you accept").
When in Section 4, Section 5, and Section 6 a field of the ASN.1 When in Section 4, Section 5, and Section 6 a field of the ASN.1
syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not
explicitly specified, it SHOULD not be used by the sending entity. explicitly specified, it SHOULD not be used by the sending entity.
The receiving entity MUST NOT require its absence and if present MUST The receiving entity MUST NOT require its absence and if present MUST
gracefully handle its presence. gracefully handle its presence.
2.6. Structure of this document 2.6. Structure of this document
Section 3 introduces the general PKI architecture and approach to Section 3 introduces the general PKI architecture and approach to
certificate management using CMP that is assumed in this document. certificate management using CMP that is assumed in this document.
Then it enlists the PKI management opertations specified in this Then it enlists the PKI management opertations specified in this
document and describes them in general words. The list of supported document and describes them in general words. The list of supported
certificate management use cases is divided into mandatory, PKI management operations is divided into mandatory, recommended, and
recommended, and optional ones. optional ones.
Section 4 profiles the CMP message header, protection, and extraCerts Section 4 profiles the CMP message header, protection, and extraCerts
section as they are general elements of CMP messages. section as they are general elements of CMP messages.
Section 5 profiles the exchange of CMP messages between an EE and the Section 5 profiles the exchange of CMP messages between an EE and the
first PKI management entities. There are various flavors of first PKI management entities. There are various flavors of
certificate enrollment requests optionally with polling, revocation, certificate enrollment requests optionally with polling, revocation,
error handling, and general support transactions. error handling, and general support PKI management operations.
Section 6 profiles the exchange between PKI management entities. Section 6 profiles the exchange between PKI management entities.
These are in the first place the forwarding of messages coming from These are in the first place the forwarding of messages coming from
or going to an EE. This includes also initiating delayed delivery of or going to an EE. This includes also initiating delayed delivery of
messages, which involves polling. Additionally, it specifies messages, which involves polling. Additionally, it specifies PKI
transactions where the PKI component manages certificates on behalf management operations where a PKI management entity manages
of an EE or for itself. certificates on behalf of an EE or for itself.
Section 7 outlines different mechanisms for CMP message transfer, Section 7 outlines different mechanisms for CMP message transfer,
namely http-based transfer as already specified in [RFC6712], using namely http-based transfer as already specified in [RFC6712], using
an additional TLS layer, or offline file-based transport. CoAP an additional TLS layer, or offline file-based transport. CoAP
[RFC7252] and piggybacking CMP messages on other protocols is out of [RFC7252] and piggybacking CMP messages on other protocols is out of
scope and left for further documents. scope and left for further documents.
2.7. Convention and Terminology 2.7. Convention and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be only when in ALL CAPS. Lower case use of these words are not to be
interpreted as carrying significance described in RFC 2119. interpreted as carrying significance described in RFC 2119.
Technical terminology is used in conformance with RFC 4210 [RFC4210], Technical terminology is used in conformance with RFC 4210 [RFC4210],
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
skipping to change at page 12, line 20 skipping to change at page 12, line 42
with proximity to the end entities. with proximity to the end entities.
KGA: Key generation authority, an optional system component, KGA: Key generation authority, an optional system component,
typically co-located with an LRA, RA, or CA, that offers key typically co-located with an LRA, RA, or CA, that offers key
generation services to end entities. generation services to end entities.
EE: End entity, a user, device, or service that holds a PKI EE: End entity, a user, device, or service that holds a PKI
certificate. An identifier for the EE is given as the subject certificate. An identifier for the EE is given as the subject
of its certificate. of its certificate.
The following terminology is reused from RFC 4210 [RFC4210] and used
as follows:
PKI management operation: All CMP messages belonging to one
transaction context. The transaction is
identified in the transactionID field of
the message header.
PKI management entity: All central PKI entites like LRA, RA and
CA.
PKI entity: EEs and PKI management entites
3. Architecture and use cases 3. Architecture and use cases
3.1. Solution architecture 3.1. Solution architecture
Typically, a machine EE will be equipped with a manufacturer issued Typically, a machine EE will be equipped with a manufacturer issued
certificate during production. Such a manufacturer issued certificate during production. Such a manufacturer issued
certificate is installed during production to identify the device certificate is installed during production to identify the device
throughout its lifetime. This manufacturer certificate can be used throughout its lifetime. This manufacturer certificate can be used
to protect the initial enrollment of operational certificates after to protect the initial enrollment of operational certificates after
installation of the EE in a plant or industrial network. An installation of the EE in a plant or industrial network. An
skipping to change at page 13, line 11 skipping to change at page 13, line 44
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
manner, e.g., because of a delayed message delivery. manner, e.g., because of a delayed message delivery.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| EE |<---------->| LRA |<-------------->| RA |<---------->| CA | | EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
| | | | | | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
synchronous (a)synchronous synchronous synchronous (a)synchronous (a)synchronous
+----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 will
have its own dedicated certificate containing an extended key usage have its own dedicated certificate containing an extended key usage
as specified in CMP Updates [I-D.brockhaus-lamps-cmp-updates] and as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] and private
private key allowing it to protect CMP messages it processes (CMP key allowing it to protect CMP messages it processes (CMP signing
signing key/certificate). The figure above shows an architecture key/certificate). The figure above shows an architecture using one
using one LRA and one RA. It is also possible to have only an RA or LRA and one RA. It is also possible to have only an RA or multiple
multiple LRAs and/or RAs. Depending on the network infrastructure, LRAs and/or RAs. Depending on the network infrastructure, the
the communication between different PKI components may be synchronous communication between different PKI management entites may be
online-communication, delayed asynchronous communication, or even synchronous online-communication, delayed asynchronous communication,
offline file transfer. or even offline file transfer.
This profile focusses on specifying the pull model, where the EE This profile focusses on specifying the pull model, where the EE
always requests a specific PKI management operation. CMP response always requests a specific PKI management operation. CMP response
messages, especially in case of central key generation, as described messages, especially in case of central key generation, as described
in Section 5.1.6, can also be used proactively to implement the push in Section 5.1.6, could also be used proactively to implement the
model towards the EE. push model towards the EE.
Third-party CAs typically implement different variants of CMP or even Third-party CAs typically implement different variants of CMP or even
use proprietary interfaces for certificate management. Therefore, use proprietary interfaces for certificate management. Therefore,
the LRA or the RA may need to adapt the exchanged CMP messages to the the LRA or the RA may need to adapt the exchanged CMP messages to the
flavor of communication required by the CA. flavor of communication required by the CA.
3.2. Basic generic CMP message content 3.2. Basic generic CMP message content
Section 4 specifies the generic parts of the CMP messages as used Section 4 specifies the generic parts of the CMP messages as used
later in Section 5 and Section 6. later in Section 5 and Section 6.
o Header of a CMP message; see Section 4.1. o Header of a CMP message; see Section 4.1.
o Protection of a CMP message; see Section 4.2. o Protection of a CMP message; see Section 4.2.
o ExtraCerts field of a CMP message; see Section 4.3. o ExtraCerts field of a CMP message; see Section 4.3.
3.3. Supported use cases 3.3. Supported PKI management operations
Following the outlined scope from Section 2.5, this section gives a Following the outlined scope from Section 2.5, this section gives a
brief overview of the certificate management use cases specified in brief overview of the PKI management operations specified in
Section 5 and Section 6 and points out, whether an implementation by Section 5 and Section 6 and points out, whether an implementation by
compliant EE or PKI component is mandatory, recommended or optional. compliant EE or PKI management entites is mandatory, recommended or
optional.
3.3.1. Mandatory use cases 3.3.1. Mandatory PKI management operations
The mandatory uses case in this document shall limit the overhead of The mandatory PKI management operations in this document shall limit
certificate management for more constrained devices to the most the overhead of certificate management for more constrained devices
crucial types of transactions. to the most crucial types of operations.
Section 5 - End Entity focused certificate management use cases Section 5 - End Entity focused PKI management operations
o Request a certificate from a new PKI with signature protection; o Request a certificate from a new PKI with signature protection;
see Section 5.1.1. see Section 5.1.1.
o Request to update an existing certificate with signature o Request to update an existing certificate with signature
protection; see Section 5.1.3. protection; see Section 5.1.3.
o Error reporting; see Section 5.3. o Error reporting; see Section 5.3.
Section 6 - LRA and RA focused certificate management use cases Section 6 - LRA and RA focused PKI management operations
o Forward messages without changes; see Section 6.1.1. o Forward messages without changes; see Section 6.1.1.
o Forward messages with replaced protection and raVerified as proof- o Forward messages with replaced protection and raVerified as proof-
of-possession; see Section 6.1.2.2. of-possession; see Section 6.1.2.2.
o Error reporting; see Section 6.3. o Error reporting; see Section 6.3.
3.3.2. Recommended Use Cases 3.3.2. Recommended PKI management operations
Additional recommended use cases shall support some more complex Additional recommended PKI management operations shall support some
scenarios, that are considered as beneficial for environments with more complex scenarios, that are considered as beneficial for
more specific boundary conditions. environments with more specific boundary conditions.
Section 5 - End Entity focused certificate management use cases Section 5 - End Entity focused PKI management operations
o Request a certificate from a PKI with MAC protection; see o Request a certificate from a PKI with MAC protection; see
Section 5.1.4. Section 5.1.4.
o Handle delayed enrollment due to asynchronous message delivery; o Handle delayed enrollment due to asynchronous message delivery;
see Section 5.1.7. see Section 5.1.7.
< TBD: There still some discussion ongoing if this should be < TBD: There still some discussion ongoing if this should be
recommended or optional. > recommended or optional. >
o Revoke an own certificate. o Revoke an own certificate.
Section 6 - LRA and RA focused certificate management use cases Section 6 - LRA and RA focused PKI management operations
o Revoke another's entities certificate. o Revoke another's entities certificate.
3.3.3. Optional use cases 3.3.3. Optional PKI management operations
The optional use cases support specific requirements seen only in a The optional PKI management operations support specific requirements
subset of environments. seen only in a subset of environments.
Section 5 - End Entity focused certificate management use cases Section 5 - End Entity focused PKI management operations
o Request a certificate from a trusted PKI with signature
protection; see Section 5.1.2.
o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986]
request; see Section 5.1.5. request; see Section 5.1.5.
o Add central generation of a key pair to a certificate request; see o Add central generation of a key pair to a certificate request; see
Section 5.1.6. If central key generation is supported, the key Section 5.1.6. If central key generation is supported, the key
agreement key management technique is REQUIRED to be supported, agreement key management technique is REQUIRED to be supported,
and the key transport and symmetric key-encryption key management and the key transport and symmetric key-encryption key management
techniques are OPTIONAL. techniques are OPTIONAL.
o Additional support messages, e.g., to update a Root CA certificate o Additional support messages, e.g., to update a root CA certificate
or to request an RFC 8366 [RFC8366] voucher; see Section 5.4. or to request an RFC 8366 [RFC8366] voucher; see Section 5.4.
Section 6 - LRA and RA focused certificate management use cases Section 6 - LRA and RA focused PKI management operations
o Initiate delayed enrollment due to asynchronous message delivery; o Initiate delayed enrollment due to asynchronous message delivery;
see Section 6.1.4. see Section 6.1.4.
3.4. CMP message transport 3.4. CMP message transport
On different links between PKI entities, e.g., EE<->RA and RA<->CA, On different links between PKI entities, e.g., EE<->RA and RA<->CA,
different transport MAY be used. As CMP has only very limited different transport MAY be used. As CMP has only very limited
requirement regarding the mechanisms used for message transport and requirement regarding the mechanisms used for message transport and
in different environments different transport mechanisms are in different environments different transport mechanisms are
skipping to change at page 16, line 21 skipping to change at page 17, line 17
o Transfer CMP messages using HTTPS with shared-secret based o Transfer CMP messages using HTTPS with shared-secret based
protection; see Section 7.3. protection; see Section 7.3.
o File-based CMP message transport. o File-based CMP message transport.
< TBD: Motivation see Section 7.4 > < TBD: Motivation see Section 7.4 >
< TBD: Michael Richardson proposed to also specify a CoAP based < TBD: Michael Richardson proposed to also specify a CoAP based
message transport profile. If there is further support for this message transport profile. If there is further support for this
profile and someone volunteering to provide the necessary input for profile and someone volunteering to provide the necessary input for
this section, I would add it to the document. > this section, I would like to add it to this document. >
4. Generic parts of the PKI message 4. Generic parts of the PKI message
To reduce redundancy in the text and to ease implementation, the To reduce redundancy in the text and to ease implementation, the
contents of the header, protection, and extraCerts fields of the CMP contents of the header, protection, and extraCerts fields of the CMP
messages used in the transactions specified in Section 5 and messages used in the transactions specified in Section 5 and
Section 6 are standardized to the maximum extent possible. Section 6 are standardized to the maximum extent possible.
Therefore, the generic parts of a CMP message are described centrally Therefore, the generic parts of a CMP message are described centrally
in this section. in this section.
skipping to change at page 17, line 23 skipping to change at page 18, line 20
is described in the context of Section 5 and Section 6. is described in the context of Section 5 and Section 6.
The behavior in case an error occurs while handling a CMP message is The behavior in case an error occurs while handling a CMP message is
described in Section 6.3. described in Section 6.3.
4.1. General description of the CMP message header 4.1. General description of the CMP message header
This section describes the generic header field of all CMP messages This section describes the generic header field of all CMP messages
with signature-based protection. The only variations described here with signature-based protection. The only variations described here
are in the fields recipient, transactionID, and recipNonce of the are in the fields recipient, transactionID, and recipNonce of the
first message of a transaction. first message of a PKI management operation.
In case a message has MAC-based protection the changes are described In case a message has MAC-based protection the changes are described
in the respective section. The variations will affect the fields in the respective section. The variations will affect the fields
sender, protectionAlg, and senderKID. sender, protectionAlg, and senderKID.
For requirements about proper random number generation please refer For requirements about proper random number generation please refer
to [RFC4086]. Any message-specific fields or variations are to [RFC4086]. Any message-specific fields or variations are
described in the respective sections of this chapter. described in the respective sections of this chapter.
header header
skipping to change at page 17, line 51 skipping to change at page 18, line 48
-- MAY be a NULL_DN if the sender does not know the DN of -- MAY be a NULL_DN if the sender does not know the DN of
-- the recipient -- the recipient
-- If this is the first message of a transaction: SHOULD be the -- If this is the first message of a transaction: SHOULD be the
-- subject of the issuing CA certificate -- subject of the issuing CA certificate
-- In all other messages: SHOULD be the same name as in the -- In all other messages: SHOULD be the same name as in the
-- sender field of the previous message in this transaction -- sender field of the previous message in this transaction
messageTime RECOMMENDED messageTime RECOMMENDED
-- MUST be the time at which the message was produced, if -- MUST be the time at which the message was produced, if
-- present -- present
protectionAlg REQUIRED protectionAlg REQUIRED
-- MUST be the algorithm identifier of the signature or algorithm -- MUST be the algorithm identifier of the signature algorithm or
-- id-PasswordBasedMac algorithm used for calculation of the -- id-PasswordBasedMac algorithm used for calculation of the
-- protection bits -- protection bits
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- SubjectPublicKeyInfo field of the signer's certificate -- SubjectPublicKeyInfo field of the signer's certificate
-- The hash algorithm used SHOULD be SHA-256 -- The hash algorithm used SHOULD be SHA-256
algorithm REQUIRED algorithm REQUIRED
-- MUST be the OID of the signature algorithm, like -- MUST be the OID of the signature algorithm, like
-- sha256WithRSAEncryption or ecdsa-with-SHA256, or -- sha256WithRSAEncryption or ecdsa-with-SHA256, or
-- id-PasswordBasedMac -- id-PasswordBasedMac
senderKID RECOMMENDED senderKID RECOMMENDED
skipping to change at page 18, line 33 skipping to change at page 19, line 30
senderNonce REQUIRED senderNonce REQUIRED
-- MUST be fresh 128 random bits -- MUST be fresh 128 random bits
recipNonce RECOMMENDED recipNonce RECOMMENDED
-- If this is the first message of a transaction: SHOULD be -- If this is the first message of a transaction: SHOULD be
-- absent -- absent
-- In all other messages: MUST be present and contain the value -- In all other messages: MUST be present and contain the value
-- from senderNonce of the previous message in the same -- from senderNonce of the previous message in the same
-- transaction -- transaction
generalInfo OPTIONAL generalInfo OPTIONAL
implicitConfirm OPTIONAL implicitConfirm OPTIONAL
ImplicitConfirmValue REQUIRED
-- The field is optional though it only applies to -- The field is optional though it only applies to
-- ir/cr/kur/p10cr requests and ip/cp/kup responses -- ir/cr/kur/p10cr requests and ip/cp/kup response messages
-- Add to request messages to request omit sending certConf
-- message
-- Add to response messages to confirm omit sending certConf
-- message
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 wants -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA
-- to grant not sending a confirmation message -- wants to grant not sending a confirmation message
4.2. General description of the CMP message protection 4.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 REQUIRED 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
Only for MAC-based protection major differences apply as described in Generally CMP message protection is required for CMP messages, but
the respective message. there are cases where protection of error messages as specified in
Section 5.3 and Section 6.3 is not possible and therefore MAY be
omitted.
For MAC-based protection as specified in Section 5.1.4 major
differences apply as described in the respective section.
The CMP message protection provides, if available, message origin The CMP message protection provides, if available, message origin
authentication and integrity protection for the CMP message header authentication and integrity protection for the CMP message header
and body. The CMP message extraCerts is not covered by this and body. The CMP message extraCerts is not covered by this
protection. protection.
NOTE: The extended key usages specified in CMP Updates
[I-D.ietf-lamps-cmp-updates] can be used for authorization of a
sending PKI management entity.
NOTE: The requirements for checking certificates given in [RFC5280] NOTE: The requirements for checking certificates given in [RFC5280]
MUST be followed for the CMP message protection. In case the CMP MUST be followed for the CMP message protection. In case the CMP
signer certificates is not the CA certificate that signed the newly signer certificates is not the CA certificate that signed the newly
issued certificate, certificate status checking SHOULD be used for issued certificate, certificate status checking SHOULD be used for
the CMP signer certificates of communication partners. the CMP signer certificates of communication partners.
4.3. General description of CMP message extraCerts 4.3. General description of CMP message extraCerts
This section describes the generic extraCerts field of all CMP This section describes the generic extraCerts field of all CMP
messages with signature-based protection. messages with signature-based protection. If extraCerts are
required, recommended, or optional is specified in the respective PKI
management operation.
extraCerts RECOMMENDED extraCerts
-- SHOULD contain the protection certificate together with its -- SHOULD contain the protection certificate together with its
-- chain, if needed -- chain, if needed
-- If present, the first certificate in this field MUST -- If present, the first certificate in this field MUST
-- be the protection certificate -- be the protection certificate
-- Self-signed certificates SHOULD NOT be included in -- Self-signed certificates SHOULD NOT be included in
-- extraCerts and MUST NOT be trusted based on the listing in -- extraCerts and MUST NOT be trusted based on the listing in
-- extraCerts in any case -- extraCerts in any case
5. End Entity focused certificate management use cases 5. 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
component it talks to. Depending on the network and PKI solution, management entities it talks to. Depending on the network and PKI
this will either be the LRA, the RA or the CA. solution, this will either be the LRA, the RA or the CA.
Profiles of the Certificate Management Protocol (CMP) [RFC4210] Profiles of the Certificate Management Protocol (CMP) [RFC4210]
handled in this chapter cover the following certificate management handled in this section cover the following PKI management
use cases: 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
The use cases mainly specify the message body of the CMP messages and
utilize the specification of the message header, protection and These operations mainly specify the message body of the CMP messages
and utilize the specification of the message header, protection and
extraCerts as specified in Section 5. extraCerts as specified in Section 5.
The behavior in case an error occurs is described in Section 5.3. The behavior in case an error occurs is described in Section 5.3.
This chapter is aligned to Appendix D and Appendix E of [RFC4210]. This chapter is aligned to Appendix D and Appendix E of [RFC4210].
The general rules for interpretation stated in Appendix D.1 in The general rules for interpretation stated in Appendix D.1 in
[RFC4210] need to be applied here, too. [RFC4210] need to be applied here, too.
This document does not mandate any specific supported algorithms like This document does not mandate any specific supported algorithms like
Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the
skipping to change at page 20, line 30 skipping to change at page 21, line 39
5.1. Requesting a new certificate from a PKI 5.1. Requesting a new certificate from a PKI
There are different approaches to request a certificate from a PKI. There are different approaches to request a certificate from a PKI.
These approaches differ on the one hand in the way the EE can These approaches differ on the one hand in the way the EE can
authenticate itself to the PKI it wishes to get a new certificate authenticate itself to the PKI it wishes to get a new certificate
from and on the other hand in its capabilities to generate a proper from and on the other hand in its capabilities to generate a proper
new key pair. The authentication means may be as follows: new key pair. The authentication means may be as follows:
o Using a certificate from a trusted PKI and the corresponding o Using a certificate from a trusted PKI and the corresponding
private key, e.g., a manufacturer certificate private key, e.g., a manufacturer issued certificate
o Using the certificate to be updated and the corresponding private o Using the certificate to be updated and the corresponding private
key key
o Using a shared secret known to the EE and the PKI o Using a shared secret known to the EE and the PKI
Typically, such EE requests a certificate from a CA. When the (L)RA/ Typically, such EE requests a certificate from a CA. When the PKI
CA responds with a message containing a certificate, the EE MUST management entity responds with a message containing a certificate,
reply with a confirmation message. The (L)RA/CA then MUST send the EE MUST reply with a confirmation message. The PKI management
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 are RSA and ECDSA, which can technically be used for
signature calculation regardless of potentially intended restrictions signature calculation regardless of potentially intended restrictions
of the key usage. of the key usage.
The requesting EE provides the binding of the proof-of-possession to The requesting EE provides the binding of the proof-of-possession to
its identity by signature-based or MAC-based protection of the CMP its identity by signature-based or MAC-based protection of the CMP
request message containing that POPO. The (L)RA/CA needs to verify request message containing that POPO. The PKI management entity
whether this EE is authorized to obtain a certificate with the needs to verify whether this EE is authorized to obtain a certificate
requested subject and other attributes and extensions. Especially with the requested subject and other attributes and extensions.
when removing the protection provided by the EE and applying a new Especially when removing the protection provided by the EE and
protection the (L)RA MUST verify in particular the included proof-of- applying a new protection the PKI management entity MUST verify in
possession self-signature of the certTemplate using the public key of particular the included proof-of-possession self-signature of the
the requested certificate and MUST check that the EE, as certTemplate using the public key of the requested certificate and
authenticated by the message protection, is authorized to request a MUST check that the EE, as authenticated by the message protection,
certificate with the subject as specified in the certTemplate (see is authorized to request a certificate with the subject as specified
Section 6.1.2). in the certTemplate (see Section 6.1.2).
There are several ways to install the Root CA certificate of a new There are several ways to install the Root CA certificate of a new
PKI on an EE. The installation can be performed in an out-of-band PKI on an EE. The installation can be performed in an out-of-band
manner, using general messages, a voucher [RFC8366], or other formats manner, using general messages, a voucher [RFC8366], or other formats
for enrollment, or in-band of CMP by the caPubs field in the for enrollment, or in-band of CMP by the caPubs field in the
certificate response message. In case the installation of the new certificate response message. In case the installation of the new
Root CA certificate is performed using the caPubs field, the root CA certificate is performed using the caPubs field, the
certificate response message MUST be properly authenticated, and the certificate response message MUST be properly authenticated, and the
sender of this message MUST be authorized to install new Root CA sender of this message MUST be authorized to install new root CA
certificates on the EE. This authorization MUST be indicated by the certificates on the EE. This authorization can be indicated by using
extended key usage in the (L)RA/CA certificate as specified in CMP pre-shared keys for the CMP message protection.
Updates [I-D.brockhaus-lamps-cmp-updates].
5.1.1. A certificate from a new PKI with signature protection 5.1.1. Request a certificate from a new PKI with signature protection
This message sequence should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate of a new PKI using an existing certificate from an certificate of a new PKI using an existing certificate from an
external PKI, e.g., a manufacturer certificate, to prove its identity external PKI, e.g., a manufacturer certificate, to prove its identity
to the new PKI. The EE already has established trust in this new PKI to the new PKI. The EE already has established trust in this new PKI
it is about to enroll to, e.g., by configuration means. The it is about to enroll to, e.g., by voucher exchgnge or configuration
initialization request message is signature-protected using the means. The initialization request message is signature-protected
existing certificate. using the existing certificate.
Preconditions: Preconditions:
1 The EE MUST have a certificate enrolled by an external PKI in 1 The EE MUST have a certificate enrolled by an external PKI in
advance to this transaction to authenticate itself to the (L)RA/CA advance to this PKI management operation to authenticate itself to
using signature-based protection, e.g., using a manufacturer the PKI management entity using signature-based protection, e.g.,
certificate. using a manufacturer issued certificate.
2 The EE SHOULD know the subject name of the new CA it requests a 2 The EE SHOULD know the subject name of the new CA it requests a
certificate from; this name MAY be established using an enrollment certificate from; this name MAY be established using an enrollment
voucher or other configuration means. If the EE does not know the voucher or other configuration means. If the EE does not know the
name of the CA, the (L)RA/CA MUST know where to route this request name of the CA, the PKI management entity MUST know where to route
to. this request to.
3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 3 The EE MUST authenticate responses from the PKI management entity;
established using an enrollment voucher or other configuration trust MAY be established using an enrollment voucher or other
means configuration means
4 The (L)RA/CA MUST trust the external PKI the EE uses to 4 The PKI management entity MUST trust the external PKI the EE uses
authenticate itself; trust MAY be established using some to authenticate itself; trust MAY be established using some
configuration means configuration means
This message sequence is like that given in [RFC4210] Appendix E.7. This PKI management operation is like that given in [RFC4210]
Appendix E.7.
Message flow: Message flow:
Step# EE (L)RA/CA 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
confirm confirm
6 <- ip <- 6 <- ip <-
7 handle ip 7 handle ip
8 In case of status 8 In case of status
skipping to change at page 22, line 41 skipping to change at page 23, line 48
ip message, no certConf ip message, no certConf
and pkiConf are sent and pkiConf are sent
9 format certConf (optional) 9 format certConf (optional)
10 -> certConf -> 10 -> certConf ->
11 handle, re-protect or 11 handle, re-protect or
forward certConf forward certConf
12 format or receive PKIConf 12 format or receive PKIConf
13 <- pkiConf <- 13 <- pkiConf <-
14 handle pkiConf (optional) 14 handle pkiConf (optional)
For this message sequence the EE MUST include exactly one single For this PKI management operation the EE MUST include exactly one
CertReqMsg in the ir. If more certificates are required, further single CertReqMsg in the ir. If more certificates are required,
requests MUST be sent using separate CMP Messages. If the EE wants further requests MUST be sent using separate CMP messages. If the EE
to omit sending a certificate confirmation message after receiving wants to omit sending a certificate confirmation message after
the ip to reduce the number of protocol messages exchanged in a receiving the ip to reduce the number of protocol messages exchanged
transaction, it MUST request this by setting the implicitControlValue in this PKI management operation, it MUST request this by setting the
in the ir to NULL. implicitControlValue in the ir to NULL.
If the CA accepts the request it MUST return the new certificate in If the CA accepts the certificate request it MUST return the new
the certifiedKeyPair field of the ip message. If the EE requested to certificate in the certifiedKeyPair field of the ip message. If the
omit sending a certConf message after receiving the ip, the (L)RA/CA EE requested to omit sending a certConf message after receiving the
MAY confirm this by also setting the implicitControlValue in the ip ip, the PKI management entity MAY confirm it by also setting the
to NULL. implicitControlValue to NULL or MAY rejects it by omitting the
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 (L)RA/CA the confirmation as follows MUST be not granted by the PKI management entity the confirmation as follows
performed. If the EE successfully receives the certificate and MUST be performed. If the EE successfully receives the certificate
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 (L)RA/CA with a pkiConf message. If the (L)RA/CA answered by the PKI management entity with a pkiConf message. If the
does not receive the expected certConf message in time it MUST handle PKI management entity does not receive the expected certConf message
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 (L)RA/CA must If the certificate request was refused by the CA, the PKI management
return an ip message containing the status code "rejection" and no entity must return an ip message containing the status code
certifiedKeyPair field. Such an ip message MUST NOT be followed by "rejection" and no certifiedKeyPair field. Such an ip message MUST
the certConf and pkiConf messages. NOT be followed by the certConf and pkiConf messages.
Detailed message description: Detailed message description:
Certification Request -- ir Certification Request -- ir
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
skipping to change at page 24, line 43 skipping to change at page 26, line 4
Certification Response -- ip Certification Response -- ip
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
body body
-- The response of the CA to the request as appropriate -- The response of the CA to the request as appropriate
ip REQUIRED ip REQUIRED
caPubs OPTIONAL caPubs OPTIONAL
-- MAY be used -- MAY be used
-- If used it MUST contain only the root certificate of the -- If used it MUST contain only the root certificate of the
-- certificate contained in certOrEncCert -- certificate contained in certOrEncCert
response REQUIRED response REQUIRED
-- MUST be exactly one CertResponse -- MUST be exactly one CertResponse
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be set to 0
status REQUIRED status REQUIRED
-- 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 no certConf and pkiConf messages will -- In case of rejection certConf and pkiConf messages MUST NOT
-- be sent -- 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" and in this case
-- the transaction MUST be terminated -- 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
skipping to change at page 25, line 40 skipping to change at page 26, line 48
-- MUST be absent in case of local key-generation -- MUST be absent in case of local key-generation
-- MUST contain the encrypted private key in an EnvelopedData -- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in section 5.1.5 in case the private -- structure as specified in section 5.1.5 in case the private
-- key was generated centrally -- key was generated centrally
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 4.3
-- MUST contain the chain of the issued certificate -- MUST contain the chain of the certificate present in
-- certOrEncCert
-- Duplicate certificates MAY be omitted -- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf Certificate Confirmation -- certConf
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
body body
-- The message of the EE sends confirmation to the (L)RA/CA -- The message of the EE sends confirmation to the PKI
-- to accept or reject the issued certificates -- management entity to accept or reject the issued certificates
certConf REQUIRED certConf REQUIRED
-- MUST be exactly one CertStatus -- MUST be exactly one CertStatus
CertStatus REQUIRED CertStatus REQUIRED
certHash REQUIRED certHash REQUIRED
-- MUST be the hash of the certificate, using the same hash -- MUST be the hash of the certificate, using the same hash
-- algorithm as used to create the certificate signature -- algorithm as used to create the certificate signature
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be set to 0
status RECOMMENDED status RECOMMENDED
-- PKIStatusInfo structure SHOULD be present -- PKIStatusInfo structure SHOULD be present
-- Omission indicates acceptance of the indicated certificate -- Omission indicates acceptance of the indicated certificate
status REQUIRED status REQUIRED
-- positive values allowed: "accepted" -- positive values allowed: "accepted"
-- negative values allowed: "rejection" -- negative values allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging or logging -- MAY be any human-readable text for debugging, logging, or to
-- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MUST be present if status is "rejection" -- MUST be present if status is "rejection"
-- MUST be absent if the status is "accepted" -- MUST be absent if the status is "accepted"
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
-- MUST use the same certificate as for protection of the ir -- MUST use the same certificate as for protection of the ir
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- SHOULD contain the protection certificate together with its -- SHOULD contain the protection certificate together with its
-- chain -- chain, but MAY be omitted if the message size is critical and
-- the PKI management entity did cash the extraCerts from the ir
-- If present, the first certificate in this field MUST be the -- If present, the first certificate in this field MUST be the
-- certificate used for signing this message -- certificate used for signing this message
-- Self-signed certificates SHOULD NOT be included in -- Self-signed certificates SHOULD NOT be included in
-- extraCerts and -- extraCerts and
-- MUST NOT be trusted based on the listing in extraCerts in -- MUST NOT be trusted based on the listing in extraCerts in
-- any case -- any case
PKI Confirmation -- pkiConf PKI Confirmation -- pkiConf
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
body body
pkiConf REQUIRED pkiConf REQUIRED
-- The content of this field MUST be NULL -- The content of this field MUST be NULL
protection REQUIRED protection REQUIRED
skipping to change at page 27, line 9 skipping to change at page 28, line 19
body body
pkiConf REQUIRED pkiConf REQUIRED
-- The content of this field MUST be NULL -- The content of this field MUST be NULL
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
-- SHOULD use the same certificate as for protection of the ip -- SHOULD use the same certificate as for protection of the ip
extraCerts RECOMMENDED extraCerts RECOMMENDED
-- SHOULD contain the protection certificate together with its -- SHOULD contain the protection certificate together with its
-- chain -- chain, but MAY be omitted if the message size is critical and
-- the PKI management entity did cash the extraCerts from the ip
-- If present, the first certificate in this field MUST be the -- If present, the first certificate in this field MUST be the
-- certificate used for signing this message -- certificate used for signing this message
-- Self-signed certificates SHOULD NOT be included in extraCerts -- Self-signed certificates SHOULD NOT be included in extraCerts
-- and -- and
-- MUST NOT be trusted based on the listing in extraCerts in -- MUST NOT be trusted based on the listing in extraCerts in
-- any case -- any case
5.1.2. A certificate from a trusted PKI with signature protection 5.1.2. Request a certificate from a trusted PKI with signature
protection
< TBD: In case the PKI is already trusted the cr/cp messages could be < TBD: In case the PKI is already trusted the cr/cp messages could be
used instead of ir/ip. It needs to be decided, whether an additional used instead of ir/ip. It needs to be decided, whether an additional
section should be added here, or the previous section should be section should be added here, or the previous section should be
extended to also cover this use case. > extended to also cover this use case. >
5.1.3. Update an existing certificate with signature protection 5.1.3. Update an existing certificate with signature protection
This message sequence should be used by an EE to request an update of This PKI management operation should be used by an EE to request an
one of the certificates it already has and that is still valid. The update of one of the certificates it already has and that is still
EE uses the certificate it wishes to update to prove its identity and valid. The EE uses the certificate it wishes to update to prove its
possession of the private key for the certificate to be updated to identity and possession of the private key for the certificate to be
the PKI. Therefore, the key update request message is signed using updated to the PKI. Therefore, the key update request message is
the certificate that is to be updated. signed using the certificate that is to be updated.
The general message flow for this message sequence is the same as The general message flow for this PKI management operation is the
given in Section 5.1.1. same as given in Section 5.1.1.
Preconditions: Preconditions:
1 The certificate the EE wishes to update MUST NOT be expired or 1 The certificate the EE wishes to update MUST NOT be expired or
revoked. revoked.
2 A new public-private key pair SHOULD be used. 2 A new public-private key pair SHOULD be used.
The message sequence for this exchange is like that given in The message sequence for this PKI management operation is like that
[RFC4210] Appendix D.6. given in [RFC4210] Appendix D.6.
The message sequence for this exchange is identical to that given in The message sequence for this PKI management operation is identical
Section 5.1.1, with the following changes: to that given in Section 5.1.1, with the following changes:
1 The body of the first request and response MUST be kur and kup, 1 The body of the first request and response MUST be kur and kup,
respectively. respectively.
2 Protection of the kur MUST be performed using the certificate to 2 Protection of the kur MUST be performed using the certificate to
be updated. be updated.
3 The subject field of the CertTemplate MUST contain the subject 3 The subject field of the CertTemplate MUST contain the subject
name of the existing certificate to be updated, without name of the existing certificate to be updated, without
modifications. modifications.
4 The CertTemplate MUST contain the subject, issuer and publicKey 4 The CertTemplate MUST contain the subject, issuer and publicKey
fields only. fields only.
5 The regCtrl OldCertId SHOULD be used to make clear, even in case 5 The regCtrl OldCertId SHOULD be used to make clear, even in case
an (L)RA changes the message protection, which certificate is to an (L)RA changes the message protection, which certificate is to
be used. be updated.
6 The caPubs field in the kup message MUST be absent. 6 The caPubs field in the kup message MUST be absent.
As part of the certReq structure of the kur the control is added As part of the certReq structure of the kur the control is added
right after the certTemplate. right after the certTemplate.
controls controls
type RECOMMENDED type RECOMMENDED
-- MUST be the value id-regCtrl-oldCertID, if present -- MUST be the value id-regCtrl-oldCertID, if present
value value
issuer REQUIRED issuer REQUIRED
serialNumber REQUIRED serialNumber REQUIRED
-- MUST contain the issuer and serialNumber of the certificate -- MUST contain the issuer and serialNumber of the certificate
-- to be updated -- to be updated
5.1.4. A certificate from a PKI with MAC protection 5.1.4. Request a certificate from a PKI with MAC protection
This message sequence should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate of a new PKI without having a certificate to prove its certificate of a new PKI without having a certificate to prove its
identity to the target PKI, but there is a shared secret established identity to the target PKI, but there is a shared secret established
between the EE and the PKI. Therefore, the initialization request is between the EE and the PKI. Therefore, the initialization request is
MAC-protected using this shared secret. The (L)RA checking the MAC- MAC-protected using this shared secret. The PKI management entity
protection SHOULD replace this protection according to Section 6.1.2 checking the MAC-protection SHOULD replace this protection according
in case the next hop does not know the shared secret. to Section 6.1.2 in case the next hop does not know the shared
secret.
For requirements with regard to proper random number and key For requirements with regard to proper random number and key
generation please refer to [RFC4086]. generation please refer to [RFC4086].
The general message flow for this message sequence is the same as The general message flow for this PKI management operation is the
given in Section 5.1.1. same as given in Section 5.1.1.
Preconditions: Preconditions:
1 The EE and the (L)RA/CA MUST share a symmetric key, this MAY be 1 The EE and the PKI management ectitiy MUST share a symmetric key,
established by a service technician during initial local this MAY be established by a service technician during initial
configuration. local configuration.
2 The EE SHOULD know the subject name of the new CA it requests a 2 The EE SHOULD know the subject name of the new CA it requests a
certificate from; this name MAY be established using an enrollment certificate from; this name MAY be established using an enrollment
voucher or other configuration means. If the EE does not know the voucher or other configuration means. If the EE does not know the
name of the CA, the (L)RA/CA MUST know where to route this request name of the CA, the (L)RA/CA MUST know where to route this request
to. to.
3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 3 The EE MUST authenticate responses from the PKI management entity;
established using the shared symmetric key. trust MAY be established using the shared symmetric key.
The message sequence for this exchange is like that given in The message sequence for this PKI management operation is like that
[RFC4210] Appendix D.4. given in [RFC4210] Appendix D.4.
The message sequence for this exchange is identical to that given in The message sequence for this PKI management operation is identical
Section 5.1.1, with the following changes: to that given in Section 5.1.1, with the following changes:
1 The protection of all messages MUST be calculated using Message 1 The protection of all messages MUST be calculated using Message
Authentication Code (MAC); the protectionAlg field MUST be id- Authentication Code (MAC); the protectionAlg field MUST be id-
PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. PasswordBasedMac as described in section 5.1.3.1 of [RFC4210].
2 The sender MUST contain a name representing the originator of the 2 The sender MUST contain a name representing the originator of the
message. The senderKID MUST contain a reference all participating message. The senderKID MUST contain a reference all participating
entities can use to identify the symmetric key used for the entities can use to identify the symmetric key used for the
protection. protection.
3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 3 The extraCerts of the ir, certConf, and PKIConf messages MUST be
absent. absent.
4 The extraCerts of the ip message MUST contain the chain of the 4 The extraCerts of the ip message MUST contain the chain of the
issued certificate and root certificates SHOULD not be included issued certificate and root certificates SHOULD not be included
and MUST NOT be trusted in any case. and MUST NOT be directly trusted in any case.
Part of the protectionAlg structure, where the algorithm identifier Part of the protectionAlg structure, where the algorithm identifier
MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields
of PBMParameter SHOULD remain constant for message protection of PBMParameter SHOULD remain constant for message protection
throughout this certificate management transaction to reduce the throughout this PKI management operation to reduce the computational
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 -- The one-way function SHA-1 MUST be supported due to
-- [RFC4211] requirements, but SHOULD NOT be used any more -- [RFC4211] requirements, but SHOULD NOT be used any more
-- SHA-256 SHOULD be used instead -- SHA-256 SHOULD be used instead
iterationCount REQUIRED iterationCount REQUIRED
-- MUST be a limited number of times the OWF is applied -- MUST be a limited number of times the one-way function is
-- applied
-- To prevent brute force and dictionary attacks a reasonable -- To prevent brute force and dictionary attacks a reasonable
-- high number SHOULD be used -- high number SHOULD be used
mac REQUIRED mac REQUIRED
-- MUST be the algorithm identifier of the MAC algorithm used -- MUST be the algorithm identifier of the MAC algorithm used
-- The MAC function HMAC-SHA1 MUST be supported due to -- The MAC function HMAC-SHA1 MUST be supported due to
-- [RFC4211] requirements, but SHOULD NOT be used any more -- [RFC4211] requirements, but SHOULD NOT be used any more
-- HMAC-SHA-256 SHOULD be used instead -- HMAC-SHA-256 SHOULD be used instead
< TBD: SHA-1 is no collision resistant hash algorithm. Due to this 5.1.5. Request a certificate from a legacy PKI using PKCS#10 request
fact the usage of SHA-1 has significantly decreased. Currently HMAC-
SHA-1seems relatively secure, it is currently recommended by
cryptographers to also depreciate the uses of SHA-1 in the context of
HMAC calculation. Should we depreciate the support of SHA-1 here
completely? >
5.1.5. A certificate from a legacy PKI using PKCS#10 request
This message sequence should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] certificate of a legacy PKI only capable to process PKCS#10 [RFC2986]
certification requests. The EE can prove its identity to the target certification requests. The EE can prove its identity to the target
PKI by using various protection means as described in Section 5.1.1 PKI by using various protection means as described in Section 5.1.1
or Section 5.1.4. or Section 5.1.4.
In contrast to the other transactions described in Section 5.1, this In contrast to the other PKI management operations described in
transaction uses PKCS#10 [RFC2986] instead of CRMF [RFC4211] for the Section 5.1, this transaction uses PKCS#10 [RFC2986] instead of CRMF
certificate request for compatibility reasons with legacy CA systems [RFC4211] for the certificate request for compatibility reasons with
that require a PKCS#10 certificate request and cannot process CMP legacy CA systems that require a PKCS#10 certificate request and
[RFC4210] or CRMF [RFC4211] messages. In such case the (L)RA must cannot process CRMF [RFC4211] requests. In such case the PKI
extract the PKCS#10 certificate request from the p10cr and provides management entity must extract the PKCS#10 certificate request from
it separately to the CA. the p10cr and provides it separately to the CA.
The general message flow for this message sequence is the same as The general message flow for this PKI management operation is the
given in Section 5.1.1, but the public key is contained in the same as given in Section 5.1.1, but the public key is contained in
subjectPKInfo of the PKCS#10 certificate request. the subjectPKInfo of the PKCS#10 certificate request.
Preconditions: Preconditions:
1 The EE MUST either have a certificate enrolled from this or any 1 The EE MUST either have a certificate enrolled from this or any
other accepted PKI, or a shared secret known to the PKI and the EE other accepted PKI, or a shared secret known to the PKI and the EE
to authenticate itself to the (L)RA/CA. to authenticate itself to the RA.
2 The EE SHOULD know the subject name of the CA it requests a 2 The EE SHOULD know the subject name of the CA it requests a
certificate from; this name MAY be established using an enrollment certificate from; this name MAY be established using an enrollment
voucher or other configuration means. If the EE does not know the voucher or other configuration means. If the EE does not know the
name of the CA, the (L)RA/CA MUST know where to route this request name of the CA, the RA MUST know where to route this request to.
to.
3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 3 The EE MUST authenticate responses from the RA; trust MAY be
established by an available root certificate, using an enrollment established by an available root certificate, using an enrollment
voucher, or other configuration means. voucher, or other configuration means.
4 The (L)RA/CA MUST trust the current or the PKI the EE uses to 4 The RA MUST trust the current or the PKI the EE uses to
authenticate itself; trust MAY be established by a corresponding authenticate itself; trust MAY be established by a corresponding
available root certificate or using some configuration means. available root certificate or using some configuration means.
The profile for this exchange is identical to that given in The message sequence for this PKI management operation is identical
Section 5.1.1, with the following changes: to that given in Section 5.1.1, with the following changes:
1 The body of the first request and response MUST be p10cr and cp, 1 The body of the first request and response MUST be p10cr and cp,
respectively. respectively.
2 The subject name of the CA MUST be in the recipient field of the 2 The subject name of the CA MUST be in the recipient field of the
p10cr message header. p10cr message header.
3 The certReqId in the cp message MUST be 0. 3 The certReqId in the cp message MUST be 0.
4 The caPubs field in the cp message SHOULD be absent. 4 The caPubs field in the cp message SHOULD be absent.
skipping to change at page 32, line 24 skipping to change at page 33, line 24
body body
-- The request of the EE for a new certificate using a PKCS#10 -- The request of the EE for a new certificate using a PKCS#10
-- certificate request -- certificate request
p10cr REQUIRED p10cr REQUIRED
CertificationRequestInfo REQUIRED CertificationRequestInfo REQUIRED
version REQUIRED version REQUIRED
-- MUST be set to 0 to indicate PKCS#10 V1.7 -- MUST be set to 0 to indicate PKCS#10 V1.7
subject REQUIRED subject REQUIRED
-- MUST contain the suggested subject name of the EE -- MUST contain the suggested subject name of the EE
subjectPKInfo REQUIRED subjectPKInfo REQUIRED
-- MUST include the subject public key algorithm ID and value algorithm REQUIRED
-- MUST include the subject public key algorithm ID
subjectPublicKey REQUIRED
-- MUST include the subject public key algorithm value
attributes OPTIONAL attributes OPTIONAL
-- MAY contain a set of end-entity-specific attributes or X.509 -- MAY contain a set of end-entity-specific attributes or X.509
-- extensions to be included in the requested certificate or used -- extensions to be included in the requested certificate or used
-- otherwise -- otherwise
signatureAlgorithm REQUIRED signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256
signature REQUIRED signature REQUIRED
-- MUST containing the self-signature for proof-of-possession -- MUST containing the self-signature for proof-of-possession
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 4.3
5.1.6. Generate the key pair centrally at the (L)RA/CA 5.1.6. Generate the key pair centrally at the PKI management entity
This functional extension can be applied in combination with This functional extension can be applied in combination with
certificate enrollment as described in Section 5.1.1 and certificate enrollment as described in Section 5.1.1 and
Section 5.1.4. The functional extension can be used in case an EE is Section 5.1.4. The functional extension can be used in case an EE is
not able or is not willing to generate its new public-private key not able or is not willing to generate its new public-private key
pair itself. It is a matter of the local implementation which pair itself. It is a matter of the local implementation which PKI
central PKI components will perform the key generation. This management entity will perform the key generation. This entity MUST
component must have a proper (L)RA/CA certificate containing the have a certificate containing the additional extended key usage
additional extended key usage id-kp-cmcKGA to be identified by the EE extension id-kp-cmcKGA to be identified by the EE as a legitimate
as a legitimate key-generation instance. In case the (L)RA generated key-generation authority. In case the PKI management entity
the new key pair for the EE, it can use Section 5.1.1 to generated the new key pair for the EE, it can use Section 5.1.1 to
Section 5.1.4 to request the certificate for this key pair as usual. Section 5.1.4 to request the certificate for this key pair as usual.
Generally speaking, in a machine-to-machine scenario it is strongly Generally speaking, in a machine-to-machine scenario it is strongly
preferable to generate public-private key pairs locally at the EE. preferable to generate public-private key pairs locally at the EE.
Together with proof-of-possession of the private key in the Together with proof-of-possession of the private key in the
certification request, this is to make sure that only the entity certification request, this is to make sure that only the entity
identified in the newly issued certificate is the only entity who identified in the newly issued certificate is the only entity who
ever hold the private key. ever hold the private key.
There are some cases where an EE is not able or not willing to There are some cases where an EE is not able or not willing to
skipping to change at page 33, line 40 skipping to change at page 34, line 42
certificate enrollment communication, it is typical not time certificate enrollment communication, it is typical not time
critical. critical.
Note: Besides the initial enrollment right after the very first Note: Besides the initial enrollment right after the very first
bootup of the device, where entropy available on the device may be bootup of the device, where entropy available on the device may be
insufficient, we do not see any good reason for central key insufficient, we do not see any good reason for central key
generation. generation.
Note: As mentioned in Section 3.1 central key generation may be Note: As mentioned in Section 3.1 central key generation may be
required in a push model, where the certificate response message is required in a push model, where the certificate response message is
transferred by the (L)RA/CA to the EE without receiving a previous transferred by the PKI management entity to the EE without receiving
request message. a previous request message.
If the EE wishes to request central key generation, it MUST fill the If the EE wishes to request central key generation, it MUST fill the
subjectPublicKey field in the certTemplate structure of the request subjectPublicKey field in the certTemplate structure of the request
message with a zero-length BIT STRING. This indicates to the (L)RA/ message with a zero-length BIT STRING. This indicates to the PKI
CA that a new key pair shall be generated centrally on behalf of the management entity that a new key pair shall be generated centrally on
EE. behalf of the EE.
Note: As the protection of centrally generated keys in the response Note: As the protection of centrally generated keys in the response
message is being extended from EncryptedValue to EncryptedKey by CMP message is being extended from EncryptedValue to EncryptedKey by CMP
Updates [I-D.brockhaus-lamps-cmp-updates] also the alternative Updates [I-D.ietf-lamps-cmp-updates] also the alternative
EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use
of EncryptedValue has been deprecated in favor of the EnvelopedData of EncryptedValue has been deprecated in favor of the EnvelopedData
structure. Therefore, this profile specifies using EnvelopedData as structure. Therefore, this profile specifies using EnvelopedData as
specified in CMS Section 6 [RFC5652] to offer more crypto agility. specified in CMS Section 6 [RFC5652] to offer more crypto agility.
+------------------------------+ +------------------------------+
| EnvelopedData | | EnvelopedData |
| [RFC5652] section 6 | | [RFC5652] section 6 |
| +--------------------------+ | | +--------------------------+ |
| | SignedData | | | | SignedData | |
| | [RFC5652] section 5 | | | | [RFC5652] section 5 | |
| | +----------------------+ | | | | +----------------------+ | |
| | | privateKey | | | | | | privateKey | | |
| | | OCTET STRING | | | | | | OCTET STRING | | |
| | +----------------------+ | | | | +----------------------+ | |
| +--------------------------+ | | +--------------------------+ |
+------------------------------+ +------------------------------+
Figure 3: Encrypted private key container Figure 3: Encrypted private key container
The (L)RA/CA delivers the private key in the privateKey field in the The PKI management entity delivers the private key in the privateKey
certifiedKeyPair structure of the response message also containing field in the certifiedKeyPair structure of the response message also
the newly issued certificate. containing the newly issued certificate.
The private key MUST be wrapped in a SignedData structure, as The private key MUST be wrapped in a SignedData structure, as
specified in CMS Section 5 [RFC5652], signed by the KGA generating specified in CMS Section 5 [RFC5652], signed by the KGA generating
the key pair. The signature MUST be performed using a CMP signer the key pair. The signature MUST be performed using a CMP signer
certificate asserting the extended key usage kp-id-cmpKGA as certificate asserting the extended key usage kp-id-cmpKGA as
described in CMP Updates [I-D.brockhaus-lamps-cmp-updates] to show described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the
the authorization to generate key pairs on behalf of an EE. authorization to generate key pairs on behalf of an EE.
This SignedData structure MUST be wrapped in an EnvelopedData This SignedData structure MUST be wrapped in an EnvelopedData
structure, as specified in CMS Section 6 [RFC5652], encrypting it structure, as specified in CMS Section 6 [RFC5652], encrypting it
using a newly generated symmetric content-encryption key. using a newly generated symmetric content-encryption key.
Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210]
this content-encryption key is not generated on the EE side. As we this content-encryption key is not generated on the EE side. As we
just mentioned, central key generation should only be used in this just mentioned, central key generation should only be used in this
profile in case of lack of randomness on the EE. profile in case of lack of randomness on the EE.
As part of the EnvelopedData structure this content-encryption key As part of the EnvelopedData structure this content-encryption key
MUST be securely provided to the EE using one of three key management MUST be securely provided to the EE using one of three key management
techniques. The choice of the key management technique to be used by techniques. The choice of the key management technique to be used by
the (L)RA/CA depends on the authentication mechanism the EE choose to the PKI management entity depends on the authentication mechanism the
protect the request message, see CMP Updates section 3.4 EE choose to protect the request message, see CMP Updates section 3.4
[I-D.brockhaus-lamps-cmp-updates] for more details on which key
management technique to use. [I-D.ietf-lamps-cmp-updates] for more details on which key management
technique to use.
o MAC protected request message: The content-encryption key SHALL be o MAC protected request message: The content-encryption key SHALL be
protected using the symmetric key-encryption key management protected using the symmetric key-encryption key management
technique, see Section 5.1.6.1, only if the EE used MAC protection technique, see Section 5.1.6.1, only if the EE used MAC protection
for the respected request message. for the respected request message.
o Signature protected request message using a certificate that o Signature protected request message using a certificate that
contains a key usage extension asserting keyAgreement: The contains a key usage extension asserting keyAgreement: The
content-encryption key SHALL be protected using the key agreement content-encryption key SHALL be protected using the key agreement
key management technique, see Section 5.1.6.2, if the certificate key management technique, see Section 5.1.6.2, if the certificate
skipping to change at page 35, line 31 skipping to change at page 36, line 34
content-encryption key SHALL be protected using the key transport content-encryption key SHALL be protected using the key transport
key management technique, see Section 5.1.6.3, if the certificate key management technique, see Section 5.1.6.3, if the certificate
used by the EE for signing the respective request message contains used by the EE for signing the respective request message contains
the key usage keyEncipherment and not keyAgreement. the key usage keyEncipherment and not keyAgreement.
The key agreement key management technique can be supported by most The key agreement key management technique can be supported by most
signature algorithms, as key transport key management technique can signature algorithms, as key transport key management technique can
only be supported by a very limited number of algorithms. The only be supported by a very limited number of algorithms. The
symmetric key-encryption key management technique shall only be used symmetric key-encryption key management technique shall only be used
in combination with MAC protection, which is a side-line in this in combination with MAC protection, which is a side-line in this
profile. Therefore, this profile REQUIRES support of the key document. Therefore, if central key generation is supported, the
agreement key management technique and the key transport and support ofthe key agreement key management technique is REQUIRED and
symmetric key-encryption key management techniques are OPTIONAL. the support of key transport and symmetric key-encryption key
management techniques are OPTIONAL.
For encrypting the SignedData structure containing the private key a For encrypting the SignedData structure containing the private key a
fresh content-encryption key MUST be generated with enough entropy fresh content-encryption key MUST be generated with enough entropy
with regard to the used symmetric encryption algorithm. with regard to the used symmetric 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 possible symmetric encryption algorithm. Therefore, this strongest available symmetric encryption algorithm. Therefore, this
specification recommends using at least AES-256. specification recommends using at least AES-256.
The detailed description of the privateKey field looks like this: The detailed description of the privateKey field looks like this:
privateKey OPTIONAL privateKey OPTIONAL
-- MUST be an envelopedData structure as specified in -- MUST be an envelopedData structure as specified in
-- CMS [RFC5652] section 6 -- CMS [RFC5652] section 6
version REQUIRED version REQUIRED
-- MUST be set to 2 -- MUST be set to 2
recipientInfos REQUIRED recipientInfos REQUIRED
-- MUST be exactly one RecipientInfo -- MUST be exactly one RecipientInfo
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be either KEKRecipientInfo (see section 5.1.5.1), -- MUST be either KEKRecipientInfo (see section 5.1.5.1),
-- KeyAgreeRecipientInfo (see section 5.1.5.2), or -- KeyAgreeRecipientInfo (see section 5.1.5.2), or
-- KeyTransRecipientInfo (see section 5.1.5.3) is used -- KeyTransRecipientInfo (see section 5.1.5.3) is used
-- If central key generation is supported, support of
-- KEKRecipientInfo is REQUIRED and support of
-- KeyAgreeRecipientInfo and KeyTransRecipientInfo is OPTIONAL
encryptedContentInfo encryptedContentInfo
REQUIRED REQUIRED
contentType REQUIRED contentType REQUIRED
-- MUST be id-signedData -- MUST be id-signedData
contentEncryptionAlgorithm contentEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the symmetric -- MUST be the algorithm identifier of the symmetric
-- content-encryption algorithm used -- content-encryption algorithm used
-- As private keys need long-term protection, the use of AES-256 -- As private keys need long-term protection, the use of AES-256
-- or a stronger symmetric algorithm is RECOMMENDED -- or a stronger symmetric algorithm is RECOMMENDED
skipping to change at page 37, line 24 skipping to change at page 38, line 31
-- used for calculation of the signature bits, -- used for calculation of the signature bits,
-- like sha256WithRSAEncryption or ecdsa-with-SHA256 -- like sha256WithRSAEncryption or ecdsa-with-SHA256
-- The signature algorithm MUST be consistent with the -- The signature algorithm MUST be consistent with the
-- SubjectPublicKeyInfo field of the signer's certificate -- SubjectPublicKeyInfo field of the signer's certificate
signature REQUIRED signature REQUIRED
-- MUST be the result of the digital signature generation -- MUST be the result of the digital signature generation
5.1.6.1. Using symmetric key-encryption key management technique 5.1.6.1. Using symmetric key-encryption 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
message flow specified in Section 5.1.4 using MAC protected CMP PKI management operation specified in Section 5.1.4 using MAC
messages. The shared secret used for the MAC protection MUST also be protected CMP messages. The shared secret used for the MAC
used for the encryption of the content-encryption key but with a protection MUST also be used for the encryption of the content-
different seed in the PBMParameter sequence. To use this key encryption key but with a different seed in the PBMParameter
management technique the KEKRecipientInfo structure MUST be used in sequence. To use this key management technique the KEKRecipientInfo
the contentInfo field. structure MUST be used in the contentInfo field.
The KEKRecipientInfo structure included into the envelopedData The KEKRecipientInfo structure included into the envelopedData
structure is specified in CMS Section 6.2.3 [RFC5652]. structure is specified in CMS Section 6.2.3 [RFC5652].
The detailed description of the KEKRecipientInfo structure looks like The detailed description of the KEKRecipientInfo structure looks like
this: this:
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be KEKRecipientInfo as specified in -- MUST be KEKRecipientInfo as specified in
-- CMS section 6.2.3 [RFC5652] -- CMS section 6.2.3 [RFC5652]
skipping to change at page 38, line 49 skipping to change at page 39, line 49
< TBD: To make use of a different symmetric keys for encrypting the < TBD: To make use of a different symmetric keys for encrypting the
private key and for MAC-protection of the CMP message, we derive private key and for MAC-protection of the CMP message, we derive
another key using the same PBMParameter structure from CMP, even another key using the same PBMParameter structure from CMP, even
though from the perspective of field names, it is not intended to be though from the perspective of field names, it is not intended to be
used for deriving encryption keys. Does anyone sees a better used for deriving encryption keys. Does anyone sees a better
solution here? > solution here? >
5.1.6.2. Using key agreement key management technique 5.1.6.2. Using key agreement key management technique
This key management technique can be applied in combination with the This key management technique can be applied in combination with the
message flow specified in Section 5.1.1 using signature-based PKI management operations specified in Section 5.1.1 to Section 5.1.3
protected CMP messages. The public key of the EE certificate used using signature-based protected CMP messages. The public key of the
for the signature-based protection of the request message MUST also EE certificate used for the signature-based protection of the request
be used for the Ephemeral-Static Diffie-Hellmann key establishment of message MUST also be used for the Ephemeral-Static Diffie-Hellmann
the content-encryption key. To use this key management technique the key establishment of the content-encryption key. To use this key
KeyAgreeRecipientInfo structure MUST be used in the contentInfo management technique the KeyAgreeRecipientInfo structure MUST be used
field. in the contentInfo field.
The KeyAgreeRecipientInfo structure included into the envelopedData The KeyAgreeRecipientInfo structure included into the envelopedData
structure is specified in CMS Section 6.2.2 [RFC5652]. structure is specified in CMS Section 6.2.2 [RFC5652].
The detailed description of the KeyAgreeRecipientInfo structure looks The detailed description of the KeyAgreeRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be KeyAgreeRecipientInfo as specified in -- MUST be KeyAgreeRecipientInfo as specified in
version REQUIRED version REQUIRED
skipping to change at page 39, line 39 skipping to change at page 40, line 39
-- MUST be the same as in the contentEncryptionAlgorithm field -- MUST be the same as in the contentEncryptionAlgorithm field
recipientEncryptedKeys recipientEncryptedKeys
REQUIRED REQUIRED
-- MUST be exactly one recipientEncryptedKey sequence -- MUST be exactly one recipientEncryptedKey sequence
recipientEncryptedKey recipientEncryptedKey
REQUIRED REQUIRED
rid REQUIRED rid REQUIRED
rKeyId REQUIRED rKeyId REQUIRED
subjectKeyID subjectKeyID
REQUIRED REQUIRED
-- MUST contain the same value as the senderKID in the respective -- MUST contain the same value as the senderKID in the
-- request messages -- respective request messages
encryptedKey encryptedKey
REQUIRED REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
5.1.6.3. Using key transport key management technique 5.1.6.3. Using key transport key management technique
This key management technique can be applied in combination with the This key management technique can be applied in combination with the
message flow specified in Section 5.1.1 using signature-based PKI management operations specified in Section 5.1.1 to Section 5.1.3
protected CMP messages. The public key of the EE certificate used using signature-based protected CMP messages. The public key of the
for the signature-based protection of the request message MUST also EE certificate used for the signature-based protection of the request
be used for key encipherment of the content-encryption key. To use message MUST also be used for key encipherment of the content-
this key management technique the KeyTransRecipientInfo structure encryption key. To use this key management technique the
MUST be used in the contentInfo field. KeyTransRecipientInfo structure MUST be used in the contentInfo
field.
The KeyTransRecipientInfo structure included into the envelopedData The KeyTransRecipientInfo structure included into the envelopedData
structure is specified in CMS Section 6.2.1 [RFC5652]. structure is specified in CMS Section 6.2.1 [RFC5652].
The detailed description of the KeyTransRecipientInfo structure looks The detailed description of the KeyTransRecipientInfo structure looks
like this: like this:
recipientInfo REQUIRED recipientInfo REQUIRED
-- MUST be KeyTransRecipientInfo as specified in -- MUST be KeyTransRecipientInfo as specified in
-- CMS section 6.2.1 [RFC5652] -- CMS section 6.2.1 [RFC5652]
skipping to change at page 40, line 34 skipping to change at page 41, line 35
REQUIRED REQUIRED
-- MUST contain the key encryption algorithm identifier used for -- MUST contain the key encryption algorithm identifier used for
-- public key encryption -- public key encryption
encryptedKey REQUIRED encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key -- MUST be the encrypted content-encryption key
5.1.7. Delayed enrollment 5.1.7. Delayed enrollment
This functional extension can be applied in combination with This functional extension can be applied in combination with
certificate enrollment as described in Section 5.1.1 to certificate enrollment as described in Section 5.1.1 to
Section 5.1.5. The functional extension can be used in case a (L)RA/ Section 5.1.5. The functional extension can be used in case a PKI
CA cannot respond to the certificate request in a timely manner, management entity cannot respond to the certificate request in a
e.g., due to offline upstream communication or required registration timely manner, e.g., due to offline upstream communication or
officer interaction. Depending on the PKI architecture, it is not required registration officer interaction. Depending on the PKI
necessary that the PKI component directly communicating with the EE architecture, it is not necessary that the PKI management entity
initiates the delayed enrollment. directly communicating with the EE initiates the delayed enrollment.
The PKI component initiating the delayed enrollment MUST include the The PKI management entity initiating the delayed enrollment MUST
status "waiting" in the response and this response MUST not contain include the status "waiting" in the response and this response MUST
the newly issued certificate. When receiving a response with status NOT contain a newly issued certificate. When receiving a response
"waiting" the EE MUST send a poll request to the (L)RA/CA. The PKI with status "waiting" the EE MUST send a poll request to the PKI
component that initiated the delayed enrollment MUST answers with a management entity. The PKI management entity that initiated the
poll response containing a checkAfter time. This value indicates the delayed enrollment MUST answers with a poll response containing a
minimum number of seconds that must elapse before the EE sends checkAfter time. This value indicates the minimum number of seconds
another poll request. As soon as the (L)RA/CA can provide the final that must elapse before the EE sends another poll request. As soon
response message for the initial request of the EE, it MUST provide as the PKI management entity can provide the final response message
this in response to a poll request. After receiving this response, for the initial request of the EE, it MUST provide this in response
the EE can continue the original message sequence as described in the to a poll request. After receiving this response, the EE can
continue the original PKI management operation as described in the
respective section of this document, e.g., send a certConf message. respective section of this document, e.g., send a certConf message.
Typically, intermediate PKI entities SHOULD NOT change the sender and Typically, intermediate PKI management entities SHOULD NOT change the
recipient nonce even in case an intermediate (L)RA modifies a request sender and recipient nonce even in case an intermediate PKI
or a response message. In the special case of polling between EE and management entity modifies a request or a response message. In the
LRA with offline transport between an LRA and RA, see Section 6.1.4, special case of polling between EE and LRA with offline transport
an exception occurs. The EE and LRA exchange pollReq and pollRep between an LRA and RA, see Section 6.1.4, an exception occurs. The
messages handle the nonce words as described. When, after pollRep, EE and LRA exchange pollReq and pollRep messages handle the nonce
the final response from the CA arrives at the LRA, the next response words as described. When, after pollRep, the final response from the
will contain the recipientNonce set to the value of the senderNonce CA arrives at the LRA, the next response will contain the
in the original request message (copied by the CA). The LRA needs to recipientNonce set to the value of the senderNonce in the original
replace the recipientNonce in this case with the senderNonce of the request message (copied by the CA). The LRA needs to replace the
last pollReq because the EE will validate it in this way. recipientNonce in this case with the senderNonce of the last pollReq
because the EE will validate it in this way.
Message flow: Message flow:
Step# EE (L)RA/CA Step# EE PKI management entity
1 format ir/cr/p10cr/kur 1 format ir/cr/p10cr/kur
As described in the As described in the
respective section respective section
in this document in this document
2 ->ir/cr/p10cr/kur-> 2 ->ir/cr/p10cr/kur->
3 handle request as described 3 handle request as described
in the respective section in the respective section
in this document in this document
4 in case no immediate final 4 in case no immediate final
response is possible, response is possible,
skipping to change at page 42, line 51 skipping to change at page 43, line 51
14 continue with line 7 14 continue with line 7
Detailed description of the first ip/cp/kup: Detailed description of the first ip/cp/kup:
Response with status 'waiting' -- ip/cp/kup Response with status 'waiting' -- ip/cp/kup
Field Value Field Value
header header
-- MUST contain a header as described for the first response -- MUST contain a header as described for the first response
-- message of the respective scheme -- message of the respective PKI management operation
body body
-- The response of the (L)RA/CA to the request in case no -- The response of the PKI management entity to the request in
-- immediate appropriate response can be sent -- case no immediate appropriate response can be sent
ip/cp/kup REQUIRED ip/cp/kup REQUIRED
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
-- MUST be set to "waiting" -- MUST be set to "waiting"
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 PROHIBITED failInfo PROHIBITED
certifiedKeyPair PROHIBITED certifiedKeyPair PROHIBITED
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the first response -- MUST contain protection as described for the first response
-- message of the respective profile, but -- message of the respective PKI management operation, but
-- MUST use the protection key of the (L)RA/CA initiating the -- MUST use the protection key of the PKI management entity
-- delayed enrollment and creating this response message -- initiating the delayed enrollment and creating this response
-- message
extraCerts REQUIRED extraCerts REQUIRED
-- MUST contain certificates as described for the first response -- MUST contain certificates as described for the first response
-- message of the respective profile. -- message of the respective PKI management operation.
-- As no new certificate is issued yet, no respective certificate -- As no new certificate is issued yet, no respective certificate
-- chain is included. -- chain is included
Polling Request -- pollReq Polling Request -- pollReq
Field Value Field Value
header header
-- MUST contain a header as described for the certConf message -- MUST contain a header as described for the certConf message
-- of the respective scheme -- of the respective PKI management operation
body body
-- The message of the EE asks for the final response or for a -- The message of the EE asks for the final response or for a
-- time to check again -- time to check again
pollReq REQUIRED pollReq REQUIRED
certReqId REQUIRED certReqId REQUIRED
-- MUST be exactly one value -- MUST be exactly one value
-- MUST be set to 0 -- MUST be set to 0
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the certConf message -- MUST contain protection as described for the certConf message
-- of the respective profile -- of the respective PKI management operation
extraCerts OPTIONAL extraCerts OPTIONAL
-- If present, it MUST contain certificates as described for the -- If present, it MUST contain certificates as described for the
-- certConf message of the respective profile. -- certConf message of the respective PKI management operation
Polling Response -- pollRep Polling Response -- pollRep
Field Value Field Value
header header
-- MUST contain a header as described for the pkiConf message -- MUST contain a header as described for the pkiConf message
-- of the respective scheme -- of the respective PKI management operation
body pollRep body pollRep
-- The message indicated the time to after which the EE may -- The message indicated the time to after which the EE may
-- send another pollReq messaged for this transaction -- send another pollReq messaged for this transaction
pollRep REQUIRED pollRep REQUIRED
-- MUST be exactly one set of the following values -- MUST be exactly one set of the following values
certReqId REQUIRED certReqId REQUIRED
-- MUST be set to 0 -- MUST be set to 0
checkAfter REQUIRED checkAfter REQUIRED
-- time in seconds to elapse before a new pollReq may be sent by -- time in seconds to elapse before a new pollReq may be sent by
-- the EE -- the EE
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the pkiConf message -- MUST contain protection as described for the pkiConf message
-- of the respective profile, but -- of the respective profile, but
-- MUST use the protection key of the (L)RA/CA that initiated the -- MUST use the protection key of the PKI management entity that
-- delayed enrollment and is creating this response message -- initiated the delayed enrollment and is creating this response
-- message
extraCerts OPTIONAL extraCerts OPTIONAL
-- If present, it MUST contain certificates as described for the -- If present, it MUST contain certificates as described for the
-- pkiConf message of the respective profile. -- pkiConf message of the respective PKI management operation.
Final response -- ip/cp/kup Final response -- ip/cp/kup
Field Value Field Value
header header
-- MUST contain a header as described for the first -- MUST contain a header as described for the first
-- response message of the respective scheme -- response message of the respective PKI management operation,
-- but the recipientNonce MUST be the senderNonce of the last -- but the recipientNonce MUST be the senderNonce of the last
-- pollReq message -- pollReq message
body body
-- The response of the (L)RA/CA to the initial request as -- The response of the PKI management entity to the initial
-- described in the respective profile -- request as described in the respective PKI management
-- operation
protection REQUIRED protection REQUIRED
-- MUST contain protection as described for the first response -- MUST contain protection as described for the first response
-- message of the respective profile, but -- message of the respective PKI management operation, but
-- MUST use the protection key of the (L)RA/CA that initiated the -- MUST use the protection key of the PKI management entity that
-- delayed enrollment and forwarding the response message -- initiated the delayed enrollment and forwarding the response
-- message
extraCerts REQUIRED extraCerts REQUIRED
-- MUST contain certificates as described for the first -- MUST contain certificates as described for the first
-- response message of the respective profile -- response message of the respective PKI management operation
5.2. Revoking a certificate 5.2. Revoking a certificate
This message sequence should be used by an entity to request the This PKI management operation should be used by an entity to request
revocation of a certificate. Here the revocation request is used by the revocation of a certificate. Here the revocation request is used
an EE to revoke one of its own certificates. A (L)RA could also act by an EE to revoke one of its own certificates. A PKI management
as an EE to revoke one of its own certificates. entity could also act as an EE to revoke one of its own certificates.
The revocation request message MUST be signed using the certificate The revocation request message MUST be signed using the certificate
that is to be revoked to prove the authorization to revoke to the that is to be revoked to prove the authorization to revoke to the
PKI. The revocation request message is signature-protected using PKI. The revocation request message is signature-protected using
this certificate. this certificate.
An EE requests the revocation of an own certificate at the CA that An EE requests the revocation of an own certificate at the CA that
issued this certificate. The (L)RA/CA responds with a message that issued this certificate. The PKI management entity responds with a
contains the status of the revocation from the CA. message that contains the status of the revocation from the CA.
Preconditions: Preconditions:
1 The certificate the EE wishes to revoke is not yet expired or 1 The certificate the EE wishes to revoke is not yet expired or
revoked. revoked.
Message flow: Message flow:
Step# EE (L)RA/CA Step# EE PKI management entity
1 format rr 1 format rr
2 -> rr -> 2 -> rr ->
3 handle, re-protect or 3 handle, re-protect or
forward rr forward rr
4 receive rp 4 receive rp
5 <- rp <- 5 <- rp <-
6 handle rp 6 handle rp
For this profile, the EE MUST include exactly one RevDetails For this PKI management operation, the EE MUST include exactly one
structure in the rr. In case no error occurred the response to the RevDetails structure in the rr message body. In case no error
rr MUST be an rp message. The (L)RA/CA MUST produce a rp containing occurred the response to the rr MUST be an rp message. The PKI
a status field with a single set of values. management entity MUST produce a rp containing a status field with a
single set of values.
Detailed message description: Detailed message description:
Revocation Request -- rr Revocation Request -- rr
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
skipping to change at page 47, line 6 skipping to change at page 48, line 18
-- As described in section 4.3 -- As described in section 4.3
Revocation Response -- rp Revocation Response -- rp
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
body body
-- The responds of the (L)RA/CA to the request as appropriate -- The responds of the PKI management entity to the request as
-- appropriate
rp REQUIRED rp REQUIRED
status REQUIRED status REQUIRED
-- MUST contain exactly one element of type PKIStatusInfo -- MUST contain exactly one element of type PKIStatusInfo
status REQUIRED status REQUIRED
-- positive value allowed: "accepted" -- positive value allowed: "accepted"
-- negative value allowed: "rejection" -- negative value allowed: "rejection"
statusString OPTIONAL statusString OPTIONAL
-- MAY be any human-readable text for debugging, logging or to -- MAY be any human-readable text for debugging, logging or to
-- display in a GUI -- display in a GUI
failInfo OPTIONAL failInfo OPTIONAL
-- MAY be present if and only if status is "rejection" -- MAY be present if and only if status is "rejection"
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3
5.3. Error reporting 5.3. Error reporting
This functionality should be used by an EE to report any error This functionality should be used by an EE to report any error
conditions upstream to the (L)RA/CA. Error reporting by the (L)RA conditions upstream to the PKI management entity. Error reporting by
downstream to the EE is described in Section 6.3. a PKI management entity downstream to the EE is described in
Section 6.3.
In case the error condition is related to specific details of an ip, In case the error condition is related to specific details of an ip,
cp, or kup response message and a confirmation is expected the error cp, or kup response message and a confirmation is expected the error
condition MUST be reported in the respective certConf message with condition MUST be reported in the respective certConf message with
negative contents. negative contents.
General error conditions, e.g., problems with the message header, General error conditions, e.g., problems with the message header,
protection, or extraCerts, and negative feedback on rp, pollRep, or protection, or extraCerts, and negative feedback on rp, pollRep, or
pkiConf messages MAY be reported in the form of an error message. pkiConf messages MAY be reported in the form of an error message.
In both situations the error is reported in the PKIStatusInfo In both situations the EE reports error in the PKIStatusInfo
structure of the respective message. structure of the respective message.
The (L)RA/CA MUST respond to an error message with a pkiConf message, Depending on the PKI architecture, the PKI management entity MUST
or with another error message if any part of the header is not valid. forward the error message (upstream) to the next PKI management
Both sides MUST treat this message as the end of the current entity and MUST terminate this PKI management operation.
transaction.
The PKIStatusInfo structure is used to report errors. The The PKIStatusInfo structure is used to report errors. The
PKIStatusInfo structure SHOULD consist of the following fields: PKIStatusInfo structure SHOULD consist of the following fields:
o status: Here the PKIStatus value rejection is the only one o status: Here the PKIStatus value "rejection" is the only one
allowed. allowed.
o statusString: Here any human-readable valid value for logging or o statusString: Here any human-readable valid value for logging or
to display in a GUI SHOULD be added. to display in a GUI SHOULD be added.
o failInfo: Here the PKIFailureInfo values MAY be used in the o failInfo: Here the PKIFailureInfo values MAY be used in the
following way. For explanation of the reason behind a specific following way. For explanation of the reason behind a specific
value, please refer to [RFC4210] Appendix F. value, please refer to [RFC4210] Appendix F.
* transactionIdInUse: This is sent in case the received request * transactionIdInUse: This is sent by a PKI management entity in
contains a transaction ID that is already in use for another case the received request contains a transaction ID that is
transaction. An EE receiving such error message SHOULD resend already in use for another transaction. An EE receiving such
the request in a new transaction using a different transaction error message SHOULD resend the request in a new transaction
ID. using a different transaction ID.
* systemUnavail or systemFailure: This is sent in case a back-end * systemUnavail or systemFailure: This is sent by a PKI
system is not available or currently not functioning correctly. management entity in case a back-end system is not available or
An EE receiving such error message SHOULD resend the request in currently not functioning correctly. An EE receiving such
a new transaction after some time. error message SHOULD resend the request in a new transaction
after some time.
Detailed error message description: Detailed error message description:
Error Message -- error Error Message -- error
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
skipping to change at page 49, line 8 skipping to change at page 50, line 36
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
extraCerts OPTIONAL extraCerts OPTIONAL
-- As described in section 4.3 -- As described in section 4.3
5.4. Support messages 5.4. Support messages
The following support messages offer on demand in-band transport of The following support messages offer on demand in-band transport of
content that may be provided by the (L)RA/CA and relevant to the EE. content that may be provided by the PKI management entity and
The general messages and general response are used for this purpose. relevant to the EE. The general messages and general response are
Depending on the environment, these requests are answered by the LRA, used for this purpose. Depending on the environment, these requests
RA, or CA. may be answered by the LRA, RA, or CA.
The general message and general response transport InfoTypeAndValue The general message and general response transport InfoTypeAndValue
structures. In addition to those infoType values defined in CMP structures. In addition to those infoType values defined in CMP
[RFC4210] further OIDs MAY be defined to define new PKI management [RFC4210] further OIDs MAY be defined to define new PKI management
operations, or general-purpose messages as needed in a specific operations, or general-purpose messages as needed in a specific
environment. environment.
Possible content described here address: Possible content described here address:
o Request of CA certificates o Request of CA certificates
skipping to change at page 49, line 24 skipping to change at page 51, line 4
structures. In addition to those infoType values defined in CMP structures. In addition to those infoType values defined in CMP
[RFC4210] further OIDs MAY be defined to define new PKI management [RFC4210] further OIDs MAY be defined to define new PKI management
operations, or general-purpose messages as needed in a specific operations, or general-purpose messages as needed in a specific
environment. environment.
Possible content described here address: Possible content described here address:
o Request of CA certificates o Request of CA certificates
o Update of Root CA certificates o Update of Root CA certificates
o Parameters needed for a planned certificate request message o Parameters needed for a planned certificate request message
o Voucher request and enrollment voucher exchange o Voucher request and enrollment voucher exchange
5.4.1. General message and response 5.4.1. General message and response
The general message transaction is similar to that given in CMP The PKI management operation is similar to that given in CMP
Appendix E.5 [RFC4210]. In this section the general message (genm) Appendix E.5 [RFC4210]. In this section the general message (genm)
and general response (genp) are described. The specific and general response (genp) are described. The specific
InfoTypeAndValue structures are described in the following sections. InfoTypeAndValue structures are described in the following sections.
The behavior in case an error occurs is described in Section 5.3. The behavior in case an error occurs is described in Section 5.3.
Message flow: Message flow:
Step# EE (L)RA/CA Step# EE PKI management entity
1 format genm 1 format genm
2 -> genm -> 2 -> genm ->
3 handle, re-protect or 3 handle, re-protect or
forward genm forward genm
4 format or receive genp 4 format or receive genp
5 <- genp <- 5 <- genp <-
6 handle genp 6 handle genp
Detailed message description: Detailed message description:
skipping to change at page 50, line 15 skipping to change at page 51, line 43
header header
-- As described in section 4.1 -- As described in section 4.1
body body
-- The request of the EE to receive information -- The request of the EE to receive information
genm REQUIRED genm REQUIRED
-- MUST contain exactly one element of type -- MUST contain exactly one element of type
-- InfoTypeAndValue -- InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying the specific scheme -- MUST be the OID identifying the specific PKI
-- described below -- management operation described below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific scheme described -- MUST be as described in the specific PKI
-- below -- management operation described below
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 4.3
General Response -- genp General Response -- genp
Field Value Field Value
header header
-- As described in section 4.1 -- As described in section 4.1
body body
-- The response of the (L)RA/CA to the information request -- The response of the PKI management entity to the
-- information request
genp REQUIRED genp REQUIRED
-- MUST contain exactly one element of type -- MUST contain exactly one element of type
-- InfoTypeAndValue -- InfoTypeAndValue
infoType REQUIRED infoType REQUIRED
-- MUST be the OID identifying the specific scheme -- MUST be the OID identifying the specific PKI
-- described below -- management operationdescribed below
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be as described in the specific scheme described -- MUST be as described in the specific PKI
-- below -- management operation described below
protection REQUIRED protection REQUIRED
-- As described in section 4.2 -- As described in section 4.2
extraCerts REQUIRED extraCerts REQUIRED
-- As described in section 4.3 -- As described in section 4.3
5.4.2. Get CA certificates 5.4.2. Get CA certificates
This scheme can be used by an EE to request CA certificates from the This PKI management operation can be used by an EE to request CA
(L)RA/CA. certificates from the PKI management entity.
An EE requests CA certificates from the (L)RA/CA by sending a general An EE requests CA certificates from the PKI management entity by
message with OID id-it-getCaCerts. The (L)RA/CA responds with a sending a general message with OID id-it-getCaCerts. The PKI
general response with the same OID that either contains a SEQUENCE of management entity responds with a general response with the same OID
certificates populated with the available CA intermediate and issuing that either contains a SEQUENCE of certificates populated with the
CA certificates or with no content in case no CA certificate is available CA intermediate and issuing CA certificates or with no
available. content in case no CA certificate is available.
< NOTE: The OID id-it-getCaCerts is not yet defined. It should be < NOTE: The OID id-it-getCaCerts is not yet defined. It should be
registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType
OIDs, see CMP Appendix F [RFC4210] on page 92. > OIDs, see CMP Appendix F [RFC4210] on page 92. >
The profile for this exchange is as given in Section 5.4.1, with the The message sequence for this PKI management operation is as given in
following specific content: Section 5.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-getCaCerts 1 the body MUST contain as infoType the OID id-it-getCaCerts
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be caCerts field 3 if present, the infoValue of the response MUST be caCerts field
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
getCaCerts OID looks like this: getCaCerts OID looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no CA certificate is available -- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available -- MUST be present if CA certificates are available
caCerts REQUIRED caCerts REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST be a sequence of CMPCertificate -- MUST be a sequence of CMPCertificate
5.4.3. Get root CA certificate update 5.4.3. Get root CA certificate update
This scheme can be used by an EE to request an update of an existing This PKI management operation can be used by an EE to request an
root CA Certificate by the EE. It utilizes the CAKeyUpdAnnContent update of an existing root CA Certificate by the EE. It utilizes the
structure as described in CMP Appendix E.4 [RFC4210] as response to a CAKeyUpdAnnContent structure as described in CMP Appendix E.4
respective general message. [RFC4210] as response to a respective general message.
An EE requests a root CA certificate update from the (L)RA/CA by An EE requests a root CA certificate update from the PKI management
sending a general message with OID id-it-caKeyUpdateInfo as infoType entity by sending a general message with OID id-it-caKeyUpdateInfo as
and no infoValue. The (L)RA/CA responds with a general response with infoType and no infoValue. The PKI management entity responds with a
the same OID that either contains the update of the root CA general response with the same OID that either contains the update of
certificate consisting of up to three certificates, or with no the root CA certificate consisting of up to three certificates, or
content in case no update is available. with no content in case no update is available.
These three certificates are described in more detail in section These three certificates are described in more detail in section
4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew
certificate is the new root CA certificates and is REQUIRED to be certificate is the new root CA certificates and is REQUIRED to be
present in the response message. The newWithOld certificate present in the response message. The newWithOld certificate is
RECOMMENDED to be present in the response message though it is RECOMMENDED to be present in the response message though it is
required for those cases where the receiving entity trusts the old REQUIRED for those cases where the receiving entity trusts the old
root CA certificate and whishes to gain trust in the new root CA root CA certificate and whishes to gain trust in the new root CA
certificate. The oldWithNew certificate is OPTIONAL though it is certificate. The oldWithNew certificate is OPTIONAL though it is
only needed in a scenario where the requesting entity already trusts only needed in a scenario where the requesting entity already trusts
the new root CA certificate and wants to gain trust in the old root the new root CA certificate and wants to gain trust in the old root
certificate. certificate.
The profile for this exchange is as given in Section 5.4.1, with the The message sequence for this PKI management operation is as given in
following specific content: Section 5.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-caKeyUpdateInfo 1 the body MUST contain as infoType the OID id-it-caKeyUpdateInfo
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be a 3 if present, the infoValue of the response MUST be a
CAKeyUpdAnnContent structure CAKeyUpdAnnContent structure
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
caKeyUpdateInfo extension looks like this: caKeyUpdateInfo extension looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no update of the root CA certificate is -- MUST be absent if no update of the root CA certificate is
available available
-- MUST be present if an update of the root CA certificate -- MUST be present if an update of the root CA certificate
skipping to change at page 52, line 38 skipping to change at page 54, line 18
caKeyUpdateInfo extension looks like this: caKeyUpdateInfo extension looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no update of the root CA certificate is -- MUST be absent if no update of the root CA certificate is
available available
-- MUST be present if an update of the root CA certificate -- MUST be present if an update of the root CA certificate
-- is available -- is available
caKeyUpdateInfo REQUIRED caKeyUpdateInfo REQUIRED
-- MUST be present and be of type CAKeyUpdAnnContent -- MUST be present and be of type CAKeyUpdAnnContent
oldWithNew OPTIONAL oldWithNew OPTIONAL
-- MUST 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
newWithOld RECOMMENDED newWithOld RECOMMENDED
-- MUST be present if infoValue is present -- SHOULD be present if infoValue is present
-- MUST contain an X.509 certificate containing the new public -- MUST contain an X.509 certificate containing the new public
-- root CA key signed with the old private root CA key -- root CA key signed with the old private root CA key
newWithNew REQUIRED newWithNew REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the new root CA certificate -- MUST contain the new root CA certificate
< TBD: To reduce unnecessary overhead by including not needed
certificates, we intend to require only to incert the newWithNew
certificate in the caKeyUpdateInfo structure and optionally omit the
oldWithNew and newWithOld certificates. This is in conflict with
[RFC4210] where also oldWithNew and newWithOld are required fields in
caKeyUpdateInfo. Is there any possiblility to optionally leave these
filds empty and still reuse the caKeyUpdateInfo structure as
specified in [RFC4210]? >
5.4.4. Get certificate request parameters 5.4.4. Get certificate request parameters
This scheme can be used by an EE to request configuration parameters This PKI management operation can be used by an EE to request
for a planned certificate request transaction. configuration parameters for a planned certificate request operation.
An EE requests certificate request parameters from the (L)RA/CA by An EE requests for a planned certificate request parameters from the
sending a general message with OID id-it-getCSRParam. The (L)RA/CA PKI management entity by sending a general message with OID id-it-
responds with a general response with the same OID that either getCSRParam. The PKI management entity responds with a general
contains the required fields, e.g., algorithm identifier for key pair response with the same OID that either contains the required fields,
generation or other attributes and extensions or with no content in e.g., algorithm identifier for key pair generation or other
case no specific requirements are made by the (L)RA/CA. attributes and extensions or with no content in case no specific
requirements are made by the PKI.
< NOTE: The OID id-it-getCSRParam is not yet defined. It should be < NOTE: The OID id-it-getCSRParam is not yet defined. It should be
registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType
OIDs, see CMP Appendix F [RFC4210] on page 92. > OIDs, see CMP Appendix F [RFC4210] on page 92. >
The EE SHOULD follow the requirements from the recieved CertTemplate The EE SHOULD follow the requirements from the recieved CertTemplate
and the optional RSA key length. In case a field is present but the and the optional RSA key length. In case a field is present but the
value is absent, it means that this field is required but its content value is absent or NULL, it means that this field is required but its
has to be provided by the EE. content has to be provided by the EE.
< TBD: There is some more explanation needed to explain how to < TBD: There is some more explanation needed to explain how to
prefill the certTemplate structure. Possibly an example will help to prefill the certTemplate structure. Possibly an example will help to
clarify this. > clarify this. >
The profile for this exchange is as given in Section 5.4.1, with the The message sequence for this PKI management operation is as given in
following specific content: Section 5.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-getCSRParam 1 the body MUST contain as infoType the OID id-it-getCSRParam
2 the infoValue of the request MUST be absent 2 the infoValue of the request MUST be absent
3 if present, the infoValue of the response MUST be a SEQUENCE of a 3 if present, the infoValue of the response MUST be a SEQUENCE of a
certTemplate structure and an rsaKeyLen field of type INTEGER certTemplate structure and an rsaKeyLen field of type INTEGER
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
getCSRParam OID looks like this: getCSRParam OID looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no requirements are available -- MUST be absent if no requirements are available
-- MUST be present if the (L)RA/CA has any requirements on the -- MUST be present if the PKI management entity has any
-- content of the certificates to be requested. -- requirements on the content of the certificates to be
-- requested
certTemplate REQUIRED certTemplate REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the prefilled certTemplate structure -- MUST contain the prefilled certTemplate structure
rsaKeyLen OPTIONAL rsaKeyLen OPTIONAL
-- This field is of type INTEGER. Any reasonable RSA key length -- This field is of type INTEGER. Any reasonable RSA key length
-- SHOULD be specified if the algorithm in the -- SHOULD be specified if the algorithm in the
-- subjectPublicKeyInfo field of the certTemplate is of type -- subjectPublicKeyInfo field of the certTemplate is of type
-- rsaEncryption. -- rsaEncryption.
< TBD: To offer a set of allowed key lenths, the rsaKeyLen field
could also be specified as a SEQUENCE OF INTEGER. >
5.4.5. Get certificate management configuration 5.4.5. Get certificate management configuration
This scheme can be used by an EE to request the current certificate This PKI management operation can be used by an EE to request the
management configuration information by the EE in advance to a current certificate management configuration information by the EE in
planned certificate management transaction, e.g., in case no out-of- advance to a planned PKI management operation, e.g., in case no out-
band transport is available. Such certificate management of-band transport is available. Such certificate management
configuration can consist of all information the EE needs to know to configuration can consist of all information the EE needs to know to
generate and deliver a proper certificate request, such as generate and deliver a proper certificate request, such as
o algorithm, curve, and key length for key generation o algorithm, curve, and key length for key generation
o various certificate attributes and extensions to be used for the o various certificate attributes and extensions to be used for the
certificate request certificate request
o specific host name, port and path on the RA/LRA to send this CMP o specific host name, port and path on the RA/LRA to send this CMP
request to request to
o Infrastructure Root CA Certificate, e.g., the root of the (L)RA o Infrastructure Root CA Certificate, e.g., the root of the (L)RA
TLS and CMP signer certificates. TLS and CMP signer certificates.
There is an overlap with Section 5.4.2 with regard to transport of CA There is an overlap with Section 5.4.2 regarding transport of CA
certificates and with Section 5.4.4 with regard to key generation certificates and with Section 5.4.4 regarding key generation
parameter and certificate request attributes and extensions. This parameter and certificate request attributes and extensions. This
profile offers to request a proprietary configuration file containing profile offers to request a proprietary configuration file containing
all information needed in one exchange. all information needed in one exchange.
< TBD: Especially with section 5.4.4 there is some overlap regarding < TBD: Especially with section 5.4.4 there is some overlap regarding
algorithms, attributes and, extensions of the certificate that will algorithms, attributes and, extensions of the certificate that will
be requested. It needs to be decided if both variants have a right be requested. It needs to be decided if both variants have a right
to exist next to the other or if one option should be removed from to exist next to each other or if one option should be removed from
this document. > this document. >
An EE requests certificate management configuration from the (L)RA/CA
by sending a general message with the OID id-it-getCertMgtConfig. An EE requests certificate management configuration from the PKI
The (L)RA/CA responds with a general response with the same OID that management entity by sending a general message with the OID id-it-
either contains a certMgtConfig field containing the configuration getCertMgtConfig. The PKI management entity responds with a general
file encoded as OCTET STRING or with no content in case no response with the same OID that either contains a certMgtConfig field
certificate management configuration is available. containing the configuration file encoded as OCTET STRING or with no
content in case no certificate management configuration is available.
< NOTE: The OID id-it-getCertMgtConfig is not yet defined. It should < NOTE: The OID id-it-getCertMgtConfig is not yet defined. It should
be registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType be registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType
OIDs, see CMP Appendix F [RFC4210] on page 92. > OIDs, see CMP Appendix F [RFC4210] on page 92. >
The EE SHOULD use the contents of this certMgtConfig to format and The EE SHOULD use the contents of this certMgtConfig to format and
deliver the certificate request. The certificate management deliver the certificate request. The certificate management
configuration may contain contact details, e.g., like an URI and configuration may contain contact details, e.g., like an URI and
issuing CA distinguished name, where to address the request messages issuing CA distinguished name, where to address the request messages
to and may also contain certificate request parameters as described to and may also contain certificate request parameters as described
in Section 5.4.4. in Section 5.4.4.
The certMgtConfig field may be of any format suitable for the EE, The certMgtConfig field may be of any format suitable for the EE,
e.g., CMS [RFC5652], JWT [RFC7519] or, XML [W3C_XML]. The e.g., JWT [RFC7519] or XML [W3C_XML]. The certMgtConfig contents MAY
certMgtConfig contents MAY be signed, e.g., like CMS SignedData be signed, e.g., like CMS SignedData [RFC5652], JWS [RFC7515] or,
[RFC5652], JWS [RFC7515] or, XML-DSig [W3C_XML-Dsig]. For XML-DSig [W3C_XML-Dsig]. For interoperability the format of the
interoperability the format of the certMgtConfig field should be certMgtConfig field should be specified in detail if needed.
specified in detail if needed.
The profile for this exchange is as given in Section 5.4.1, with the The message sequence for this PKI management operation is as given in
following specific content: Section 5.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it-getCertMgtConfig 1 the body MUST contain as infoType the OID id-it-getCertMgtConfig
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 certMgtConfig 3 if present, the infoValue of the response MUST be a certMgtConfig
structure structure
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
getCertMgtConfig extension looks like this: getCertMgtConfig extension looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no certificate management configuration -- MUST be absent if no certificate management configuration
-- is available -- is available
-- MUST be present if the (L)RA/CA provides any certificate -- MUST be present if the PKI management entity provides any
-- management configuration -- certificate management configuration
certMgtConfig REQUIRED certMgtConfig REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the certificate management configuration as OCTET -- MUST contain the certificate management configuration as OCTET
-- OCTET STRING -- OCTET STRING
5.4.6. Get enrollment voucher 5.4.6. Get enrollment voucher
This scheme can be used by an EE to request an enrollment voucher This PKI management operation can be used by an EE to request an
containing the root certificate of a new, additional, or alternative enrollment voucher containing the root certificate of a new,
PKI to establish trust in this PKI, e.g., in case no out-of-band additional, or alternative PKI to establish trust in this PKI, e.g.,
transport is available. Such an enrollment voucher can be used in in case no out-of-band transport is available. Such an enrollment
advance to an enrollment to this new environment. It may contain voucher can be used in advance to an enrollment to this new
further information depending on the use case. environment.
An EE requests an enrollment voucher from the (L)RA/CA by sending a An EE requests an enrollment voucher from the PKI management entity
general message. The (L)RA/CA responds with a general response with by sending a general message. The PKI management entity responds
the same OID that either contains the voucher or with no content in with a general response with the same OID that either contains the
case no voucher is available. voucher or with no content in case no voucher is available.
The (L)RA MAY use the content of the voucherRequest to get an The PKI management entity MAY use the content of the voucherRequest
enrollment voucher from other backend components, e.g., as described to get an enrollment voucher from other backend components, e.g., as
in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The EE SHOULD use described in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The EE
the contents of the received enrollmentVoucher to authenticate the SHOULD use the contents of the received enrollmentVoucher to
(L)RA/CA it is about to enroll to. The enrollment voucher may for authenticate the PKI management entity it is about to enroll to. The
example contain the Root CA certificate of the new PKI or the CMP enrollment voucher may for example contain the Root CA certificate of
signer certificate of the (L)RA. The general response message MUST the new PKI or the CMP signer certificate of the PKI management
be properly authenticated and the EE MUST verify the authorization of entity. The general response message MUST be properly authenticated
the sender to install new root certificates. One example for an and the EE MUST verify the authorization of the sender to install new
enrollment voucher is specified in RFC8366 [RFC8366]. root certificates. One example for an enrollment voucher is
specified in RFC8366 [RFC8366].
The voucherRequest and enrollmentVoucher fields may be of any format The voucherRequest and enrollmentVoucher fields may be of any format
suitable for the EE, e.g., CMS [RFC5652], JWT [RFC7519] or, XML suitable for the EE, e.g., JWT [RFC7519] or XML [W3C_XML]. The
[W3C_XML]. The voucherRequest and enrollmentVoucher contents MAY voucherRequest and enrollmentVoucher contents MAY contain a
contain a signature, e.g., CMS SignedData [RFC5652], JWS [RFC7515] signature, e.g., CMS SignedData [RFC5652], JWS [RFC7515] or, XML-DSig
or, XML-DSig [W3C_XML-Dsig]. For interoperability the format of the [W3C_XML-Dsig]. For interoperability the format of the
voucherRequest and enrollmentVoucher field schould be specified in voucherRequest and enrollmentVoucher field schould be specified in
detail if needed, e.g., as defined in BRSKI detail if needed, e.g., as defined in BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366].
< TBD: The vontent of the voucherRequest and enrollmentVoucher fields < TBD: The vontent of the voucherRequest and enrollmentVoucher fields
can also be linited to the specufucations in BRSKI can also be linited to the specifications in BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. > [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. >
The profile for this exchange is as given in Section 5.4.1, with the The message sequence for this PKI management operation is as given in
following specific content: Section 5.4.1, with the following specific content:
1 the body MUST contain as infoType the OID id-it- 1 the body MUST contain as infoType the OID id-it-
getEnrollmentVoucher getEnrollmentVoucher
2 if present, the infoValue of the request MUST be a voucherRequest 2 if present, the infoValue of the request MUST be a voucherRequest
structure structure
3 if present, the infoValue of the response MUST be an 3 if present, the infoValue of the response MUST be an
enrollmentVoucher structure enrollmentVoucher structure
skipping to change at page 57, line 23 skipping to change at page 59, line 10
-- MUST be present if the EE provides the voucher request -- MUST be present if the EE provides the voucher request
voucherRequest REQUIRED voucherRequest REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the voucher request as OCTET STRING -- MUST contain the voucher request as OCTET STRING
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
getEnrollmentVoucher extension looks like this: getEnrollmentVoucher extension looks like this:
infoValue OPTIONAL infoValue OPTIONAL
-- MUST be absent if no enrollment voucher is available -- MUST be absent if no enrollment voucher is available
-- MUST be present if the (L)RA/CA provides the enrollment -- MUST be present if the PKI management entity provides
-- voucher -- the enrollment voucher
enrollmentVoucher REQUIRED enrollmentVoucher REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain the enrollment voucher as OCTET STRING -- MUST contain the enrollment voucher as OCTET STRING
6. LRA and RA focused certificate management use cases 6. LRA and RA focused PKI management operations
This chapter focuses on the communication of PKI backend components This chapter focuses on the communication among different PKI
with each other. Depending on the network and PKI solution design, management entities. Depending on the network and PKI solution
these will either be an LRA, RA or CA. design, these will either be an LRA, RA or CA.
Typically, an (L)RA forwards messages from downstream, but it may Typically, a PKI management entity forwards messages from downstream,
also reply to them itself. Besides forwarding of received messages but it may also reply to them itself. Besides forwarding of received
an (L)RA could also need to revoke certificates of EEs, report messages a PKI management entity could also need to revoke
errors, or may need to manage its own certificates. certificates of EEs, report errors, or may need to manage its own
certificates.
< TBD: In CMP Updates [I-D.brockhaus-lamps-cmp-updates] additional < TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] additional
extended key usages like id-kp-cmpRA will be defined to indicate that extended key usages like id-kp-cmpRA will be defined to indicate that
a key pair is entitled to be used for signature-based protection of a a key pair is entitled to be used for signature-based protection of a
CMP message by an (L)RA/CA. > CMP message by a PKI management entity. >
6.1. Forwarding of messages 6.1. Forwarding of messages
Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or
certConf) or error message coming from an EE or the previous certConf) or error message coming from an EE or the previous
(downstream) PKI component MUST be sent to the next (upstream) PKI (downstream) PKI management entity MUST be sent to the next
component. This PKI component MUST forward response messages to the (upstream) PKI management entity. This PKI management entity MUST
next (downstream) PKI component or EE. forward response messages to the next (downstream) PKI management
entity or EE.
The (L)RA SHOULD verify the protection, the syntax, the required The PKI management entity SHOULD verify the protection, the syntax,
message fields, the message type, and if applicable the authorization the required message fields, the message type, and if applicable the
and the proof-of-possession of the message. Additional checks or authorization and the proof-of-possession of the message. Additional
actions MAY be applied depending on the PKI solution requirements and checks or actions MAY be applied depending on the PKI solution
concept. If one of these verification procedures fails, the (L)RA requirements and concept. If one of these verification procedures
SHOULD respond with a negative response message and SHOULD not fails, the (L)RA SHOULD respond with a negative response message and
forward the message further upstream. General error conditions SHOULD not forward the message further upstream. General error
should be handled as described in Section 5.3 and Section 6.3. conditions should be handled as described in Section 5.3 and
Section 6.3.
An (L)RA SHOULD not change the received message if not necessary. A PKI management entity SHOULD not change the received message if not
The (L)RA SHOULD only update the message protection if it is necessary. The PKI management entity SHOULD only update the message
technically necessary. Concrete PKI system specifications may define protection if it is technically necessary. Concrete PKI system
in more detail if and when to do so. specifications may define in more detail if and when to do so.
This is particularly relevant in the upstream communication of a This is particularly relevant in the upstream communication of a
request message. request message.
Each hop in a chain of PKI components has one or more Each hop in a chain of PKI management entity has one or more
functionalities, e.g., functionalities, e.g., a PKI management entity
o An (L)RA may need to verify the identities of EEs or base o may need to verify the identities of EEs or base authorization
authorization decisions for certification request processing on decisions for certification request processing on specific
specific knowledge of the local setup, e.g., by consulting an knowledge of the local setup, e.g., by consulting an inventory or
inventory or asset management system. asset management system,
o An (L)RA may need to add fields to certificate request messages. o may need to add fields to certificate request messages,
o An (L)RA may need to store data from a message in a database for o may need to store data from a message in a database for later
later usage or documentation purposes. usage or documentation purposes,
o An (L)RA may provide traversal of a network boundary. o may provide traversal of a network boundary,
o An (L)RA may need to double-check if the messages transferred back o may need to double-check if the messages transferred back and
and forth are properly protected and well formed. forth are properly protected and well formed,
o An (L)RA may provide a proof that it has performed all required o may provide a proof that it has performed all required checks,
checks.
o An (L)RA may initiate a delayed enrollment due to offline upstream o may initiate a delayed enrollment due to offline upstream
communication or registration officer interaction. communication or registration officer interaction,
o An (L)RA may grant the request of an EE to omit sending a o may grant the request of an EE to omit sending a confirmation
confirmation message. message, or
o An RA can collect messages from different LRAs and forward them to o can collect messages from different LRAs and forward them to the
the CA. CA.
Therefore, the decision if a message should be forwarded Therefore, the decision if a message should be forwarded
o unchanged with the original protection, o unchanged with the original protection,
o unchanged with a new protection, or o unchanged with a new protection, or
o changed with a new protection o changed with a new protection
depends on the PKI solution design and the associated security policy depends on the PKI solution design and the associated security policy
(CP/CPS [RFC3647]). (CP/CPS [RFC3647]).
< TBD: In [CMP Updates] different circumstances that require adding < TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] different
of an additional protection by an (L)RA or batching CMP messages at circumstances that require adding of an additional protection by a
an (L)RA by using the nested messages is described. It needs to be PKI management entity or batching CMP messages at a PKI management
entity by using the nested messages is described. It needs to be
decided which of these variants should be specified here. Finally, I decided which of these variants should be specified here. Finally, I
guess they will all be OPTIONAL. > guess they will all be OPTIONAL. >
This section specifies the different options an (L)RA may implement This section specifies the different options a PKI management entity
and use. may implement and use.
An (L)RA MAY update the protection of a message A PKI management entity MAY update the protection of a message
o if the (L)RA performs changes to the header or the body of the o if it performs changes to the header or the body of the message,
message,
o if the (L)RA 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 the (L)RA needs to protect the message using a key and o if it needs to protect the message using a key and certificate
certificate from a different PKI, or from a different PKI, or
o if the (L)RA needs to replace a MAC based-protection. o if it needs to replace 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 (L)RA MAY change the extraCerts in any of the the extraCerts. The PKI management entity MAY change the extraCerts
following message adaptations, e.g., to sort or add needed or to in any of the following message adaptations, e.g., to sort or add
delete needless certificates to support the next hop. This may be needed or to delete needless certificates to support the next hop.
particularly helpful to extend upstream messages with additional This may be particularly helpful to extend upstream messages with
certificates or to reduce the number of certificates in downstream additional certificates or to reduce the number of certificates in
messages when forwarding to constrained devices. downstream messages when forwarding to constrained devices.
6.1.1. Not changing protection 6.1.1. Not changing protection
This message adaptation can be used by any (L)RA to forward an This alternative to forward a message can be used by any PKI
original CMP message without changing the header, body or protection. management entity to forward an original CMP message without changing
In any of these cases the (L)RA acts more like a proxy, e.g., on a the header, body or protection. In any of these cases the PKI
network boundary, implementing no specific RA-like security management entity acts more like a proxy, e.g., on a network
functionality to the PKI. boundary, implementing no specific RA-like security functionality to
the PKI.
This message adaptation MUST be used for forwarding kur messages that This alternative to forward a message MUST be used for forwarding kur
must not be approved by the respective (L)RA. messages that must not be approved by the respective PKI management
entity.
6.1.2. Replacing protection 6.1.2. Replacing protection
The following two message adaptations can be used by any (L)RA to The following two alternatives to forward a message can be used by
forward a CMP message with or without changes, but providing its own any PKI management entity to forward a CMP message with or without
protection using its CMP signer key providing approval of this changes, but providing its own protection using its CMP signer key to
message. In this case the (L)RA acts as an actual Registration assert approval of this message. In this case the PKI management
Authority (RA), which implements important security functionality of entity acts as an actual Registration Authority (RA), which
the PKI. implements important security functionality of the PKI.
Before replacing the existing protection by a new protection, the Before replacing the existing protection by a new protection, the PKI
(L)RA MUST verify the protection provided by the EE or by the management entity MUST verify the protection provided by the EE or by
previous PKI component and approve its content including any own the previous PKI component and approve its content including any own
modifications. For certificate requests the (L)RA MUST verify in modifications. For certificate requests the PKI management entity
particular the included proof-of-possession self-signature of the MUST verify in particular the included proof-of-possession self-
certTemplate using the public key of the requested certificate and signature of the certTemplate using the public key of the requested
MUST check that the EE, as authenticated by the message protection, certificate and MUST check that the EE, as authenticated by the
is authorized to request a certificate with the subject as specified message protection, is authorized to request a certificate with the
in the certTemplate. subject as specified in the certTemplate.
In case the received message has been protected by a CA or another In case the received message has been protected by a CA or another
(L)RA, the current (L)RA MUST verify its protection and approve its PKI management entity, the current PKI management entity MUST verify
content including any own modifications. For certificate requests its protection and approve its content including any own
the (L)RA MUST check that the other (L)RA, as authenticated by the modifications. For certificate requests the PKI management entity
message protection, is authorized to issue or forward the request. MUST check that the other PKI management entity, as authenticated by
the protection of the incomming message, was authorized to issue or
forward the request.
These message adaptations MUST NOT be applied to kur request messages These message adaptations MUST NOT be applied to kur request messages
as described in Section 5.1.3 since their original protection using as described in Section 5.1.3 since their original protection using
the key and certificate to be updated needs to be preserved, unless the key and certificate to be updated needs to be preserved, unless
the regCtrl OldCertId is used to clearly identify the certificate to the regCtrl OldCertId is used to clearly identify the certificate to
be updated. be updated.
6.1.2.1. Keeping proof-of-possession 6.1.2.1. Keeping proof-of-possession
This message adaptation can be used by any (L)RA to forward a CMP This alternative to forward a message can be used by any PKI
message with or without modifying the message header or body while management entity to forward a CMP message with or without modifying
preserving any included proof-of-possession. the message header or body while preserving any included proof-of-
possession.
By replacing the existing protection using its own CMP signer key the By replacing the existing protection using its own CMP signer key the
(L)RA provides a proof of verifying and approving of the message as PKI management entity provides a proof of verifying and approving of
described above. the message as described above.
In case the (L)RA modifies the certTemplate of an ir or cr message, In case the PKI management entity modifies the certTemplate of an ir
the message adaptation in Section 6.1.2.2 needs to be applied or cr message, the message adaptation in Section 6.1.2.2 needs to be
instead. applied instead.
6.1.2.2. Breaking proof-of-possession 6.1.2.2. Breaking proof-of-possession
This message adaptation can be used by any (L)RA to forward an ir or This alternativeto forward a message can be used by any PKI
cr message with modifications of the certTemplate i.e., modification, management entity to forward an ir or cr message with modifications
addition, or removal of fields. Such changes will break the proof- of the certTemplate i.e., modification, addition, or removal of
of-possession provided by the EE in the original message. fields. Such changes will break the proof-of-possession provided by
the EE in the original message.
By replacing the existing or applying an initial protection using its By replacing the existing using its own CMP signer key the PKI
own CMP signer key the (L)RA provides a proof of verifying and management entity provides a proof of verifying and approving the new
approving the new message as described above. message as described above.
In addition to the above the (L)RA MUST verify in particular the In addition to the above the PKI management entity MUST verify in
proof-of-possession contained in the original message as described particular the proof-of-possession contained in the original message
above. If these checks were successfully performed the (L)RA MUST as described above. If these checks were successfully performed the
change the popo to raVerified. PKI management entity MUST change the popo to raVerified.
The popo field MUST contain the raVerified choice in the certReq The popo field MUST contain the raVerified choice in the certReq
structure of the modified message as follows: structure of the modified message as follows:
popo popo
raVerified REQUIRED raVerified REQUIRED
-- MUST have the value NULL and indicates that the (L)RA -- MUST have the value NULL and indicates that the PKI
-- verified the popo of the original message. -- management entity verified the popo of the original
-- message
6.1.3. Adding Protection 6.1.3. Adding Protection
< TBD: In [CMP Updates] different circumstances that require adding < TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] different
of an additional protection by an (L)RA or batching CMP messages at circumstances that require adding of an additional protection by a
an (L)RA by using the nested messages is described. It needs to be PKI management entity or batching CMP messages at a PKI management
entity by using the nested messages is described. It needs to be
decided which of these variants should be specified here. Finally, I decided which of these variants should be specified here. Finally, I
guess they will all be OPTIONAL. > guess they will all be OPTIONAL. >
6.1.4. Initiating delayed enrollment 6.1.4. Initiating delayed enrollment
This message adaptation can be used by an (L)RA to initiate delayed This functional extension can be used by a PKI management entity to
enrollment. In this case a (L)RA/CA MUST add the status waiting in initiate delayed enrollment. In this case a PKI management entity
the response message. The (L)RA/CA MUST then reply to the pollReq MUST add the status waiting in the response message. The PKI
messages as described in Section 5.1.7. management entity MUST then reply to the pollReq messages as
described in Section 5.1.7.
6.2. Revoking certificates on behalf of another's entities 6.2. Revoking certificates on behalf of another's entities
This message sequence can be used by an (L)RA to revoke a certificate This PKI management operation can be used by a PKI management entity
of any other entity. This revocation request message MUST be signed to revoke a certificate of any other entity. This revocation request
by the (L)RA using its own CMP signer key to prove to the PKI message MUST be signed by the PKI management entity using its own CMP
authorization to revoke the certificate on behalf of the EE. signer key to prove to the PKI authorization to revoke the
certificate on behalf of the EE.
The general message flow for this profile is the same as given in
section Section 5.2.
Preconditions: Preconditions:
1 the certificate to be revoked MUST be known to the (L)RA 1 the certificate to be revoked MUST be known to the PKI management
entity
2 the (L)RA MUST have the authorization to revoke the certificates 2 the PKI management entity MUST have the authorization to revoke
of other entities issued by the corresponding CA the certificates of other entities issued by the corresponding CA
The profile for this exchange is identical to that given in section The message sequence for this PKI management operation is identical
Section 5.2, with the following changes: to that given in section Section 5.2, with the following changes:
1 it is not required that the certificate to be revoked is not yet 1 it is not required that the certificate to be revoked is not yet
expired or revoked expired or revoked
2 the (L)RA acts as EE for this message exchange 2 the PKI management entity acts as EE for this message exchange
3 the rr messages MUST be signed using the CMP signer key of the 3 the rr messages MUST be signed using the CMP signer key of the PKI
(L)RA. management entity.
6.3. Error reporting 6.3. Error reporting
This functionality should be used by the (L)RA to report any error This functionality should be used by the PKI management entity to
conditions downstream to the EE. Potential error reporting by the EE report any error conditions downstream to the EE. Potential error
upstream to the (L)RA/CA is described in Section 5.3. reporting by the EE upstream to the PKI management entity is
described in Section 5.3.
In case the error condition is related to specific details of an ir, In case the error condition is related to specific details of an ir,
cr, p10cr, or kur request message it MUST be reported in the specific cr, p10cr, or kur request message it MUST be reported in the specific
response message, i.e., an ip, cp, or kup with negative contents. response message, i.e., an ip, cp, or kup with negative contents.
General error conditions, e.g., problems with the message header, General error conditions, e.g., problems with the message header,
protection, or extraCerts, and negative feedback on rr, pollReq, protection, or extraCerts, and negative feedback on rr, pollReq,
certConf, or error messages MUST be reported in the form of an error certConf, or error messages MUST be reported in the form of an error
message. message.
In both situations the (L)RA reports the errors in the PKIStatusInfo In both situations the PKI management entity reports the errors in
structure of the respective message as described in Section 5.3. the PKIStatusInfo structure of the respective message as described in
Section 5.3.
An EE receiving any such negative feedback SHOULD log the error An EE receiving any such negative feedback SHOULD log the error
appropriately and MUST terminate the current transaction. appropriately and MUST terminate the current transaction.
7. CMP message transport variants 7. CMP message transport variants
The CMP messages are designed to be self-contained, such that in The CMP messages are designed to be self-contained, such that in
principle any transport can be used. HTTP SHOULD be used for online principle any transport can be used. HTTP SHOULD be used for online
transport while file-based transport MAY be used in case offline transport while file-based transport MAY be used in case offline
transport is required. In case HTTP transport is not desired or transport is required. In case HTTP transport is not desired or
skipping to change at page 63, line 25 skipping to change at page 65, line 25
are lost, or a communication partner does not respond. In order to are lost, or a communication partner does not respond. In order to
prevent waiting indefinitely, each CMP client component SHOULD use a prevent waiting indefinitely, each CMP client component SHOULD use a
configurable per-request timeout, and each CMP server component configurable per-request timeout, and each CMP server component
SHOULD use a configurable per-response timeout in case a further SHOULD use a configurable per-response timeout in case a further
message is to be expected from the client side. In this way a message is to be expected from the client side. In this way a
hanging transaction can be closed cleanly with an error and related hanging transaction can be closed cleanly with an error and related
resources (for instance, any cached extraCerts) can be freed. resources (for instance, any cached extraCerts) can be freed.
7.1. HTTP transport 7.1. HTTP transport
This transport mechanism can be used by an EE and (L)RA/CA to This transport mechanism can be used by a PKI entity to transfer CMP
transfer CMP messages over HTTP. If HTTP transport is used the messages over HTTP. If HTTP transport is used the specifications as
specifications as described in [RFC6712] MUST be followed. described in [RFC6712] MUST be followed.
Each PKI management entity supporting HTTP(S) transport MUST support Each PKI management entity supporting HTTP or HTTPS transport MUST
the use of the path-prefix of '/.well-known/' as defined in [RFC5785] support the use of the path-prefix of '/.well-known/' as defined in
and the registered name of 'cmp' to ease interworking in a multi- [RFC5785] and the registered name of 'cmp' to ease interworking in a
vendor environment. multi-vendor environment.
The CMP client MUST be configured with sufficient information to form The CMP client MUST be configured with sufficient information to form
the CMP server URI. This MUST be at least the authority portion of the CMP server URI. This MUST be at least the authority portion of
the URI, e.g., 'www.example.com:80', or the full operational path of the URI, e.g., 'www.example.com:80', or the full operational path of
the CA/RA. An additional arbitrary label, e.g., 'arbitraryLabel1', the PKI management entity. An additional arbitrary label, e.g.,
MAY be configured as a separate component or as part of the full 'arbitraryLabel1', MAY be configured as a separate component or as
operational path to provide further information to address multiple part of the full operational path to provide further information to
CAs or certificate profiles. A valid full operational path can look address multiple CAs or certificate profiles. A valid full
like this: operational path can look like this:
1 http://www.example.com/.well-known/cmp 1 http://www.example.com/.well-known/cmp
2 http://www.example.com/.well-known/cmp/keyupdate 2 http://www.example.com/.well-known/cmp/keyupdate
3 http://www.example.com/.well-known/cmp/arbitraryLabel1 3 http://www.example.com/.well-known/cmp/arbitraryLabel1
4 http://www.example.com/.well-known/cmp/arbitraryLabel1/keyupdate 4 http://www.example.com/.well-known/cmp/arbitraryLabel1/keyupdate
PKI management operations SHOULD use the following URI path: PKI management operations SHOULD use the following URI path:
skipping to change at page 65, line 7 skipping to change at page 67, line 7
Subsequent certConf, error, and pollReq messages are sent to the URI Subsequent certConf, error, and pollReq messages are sent to the URI
of the respective PKI management operation. of the respective PKI management operation.
< TBD: It needs to be defined if specific path values for < TBD: It needs to be defined if specific path values for
communication between PKI management entities as specified in section communication between PKI management entities as specified in section
6 are needed, e.g., 'forward' or 'nested'.> 6 are needed, e.g., 'forward' or 'nested'.>
7.2. HTTPS transport using certificates 7.2. HTTPS transport using certificates
This transport mechanism can be used by an EE and (L)RA/CA to further This transport mechanism can be used by a PKI entity to further
protect the HTTP transport as described in Section 7.1 using TLS 1.2 protect the HTTP transport as described in Section 7.1 using TLS 1.2
[RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with
certificate-based authentication. Using this transport mechanism, certificate-based authentication. Using this transport mechanism,
the CMP transport via HTTPS MUST use TLS server authentication and the CMP transport via HTTPS MUST use TLS server authentication and
SHOULD use TLS client authentication. SHOULD use TLS client authentication.
EE: EE:
o The EE SHOULD use a TLS client certificate as far as available. o The EE SHOULD use a TLS client certificate as far as available.
If no dedicated TLS certificate is available the EE SHOULD use an If no dedicated TLS certificate is available the EE SHOULD use an
already existing certificate identifying the EE (e.g., a already existing certificate identifying the EE (e.g., a
manufacturer certificate). manufacturer certificate).
o If no TLS certificate is available at the EE, server-only o If no TLS certificate is available at the EE, server-only
authenticated TLS SHOULD be used. authenticated TLS SHOULD be used.
o The EE MUST validate the TLS server certificate of its o The EE MUST validate the TLS server certificate of its
communication partner. communication partner.
(L)RA: PKI management entity:
o Each (L)RA SHOULD use a TLS client certificate on its upstream o Each PKI management entity SHOULD use a TLS client certificate on
(client) interface. its upstream (client) interface.
o Each (L)RA SHOULD use a TLS server certificate on its downstream o Each PKI management entity MUST use a TLS server certificate on
(server) interface. its downstream (server) interface.
o Each (L)RA MUST validate the TLS certificate of its communication o Each PKI management entity MUST validate the TLS certificate of
partner. its communication partners.
NOTE: The requirements for checking certificates given in [RFC5280], NOTE: The requirements for checking certificates given in [RFC5280],
[RFC5246] and [RFC8446] MUST be followed for the TLS layer. [RFC5246] and [RFC8446] MUST be followed for the TLS layer.
Certificate status checking SHOULD be used for the TLS certificates Certificate status checking SHOULD be used for the TLS certificates
of communication partners. of communication partners.
7.3. HTTPS transport using shared secrets 7.3. HTTPS transport using shared secrets
This transport mechanism can be used by an EE and (L)RA/CA to further This transport mechanism can be used by a PKI entity to further
protect the HTTP transport as described in Section 7.1 using TLS 1.2 protect the HTTP transport as described in Section 7.1 using TLS 1.2
[RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual
authentication based on shared secrets as described in [RFC5054]. authentication based on shared secrets as described in [RFC5054].
EE: EE:
o The EE MUST use the shared symmetric key for authentication. o The EE MUST use the shared symmetric key for authentication.
(L)RA: PKI management entity:
o The (L)RA MUST use the shared symmetric key for authentication. o The PKI management entity MUST use the shared symmetric key for
authentication.
7.4. File-based transport 7.4. File-based transport
For offline transfer file-based transport MAY be used. Offline For offline transfer file-based transport MAY be used. Offline
transport is typically used between LRA and RA nodes. transport is typically used between LRA and RA nodes.
Connection and error handling mechanisms like those specified for Connection and error handling mechanisms like those specified for
HTTP in [RFC6712] need to be implemented. HTTP in [RFC6712] need to be implemented.
< TBD: Details need to be defined later > < TBD: Details need to be defined later >
skipping to change at page 66, line 50 skipping to change at page 69, line 7
8. IANA Considerations 8. IANA Considerations
<Add any IANA considerations> <Add any IANA considerations>
9. Security Considerations 9. Security Considerations
<Add any security considerations> <Add any security considerations>
10. Acknowledgements 10. Acknowledgements
We would like to thank the various reviewers of this CMP profile. We would like to thank the various reviewers of this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.brockhaus-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H., "CMP Updates", draft-brockhaus-lamps-cmp- Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp-
updates-03 (work in progress), January 2020. updates-00 (work in progress), February 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
 End of changes. 273 change blocks. 
704 lines changed or deleted 799 lines changed or added

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