draft-ietf-lamps-lightweight-cmp-profile-07.txt   draft-ietf-lamps-lightweight-cmp-profile-08.txt 
LAMPS Working Group H. Brockhaus, Ed. LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft S. Fries Internet-Draft D. von Oheimb
Intended status: Standards Track D. von Oheimb Intended status: Standards Track S. Fries
Expires: 28 April 2022 Siemens Expires: 23 May 2022 Siemens
25 October 2021 19 November 2021
Lightweight Certificate Management Protocol (CMP) Profile Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-07 draft-ietf-lamps-lightweight-cmp-profile-08
Abstract Abstract
This document aims at simple, interoperable, and automated PKI This document aims at simple, interoperable, and automated PKI
management operations covering typical use cases of industrial and management operations covering typical use cases of industrial and
IoT scenarios. This is achieved by profiling the Certificate IoT scenarios. This is achieved by profiling the Certificate
Management Protocol (CMP), the related Certificate Request Message Management Protocol (CMP), the related Certificate Request Message
Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
but sufficiently detailed and self-contained way. To make secure but sufficiently detailed and self-contained way. To make secure
certificate management for simple scenarios and constrained devices certificate management for simple scenarios and constrained devices
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 23 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4
1.2. Motivation for a lightweight profile of CMP . . . . . . . 4 1.2. Motivation for a lightweight profile of CMP . . . . . . . 4
1.3. Special requirements of industrial and IoT scenarios . . 5 1.3. Special requirements of industrial and IoT scenarios . . 5
1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6
1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7
1.6. Compatibility with existing CMP profiles . . . . . . . . 7 1.6. Compatibility with existing CMP profiles . . . . . . . . 7
skipping to change at page 3, line 24 skipping to change at page 3, line 24
4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 51 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 51
4.3. Support messages . . . . . . . . . . . . . . . . . . . . 54 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 54
4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 56 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 56
4.3.2. Get root CA certificate update . . . . . . . . . . . 56 4.3.2. Get root CA certificate update . . . . . . . . . . . 56
4.3.3. Get certificate request template . . . . . . . . . . 58 4.3.3. Get certificate request template . . . . . . . . . . 58
4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 60 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 60
4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 62 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 62
5. PKI management entity operations . . . . . . . . . . . . . . 66 5. PKI management entity operations . . . . . . . . . . . . . . 66
5.1. Responding to requests . . . . . . . . . . . . . . . . . 66 5.1. Responding to requests . . . . . . . . . . . . . . . . . 66
5.1.1. Responding to a certificate request . . . . . . . . . 67 5.1.1. Responding to a certificate request . . . . . . . . . 67
5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 68 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 67
5.1.3. Responding to a confirmation message . . . . . . . . 68 5.1.3. Responding to a confirmation message . . . . . . . . 68
5.1.4. Responding to a revocation request . . . . . . . . . 69 5.1.4. Responding to a revocation request . . . . . . . . . 68
5.1.5. Responding to a support message . . . . . . . . . . . 69 5.1.5. Responding to a support message . . . . . . . . . . . 69
5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 69 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 69
5.2.1. Not changing protection . . . . . . . . . . . . . . . 71 5.2.1. Not changing protection . . . . . . . . . . . . . . . 71
5.2.2. Adding protection and batching of messages . . . . . 72 5.2.2. Adding protection and batching of messages . . . . . 71
5.2.2.1. Adding protection to a request message . . . . . 72 5.2.2.1. Adding protection to a request message . . . . . 72
5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 74 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 73
5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75
5.2.3.1. Not changing any included proof-of-possession . . 76 5.2.3.1. Not changing any included proof-of-possession . . 75
5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76
5.3. Acting on behalf of other PKI entities . . . . . . . . . 77 5.3. Acting on behalf of other PKI entities . . . . . . . . . 76
5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77
5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 78 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 77
6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 78 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 78
6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 79 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 79
6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 81 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 81
6.3. Piggybacking on other reliable transfer . . . . . . . . . 83 6.3. Piggybacking on other reliable transfer . . . . . . . . . 83
6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 83 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 83
6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 83 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 83
6.4.2. Other asynchronous transfer protocols . . . . . . . . 84 6.4.2. Other asynchronous transfer protocols . . . . . . . . 84
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
8. Security Considerations . . . . . . . . . . . . . . . . . . . 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 84
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.1. Normative References . . . . . . . . . . . . . . . . . . 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 84
10.2. Informative References . . . . . . . . . . . . . . . . . 86 10.2. Informative References . . . . . . . . . . . . . . . . . 86
Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 89 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 89
Appendix B. History of changes . . . . . . . . . . . . . . . . . 91 Appendix B. History of changes . . . . . . . . . . . . . . . . . 91
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
[RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC-
CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of
CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms], when available. [I-D.ietf-lamps-cmp-algorithms], when available.
This document specifies PKI management operations supporting machine- This document specifies PKI management operations supporting machine-
to-machine and IoT use cases. Its focus is to maximize automation to-machine and IoT use cases. Its focus is to maximize automation
skipping to change at page 9, line 39 skipping to change at page 9, line 39
For the sake of interoperability and robustness, implementations For the sake of interoperability and robustness, implementations
should, as far as security is not affected, adhere to Postel's law: should, as far as security is not affected, adhere to Postel's law:
"Be conservative in what you do, be liberal in what you accept from "Be conservative in what you do, be liberal in what you accept from
others" (often reworded as: "Be conservative in what you send, be others" (often reworded as: "Be conservative in what you send, be
liberal in what you receive"). liberal in what you receive").
When in Section 3, Section 4, and Section 5 a field of the ASN.1 When in Section 3, Section 4, and Section 5 a field of the ASN.1
syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates],
CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly
specified, it SHOULD not be used by the sending entity. The specified, it SHOULD NOT be used by the sending entity. The
receiving entity MUST NOT require its absence and if present MUST receiving entity MUST NOT require its absence and if present MUST
gracefully handle its presence. gracefully handle its presence.
1.8. Structure of this document 1.8. Structure of this document
Section 2 introduces the general PKI architecture and approach to Section 2 introduces the general PKI architecture and approach to
certificate management that is assumed in this document. Then it certificate management that is assumed in this document. Then it
lists the PKI management operations specified in this document, lists the PKI management operations specified in this document,
partitioning them into mandatory, recommended, and optional ones. partitioning them into mandatory, recommended, and optional ones.
skipping to change at page 18, line 46 skipping to change at page 18, line 46
-- the hashAlg field -- the hashAlg field
-- MUST be 2 to indicate CMP v2 in all other cases -- MUST be 2 to indicate CMP v2 in all other cases
-- For details on version negotiation see RFC-CMP-Updates -- For details on version negotiation see RFC-CMP-Updates
sender REQUIRED sender REQUIRED
-- SHOULD contain a name representing the originator of the -- SHOULD contain a name representing the originator of the
-- message; otherwise, the NULL-DN (a zero-length -- message; otherwise, the NULL-DN (a zero-length
-- SEQUENCE OF RelativeDistinguishedNames) MUST be used -- SEQUENCE OF RelativeDistinguishedNames) MUST be used
-- SHOULD be the subject of the CMP protection certificate, i.e., -- SHOULD be the subject of the CMP protection certificate, i.e.,
-- the certificate corresponding to the private key used to sign -- the certificate corresponding to the private key used to sign
-- the message -- the message
-- In a multi-hop scenario, the receiving entity SHOULD not rely -- In a multi-hop scenario, the receiving entity SHOULD NOT rely
-- on the correctness of the sender field. -- on the correctness of the sender field.
recipient REQUIRED recipient REQUIRED
-- SHOULD be the name of the intended recipient; otherwise, the -- SHOULD be the name of the intended recipient; otherwise, the
-- NULL-DN MUST be used -- NULL-DN MUST be used
-- In the first message of a PKI management operation: -- In the first message of a PKI management operation:
-- SHOULD be the subject DN of the CA the PKI management -- SHOULD be the subject DN of the CA the PKI management
-- operation is requested from -- operation is requested from
-- In all other messages: -- In all other messages:
-- SHOULD contain the value of the sender field of the previous -- SHOULD contain the value of the sender field of the previous
-- message in the same PKI management operation -- message in the same PKI management operation
skipping to change at page 22, line 26 skipping to change at page 22, line 26
Authorization of PKI management operations: Authorization of PKI management operations:
* Each EE or RA MUST have sufficient information to be able to * Each EE or RA MUST have sufficient information to be able to
authorize the PKI management entity for performing the upstream authorize the PKI management entity for performing the upstream
PKI management operation. PKI management operation.
Note: This may be achieved for example by using the cmcRA extended Note: This may be achieved for example by using the cmcRA extended
key usage in server certificates, by local configuration such as key usage in server certificates, by local configuration such as
specific name patterns for subject DN or SAN portions that may specific name patterns for subject DN or SAN portions that may
identify an RA, and/or by having a dedicated PKI Infrastructure identify an RA, and/or by having a dedicated root CA usable only
root CA usable only for authenticating PKI management entities. for authenticating PKI management entities.
* Each PKI management entity MUST have sufficient information to be * Each PKI management entity MUST have sufficient information to be
able to authorize the downstream PKI entity requesting the PKI able to authorize the downstream PKI entity requesting the PKI
management operation. management operation.
Note: For authorizing an RA the same examples apply as above. The Note: For authorizing an RA the same examples apply as above. The
authorization of EEs can be very specific to the application authorization of EEs can be very specific to the application
domain and may involve information from configuration or inventory domain and may involve information from configuration or inventory
database. It may involve, e.g., the issuer information of the EE database. It may involve, e.g., the issuer information of the EE
certificate, specific contents of the CMP protection certificate certificate, specific contents of the CMP protection certificate
skipping to change at page 25, line 25 skipping to change at page 25, line 25
* timeout occurred while waiting for a response, * timeout occurred while waiting for a response,
* rejection of a newly issued certificate while implicit * rejection of a newly issued certificate while implicit
confirmation has been granted. confirmation has been granted.
Upstream PKI management entities will not receive any CMP message to Upstream PKI management entities will not receive any CMP message to
learn that the PKI management operation has been terminated. In case learn that the PKI management operation has been terminated. In case
they expect a further message from the EE, a connection interruption they expect a further message from the EE, a connection interruption
or timeout will occur. Then they also MUST regard the current PKI or timeout will occur. Then they also MUST regard the current PKI
management operation as terminated with failure and MUST not attempt management operation as terminated with failure and MUST NOT attempt
to send an error message downstream. to send an error message downstream.
3.6.2. Reporting error conditions downstream 3.6.2. Reporting error conditions downstream
In case the PKI management entity detects an error condition, e.g., In case the PKI management entity detects an error condition, e.g.,
rejecting the request due to policy decision, in the body of an ir, rejecting the request due to policy decision, in the body of an ir,
cr, p10cr, kur, or rr message received from downstream, it SHOULD cr, p10cr, kur, or rr message received from downstream, it SHOULD
report the error in the specific response message, i.e., an ip, cp, report the error in the specific response message, i.e., an ip, cp,
kup, or rp with "rejection" status, as described in Section 4.1.1 and kup, or rp with "rejection" status, as described in Section 4.1.1 and
Section 4.2. This can also happen in case of polling. Section 4.2. This can also happen in case of polling.
skipping to change at page 30, line 50 skipping to change at page 30, line 50
| waiting for pkiConf*) | | | waiting for pkiConf*) | |
| | | | | | | |
| | received | | | | received | |
| | pkiConf | | | | pkiConf | |
+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+
| |
v v
end end
*) in case of a delayed delivery of pkiConf responses the same *) in case of a delayed delivery of pkiConf responses the same
polling mechanism is initiated as for rp or genp messages, by sending polling mechanism is initiated as for rp or genp messages, by
an error message with status "waiting". sending an error message with status "waiting".
Note: All CMP messages belonging to the same PKI management operation Note: All CMP messages belonging to the same PKI management operation
MUST have the same transactionID because the message receiver MUST have the same transactionID because the message receiver
identifies the elements of the operation in this way. identifies the elements of the operation in this way.
This section is aligned with CMP [RFC4210], CMP Updates This section is aligned with CMP [RFC4210], CMP Updates
[I-D.ietf-lamps-cmp-updates], and CMP Algorithms [I-D.ietf-lamps-cmp-updates], and CMP Algorithms
[I-D.ietf-lamps-cmp-algorithms]. [I-D.ietf-lamps-cmp-algorithms].
Guidelines as well as an algorithm use profile for this document are Guidelines as well as an algorithm use profile for this document are
skipping to change at page 32, line 40 skipping to change at page 32, line 40
certificate request message as described in Section 3.1. certificate request message as described in Section 3.1.
In case the EE receives a CA certificate in the caPubs field for In case the EE receives a CA certificate in the caPubs field for
installation as a new trust anchor, it MUST properly authenticate the installation as a new trust anchor, it MUST properly authenticate the
message and authorize the sender as trusted source of the new trust message and authorize the sender as trusted source of the new trust
anchor. This authorization is typically indicated using shared anchor. This authorization is typically indicated using shared
secret information for protecting an initialization response (ir) secret information for protecting an initialization response (ir)
message. Authorization can also be signature-based using a message. Authorization can also be signature-based using a
certificate issued by another PKI that is explicitly authorized for certificate issued by another PKI that is explicitly authorized for
this purpose. A certificate received in caPubs MUST NOT be accepted this purpose. A certificate received in caPubs MUST NOT be accepted
as trust anchor if the CMP message has been protected using a as a trust anchor if it is the root CA certificate of the certificate
certificate issued by this same CA or one of its subordinate CAs. used for protecting the message.
4.1.1. Requesting a certificate from a new PKI with signature-based 4.1.1. Requesting a certificate from a new PKI with signature-based
protection protection
This PKI management operation should be used by an EE to request a This PKI management operation should be used by an EE to request a
certificate from a new PKI using an existing certificate from an certificate from a new PKI using an existing certificate from an
external PKI, e.g., a manufacturer-issued IDevID certificate external PKI, e.g., a manufacturer-issued IDevID certificate
[IEEE.802.1AR_2018], to authenticate itself to the new PKI. [IEEE.802.1AR_2018], to authenticate itself to the new PKI.
Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI)
skipping to change at page 34, line 14 skipping to change at page 34, line 14
For this PKI management operation, the EE MUST include exactly one For this PKI management operation, the EE MUST include exactly one
CertReqMsg in the ir. If more certificates are required, further CertReqMsg in the ir. If more certificates are required, further
requests MUST be sent using separate PKI management operation. If requests MUST be sent using separate PKI management operation. If
the EE wants to omit sending a certificate confirmation message after the EE wants to omit sending a certificate confirmation message after
receiving the ip, e.g., to reduce the number of protocol messages receiving the ip, e.g., to reduce the number of protocol messages
exchanged in this PKI management operation, it MUST request this by exchanged in this PKI management operation, it MUST request this by
including the implicitConfirm extension in the header of the ir including the implicitConfirm extension in the header of the ir
message, see Section 3.1. message, see Section 3.1.
If the EE did not request implicit confirmation or timplicit If the EE did not request implicit confirmation or implicit
confirmation was not granted by the PKI management entity, confirmation was not granted by the PKI management entity,
certificate confirmation MUST be performed as follows. If the EE certificate confirmation MUST be performed as follows. If the EE
successfully received the certificate, it MUST send a certConf successfully received the certificate, it MUST send a certConf
message in due time. On receiving a valid certConf message, the PKI message in due time. On receiving a valid certConf message, the PKI
management entity MUST respond with a pkiConf message. If the PKI management entity MUST respond with a pkiConf message. If the PKI
management entity does not receive the expected certConf message in management entity does not receive the expected certConf message in
time it MUST handle this like a rejection by the EE. In case of time it MUST handle this like a rejection by the EE. In case of
rejection the PKI management entity SHALL terminate the PKI rejection the PKI management entity SHALL terminate the PKI
management operation, and the PKI MAY revoke the newly issued management operation, and the PKI MAY revoke the newly issued
certificate. certificate.
skipping to change at page 49, line 19 skipping to change at page 49, line 19
The detailed description of the KeyAgreeRecipientInfo structure looks The detailed description of the KeyAgreeRecipientInfo structure looks
like this: like this:
kari REQUIRED kari REQUIRED
-- MUST be a KeyAgreeRecipientInfo as specified in CMS Section -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section
-- 6.2.2 [RFC5652] -- 6.2.2 [RFC5652]
version REQUIRED version REQUIRED
-- MUST be 3 -- MUST be 3
originator REQUIRED originator REQUIRED
-- MUST contain the originatorKey choice -- MUST contain the subjectKeyIdentifier of the certificate,
algorithm REQUIRED -- and thereby identifies the sender's public key.
-- MUST be the algorithm identifier of the key agreement -- MUST contain the same value as the senderKID in the
-- algorithm -- message header
-- The algorithm type MUST be a KM_KA_ALG as specified in
-- RFC-CMP-Alg Section 4.1
publicKey REQUIRED
-- MUST be the ephemeral public key of the sending party
ukm RECOMMENDED ukm RECOMMENDED
-- MUST be used when 1-pass ECMQV is used -- MUST be used when 1-pass ECMQV is used
-- SHOULD be present to ensure uniqueness of the key -- SHOULD be present to ensure uniqueness of the key
-- encryption key, see [RFC8419] -- encryption key
keyEncryptionAlgorithm keyEncryptionAlgorithm
REQUIRED REQUIRED
-- MUST be the algorithm identifier of the key wrap algorithm -- MUST be the algorithm identifier of the key agreement
-- algorithm
-- The algorithm type MUST be a KM_KA_ALG as specified in
-- RFC-CMP-Alg Section 4.1
-- The parameters field of the key agreement algorithm MUST
-- contains the key wrap algorithm
-- The algorithm type MUST be a KM_KW_ALG as specified in -- The algorithm type MUST be a KM_KW_ALG as specified in
-- RFC-CMP-Alg Section 4.3 -- RFC-CMP-Alg Section 4.3
recipientEncryptedKeys recipientEncryptedKeys
REQUIRED REQUIRED
-- MUST contain exactly one RecipientEncryptedKey element -- MUST contain exactly one RecipientEncryptedKey element
rid REQUIRED rid REQUIRED
-- MUST contain the rKeyId choice -- MUST contain the rKeyId choice
rKeyId REQUIRED rKeyId REQUIRED
subjectKeyIdentifier subjectKeyIdentifier
REQUIRED REQUIRED
skipping to change at page 51, line 8 skipping to change at page 51, line 8
CMP messages. The shared secret information used for the MAC-based CMP messages. The shared secret information used for the MAC-based
protection MUST also be used for the encryption of the content- protection MUST also be used for the encryption of the content-
encryption key but with a different salt value applied in the key encryption key but with a different salt value applied in the key
derivation algorithm. For this key management technique, the derivation algorithm. For this key management technique, the
PasswordRecipientInfo structure MUST be used in the contentInfo PasswordRecipientInfo structure MUST be used in the contentInfo
field. field.
Note: The entropy of the shared secret information is crucial for the Note: The entropy of the shared secret information is crucial for the
level of protection when using a password-based key management level of protection when using a password-based key management
technique. For centrally generated key pairs, the entropy of the technique. For centrally generated key pairs, the entropy of the
shared secret information SHALL not be less than the security shared secret information SHALL NOT be less than the security
strength of the centrally generated key pair. Further guidance is strength of the centrally generated key pair. Further guidance is
available in Section 8. available in Section 8.
The PasswordRecipientInfo structure included into the EnvelopedData The PasswordRecipientInfo structure included into the EnvelopedData
structure is specified in CMS Section 6.2.4 [RFC5652]. structure is specified in CMS Section 6.2.4 [RFC5652].
The detailed description of the PasswordRecipientInfo structure looks The detailed description of the PasswordRecipientInfo structure looks
like this: like this:
pwri REQUIRED pwri REQUIRED
skipping to change at page 57, line 7 skipping to change at page 57, line 7
-- MUST be a sequence of CMPCertificate -- MUST be a sequence of CMPCertificate
4.3.2. Get root CA certificate update 4.3.2. Get root CA certificate update
This PKI management operation can be used by an EE to request an This PKI management operation can be used by an EE to request an
updated root CA Certificate as described in Section 4.4 of RFC 4210 updated root CA Certificate as described in Section 4.4 of RFC 4210
[RFC4210]. [RFC4210].
An EE requests an update of a root CA certificate from the PKI An EE requests an update of a root CA certificate from the PKI
management entity by sending a general message with OID id-it- management entity by sending a general message with OID id-it-
oldTrustAnchor, which SHOULD include this root CA certificate in the rootCaCert, which SHOULD include the old root CA certificate in the
message body, as specified in CMP Updates message body, as specified in CMP Updates
[I-D.ietf-lamps-cmp-updates]. Optionally, the trust anchor MAY be [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds
provided as public key only. The PKI management entity responds with with a general response with OID id-it-rootCaKeyUpdate that either
a general response with the same OID that either contains the update contains the update of the root CA certificate consisting of up to
of the root CA certificate consisting of up to three certificates, or three certificates, or with no content in case no update is
with no content in case no update is available. available.
Note: This mechanism can also be used in case the trust anchor to be Note: This mechanism may also be used to update trusted non-root
updated is not provided as a self-signed certificate, but, e.g., as a certificates, i.e., trusted intermediate CA or issuing CA
certificate issued by a different CA. certificates.
The newWithNew certificate is the new root CA certificate and is The newWithNew certificate is the new root CA certificate and is
REQUIRED to be present if available. The newWithOld certificate is REQUIRED to be present if available. The newWithOld certificate is
REQUIRED to be present in the response message because it is needed REQUIRED to be present in the response message because it is needed
for the receiving entity trusting the old root CA certificate to gain for the receiving entity trusting the old root CA certificate to gain
trust in the new root CA certificate. The oldWithNew certificate is trust in the new root CA certificate. The oldWithNew certificate is
OPTIONAL because it is only needed in rare scenarios where entities OPTIONAL because it is only needed in rare scenarios where entities
do not already trust the old root CA. do not already trust the old root CA.
No specific prerequisites apply in addition to those specified in No specific prerequisites apply in addition to those specified in
Section 3.4. Section 3.4.
The message sequence for this PKI management operation is as given The message sequence for this PKI management operation is as given
above, with the following specific content: above, with the following specific content:
1 the infoType OID to use is id-it-oldTrustAnchor in the request and 1 the infoType OID to use is id-it-rootCaCert in the request and id-
id-it-trustAnchorUpdate in the response it-rootCaKeyUpdate in the response
2 the infoValue of the request MUST be an OldTrustAnchor structure 2 the infoValue of the request SHOULD contain the root CA
referencing the trust anchor the update is requested for certificate the update is requested for
3 if present, the infoValue of the response MUST be a 3 if present, the infoValue of the response MUST be a
TrustAnchorUpdate structure RootCaKeyUpdateContent structure
The infoValue field of the general request containing the id-it- The infoValue field of the general request containing the id-it-
oldTrustAnchor OID looks like this: rootCaCert OID looks like this:
infoValue RECOMMENDED infoValue RECOMMENDED
-- MUST contain an OldTrustAnchor structure referencing the -- MUST contain the root CA certificate to be updated, if
-- trust anchor to be updated -- available
-- SHOULD be the root CA certificate, if available
-- MAY be the publicKey of the trust anchor otherwise
The infoValue field of the general response containing the id-it- The infoValue field of the general response containing the id-it-
trustAnchorUpdate OID looks like this: rootCaKeyUpdate OID 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 and MUST be of type TrustAnchorUpdate -- is available and MUST be of type RootCaKeyUpdateContent
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
newWithOld REQUIRED newWithOld REQUIRED
-- MUST be present if infoValue is present -- MUST be present if infoValue is present
-- MUST contain a certificate containing the new public -- MUST contain a certificate containing the new public
-- root CA key signed with the old private root CA key -- root CA key signed with the old private root CA key
oldWithNew OPTIONAL oldWithNew OPTIONAL
-- MAY be present if infoValue is present -- MAY be present if infoValue is present
-- MUST contain a certificate containing the old public -- MUST contain a certificate containing the old public
skipping to change at page 85, line 8 skipping to change at page 85, line 8
We thank the various reviewers of this document. We thank the various reviewers of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cmpv2-coap-transport] [I-D.ietf-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transfer for the Sahni, M. and S. Tripathi, "CoAP Transfer for the
Certificate Management Protocol", Work in Progress, Certificate Management Protocol", Work in Progress,
Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-03, 1 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8
October 2021, <https://datatracker.ietf.org/doc/html/ November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-ace-cmpv2-coap-transport-03>. draft-ietf-ace-cmpv2-coap-transport-04>.
[I-D.ietf-lamps-cmp-algorithms] [I-D.ietf-lamps-cmp-algorithms]
Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms", Work "Certificate Management Protocol (CMP) Algorithms", Work
in Progress, Internet-Draft, draft-ietf-lamps-cmp- in Progress, Internet-Draft, draft-ietf-lamps-cmp-
algorithms-07, 22 August 2021, algorithms-08, 17 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-algorithms-07>. cmp-algorithms-08>.
[I-D.ietf-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H. and D. V. Oheimb, "Certificate Management Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
Protocol (CMP) Updates", Work in Progress, Internet-Draft, Management Protocol (CMP) Updates", Work in Progress,
draft-ietf-lamps-cmp-updates-12, 9 July 2021, Internet-Draft, draft-ietf-lamps-cmp-updates-13, 25
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- October 2021, <https://datatracker.ietf.org/doc/html/
cmp-updates-12>. draft-ietf-lamps-cmp-updates-13>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
skipping to change at page 87, line 16 skipping to change at page 87, line 16
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, Progress, Internet-Draft, draft-ietf-anima-brski-prm-00,
25 October 2021, <https://datatracker.ietf.org/doc/html/ 25 October 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-00>. draft-ietf-anima-brski-prm-00>.
[I-D.ietf-netconf-sztp-csr] [I-D.ietf-netconf-sztp-csr]
Watsen, K., Housley, R., and S. Turner, "Conveying a Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-09, Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-11,
22 October 2021, <https://datatracker.ietf.org/doc/html/ 8 November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-09>. draft-ietf-netconf-sztp-csr-11>.
[IEC.62443-3-3] [IEC.62443-3-3]
IEC, "Industrial communication networks - Network and IEC, "Industrial communication networks - Network and
system security - Part 3-3: System security requirements system security - Part 3-3: System security requirements
and security levels", IEC 62443-3-3, August 2013, and security levels", IEC 62443-3-3, August 2013,
<https://webstore.iec.ch/publication/7033>. <https://webstore.iec.ch/publication/7033>.
[IEEE.802.1AR_2018] [IEEE.802.1AR_2018]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", IEEE 802.1AR-2018, networks - Secure Device Identity", IEEE 802.1AR-2018,
skipping to change at page 91, line 12 skipping to change at page 91, line 12
} }
} }
} }
Appendix B. History of changes Appendix B. History of changes
Note: This appendix will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
From version 07 -> 08:
* Updates Section 4.1.6.1. regarding content of the originator and
keyEncryptionAlgorithm fields (see thread "AD review of draft-
ietf-lamps-cmp-algorithms-07")
* Rolled back part of the changes on root CA certificate updates in
Section 4.3.2 (see thread "Allocation of OIDs for CRL update
retrieval (draft-ietf-lamps-cmp-updates-13)")
From version 06 -> 07: From version 06 -> 07:
* Added references to [draft-ietf-netconf-sztp-csr] in new * Added references to [draft-ietf-netconf-sztp-csr] in new
Section 1.5 and Section 4.1.4 Section 1.5 and Section 4.1.4
* Added reference to [I-D.ietf-anima-brski-async-enroll] in new * Added reference to [I-D.ietf-anima-brski-async-enroll] in new
Section 1.5 and Section 4.1.1 Section 1.5 and Section 4.1.1
* Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as * Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as
the PUSH use case is continued to be discussed in this draft after the PUSH use case is continued to be discussed in this draft after
the split of BRSKI-AE the split of BRSKI-AE
* Improved note regarding UNISIG Subset-137 in Section 1.6 * Improved note regarding UNISIG Subset-137 in Section 1.6
skipping to change at page 95, line 45 skipping to change at page 96, line 12
document. document.
* Further minor changes in wording. * Further minor changes in wording.
Authors' Addresses Authors' Addresses
Hendrik Brockhaus (editor) Hendrik Brockhaus (editor)
Siemens AG Siemens AG
Email: hendrik.brockhaus@siemens.com Email: hendrik.brockhaus@siemens.com
Steffen Fries
Siemens AG
Email: steffen.fries@siemens.com
David von Oheimb David von Oheimb
Siemens AG Siemens AG
Email: david.von.oheimb@siemens.com Email: david.von.oheimb@siemens.com
Steffen Fries
Siemens AG
Email: steffen.fries@siemens.com
 End of changes. 41 change blocks. 
76 lines changed or deleted 80 lines changed or added

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